Application Lifecycle Management and a Collaborative Culture.
I had some interesting discussion last week about working together and ALM, based on what I wrote in this post Visual Studio Team System 2010 – Episode 3: The Lifecycle;
Tools can help with this goal. Having gear in place which supports and stimulates collaboration is a driver for a successful Application Lifecycle Management. But without a plan, how people should collaborate and communicate, tools are useless.
Now I’m not a Team Dynamics nor a behavioral specialist. But, I did some investigation according these topics past year for the Cloud Collaboration Book we have written.
A big word in the Book TagCloud is ‘Collaboration’ [made by wordle.net]
So, I thought [also as a trigger for the book :-) available on Amazon somewhere in March] let’s take the intro of the chapter which talks about this. The topics and main concerns fit perfectly on ALM culture.
Creating new modes of collaboration supported by technology can only be done by addressing the human aspect. More specifically, we need to address some of the worries and obstacles people encounter when collaborating using technology.
The three most important concerns are:
Trust. Trust is a condition for social interaction. People will only work with people, companies, tools and information they know they can trust. Before we can expect collaboration to take off online, there must be a way for people to get this “trust.” And a topic closely associated with trust when it refers to people is Identity.
Collaborative culture. If one individual is the greatest collaborator in the world, he or she is probably not getting anywhere. Only when all people involved are part of the same collaborative culture will new levels of creativity and productivity be reached. A collaborative culture consists of many things, including:
- Collaborative leadership;
- Shared goals;
- Shared model of the truth; and
- Rules or norms.
Reward. Changing the way people work takes effort, so it must be clear for the parties involved what they will gain, at a personal level, from collaborating in a new way. Surprisingly, a “reward” for successful collaboration is most often of a non-financial nature.
“The ways that people work together shift over time, which can affect your culture of collaboration. More important, the introduction of collaboration technologies can also change the culture of collaboration. If handled properly, the tools and the culture will coevolve.”
Dennis Kennedy
Microsoft-applicatieplatform congress
One more congress where I speak…
Track C on the second day is the VSTS2010 track, that's where we [Marcel, Pieter and I] are speaking about VTS 2010.
http://www.microsoft.com/netherlands/evenementen/apo/hetcongres.aspx
Dutch-Information-Worker-User-Group Presentation.
TagCloud of my presentation for this evening at DIWUG… Serge is the other speaker and is going to speak about MS-Online.
Its also the TagCloud from the book we have written, will be available with in weeks…
April 9th 2009: Knowing Your Enemy. OWASP Meeting at Sogeti Netherlands
April 9th 2008: Knowing Your Enemy
If you want to attend, please send a email to OWASP@irc2.nI
18.30 - 19:00 Introduction, OWASP organization, projects, sponsor
19.00 - 19.45 Modern information gathering; how to abuse search engines by Dave van Stem
Great generals already know the key to success is "knowing your enemy". In hacking terms this is called information gathering, fingerprinting or reconnaissance. Traditionally this phase consisted of using public records like WHOIS and DNS combined with active scans on servers. With the rise of advanced search engines like Yahoo, Live Search and Google a whole new type of reconnaissance has come to live; passive reconnaissance. Often servers are not properly configured which causes lots of valuable information to become available without accessing the server at all. Recently several hacker-tools appeared which use the full capabilities of these search engines giving hackers a head-start at mapping the network they plan to attack. The goal of this session is to give insight in the methods and tools hackers have at their disposal to gather information about systems they plan to attack without accessing the system itself. Dave van Stein has close to 8 years of experience in software testing. Since the beginning of 2008 he’s working for ps_testware as a web application security testing specialist.
19.45 – 20.00 VAC Cross-site scripting by Martin Visser
Martin Visser is a software designer with Sogeti Nederland B.V. specialized in secure application development with Microsoft technologies. He has experience with Microsoft server technologies like ASP.NET, SharePoint and Biztalk. Martin also developed and teaches a 2-day "Application Security – Microsoft development" course both within and outside Sogeti.
20.00 – 20.15 Break
20.15 – 21.00 Beveiligingsaspecten van webapplicatie-ontwikkeling Wouter van Kuipers
Het ontwikkelen van webapplicaties verschilt op verschillende aspecten met het ontwikkelen van desktop applicaties, met name op het gebied van security. Voor grote bedrijven zijn er oplossingen beschikbaar als bijvoorbeeld SDL, maar voor het midden- en kleinbedrijf zijn dit soort oplossingen beperkt, omdat zij vaak niet de middelen hebben om dergelijke strategieën uit te kunnen voeren. Voor mijn scriptie heb ik middels een literatuuronderzoek, interviews met ontwikkelaars en een onderzoek naar Fortify 360 gekeken hoe het midden- en kleinbedrijf omgaat met deze verschillen en hoe zij het ontwikkelproces kunnen optimaliseren op het gebied van security.
Na een MBO opleiding in de IT is Wouter Kuipers via de HBO opleiding 'Communicatie Systemen' begin 2007 begonnen met een master Informatiekunde aan de Radboud Universiteit Nijmegen, welke hij in maart dit jaar hoopt af te ronden. Tijdens zijn MBO studie is zijn interesse in het ontwikkelen van webapplicaties gewekt, wat in 2003 resulteerde in het opzetten van een eigen web-development bedrijf. Dit bedrijf is met name gespecialiseerd in het ontwikkelen van webapplicaties op maat, en het ondersteunen van bedrijven op het gebied van web-developement op freelance basis.
Location:
Sogeti NederLand B.V.
Lange Dreef 17
4131 NJ Vianen
If you want to attend, please send a email to OWASP@irc2.nI
Visual Studio Team System 2010 – Episode 3: The Lifecycle
Previous episodes:
In the last episode Rob talked about the main challenges of testing, and not only for the acceptance tester but all the roles who are responsible for the quality of the product and that's actually everybody.
No Risk- No Test… what needs to be tested, when there is no business risk there is no reason to test, no reason to make unit tests by the developer, no reason to make regression tests and no reason to do acceptance testing. But when there is a risk every role has the goal of making that risk as small as possible. There is a joined effort in execution of tests to prove that the risk is minimized or solved. The development testers, system integration testers and acceptance testers together have to make a strategy on how to test.
Application Lifecycle Management
When talking about Application Lifecycle Management [ALM] terms like accountability, governance and compliance are used. All of them refer back to “working together”, how do we work together during the application lifecycle. ALM is not about tools, it’s about working together. Working together seamless and flexible while staying in control, being measurable and responsible. All the roles in the application lifecycle have a part in this collaboration effort. Tools can help but isn’t’ the core driver.
There are lots of examples of wrong interpreted business requirements, miss communication between development en test [Rob describes a very real example], applications which won’t run in production, operations who don’t understand the applications. All of them resulting in more work, more faults, more costs or even only costs and no application because the project was unplugged. Most of these projects faults, these extra costs are a slip in communication.
Having a strategy how people have to collaborate within the lifecycle is one important piece of Application Lifecycle Management. Most organizational parts have already some kind of process / methodology in place. Having an approach how to share information and share ideas from their own role point of view through the other roles is a key success factor for lowering the costs and raise the business value of IT investments.
Tools can help with this goal. Having gear in place which supports and stimulates collaboration is a driver for a successful Application Lifecycle Management. But without a plan, how people should collaborate and communicate, tools are useless.
Before ALM…
In the early ages, the waterfall ages, nobody talked about Application Lifecycle Management. Software development was still in his youth, experimenting with proven processes from the industrial age. The era where Taylor educated managers controlled the workforce. Business people writing down what they want [not knowing what they need] and throwing their needs over the wall to the workforce.
There was no communication between the guy who needed the software and the guy who implemented the software, a massive brick wall separated them. All the roles in the Application Lifecycle did their job between walls. People where used to this formal way of working, not arguing, not discussing about the solution, be doing their job as optimal as possible.
It doesn’t need any explanation that this Taylor way of work didn’t work for software development. Some software projects succeeded but many more failed to reach the goal. The main reason why all those projects fail: there was no sharing of ideas, ideas how to achieve business value. Everybody was working in his own domain with their own specific tools, as shown in the picture below, everybody on his own island with his own specific tools, practices and methodologies.
Software development is way different than producing products [Taylor’s theory is about optimizing the work force, something Ford did very well]. Software development needs a shared effort, a shared effort by all the roles in the lifecycle. From the people who have the business ideas and knowledge to the people who have to implement, test and maintain the final solution. Everybody in the lifecycle needs to collaborate with each other. Everybody needs to add their specific knowledge to the solution, that's not the same as adding parts to a car.
It’s interesting to notice that when there are no guidelines / structure in place, and nothing is done to stimulate collaboration. People and groups of same interest starting building their own walls, building their own kingdoms, protecting their environment. So, if we want to change this cubicle way of working, management buy-in needs to be in place, groups aren’t going to collaborate automatically.
Now
Nowadays, everybody understands that communication is king. Roles in the lifecycle need to communicate, need to listen to each other and share ideas about their view on the solution. The Agile methodology gives guidelines and structure , with valuable principles like:
-
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Business people and developers must work together daily throughout the project.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- The best architectures, requirements, and designs emerge from self-organizing teams.
Tooling starts to support these principles [and the other 17] adopting a new way of communicative work around the Application Lifecycle. In 2005 Visual Studio Team System starts to support these principles. The integrated development environment got supported by Team Foundation Server with workitems, process templates and reports, helping to get roles in the lifecycle to communicate in a more efficient manner. Integrated in one tool people can share their workload and workprocesses, giving the project leader and for sure the other roles the ability to have more control over the process of software development, by knowing what the other one is doing.
Telling each other what you are doing is challenging. It’s challenging within a group of people with the same interest, it’s even more challenging between groups of different interests. It’s a culture challenge to get it working. Everybody knows it’s valuable, but most don’t want to give someone else a look in his kitchen. It’s valuable because it give transparency, agreements are known, even if someone is working according to this agreement and people can more easily get in sync. Everybody gets the focus on the business target.
[A dependency diagram of RUP’s process components.]
That people need to work together on a process and workitem level isn’t that strange when we look at the above image. This is a visualization of the degree of coupling between different process elements in the RUP methodology. …A Rational Unified Process (RUP) Plug-in To Support Requirements Quality Assurance [pdf]
The figure shows, that there is a very high coupling for approximately one third of all process components. 21 process components have a coupling less than 25%, 8 process components have a coupling of more than 25% and 3 process components more than 40%.
It’s interesting to notice that the adoption of workitems and processtemplates, although they are valuable, within companies fail. The main reason is the culture of the organization and management which doesn’t fully supports communication. This cultural aspect of communication between different roles, different social groups, should have a main focus while implementing Visual Studio Team System, otherwise success isn’t guaranteed.
This is also recognized by agile gurus like Scott Ambler who is writing in his blog:
Your existing culture and organization can really hinder your ability to scale agile approaches,
In his book “Agile Database techniques” he talks about The Cultural Impedance Mismatch between Data Professionals and Application Developers, discussing the cultural problems according to the communication between database people and code ‘object oriented’ people.
Overcoming the cultural impedance mismatch is much more difficult than overcoming the technical impedance mismatch. [The Cultural Impedance Mismatch Between Data Professionals and Application Developers]
The collaboration starts
While VSTS 2005 and 2008 support communication at a workitem level, the 2010 version of Visual Studio is going to support collaboration at artifact level. Different roles in the lifecycle work together on artifacts. Each of them adds their knowledge, vision and ideas to the solution from their view point. These artifacts are accessible by every role in every phase of the project, adding value throughout the lifecycle.
People are enabled to collaborate, making applications together, and not only by telling what they are doing but most important by working seamless together on the application.
While working together with all the roles and having these ‘ALM’ artifacts accessible for every role, collaboration in the application lifecycle will rise to the next level. People with different social and cultural characters start discussing solutions, trigger each other to improve and being innovative with their view on the application and all within the constraints of their role.
VSTS 2010 enables people to collaborate on artifacts in the Application Lifecycle. While the 2005 and 2008 versions mainly focus on communicating about work [workitems , processes and reports]. With VSTS 2010 the focus moves on to collaboration on artifacts. The main reason this is going to be possible is the investment by Microsoft in the Architecture Edition and Test Edition, widening the scope from developer to more roles in the lifecycle.
Not only development artifacts like source code can be saved to a repository but also test artifacts like test cases and test results. they can also be saved to the same repository, creating the possibility to work together on these artifacts from the same repository.
Testing in the Lifecycle
To figure out how this all works with testing we need a deep dive in the different test roles, what they do, what way they work together with the other team members and what kind of capabilities they need from the tools they use. Rob already talked about the different test roles “developers who are testing, specialist testers during system testing or generalist testers during the final acceptance test”. How do all these test roles work together with for example the business to capture risks of the system?
In the next episodes we will discuss these different test practices what they patterns are and the capabilities the need from tools.
Visual Studio Team System 2010 – Episode 1: A Focus on Testing
An intro from the VSTS 2010 data sheet:
[VSTS 2010 new functionality focuses on the architect, designer and test rolls in the Application Lifecycle]
This series will focus on the test roll; which flavors are there, what do they do, what are their goals, what do they do to reach that goal, how do they collaborate with other rolls and in what way does VSTS 2010 support their activities.
In what way can a collaborative effort in test activities support the business goal? Visual Studio Test Edition offers several new possibilities according to testing in the lifecycle and with the interaction between the tester and the other rolls in the lifecycle.
[Tests in the Lifecycle]
In the early and current edition of Visual Studio Team Test there are already several testing features available, helping the developer with test driven development, performance testing, load testing and several more [see this MSDN page].
While the current version of the Test Edition focuses on the roll of the tester and their activities, Visual Studio Team System 2010 is focused on the collaborative effort between the tester and the other rolls in the application lifecycle.
[Camano, VSTS2010 Acceptance Test Tool]
The most visible feature is Camano, a standalone acceptance test tool. This tool connects with Team Foundation Server and the newly introduced workitemtype ‘test case’. Workitems aren’t the only integration with the rest of the lifecycle, Camano also create automation strips which can be used during the ‘readiness scan’ [the system / integration test phase of the lifecycle]. Both possibilities of Team Test give the tester a stronger connection, a better collaboration with development. Another addition which stimulates the collaboration is Lab Management [see this screencast on Channel9]:
…lab management, which leverages virtualization to enable software development and test teams to build higher quality apps. Lab management accelerates setup/tear down time and eliminates no-repro bugs by creating better integration across dev and test teams throughout the application lifecycle.
[Lab Management]
These new capabilities will help fixing some major challenges in product development, they will save time and improve the quality of the overall product. Analyzing and fixing a bug is, without doubt, a loss of time. And the later the bug is found, the greater are the losses. Finding bugs AEAP (As Early As Possibly) becomes more and more important, especially in the complex systems we make nowadays. The joined knowledge together with integrated tooling of the developer, the tester and the architect/designer can help with this challenge. But, having tooling in place which help the tester to their job more efficient isn’t enough for a good test process. Testers can still just test one button, one screen or even the wrong functionality or do it the monkey way.
[Monkey Testing]
How good is your test process? This seemingly easy question turns out to be very hard to answer in reality. Testing is often experienced as a troublesome and uncontrollable process. Testing takes too much time, costs a lot more than planned, and offers insufficient insight in the quality of the test process and, therefore, the quality of the information system under test and the risks for the business process itself.
The Test Process Improvement (TPI®)-model offers insight in the 'maturity' of test processes within your organization. Based on this understanding the model helps to define gradual and controllable improvement steps.
[TPI® levels mapped on IO model]
Collaborative, efficient tooling together with a mature structured test approach will not only result in better quality software but also gives the Application Lifecycle a way to improve the software delivery process. The responsibility of testers is not only finding bugs, but also to initiate learning cycles. They know where things go wrong.
In the next episode Rob will guide us through the world of testing…