issue 3 - Agile Record

The Magazine for Agile Developers and Agile Testers

July 2010

www.agilerecord.com © Val Thoermer - Fotolia.com

free digital version

made in Germany

issue 3

© iStockphoto/Yuri_Arcurs

online training English & German (Foundation)

ISTQB® Certified Tester Foundation Level ISTQB® Certified Tester Advanced Level Test Manager

Our company saves up to

60% of training costs by online training. The obtained knowledge and the savings ensure the competitiveness of our company.

www.te-trainings-shop.com

2

www.agilerecord.com

Editorial Dear readers, we are very happy with the response of the market. We are on the right track for success with the Agile Record. Thank you to all of you who support and spread the links to your interested contacts. We need the community to succeed. We need you not only to read the magazine, but also to write articles to inform, to share knowledge or just to give your opinion. We have seen and still see that there is a lot to learn and to share. Agile is getting more and more popular and the new members of the community are happy about the transfer medium Agile Record. In our conference “Testing & Finance” in Bad Homburg, Germany, Nitin Bhargava, Head of Quality Services at Barclays, held a keynote and told that around 25% of the projects run by Barclays are already done by agile methods. Amazing! He pointed out that they figured out that it is not that easy to run these projects using outsourced forces and that’s why they started to run it by local teams. I don’t know if this means that test outsourcing is on the way out, maybe not, but for sure in the way of transforming. I think that outsourcing will happen as a complete service. I mean development and testing for agile projects in one go. If you have experience with that, please send me an article on it. I also spoke with one of the biggest software and system service companies for banks. They told me that they just run small projects in Agile. As soon as one project has too much interfaces/interferences from other projects expecting results and so on, it is for them impossible to control the interchange gates to determinate dates. I don’t know if any of you have some experience with that, but we are happy about any article discussing experiences with those kind of projects. We are facing the Agile Testing Days in Berlin. We are happy to see that many of you are using the early bird. Please be aware that there are only 20 places for each tutorial. First come first served! The conference hotel has only a capacity of 170 rooms. If you want to be there and not in another hotel next to it, then book there soon. The Oz Agile Days in Sydney are organized together with Planit Ltd. The call for papers is over and we will present the Program in a few days. Please inform your contacts down under. Australia, we are on the way to you! The Belgium Testing Days are going to be quite Agile and we are in the planning. Save the dates Feb 14–16, 2011. Last but not least, I want to thank all the authors for the great articles and the supporting companies for their ads. Thanks! Looking forward to hearing from you. Enjoy reading

José Díaz P.S. Don’t be sad when Spain wins the World Cup!!

www.agilerecord.com

3

Contents Editorial  3 Keep it simple – Seven rules of thumb for effective software development  6 by Remi-Armand Collaris & Eef Dekker Problem Solving Through Pair Programming  10 by Paul Pagel What Really Happened  12 by Catherine Powell Agile Testing Between Theory and Practice  14 by Sara Medhat Value-Driven Development Principles and Values – Agility is the Tool, Not the Master  18 by Tom Gilb Things I’ve Learned … the Hard Way  26 by Alex Rosiu The Art of Throw-Away Test Automation  28 by George Wilson Test Automation in Agile Environments  31 by Mallika Singh The Visionary Story Teller  37 by Geert Bossuyt The Agile Bible  40 by Simon Romans Task Boards and Caution Signs!!  49 by Sowmya Karunakaran SCRUM & Testing: Assessing the risks  52 by Erik van Veenendaal Skills for SCRUM Agile Teams  55 by Prasad Prabhakaran Dangers Lurking in Tasks and Breakdowns  58 by Alexander Tarnowski Significance of Tools in Agile Software Development  61 by Chaitanya Sudha Nakka The Abilene Paradox and Team Collaboration  66 by Badri N Srinivasan Masthead  69 Index Of Advertisers  69

4

www.agilerecord.com

Es gibt nur einen Weg zum Glück.

© Alexander Maier - Fotolia.com

Keep it simple – Seven rules of thumb for effective software development by Remi-Armand Collaris & Eef Dekker

Introduction An important question with respect to implementing a software development method is how to concretize the method in the organization and the project which it should serve. This step is easily forgotten in introducing and applying a new method, and it is easy to slip into the habit of regarding a full and clean application of a method as a goal in itself. Many development methods (DSDM, Scrum, XP) presuppose this concretization step without making it explicit. In the Rational Unified Process (RUP), this step is explicit in its first key principle: “Adapt the Process”. It is by no means an easy step, since knowledge of and experience with the method is needed. Which rules could you use in performing this step? How do you get to a clear and concrete development process that optimally supports your project? Which tools do you apply and who will use them? Below we have listed a few situations, in which this step should have been taken more consciously: 1. An enterprise bought an expensive tool but did not anticipate the large amounts of time it costs to implement it and keep it up-to-date. This results in the tool remaining unused. 2. Review forms are developed, but it takes so much time to fill them in that everyone avoids reviewing. 3. RUP defines 128 work products. It is decided that all need to be created. This results in the project coming to a complete standstill. 4. The project needs to be finished quickly, so a large development team is rolled out, but the demanding organization cannot supply sufficient input to the team. 5. The change procedure takes 3 months at least. This leads to a large part of the changes not being relevant anymore by the time they are finally implemented. 6. People responsible for requirements are not available during system implementation, and therefore the system does not comply with the customer’s needs.

6

www.agilerecord.com

7. A lot of time was invested in keeping an up-to-date traceability between requirements and code, but estimation of changes does not appear to be any quicker. In this article, we provide seven rules of thumb which help you to make the development method of your choice more effective. These rules were developed during our experiences in various enterprises, in which we helped to implement modern development methods. Following these rules will help to avoid the situations described above. Seven Rules of Thumb All rules presented here follow the same principle: balance cost and revenues. A measure (document, procedure, application or a tool) is effective if it yields the correct effect, i.e. an optimal balance of costs and revenues. Costs and revenues not only apply to the period of software development, but to the complete lifecycle of the application and to the context within which the application is developed and used. An important question in this respect is what the expected lifetime of the application is and how many changes are expected. We often see people being so enthusiastic about the expected revenues that they lose sight of the costs. Or the other way around: because of the costs, a “smart” solution is not chosen, although in the long run the revenues would have outweighed the costs. Costs or revenues in themselves are not the criterion for a good decision, but the balance of both is. Rule 1: Keep the level of ceremony as low as possible The level of ceremony can be defined as the amount of additions to the development process for the sake of controlling the process and its resulting work products. A higher level of ceremony implies more formal recording, review and approval and often more work products, procedure descriptions and more detailed means of control.

Every organization knows its own “ceremonies”. Usually the bigger the organization, the more formal it is. Some examples of lower and higher levels of ceremony are listed in the table below: Lower level of ceremony

Higher level of ceremony

Information is available in a WIKI,

It is explicitly recorded who must

everyone can look there.

be informed, and in what way.

The work products themselves

Minutes of every meeting are

mirror what is agreed upon.

made and formally approved.

Informal exchange of information

Information is usually exchanged in writing.

Quality is acknowledged and as-

There is a Quality Assurance

sured by the team.

department.

Changes can be processed easily.

There is a committee which must approve changes.

Reviews are held informally.

All review results are recorded.

Standards and guidelines are

There are extensive lists of stan-

implicit.

dards and guidelines.

Many organizations are unaware of the costs as well as the revenues of their level of ceremony. Many people see formal reviews, an extensive approval procedure and detailed plans with Gantt charts as simply indispensable. We have found that asking for explicit estimates of costs and revenues helps people to become aware of the amount of overhead brought about by the level of ceremony. Rule 2: Keep the team as small as possible A development team of exactly 1 experienced person who unifies all roles in himself is most efficient in avoiding handovers. However, not only the availability of one person with all knowledge and skills needed prohibits this option, but also development speed (time to market), vulnerability (what happens if this single person gets sick) and safeguarding of knowledge. Adjust the number of team members to the level of input the demand organization can supply on a continuous basis. It does not make much sense to install a team of 3 analysts and 8 developers if the maximum input the key users can supply is only sufficient for Often a 1 analyst and 2 developers.

Rule 3: Make as few work products as possible If you make a list of work products, the questions you need to ask yourself are: • Who will miss this work product? • What will go wrong if we don’t make it? This approach will clarify the purpose of the work product. Will this work product only be needed for development, or will it also play a role in future system administration? By knowing who will need the work product, you can involve this person in producing it, validating its contents and balancing production effort with the expected revenues. The amount of work products for software development depends on the circumstances of the project, as do their specific form and comprehensiveness. If a sketch on a whiteboard suffices, it is not necessary to produce a comprehensive document. Some work products will be part of the final product, for instance because they are needed for system administration or future maintenance and support. If the only thing you deliver is the application, and the demand organization can use and administrate it, that is fine for the short term. This is even more likely if an Agile way of development is applied and all code is accompanied by unit tests and code documentation and kept as simple as possible by refactoring. However, most applications must be maintained long after the original developers are gone. In this case it might be better to have some documentation in place, like use case specifications, a software architecture document and system administration document. Rule 4: Apply the simplest possible approval procedure on as few work products as possible Not all work products need to be approved in a formal way. A similar question as above applies here: • What goes wrong if a work product is not formally approved?

few separate, specialized tools better meet the requirements than a complete integrated toolset.

Moreover, a bigger team does not have a proportionally bigger productivity, due to a larger overhead in planning, handovers and dependencies. It may well be the case that a wellfunctioning team of 3 developers, an architect, an analyst and a tester are more productive than the same team but now enlarged with 3 more developers, an analyst and a tester to meet the timeto-market. If such a scaling operation takes place toward the end of the project to meet the deadline, the net effect will be negative. Many people forget to take into account the learning curve of new team members and the extra overhead.1

If the answer is “nothing”, it is clear that formal approval is not needed. Often the work products that define the scope of the project are candidates for formal approval. Also use case specifications could be approved in order to have a common point of reference for accepting the solution.

Formal approval takes time and energy. On the other hand, it delivers clarity, baselines and reference points. If there is a clear mandate of one person approving a work product, this will simplify the process tremendously. For example, a subject matter expert who has mandate can decide very quickly if a use case specification is correct. He can do the formal acceptance as well. It does not add much value to have a person higher in the management hierarchy accept the use case specification.

www.agilerecord.com

7

Rule 5: Take the simplest toolset that meets your needs It is often underestimated how well requirements and management can be done using only a big whiteboard, brown paper and post-its, a word processor, spreadsheet, simple modeling tool and WIKI. Add more only if there is a very clear need or bottleneck. Be sure that a solution is already proven in practice and that you have a good picture of how it will help you before choosing it. Do not only formulate requirements for a tool, but look at the costs as well. Tools need to be installed, configured and maintained. The time and expertise needed to do this is often underestimated. Formulate tool requirements with concrete improvements in mind, which can be expressed in terms of revenue. If you balance costs (purchase, configuration, maintenance, keeping information up-to-date) against revenues (savings in time), this balance may easily turn out negative. If you have a set of prioritized tool requirements, look at the simplest tools that meet them. Often a few separate, specialized tools better meet the requirements than a complete integrated toolset. Integrated toolsets are inherently complex and may lack the features of specialized tools.

detailing requirements, you gain more insight. High-level requirements formulated (much) earlier might no longer be relevant. Hence, we need human inspection here as well. Maintaining traceability between changing requirements is time-consuming, even when tools are used. A solution using just human inspection might be cheaper. Traceability can be kept implicit in many cases, which is a cheap approach. For example, naming conventions and object-oriented development may help. If something is called ‘dossier’ by the business, then it is a good idea to give the object in the code which represents the dossier the name ‘dossier’ as well. Things you can do in reality with a dossier will then be associated with the dossier in the code. The more perspicuous an application is built, the better the implicit traceability is. The worst scenario is that in which explicit traceability is installed but not kept up-to-date. Outdated information renders the traceability unreliable and hence useless. In this case the investment in traceability has a negative result, since the effort that has been put in does not pay at all. Consider explicit traceability only when its maintenance is guaranteed throughout the application’s lifecycle. Rule 7: Choose the most effective form of communication

Rule 6: Maintain (explicit) traceability as little as possible Traceability may mean two things: there is a connection made between decisions in time, or between work products belonging together in one baseline. The connection may be made explicitly (in a tool or spreadsheet) or implicitly by following design rules or naming conventions. Traceability is often desired because it may help with: • Keeping business requirements, highlevel and detailed software requirements, test cases and implemented functionality in line; • Impact estimation, especially when the original developers are no longer available; • Tracing why certain decisions were made, by whom, and when.

The quicker and better your intentions are understood, the more effective your communication is. The best way to reach this is to have a live conversation and be enabled to visualize your intentions. The worst way is to send a text document without any explanation or possibility to raise questions about it. In the figure below, various communication channels and their effectiveness are shown.

Explicit traceability from high-level to detail software requirements and implemented functionality may be useful, for example in situations in which changed laws or government rules may lead to adaptations in the application. If the right traceability is in place, this may help in estimating the impact of these changes. Keep in mind, however, that traceability can never serve as a substitute for intelligent, human inspection. Traceability may be used to ensure that all high-level requirements are met. While

8

www.agilerecord.com

Figure 1: Effectiveness of communication channels

Do not trust blindly in this figure. Keep in mind how a communication channel is used. In order to convey an intention, a piece of paper on its own is not very effective. If we have a face-to-face conversation, a paper document could, however, be helpful to support the conversation and capture the result for future reference. It then functions as a means to support the “real” communication. Conclusion We have presented seven tested rules of thumb, which can be used to tailor any software development method. They help you to implement an effective development process or to improve an existing process: 1. Keep the level of ceremony as low as possible 2. Keep the team as small as possible 3. Make as few work products as possible 4. Apply the simplest possible approval procedure on as few work products as possible 5. Take the simplest toolset that meets your needs 6. Maintain (explicit) traceability as little as possible 7. Choose the most effective form of communication

Each of these rules supports balancing of costs and revenues. Especially revenues that will show up only in the long run might be hard to quantify, but might be very worthwhile investigating. Making expected revenues explicit gives you a tool for measuring the effectiveness of the measures taken. The results of such a measurement are in turn indispensable for further optimization of your development process. ■ [1] See Frederick P. Brooks Jr., The Mythical Man-Month. Essays on Software Engineering, Anniversary Edition 1995. The insights that Brooks formulated in 1975 are still valid.

> About the authors Remi-Armand Collaris Remi-Armand Collaris is a consultant at Ordina, based in The Netherlands. He has worked for a number of financial, insurance and semi-government institutions. In recent years, his focus shifted from project management to coaching organizations in adopting Agile using RUP and Scrum. An important part of his work at Ordina is contributing to the company’s Agile RUP development case and giving presentations and workshops on RUP, Agile and project management. With co-author Eef Dekker, he wrote the Dutch book RUP op Maat: Een praktische handleiding voor IT-projecten, (translated as RUP Tailored: A Practical Guide to IT Projects), second revised edition published in 2008 (see www.rupopmaat.nl). They are now working on a new book: ScrumUP, Agile Software Development with Scrum and RUP (see www.scrumup.eu). Eef Dekker is a consultant at Ordina, based in The Netherlands. He mainly coaches organizations in implementing RUP in an agile way. Furthermore he gives presentations and workshops on RUP, Use Case Modeling and software estimation with Use Case Points. With co-author Remi-Armand Collaris, he wrote the Dutch book RUP op Maat, Een praktische handleiding voor IT-projecten, (translated as RUP Tailored, A Practical Guide to IT Projects), second revised edition published in 2008 (see www.rupopmaat.nl). They are now working on a new book: ScrumUP, Agile Software Development with Scrum and RUP (see www.scrumup.eu).

www.agilerecord.com

9

© Cyhel - Fotolia.com

Problem Solving Through Pair Programming by Paul Pagel

“I can’t seem to figure out what is wrong with this function. Jim, can you help me out?” “Of course.” “Okay, so first you get rid of the element through the form post. Then, you look up the model from the database and ask it to update itself. That, in turn, tells it  … EUREKA! That’s it! Thanks, Jim, for the help.” “Sure, but I didn’t even do anything.”

Does this one-sided conversation sound familiar? For many the simple process of explaining a problem to a coworker allows them to arrive at the answer independently. (Then, if you’re anything like me, you run back to your computer in order to get the solution into code as quickly as possible!) Meanwhile, bystanders like Jim are left to wonder why they were credited with the solution when their feedback -- or lack thereof -- didn’t actually solve the problem. In fact, in many instances it isn’t the feedback that allows us to overcome our hurdles; it is the very act of communication that triggers the solution. The idea that verbal communication can positively affect the solutions and designs of a system is pretty powerful, because, let’s face it, creating software is no easy task. It is difficult to consistently design simple solutions for complicated problems. Still, the proven positive effects that communication has on both design and problem-solving makes me wonder why more developers aren’t actively seeking out opportunities to work together. There is evidence that shows that pair programming -- similar to what is being done currently by members of the eXtreme programming community -- is more productive than individual programmers

10

www.agilerecord.com

working alone. I would like to propose that pair programming is productive thanks in part to the fact that the verbal reflection loop is in constant motion. So what is pair programming? Pair programming is a technique in which two developers sit at a single computer and collaborate on the same problem. Usually one person is “driving,” with control of mouse and keyboard, although the driver is frequently changed. During the process, communication between the two programmers is constant, as they explain to one another the nature of what they are doing in real time, as they type it. This set-up allows the passive member of the duo an opportunity to reflect upon the team’s work and offer suggestions or alternatives to the design. To be “in the zone” when pair programming requires that the two programmers continually verbalize their ideas in a way that allows their partner to follow their thinking and stay engaged (Cogley 1). The simulated conversation with Jim is a demonstration of what is referred to as the “Rubber Ducky Syndrome”; a joke that portends that you might as well have been talking to an inanimate rubber duck instead of a person. “Rubber Ducky Syndrome,” as we all know, is not technically true: when trying to solve a problem you can’t simply explain it to an inanimate object and expect a solution every time. Nonetheless, everyone can relate to the need to talk through certain problems out loud. For this reason, the spirit of the “Rubber Ducky Syndrome” is relevant; since the act of explaining a problem to another person creates the mental context that is necessary for solving the problem. According to Robert M. Krauss and Susan R. Fussell, authors of Models of Interpersonal Communication, there is “evidence that creating a message can affect the way the creator perceives, remembers, and thinks about the message’s contents (99).” In other words, communicating a message will, in effect, alter it. Although his alteration can have a negative effect when you are trying to do something specific, like recognize a facial structure or

explain a memory, it has a very positive effect when you want to solve a problem. The communication lays out an explanation of the known parts of the problem. Then, by linking together these known parts of the problem, a solution frequently appears by virtue of verbalizing the problem itself. In a study that Annekatrin Wetzstein and Winfried Hacker published in 2004, they asked a group of students to put together a complex garden grill. The control group was asked to assemble the grill and then left alone until their design was complete. The experimental group was asked to, at some point, stop what they were doing and explain any difficulties they were having, along with their proposed solution. The results of the study indicated that the experimental group that had been asked to stop and verbalize their plan had a much better final design than the control group that worked straight through. Even without providing any feedback, the study demonstrated that communication itself alters the way we think about problems. “Being asked for explanations for results, justifications of decisions, and evaluation of procedures and results requires people to bring information into working memory which is not normally stored there (Wetzstein and Hacker 146).” When you have to interact socially with another person about a problem, you load a full context into your memory, which provides you with more information and framing for the problem. Then, with this clear mental snapshot of the challenges at hand, it is more likely that you will arrive at a solution that you had not previously considered. The results are similar within the realm of computer programming. Pair programming has been shown to be more effective through a number of metrics. The Williams (2000) study showed an improvement in [programming] correctness of around 15%, as well as a 20–40% decrease in time and an increase in effort of between 15–60%. The overall quality of the code is increased, which over the life of a software application drives down all negative metrics. Imagine if your application had 15% fewer mistakes which took you 20–40% less time to fix. This quality makes the application stable and able to adapt to changes. The importance of this research is that programming is shown to demonstrate consistent benefits when employing some form of a communication loop. It is through explanation and verbal reflection that we solve problems most effectively, in addition to creating solutions that are simple and readable for the rest of the world. ■

Bibliography http://en.wikipedia.org/wiki/Pair_programming Arisholm, Erik; Hans Gallis, Tore Dybå, Dag I.K. Sjøberg (February 2007). “Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise”. IEEE Transactions on Software Engineering 33 (2): 65–86. doi:10.1109/TSE.2007.17. http://simula.no/research/engineering/publications/Arisholm.2006.2/simula_pdf_file. Retrieved 2008-07-21. Models of Interpersonal Communication (Robert M. Krauss and Susan R. Fussell) Jonathan Cogley: http://weblogs.asp.net/jcogley/archive/2007/​ 03/19/pair-programming-improves-your-communication-skills. aspx

> About the author Paul Pagel is co-founder and software craftsman at 8th Light. He has been working in the software industry for over 5 very unique years. Paul is among the first formally trained software craftsmen. He spent about 3 and a half years apprenticing under the tutelage of the renowned developers at Object Mentor. Paul has been a driving force in the realm of Software Craftsmanship. He was the primary organizer of the Software Craftsmanship Summit in December 2008 and major contributor to the Manifesto for Software Craftsmanship (manifesto.softwarecraftsmanship.org). Not only is Paul a practicing craftsman, but he is also an active mentor for software apprentices. Participating in the software community is important to Paul.

www.agilerecord.com

11

© Martin Fischer - Fotolia.com

What Really Happened by Catherine Powell

Graphs and numbers look like they contain a lot of information, but they can be misleading. This is the story behind the chart. This is the number of found and fixed defects during an iteration, and more importantly, this is what really happened.

But is that really the right story? What Really Happened Background

The Chart This project is a software solution being developed by a Bostonbased team. The software is a library that runs on several Linux variants and provides services to enterprise OEM customers. The team relies heavily on automation for testing, and has a large lab that runs developer tests, unit tests, build verification tests, nightly tests, and multi-node scaling tests near constantly. Defects are logged by machines (automatically with scripts) and by humans. Any test that does not complete successfully is considered a failure; tests that do not run or that are faulty are logged as defects, as well as test failures. In addition, support engineers log defects based on customer escalations. Episode 1: Memorial Day Figure 1

This chart shows the number of defects found (red) and the number of defects resolved (green) over a thirty-day period on a single project. This is the middle of a project, with new features being coded and checked in, ongoing tests being conducted, and defects being identified, fixed, and verified.

The Memorial Day holiday occurred on May 31, 2010 in the United States. The office was closed, and little to no work was done. The drop in the number of defects identified and in the number of defects fixed has nothing to do with the software. Rather, it’s because no humans were finding or fixing defects. That apparent “increased stability”? That was really a barbecue and a team ignoring their computers for a long weekend.

What It Looks Like Episode 2: The Heat Wave On the surface, this chart tells a story. It says that bugs are getting found, and bugs are getting fixed in about equal measure. The code is churning, which is normal for the middle of a development cycle, but isn’t trending toward stability. The number of bugs found slightly exceeds the number of bugs being fixed, so this is a project to keep an eye on. The developers (and testers) may need some intervention!

12

www.agilerecord.com

In the first week of June 2010, Boston experienced a heat wave and high humidity. It’s not uncommon, but this happened earlier in the summer than normal. The building was unprepared, and the air conditioners were not yet turned on for summer weather. The spike in defects is the lab getting warm. Several machines simply got too hot and died. When they died, the tests that hap-

pened to be using those machines failed with an error and automatically logged a defect. So a spike in heat led to a spike in defects created. There is a spike in resolved defects just afterwards, as the team replaced the dead machines and tracked the test failures to those machines. Episode 3: The File Server Update All test machines in the lab use a central file server for storing logs and other shared information. On May 24, the IT team deployed a new file server. This would have been fine had no tests been running, but one set of tests was still going. When the central file server went down (for replacement), it exposed a bug in the test infrastructure. The test infrastructure panicked, discarding machines that didn’t work and grabbed new machines, over and over. This stopped when the central file server came back up, by which time the test infrastructure had used and discarded 24 machines. One bug in the test infrastructure, and one triggering event in the form of file server downtime caused 24 defects to be logged. The fix took 10 minutes to implement. Episode 4: The New Operating System This project is software running on various flavors of Linux. In general, the various flavors of Linux are roughly similar, but they are each quirky in their own way. In mid-June, the team decided to start supporting a new type of Linux: Red Hat Enterprise Linux. A team member installed Red Hat Enterprise on a few machines, put them in the lab, and configured the tests to start running on those machines. That night, some of the tests failed, and the team came in the next day to find some bugs specific to Red Hat Enterprise Linux. Some were fixed, and another spike occurred the next day as follow-on issues showed up. This spike in defects logged is the result of a new feature of the software – support for a new operating system. Episode 5: The Vacation In mid-May one of the developers took a week of vacation. With a small team like this, the developer’s vacation meant that 20% of the team was gone for a week. The chart shows an unusually low number of defects fixed; this is because a significant portion of the team simply wasn’t around to fix things. The following week – when the developer returned from vacation – shows a jump in the number of defects fixed. Is that indicative of a problem? No. It’s indicative of a vacation.

Conclusion The chart shown above implies a story. At first glance it’s a story of some churning code and some developers who just can’t keep up. That story is wrong. A look at what really happened points to two things: a small team, and an unstable test lab. A more “spikey” chart is a consequence of a small team, where the effects of one team member being gone are highly visible; on larger teams the effect of any one person is generally smaller, so charts are smoother. For the manager looking at this chart, understanding the story behind the lines of the chart points to needing to spend more effort on stabilizing the test lab rather than on changing a development team’s behavior. ■

> About the author Catherine Powell has been testing and managing for about ten years. She is a manager, a tester, an author and a formal mentor to testers and test managers. Catherine has worked with a broad range of software, including an enterprise storage system, a web-based healthcare system, data synchronization applications on mobile devices, and web apps of various flavors. With a focus on the human side of software development, Catherine builds strong teams spanning testers, developers, support, product management, and all the people involved in turning an idea into reality. She emphasizes the generation of information and pragmatic decision making using a myriad of approaches. With thoughtful techniques that access the strengths of the human team members combined with the needs of the system and its users, Catherine guides both developers and testers to be a valuable part of the decision making required to create rock-solid software. Catherine focuses primarily on the realities of shipping software in small and mid-size companies. Specifically, she highlights and works to explicate the “onthe-ground” pragmatism necessary for an engineering team to work effectively with both software and humans from product definition through release, and in the field.

www.agilerecord.com

13

© Kzenon - Fotolia.com

Agile Testing Between Theory and Practice by Sara Medhat

If you are working with an Agile team or even around one, you will be familiar with the words iterative builds, regression testing, automation, feedback, code excellence, unit testing, and other terminologies that indicate testing and quality. Why testing and quality? Because this is what differentiates one organization from another, because quality is the reason why people use certain products and and not others, because quality means safety, reliability, efficiency and outstanding performance. Nowadays, organizations are very competitive. The market changes rapidly, and customers’ demands are sometimes challenging, so if we did not do our best to catch up the technology train, we will be way behind. How can we do this? The answer is by raising our work quality standards, because  – believe me  – it is all about quality. As quality is a basic objective in our work, and because we are committed to delivering high-quality products, we will look at some basic definitions of Agile Testing. Who are the Agile testers, what is their role in Agile teams, and why do we need Agile testers in our teams anyway?

testing after every build to make sure the already implemented features are still working properly and that the newly added features have not introduced new bugs. In Agile teams, testers are no longer intruders. They are team members, they work together with the rest of the team to deliver the highest quality to satisfy their customers. In some Agile teams the relation between testers and developers is not the traditional relation with each of them defending their side as if in a battle. In Agile teams, the testers and the developers have the same vision and the same goal to reach. Who are Agile Testers? An Agile tester is not just a quality control person, but is a good tester with excellent knowledge of the Agile practices and the development lifecycle. He is the team member who helps guide the whole development team in a way that ensures the product behaves as intended, and the implemented features are exactly what was agreed with the customer in the stories of the iteration or the release.

What is Agile Testing? Agile Testing is software testing based on the principles of the Agile Manifesto. It differs from the traditional software testing in the approach of the tester and in how he sees the software application. It is based mainly on “Personas” that are using/buying the system, i.e. testing from the customer perspective. Also Agile testing is not an activity that comes at the end of the software development lifecycle, but it is an iterative activity that comes within the project iterations throughout the whole lifecycle of the project. It is a “test early and test often” activity. Agile testers should use automation testing to eliminate the repetitive manual testing of the acceptance tests and the regression test suites. Automated testing is essential in Agile testing because of the repetitive builds. Testers need to perform regression

14

www.agilerecord.com

The Agile tester works with the customer and the stakeholders to understand every feature of the project to facilitate the communication between team and customer and to ensure that they are all on the same page and speak the same language. For example, the team and the customer have agreed on the definition of a Done-Done feature/story, agreeing on the acceptance criteria for each story (which can be a major conflict issue between customer and team); they therefore need to have the same understanding of the definition of the acceptance criteria. You have to take into consideration that every customer has his own personality and his own business background. So even if the development team has predefined what the acceptance criteria are, they still need to be discussed with the customer. This way they will know their customer better and know exactly what is expected.

Do We Need Agile Testers in our Team? Some Agile teams which practice unit testing, test driven development or any other type of code testing think that they do not need an Agile tester in their team. They see it this way: we code, we test our code, we get feedback from the customer, and we work on that feedback, what is the value of a tester in our team. Let me show you the value of testers in any development team, not only an Agile team. What distinguishes the tester from the rest of the development team is that when a tester tests the application, he keeps in mind a couple of things:

Agile tester attends the iteration planning, release planning, acceptance criteria writing, feedback meetings with clients, demo meeting with clients, functionality testing for each story during the iteration, performs acceptance tests per story, and regression testing after each build. The Agile tester verifies and validates every story delivered to the customer and makes sure that the “Done-Done” criteria are met. In the real world, the Agile tester’s role may vary from this specific defined role. Because we live in an imperfect world, we can expect complications along the way. Throughout any project the development team may face some obstacles that may cause – unintentionally – diversions from their clearly defined way.

First: How will the user deal with this application? Is it usable? Does it function correctly for every user action? Testers verify the application against the requirements. Or in an Agile team they verify the application against the stories, and he does so using the predefined acceptance criteria. This type of testing is called positive testing.

Complications may be from the team side or from the customer side, or maybe both. It could be the performance of one team member that affects the rest of the team, it could be a misunderstanding of the project scope and/or requirements that cause a conflict between team members or between team and Sometimes we have to change Second: Testers think about ways to customer, it could be a misunderstanding our plans and our goals to cope break the application, testing the reof Agile implementation or absence of an with world imperfection. sponse of the application after incorrect Agile coach to guide the team, it could be user inputs (e.g. wrong entry). How will late delivery that causes trust issues bethe application behave? Will it break? Will it respond correctly? tween the team and the client, it could be scope creep or that the In this type of testing the tester validates the requirements or the client keeps changing his mind with new requirements which afstories to see what was not covered when coding. This type of fect the project time, the team effort, it could literally be anything testing is called negative testing, and this is exactly why we need that affects the team’s productivity or the quality of the delivered testers in our development teams, whether they are Agile or not. project. During iteration planning, release planning, or project Most of the developers do not consider these types of cases, the planning, the team may take into consideration some of the risks breaking types. that they are already aware of, risks that may affect their project, but sometimes we get risks that we did not know about, risks that When developers test their work, they test the normal cases, they evolve while the team is working. understand how the function works and they test that it works the way it should, but the negative testing of the function is not Be Part of the Solution, Not the Problem what they keep in mind while testing their work. • Applying risk assessment in the chartering phase will elimiAnother reason why we need testers in our development team is nate as much as possible any future risks that the team could that we as human beings are fallible, and we cannot discover our face during development. As an Agile tester, you should raise a own mistakes, so a fresh eye to our work will enhance our work flag with any potential problems you may face, like undefined quality. So let’s agree that, whether we are Agile or not, we need scope, lots of testing activity, the need for more testers in the software testers in our projects. team, and/or an unclear test plan. If you are not sure of what you are going to test, then you should ask for help. Agile Testers in the Real World • Be honest. This is meant not only for the Agile tester, but for the whole team. Be honest with yourself and your team. If you One of the main natural challenges we face in our lives is that we can think of anything that may disrupt the team progress in the live in an imperfect world. Things will not always work the way we future, you should be clear and admit it from the beginning. want it to. Sometimes we have to change our plans and our goals • If you do not have the skill. If the team plans to use a new to cope with world imperfection. These changes may be trivial or technology, or will apply some new practices that you are not crucial, depending on whether we have considered them when familiar with, you may well be eager to learn these, but this setting our goals, or what happened was not expected and we may not be for the benefit of the project. If time is tight, or the were hit in the face. In all cases, we keep asking the same queswork load is too much, they would be better off with an already tion; how can we handle and eliminate the risks that may affect experienced person to help with the delivery. So be honest and our objective to achieve the best quality? tell your team your concerns. • Demanding customer. What if the team has a demanding By the book, the Agile tester’s role in an Agile team is clear, even customer that wants everything at the same time and at the if he may play more than one role in the team. We know that the same price. This kind of customer is definitely a headache for

www.agilerecord.com

15

the team and for the whole organization. Agile teams in particular know the value of customer satisfaction and continuous feedback, but who said that feedback is for free, and who said managing the customer means saying no to his requests. It is hard to keep your customer satisfied and at the same time keep your project within budget, but that is what good teams and good managers are for. Testers and Project Failures Can testers cause a project to fail? Well, in agile development, as we know, quality is everyone’s responsibility, not only the testers’. Every team member is responsible for delivering his part with the best quality he can. Of course, we cannot deny the important role of the tester in the delivery or in the project quality. The tester is the one who decides that everything is okay and that we can deliver to the customer, so poor testing or a poor test plan will cause the delivery of a buggy application, which may affect the organization’s future business. The good understanding of the project requirements/stories, good knowledge of the Agile process, understanding the customer needs, and, of course, excellent understanding of the testing techniques used within your project will empower the tester to decide whether the project meets the quality standards agreed with the customer, or whether it is a disaster and the customer should know nothing about it. At the end, it is all about quality. Whether you are Agile or not, whether you are a tester or not, you work in a team and the quality is the whole team’s responsibility. We may face some obstacles along our way, but this is life, it is all about challenges. So are you ready to face your next challenge and take it as a step towards reaching your goals? ■

Wachsen Sie mit uns! Wir suchen

Senior Consultants IT Management & Quality Services (m/w) www.diazhilterscheid.de

Sara Medhat is a senior software test engineer, ISTQB® (International Software Testing and Qualifications Board) certified, and software testing trainer with five years of experience in the quality control and software testing field. For the last two years she has been working with agile teams as an agile tester and project coordinator. She has published an article about “Agile Adoption” in Agile Record issue No. 2. She is also a co-speaker at the Agile2010 conference with Dr. Ahmed Sidky in a session about “How an Agile Project can Fail; and what to do about it.”

16

www.agilerecord.com

© iStockphoto.com/mariusFM77

> About the author

by Tom Gilb

Part 1 of 2: Gilb’s Ten Key Agile Principles to deliver stakeholder value, to avoid bureaucracy and to give creative freedom (Part 2, Values for Value, next issue)

Introduction The Agile Manifesto [2] has its heart in the right place, I am only worried about its ‘mind’. And its first principle “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”, is central to the ideas in this article. It is not strange that I agree, since many of the Agilistas, for example Kent Beck, explicitly point to my 1988 book as a source of some of their ideas [4, 5, 6, 7, 8, 9, 12]. My problem with agile is not in its ideals, but in the everyday teaching and practices we see. What we see is the same problem that has been afflicting all software and IT projects long before agile appeared. Our technocratic culture has forgotten our stakeholders and their values. The practices are far too ‘programmer centric’, and far too little ‘stakeholder value’ centric. The result is that ‘working software’ [2] is delivered to a ‘customer’ [2]. However, necessary values are not necessarily, and all too rarely, delivered to all critical stakeholders. Code has no value in itself. We can deliver bug-free code, that has little or none of the anticipated value. We can deliver software functions, as defined in requirements, to the ‘customer’ – but totally fail to deliver critical value to many critical stakeholders. The Opera ticket system at the magnificent new Oslo Opera House is a simple example. In the old days, a ticket was ripped off a stack and immediately delivered to the ticket buyer. The new system, at opening, took 10–20 minutes for the ticket sellers to negotiate what to do and how to do things like senior and child discounts. With frequent access to supervisors, who were not sure of what or how. No bugs, all the functions, but something was catastrophically wrong. ‘Working software’  – working badly. Thank God, the Agilistas did not design the Opera House itself! That was done by real first-class architects! [3]

18

www.agilerecord.com

I fear this article may not correct the narrow-mindedness of the coder community, and my principles do apply to a higher level of thinking than coding. I am going to try to formulate a much clearer set of principles, a more explicit set; and in the subsequent article, I will formulate clearer ‘values’ than the Agilistas managed to do. I have one decided advantage: I am not subject to lowest common denominator politics, as they were; I can express my own opinion – unopposed! I hereby give them specific permission to update their wooly and dangerous ideals with these more focussed ideals. And because they won’t (chiselled in stone, unagile documentation Manifesto) I give the reader the right to spread it, and update, and improve it, as they like. ‘Value Principles’ Principle 1. Control projects by quantified critical-few results. 1 page in total! (Not stories, functions, features, use cases, objects,  …) Most of our so-called functional requirements are not actually requirements. They are designs to meet unarticulated, higher-level, and critical requirements [14]. For example the requirement to have a ‘password’ is hiding the real ‘Security’ quality requirement [13]. Most of the really critical project objectives are almost always buried in old management slides, and formulated in a wooly and un-testable way. They are never used in architecture, contracting or testing. This is a major cause of project failure [14]. Management and project sponsors are led to believe the project will deliver certain improvements. In practice the agile culture has no mechanism for following up and delivering expected values. Scrum would argue that that is the job of the product owner. However, even top Scrum gurus openly acknowledge that the situation in practice is nowhere near what it should be. We simply do not teach and practice the necessary mechanisms. Software people were always bad at this, but agile did not deliver clear ideals on its own.

© Mikhail Tolstoy - Fotolia.com

Value-Driven Development Principles and Values – Agility is the Tool, Not the Master

Principle 2. Make sure those results are business results, not technical. Align your project with your financial sponsor’s interests!

one example earlier (a real one, Ohio), where a ‘password’ was required, but ‘security’ (the real requirement) was not at all defined.

People do not do development projects to get function, features and stories. Yet these seem primary in the current agile methods. We need functions, stories and perhaps ‘features’ to make sure the application will do the fundamental business activities that are expected (e.g. ‘issue an opera ticket’, ‘give a child discount’). But these fundamentals are never the primary drivers for the investment in a development project. As a rule, the stakeholders already have those functions in place, in current systems. If you look at the project documentation, someone ‘sold’ management on better systems – some improvements. Faster, cheaper, more reliable etc.

We are so bad at this, that you can safely assume that almost all so-called requirements are not real requirements, they are bad designs. All you have to do to see this is ask: WHY? Why ‘password’? (Security, stupid!)  – Oh! Where is the security requirement? Not there, or worse, stated in management slides as ‘state-of-the-art security’ – and then left to total amateurs to design it in!

These are always improvements that are specifically stated somewhere, and they are always quantifiable,. Unfortunately, we in agile development avoid being specific at this level. We use adjectives like ‘better’, ‘improved’, ‘enhanced’ and leave it at that. We have learned long ago that our customer is too uneducated and too stupid (common sense should compensate for lack of education) to challenge us on these points. And they happily pay us a lot of money for worse systems than they already have. We need to make it part of our development culture to carefully analyze business requirements (‘save money’), to carefully analyze stakeholder needs (reduce employee training costs’), to carefully analyze application quality requirements (‘vastly better usability’). We need to express these requirements quantitatively. We need to systematically derive stakeholder requirements from the business requirements. We need to derive the application quality requirements from the stakeholder requirements. Then we need to design and architect the systems to deliver the quantified requirement levels on time. We are nowhere near trying to do this in current conventional agile methods. So we consistently fail the business, the stakeholders, and fail to deliver the quality levels required [15].

Imagine if Test Driven Development (TDD) actually tested the quality levels, like the security levels, to start with? Far from it; and TDD is another disappointment in the agile kitbag. I analyze real requirements about once a week, internationally, and find very few exceptions – i.e. situations where the real requirements are defined, quantified, and then designed (engineered, architected) towards. Agile culture has no notion of real engineering at all. Softcrafting [4], sure. But not engineering – totally alien. You cannot design correctly towards a vague requirement (‘better security’). How do I know if a password is a good design? If the security requirements are clear and quantified (and I simplify!) like “Less than 1% chance that expert hackers can penetrate the system within 1 hour of effort”, then we can have an intelligent discussion about the 4-digit pin code that some think is an OK password. I have one client (Confirmit, [16]) who pointedly refuses to accept functions and features requirements from any customer or salesperson. They focus on a few critical product qualities (like usability, intuitiveness) and let their developers engineer technical solutions to measurably meet the quantified quality requirements.

Let me be clear here. You can do this as the system evolves, and it can be expressed on a single page of quantified top level requirements [examples 14]. So don’t try the ‘up front bureaucracy’ argument on me!

This gets the right job (design) done by the right people (developers) towards the right requirements (higher level overall views of the qualities of the application). They even do their ‘refactoring’ by iterating towards a set of long-term quality requirements regarding maintainability, and testability. Probably just a coincidence that their leaders have real engineering degrees?

Principle 3. Give developers freedom, to find out how to deliver those results.

Principle 4. Estimate the impacts of your designs, on your quantified goals.

The worst scenario I can imagine is when we allow real customers, users, and our own salespeople to dictate ‘functions and features’ to the developers, carefully disguised as ‘customer requirements’. Maybe conveyed by our product owners.

I take quantified improvement requirements for granted. So do engineers. Agilistas do not seem to have heard of the ‘quantified quality’ concept. This means they cannot deal with specific, or ‘high’, quality levels.

If you go slightly below the surface of these false ‘requirements’ (‘means’, not ‘ends’), you will immediately find that they are not really requirements. They are really bad amateur design for the ‘real’ requirements  – implied, but not well defined [17]. I gave

The concept of ‘design’ also seems alien. The only mention of design or architecture in the Agile Manifesto is “The best architectures, requirements, and designs emerge from self-organizing teams.” [2]. There is some merit in this idea. But, the Agile view

20

www.agilerecord.com

© Katrin Schülke

Berlin, Germany

IT Law Contract Law German English Spanish French www.kanzlei-hilterscheid.de [email protected]

k

a

n

z

l

e

i

h

i

l

t

e

r

s

c

h

e

www.agilerecord.com

i

d 21

on architecture and design is missing most all essential ideas of real engineering and architecture [18]. We have to design and architect with regard to many stakeholders, many quality and performance objectives, many constraints, many conflicting priorities. We have to do so in an ongoing evolutionary sea of changes with regard to all requirements, all stakeholders, all priorities, and all potential architectures. Simply pointing to ‘self-organizing teams’ is a method falling far short of necessary basic concepts of how to architect and engineer complex, large-scale critical systems. Indeed, even for much smaller systems such as the 13-developer Confirmit system [16].

lazily taken advantage of it. Principle 6. Decompose the workflow into weekly (or 2% of budget) time boxes. At one level, the Agilistas and I agree that dividing up big projects into smaller chunks, of a week or so, is much better than a Waterfall/Big Bang approach [21].

However, I would argue that we need to do more than chunk by ‘product owner prioritized requirements’. We need to chunk the value flow itself – not just by story/function/use cases. This value chunking is similar to the previous Any proposed design or architecture must principle of prioritizing the designs of best be compared numerically, with estimates, value/cost. We need to select, next week Sometimes the quantified then measurements, of how well it meets (next value delivery step to stakeholders) quality and value requirements the multitude of performance and qualthe greatest value we can produce in an are overambitious. ity requirements; and to what degree it arbitrarily small step (our team, working a eats up resources, or threatens to violate week). In principle this is what the Scrum constraints. I recommend the Impact Estimation table as a basic Product owner should be doing. But I don’t think they are even method for doing this numeric comparison of many designs to remotely equipped to do this well. They just do not have the quanmany requirements [19, 10, 4]. It has been proven to be consistified value requirements (above), and the quantified design estitent with agile ideals and practices, and has been given far betmates (above) to make it happen in a logical manner. ter reported results than other methods [16]. If other methods have better results, they are unable to report them convincingly, One dispute I do not seem to have with Agilistas is about whether since they do not deal numerically with the values and qualities you can in fact divide any project into small (2% of budget) delivof stakeholders. ery steps. I find that you always can, but there are a lot of people out there who are firmly, and falsely, convinced it is impossible If a designer is unable to estimate the many impacts of a sug[21]. But maybe the dispute will surface when they are confrontgested design on our requirements, then the designer is incomed with the need to chunk by value, not by function. petent, and should not be employed. Most software designers are by this definition incompetent. They don’t just fail to estimate, Principle 7. Change designs, based on quantified value and they do not even understand their obligation to try! cost experience of implementation. Principle 5. Select designs with the best value impacts for their costs, do them first. Assuming we find the assertion above, that we should estimate and measure the potential, and real, impacts of designs and architecture on our requirements, to be common sense. Then I would like to argue that our basic method of deciding ‘which designs to adopt’ should be based on which ones have the best value for money. Scrum, like other methods, focuses narrowly on estimating effort. This is not the same as also estimating the multiple values contributed to the top ten project objectives (which ‘Impact Estimation’ does routinely) [19]. It seems strange to me that agile methods understand the secondary concept of estimating costs, but never deal with the primary concept of estimating value to stakeholders, and to their requirements. There is little point in managing cost, if you cannot first manage value. The deeper problem here is probably not Agile methods, but is a total failure of our business schools to teach managers much more about finance, and nothing about quality and values [20]. If management were awake and balanced, they would demand far more accountability with regard to value delivered by software developers and IT projects. But the development community has long since realized that management was asleep on the job, and

22

www.agilerecord.com

If you get stepwise numeric feedback on the actual delivered value of a design, compared to estimated and perceived value, as is normal at Confirmit [16], then you will occasionally be disappointed with the value achieved. This will give you the opportunity to reconsider your design, or your design implementation, in order to get the value you need, irrespective of your previous lack of understanding. You might even learn that ‘coding alone is not enough’ to deliver value to stakeholders. I fear that this realistic insight possibility is largely lost; since the agile methods neither quantify the value required, nor do they quantify the value expected from a step or a design at a given delivery step. The result is that we get stuck with bad designs until it is too late. To me, that does not seem very ‘agile’. Principle 8. Change requirements based on quantified value and cost experience, new inputs. Sometimes the quantified quality and value requirements are overambitious. It is too easy to dream of perfection, and impossible to actually get it. It is too easy to dream of great improve-

ment, without being aware of its true cost, or state-of-the-art limitations. Sometimes we have to learn the reality of what we can or should require by practical experience. This is of course normal engineering and science. To learn technical and economic realities step by step.

even recognizing the stakeholder concept. Head in the sand, if you ask me!

The agile community, however, has, as we have pointed out, little concept of quantifying any requirements. Consequently, they cannot learn what is realistic. They will just get what they get by chance or custom.

Finally – the stakeholders are the ones who should get value delivered incrementally, at every increment of development.

If they actually quantified their key requirements, and if they measured the incremental numeric results, then if requirements were either overambitious or unacceptably costly, we would have a chance to react quickly (agility!). Learning and agile change are threatened by the lack of quantification and measurement in the normal development process. But today’s agile community remains unconcerned. Principle 9. Involve the stakeholders, every week, in setting quantified value goals. Agile methods refer to users and customers. The terms used are ‘sponsors, developers, and users, customers’. In systems engineering (incose.org) there is no doubt that the generic concept is ‘stakeholder’. Some parts of software engineering have been adopting a stakeholder paradigm [22]. But agile methods do not mention the concept. In real projects of moderate size, there are 20 to 40 interesting stakeholder roles worth considering. Stakeholders are sources of critical requirements. Microsoft did not worry enough about a stakeholder called the EU – a costly mistake. In every failed project – and we have far too many – you will find a stakeholder problem at the root. Stakeholders have priorities, and their various requirements have different priorities. We have to keep systematic track of these. Sorry, if it requires mental effort. We cannot be lazy and then fail. I doubt if a Scrum product owner is trained or equipped to deal with the richness of stakeholders and their needs In fact, the PO seems to be a dangerous bottleneck in this concern. However, it can never be a simple matter of analyzing all stakeholders and their needs and the priorities of those needs up front. The fact of actual value delivery on a continuous basis will change needs and priorities. The external environment of stakeholders (politics, competitors, science, economics) will constantly change their priorities, and indeed even change the fact of who the stakeholders are. So we need to keep some kind of line open to the real world, on a continuous basis. We need to try to sense new prioritized requirements as they emerge, in front of earlier winners. It is not enough to think of requirements as simple functions and use cases. The most critical and pervasive requirements are overall system quality requirements, and it is the numeric levels of the ‘ilities’ that are critical to adjust, so that they are in balance with all other considerations.

Principle 10. Involve the stakeholders, every week, in actually using value increments.

I believe that this should be the aim of each increment and not ‘delivering working code to customers’. This means you need to recognize exactly which stakeholder type is projected to receive exactly which value improvement, and plan to have them, or a useful subset of them, on hand to get the increment, and evaluate the value delivered. Current agile methods are not set up to do this, and in fact do not seem to care at all about value or stakeholders. In fact, developers would have to consider the whole system, not just the code, in order to deliver real value – and coders feel very uncomfortable with anything outside their narrow domain. Isn’t it is amazing that they have been given so much power by ‘managers’ to screw up society? ■

Here is an overview of my Agile Values, the subject of a more detailed article in the next issue. My 10 Agile Values? © Tom Gilb 2004-10 Simplicity 1.

Focus on real stakeholder values

Communication 2.

Communicate stakeholder values quantitatively

3.

Estimate expected results and costs in weekly steps and get quantified measurement feedback on your estimates the same week

4.

Install real quantified improvements for real stakeholders weekly

5.

Measure the critical aspects in the improved system weekly

6.

Analyze deviations from value and cost estimates

Courage 7.

Change plans to reflect weekly quantified learning

8.

Immediately implement the most valued stakeholder needs by next week Don’t wait, don’t study (analysis paralysis), don’t make excuses. Just do it!

9.

Tell stakeholders exactly what quantified improvement you will deliver next week

10. Use any design, strategy, method, process that works well quantitatively in order to get your results Be a systems engineer, not a just a programmer (a ‘Softcrafter’). Do not be limited by your craft background, in serving your paymasters.

A tricky business indeed, but – are we going to really be ‘agile’? Then we need to be realistic – and current agile methods are not

www.agilerecord.com

23

References 1. Gilb’s Agile Principles and Values The draft basis for a full paper. Originally formulated for conference speeches in November 2004 (London, XP Days Keynote, What’s Wrong with Agile?). http://xpday4.xpday.org/slides.php Original slides still here. Slides 38-39 the Principles and Values statements. This is why I am copyrighting from 2004. I literally wrote the values and principles at the conference just before my speech, and they first appeared in my slides. I have updated the principles to stress “values, stakeholders and costs” in 2007 and 2010 for this article. 2. Agile Manifesto: URL http://agilemanifesto.org/principles.html 3. http://en.wikipedia.org/wiki/Oslo_Opera_House 4. Gilb, Principles of Software Engineering management, 1988. http://books.google.co.uk/books?q=gilb+principles+of+software+e ngineering+management&spell=1&oi=spell 5. Mike Cohn, “I’ve always considered Tom to have been the original agilist. In 1989, he wrote about short iterations (each should be no more than 2% of the total project schedule). This was long before the rest of us had it figured out.” http://blog.mountaingoatsoftware.com/?p=77 6. Comment of Kent Beck on Tom Gilb, Principles of Software Engineering Management: “ A strong case for evolutionary delivery – small releases, constant refactoring, intense dialog with the customer”. (Beck, page 173). In a mail to Tom, Kent wrote: “I’m glad you and I have some alignment of ideas. I stole enough of yours that I’d be disappointed if we didn’t :-), Kent” (2003) 7. Jim Highsmith (an Agile Manifesto signatory) commented: “Two individuals in particular pioneered the evolution of iterative development approached in the 1980’s  – Barry Boehm with his Spiral Model and Tom Gilb with his Evo model. I drew on Boehm’s and Gilb’s ideas for early inspiration in developing Adaptive Software Development. … Gilb has long advocated this more explicit (quantitative) valuation in order to capture the early value and increase ROI” (page 4, July 2004). 8. Ward Cunningham wrote in April 2005: Tom -- Thanks for sharing your work. I hope you find value in ours. I’m also glad that the agile community is paying attention to your work. We know (now) that you were out there ahead of most of us. Best regards. – Ward, http:// c2.com 9. Robert C. Martin (Agile Manifesto initial signatory, aka Uncle Bob): “Tom and I talked of many things, and I found myself learning a great deal from him. The item that sticks most prominently in my mind is the definition of progress.”, “Tom has invented a planning formalism that he calls Planguage that captures this idea of customer need. I think I’m going to spend some serious time investigating this.” from http://www.butunclebob.com/ArticleS.UncleBob.TomGilbVisit 10. Gilb, Competitive Engineering, 2005, http://books.google.co.uk/ books?q=gilb+competitive+engineering&btnG=Search+Books 11. Scott Ambler on Amazon reviews, of Competitive Engineering: Tom Gilb, the father of the Evo methodology, shares his practical, real-world experience for enabling effective collaboration between developers, managers, and stakeholders in this book. Although

24

www.agilerecord.com

the book describes in detail Planguage, a specification language for systems engineering, the methodological advice alone is worth the price of the book. Evo is one of the truly underappreciated agile methodologies and as a result Gilb’s thought-provoking work isn’t as well known as it should be, although I suspect that this will change with this book. The book describes effective practices for requirements and design specification that are highly compatible with the principles and practices of Agile Modeling, yet it goes on to address planning activities, quality, and impact estimation. I suspect that this book will prove to be one of the “must read” software development books of 2006. 12. http://leansoftwareengineering.com/2007/12/20/tom-gil​bsevolutionary-delivery-a-great-improvement-over-its-successors/ “But if you really want to take a step up, you should read Tom Gilb. The ideas expressed in Principles of Software Engineering Management aren’t quite fully baked into the ADD-sized nuggets that today’s developers might be used to, but make no mistake, Gilb’s thinking on requirements definition, reliability, design generation, code inspection, and project metrics are beyond most current practice.” Corey Ladas 13. Re Security Requirements: http://www.gilb.com/tiki-download_file.php?fileId=40 A paper on how to quantify security requirements. 14. Top Level Objectives: http://www.gilb.com/tiki-download_file.php?fileId=180 A handful of real case studies regarding top level project requirements, or lack of them. 15. One example of systematic quantitative analysis and connection of business, stakeholder and quality levels of requirements in the Norwegian Post case study by Kai Gilb. http://www.gilb.com/tikidownload_file.php?fileId=277 16. Confirmit Case: Paper http://www.gilb.com/tiki-download_file.php?fileId=32 Confirmit case slides: http://www.gilb.com/tiki-download_file.php?fileId=278 17. Real Requirements: How to find out what the requirements really are, paper. http://www.gilb.com/tiki-download_file.php?fileId=28 18. Architecture, a View. http://www.gilb.com/tiki-download_file.php?fileId=47 19. Design Evaluation: Estimating Multiple Critical Performance and Cost Impacts of Designs http://www.gilb.com/tiki-download_file.php?fileId=58 20. Hopper: The Puritan Gift: Reclaiming the American Dream Amidst Global Financial Chaos’, http://www.puritangift.com/ This is not least a direct and deep attack on Business Schools to teach much more than a narrow financial agenda (aka greed), forgetting the broader set of values that lead to long-term financial soundness. http://twitter.com/puritangift 21. Decomposition: http://www.gilb.com/tiki-download_file.php?fileId=41 22. Susanne Robertson’s several papers regarding stakeholders: http://www.systemsguild.com/GuildSite/Guild/Articles.html

> About the author Tom Gilb (born 1940, California) has lived in UK since 1956, and Norway since 1958. He is the author of 9 published books, including Competitive Engineering: A Handbook For Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage, 2005. He has taught and consulted world-wide for decades, including having direct corporate methods-change influence at major corporations such as Intel, HP, IBM, Nokia. He has had documented his founding influence in Agile Culture, especially with the key common idea of iterative development. He coined the term ‘Software Metrics’ with his 1976 book of that title. He is co-author with Dorothy Graham of the static testing method ‘Software Inspection’ (1993). He is known for his stimulating and advanced presentations, and for consistently avoiding the oversimplified pop culture that regularly entices immature programmers to waste time and fail on their projects. More detail at www.gilb.com.

Subscribe at

www.agilerecord.com www.agilerecord.com

25

© Leah-Anne Thompson - Fotolia.com

Things I’ve Learned … the Hard Way by Alex Rosiu

Don’t Procrastinate It’s always easy to leave things for later, but the consequences are almost always bad. Usually, there is no logical reason to defer anything, starting with simple things such as paying your bills, and ending with dealing with your project’s problems. They won’t just get solved by themselves; they are only going to get worse as time passes. What is more, there are for sure some people relying on you and waiting for you to finish, in order to be able to do their job. You owe these people to get your job done as soon and as well as you can. Respect Your People They’ve made it to this team thanks to their qualities and strengths. They have developed into experienced professionals, or they are just taking the first steps. Anyhow, they are the ones directly helping you do your job, and respect is one of the key factors in any good relationship. Trust Them There are two kinds of people. The ones thinking that trust is to be earned, and the others who trust people from the beginning, only to lose it if they get let down. I personally belong to the latter, but I find worth mentioning that trusting someone doesn’t mean being naive. You still have deadlines to meet, you still have to make sure your team is producing quality work, so there is a very thin line between being trusting and being too loose. Don’t Lose Control There is an old saying: Trust is good, control is better. You may be shocked to find out it belongs to no other than Joseph Stalin, but I consider this only proves that even villains can be pretty wise

26

www.agilerecord.com

from time to time. Even if you are lucky to have competent people in your team, you still have to find non-intrusive ways of keeping track of your schedules and commitments. Thinking about that fine line again… Don’t Micromanage While being confronted with stressful situations or tight commitments, you can easily turn into a control freak. You may feel the need to know every aspect, every detail, in order to be able to have everything under control. Humans, however, are not that “multi-threaded”, so they need to surround themselves with trustworthy and skilled people who they can rely on, rather than trying to squeeze every bit of information into their 20%-used brain. Listen and Make Sure They Listen to You You want to be constantly aware of your people’s needs and problems, while making sure they know your expectations. You have every reason in the world to be attentive while in meetings with your fellow leaders and managers, but also to be able to leave relieved that they all know your team’s status or your personal points of view, when the meeting is over. Finding the right ways to communicate is therefore crucial, and yet so different from one situation to another. Never Wait Leaders aren’t waiting, they’re acting. Being reactive, or even worse – passive, isn’t part of a leader’s job description. A good way to tell if you are being proactive enough is to ask yourself this question: Usually, when my manager asks me something, do I know the answer on the spot, or do I have to find it out? If you are always being told what to do, you probably aren’t much of a leader after all.

Be What You Want Them to Be Being a leader means heaving people follow you. But if they find you worthy in any way, they will also borrow from your way of being, more or less consciously. Your behavior is therefore crucially determinative for their own, so unless you don’t want to be surrounded by jerks, make sure you’re not one. Unfortunately, negative behaviors are easy to imitate, but the good news is, positive things are also quite catchy. ■

> About the author Alex Rosiu is a Technical Project Manager at BitDefender, a security software company. As a computer science graduate, he started his career as a software developer, moving on to technical lead as soon as his experience allowed me to. As a Certified Scrum Master, he finds great interest in mentoring and implementing the Agile practices in his company. He is an active member of the Agile Alliance and the Scrum Alliance, and he also enjoys sharing his professional experiences on his personal blog: http://alex.rosiu.eu.

www.agilerecord.com

27

© Michael Flippo - Fotolia.com

The Art of Throw-Away Test Automation Business agility requires disposable test assets by George Wilson

Introduction Software test automation has been available for over a quarter of a century, but the practice still has many skeptics, and the biggest barrier to adoption remains the level of maintenance required to sustain it. Achieving just a moderate level of automation coverage requires considerable investment of budget and resource. With increasing software development complexity and more and more IT departments taking on an agile approach, traditional test automation has become too cumbersome for most to sustain. But Why is Test Automation so Cumbersome? Traditional test automation systems originated in a world that moved at a much slower pace, where waterfall developments were the only game in town and no-one attempted to tackle fast moving, mission-critical applications – they knew that the technology simply couldn’t keep up. These products all get their capabilities from powerful scripting languages; something that sounds good in a presentation, but has become a horror in the real world, requiring a cult of high priests, who are highly skilled and paid test automation engineers, to communicate with the complex and mysterious deity; the test automation tool. Worse still, the script library took weeks and months to develop. This was something that was rationalized as OK, because you could write the scripts in parallel with code development. The truth was somewhat different as the script required knowledge of how the developers were naming the visual components  – something that was neither consistent nor predictable. Because of this, the code-based tools reverted to a ‘record’ mode to establish the initial script, which made them only usable once the application was complete. This was more practical, but now the

28

www.agilerecord.com

automation coding effort couldn’t even commence until sections of the code were complete and stable. It got worse. Most of each script that needed to be coded had nothing to do with testing the application. The engineers had to overcome many challenges before they could even get that far – handling unpredictable response times, retrieving displayed data needed for validation, and establishing checkpoints to signify when the application had completed a logical step. But the death knell was what happened when the application to be tested changed. Suddenly all these laboriously created ‘assets’ were worth nothing and would not execute until the entire process had been repeated. What happened next ranged from the sane to the almost comical. The sane organisations did what came naturally and gave up. Others were not to be defeated and threw even more expensive resources at the problem, some hiding the failure by outsourcing the entire test burden – often to companies who did most of the testing manually. All this for an initiative which was meant to reduce the need for resources, save time and improve quality! To put this in perspective, industry analysts state that the high water mark in automation success is when 20% of an application has been automated. This is the high water mark, mind you, not the average, 20% is the peak of what you can expect after a financial investment measured in hundreds of thousands of dollars and an effort investment measured in many man years. The Current Need for Speed The way we work has also changed. In the last decade the rate of business change has risen beyond anything we could have expected. The availability of new technology and the strategic advantage that it can potentially provide businesses has fuelled

this, along with the need to adapt quickly to changing market requirements. The recession has arguably exasperated the situation. As the fortunes of markets change and move with a frighteningly sudden pace, every business finds itself needing to achieve more, with static or reduced budgets and resources.

suggests an almost static application, not one that is a subject of active development efforts. This sort of automation is fine for regression tests, but will not make any impact on current QA bottlenecks. The need is for a solution that is faster, lighter and better able to respond to dynamic application developments.

Agile development is experiencing increasing popularity in IT departments, because today’s fast-paced business environment requires an organisation’s development process to be flexible and adaptable to changing needs. The Agile model provides frequent delivery, increased customer involvement and helps to deal with the problem of rising complexity in systems. However, with all the benefits of a more fluid, flexible process, come challenges in how to assure the quality and governance of these ever-changing applications.

In short, the modern business with all its need for speed and agility just has no place left for these types of solutions, regardless of how much organizations have already invested in them, and regardless of how much resource is tied up in trying to maintain them. The need for change is now.

QA teams now have to accept that requirements can often change during and after each iteration, depending on the feedback from the customer. These changes in requirements are consequently reflected in the code and the tests that QA teams have to develop, which in turn can lead to a large amount of rework and script maintenance. With delivery cycles getting shorter, and with security concerns and new regulations to manage, applications are becoming more like living things; beings that grow and mature, morphing from new-born status to an almost unrecognizable fully grown adult with all the associated trappings and documents that adults tend to collect throughout their lives. How on earth is outdated and cumbersome test automation technology supposed to cope with this level of change and complexity? It simply can’t. Still Stuck in the 90’s I read an interesting comment by James A. Whittaker in his blog post Still Stuck in the 90s. “Don’t get me wrong, software testing has been full of innovation. We’ve minted patents and PhD theses. We built tools and automated the crud out of certain types of interfaces. But those interfaces change and that automation, we find to our distress, is rarely reusable. How much real innovation have we had in this discipline that has actually stood the test of time?I argue that we’ve thrown most of it away. A disposable two decades. It was too tied to the application, the domain, the technology. Each project we start out basically anew, reinventing the testing wheel over and over. Each year’s innovation looks much the same as the year before. 1990 quickly turns into 2010 and we remain stuck in the same old rut.” HP in a refreshing burst of honesty now state that unless you will run a script a minimum of seven times, there will not be any payback from automation. That is one heck of a statement. Any part of an application that needs to be tested at least seven times,

“The Rate of Obsolescence Outpaces the Pace of Change.” * So says Ray Wang, industry analyst and the author of the popular enterprise software blog “A Software Insider’s Point of View” He’s right. Technology changes too quickly for any one company to stay on top of it. New software is released so regularly that it is already out of date by the time it is launched – consider the frequency of SAP or even Microsoft updates, keeping on top of these pose a real headache to most IT departments. We’ve got to a state where traditional testing processes and tools are too cumbersome and development is pulling away. Testing becomes the bottleneck. We don’t need test assets which have cost companies thousands of dollars and man-hours to develop. What the business needs now is test assets that are quick and easy to develop, that can be re-used or adapted easily, or can be discarded without a second thought. So Why Throw Such Perfection Away? Now it would be foolish to dispose of the entire concept purely based on what came before. We need to recalibrate our expectations and remind ourselves of excellent potential benefits from test automation, if only the capabilities were delivered in a form usable by all. The ability of any automation technology to adapt to changes in the underlying application will always have some limitations. Is it reasonable to expect that a test script created for a legacy mainframe application to still be valid on the replacement .Net WPF architecture? Can you expect the test scripts created for the English version of your web site to be applicable to the newly developed Japanese version? By freeing automation from the burden of a script based on code, we can begin to imagine a solution that could be used by subject matter experts and not limited to frustrated developers, a solution that could adapt to changes in the application under test, an intelligent solution that inherently understood the application under test, removing the need to develop logic in addition to the validation itself. The exciting thing is that modern automation goes a surprisingly long way towards addressing these needs. But do not let that op-

www.agilerecord.com

29

timistic outlook hide the core issue – at some point the application, environment or business will change in such a fundamental way that the existing test assets have little or no value. If that loss represents an investment in intellectual property, resource and time at a level so large that there is no appetite to redevelop those assets for the version of the application, then automation will have failed. Thus we arrive at the acid test – if it is deemed easier to return to a manual test approach, then automation has failed and deserves to be thrown away. Summary Test automation has failed to date simply because we could not afford to throw it away. Creating any form of automation takes effort and time, when the application under test changes and the automation ceases to work you are faced with a stark choice – either maintain it at additional effort and time or abandon it. If you abandon it, you are also writing off the effort and time you invested in creating it, thus bringing the whole concept into question. The reality is that you have to be in a position to throw away the automation you have created, as sooner or later the application will change in such a way that no amount of automatic healing can tackle. So by definition, the creation of the automation must have been so fast and painless and the investment minimal, that you can afford, both financially and emotionally, to throw it away. Think about your own test assets? Can you even estimate the cost in time and effort in building them? How constricted are you by that investment? Can you hand on heart claim that you don’t grimace every time you have to throw them away? ■ * From: http://www.altimetergroup.net/

30

www.agilerecord.com

> About the author George Wilson is Operations Director responsible for sales, consulting services & product support delivery to Original Software’s worldwide client base. Another founding member; George’s strong software quality and customer care orientation is reinforced by extensive software product and large-scale development project experience within many areas of IT. He has helped shaped the solutions Original offer today with practical experience from the field, combining well with Colin’s insight and innovation. An engineer by training, his background served him to great effect at Osprey Computer Services (to 1995) where, as a main board director, he drove development and marketing of new applications into new markets for the company. Later, as Business Group Manager at AIG Computer Services, George rapidly broadened his platform experience, simultaneously managing IBM Midrange, NT and PC development projects – in a rigorous ISO9001 and TickIT management environment, where George’s natural ‘quality evangelism’ served him well. He has been a keen dinghy sailor, enthusiastic windsurfer but these days golf seems to take precedence.

© DIREKTHIER - Fotolia.com

Test Automation in Agile Environments by Mallika Singh

I. Introduction In today’s competitive world, most of the software organizations are churning out the processes that can reduce the time to market with customer satisfaction. Whether it is Scrum, XP, Crystal or any other Agile methodology, the basis will remain the continual improvement. And this has to happen with an unclear project scope and a lot less documentation in small installments, typically referred to as iterations in Agile. With this the final outcome should be delivery on time with good ROI (return on investment) for the business. Literature available on Agile defines it this way: • Individuals and interactions over processes and tools. • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan • Being proactive rather than reactive

quirement document. And there is enough time to put the things in place, such as test case design and test bed set-up. In Agile, all this has to be decided on the go. At the end of each iteration working software must be delivered to the stakeholder. So there is a need to have a very smart approach to testing. To achieve this, no doubt well done unit testing is the foundation to any Agile methodology. If unit testing is not done properly, a large degree of code change will happen during the testing phase to fix the bugs which make the system more fragile and prone to have a higher number of defects. Since the tester is more dependent on the interaction with stakeholders and team members, the two approaches of risk-based testing and exploratory testing play a very crucial role. In a risk-based approach, the tests are performed according to priority, which helps to detect the important defects early in the test execution. This also lays the foundation for building automated functional test scripts, which can be used further for regression testing.

With all these key features about Agile, the testers get much less time for testing. The discussions below uncover some of the challenges to tackle.

III. Role of the Tester in Agile Environments

II. Role of Testing in Agile Environments

An agilist tester needs to be proactive rather than reactive. There needs to be a change in the mindset of testers to adopt the Agile way of working and thinking.

Requirements in Agile testing are specified as user stories. To make up an effective agile methodology, acceptance criteria should be a part of user stories. Acceptance tests check each iteration to verify that business values are present. This way they start to also serve as a documentation of customer requirements. Commonly in Agile practices, yellow sticky notes are used for the active user stories, orange sticky notes for tests in progress, and the red sticky notes are bugs reported during daily stand-up meetings.

In an Agile environment, the tester needs to think analytically in order to find difficult bugs earlier in the execution. The real challenge for the tester lies in the fact that requirements keep on changing; the very evidence for this is constant bug reports getting rejected. In a traditional development environment this is considered not a positive sign for testers, whereas in Agile methodologies the tester is evaluated not on the number of bugs but the quality of the product.

The challenge for testing in Agile is that the short iterations do not allow test systems to be in place. In waterfall or any other traditional model, the test cases are written on the basis of the re-

The change in attitude is required for the whole team that is working in an Agile way. Whereas testers need to be precise and consistent, the team should also try to implement variation

www.agilerecord.com

31

through different test techniques and methodologies, especially since there is no test strategy that could resolve the issue of changing system. Testers working on Agile projects should be able to understand the root cause analysis of problems (e.g. a similar bug that occurs in consecutive releases). To do this, a sound knowledge of software development will help. It is also required for the tester to be close to the developers and users to work towards the final release of a bug-free and stable product that will satisfy the customer.

The key to tackling these limitations would be to find out the scenarios that will fit into automation. The solution could be to do manual testing initially for the first few iterations, and to then develop automated regression test scripts with the right set of scenarios. These can then be executed in consecutive iterations and also before the final release. This is illustrated in Figure 1.

IV. Test Automation in Agile Environments To keep up with the pace of developers, test automation is required in any project following any of the Agile methodologies. Automation in early stages of an Agile project is a tough job, but as the system evolves there are parts of the application that become stable and can be used to develop scripts that check the functionality of application. Otherwise opting for an automation very early could become a chaotic, unstructured and uncontrolled venture. Here the maintenance of scripts will become another major task of the tester, and the crucial areas to be tested will be left aside. As the code that worked in the last iteration gets modified in consecutive releases, the risk of regressions is higher in Agile methodologies. Therefore it is very important to pick up the right areas as candidates for automation. Areas, which are repetitive, are obvious candidates for test automation. Automated regression scripts can also help. These will check faster to ensure nothing has been broken, as more stress id put on high-value critical paths and on the standards parts of the application. V. Choice of Automation Tools Once it has been decided to automate testing (or parts of it), it is very important to do a feasibility check beforehand to see which automation tool(s) should be used. Whether it is a commercial, open-source or home grown tool, all of these come with a set of limitations. Commercial tools such as IBM Rational, Functional Tester, or hp Mercury Quick Test Pro are some of the best tools available to do functional testing, and they are compatible with most of the latest technologies used. However, the limitation is that most of these record and playback tools work on test last kind of scenarios, whereas Agile is all about testing early and testing continuously. Also the cost of the licenses might be prohibitive. Open-source or home grown tools will need a lot of modification before they suit the need of an application, where changes happen frequently depending on the regular inputs from the customer. Moreover, if scripts are developed which are based on screen content and location, they are inflexible and expensive to maintain. 32

www.agilerecord.com

Figure 1

VI. Conclusion Since testing is a very crucial part of an Agile environment, it is very important for a tester to have the right attitude to keep up with rest of the team and the stakeholders. Testing should be automated to reach the objective of adopting the Agile methodology and to deliver faster. This can be done by opting for the right tool within a feasible framework and by selecting the right set of tests to automate. ■ References [1] Addison Wesley, “Software Test Automation”, 1999. Available at: http://www.stickyminds.com/books.asp?Objec tId=299&Function=DETAILBROWSE&ObjectType=BOOK [2] Geek Interview, “Testing articles”, Available at: http://www.geekinterview.com/articles/61 [3] Bret Pettichord, “Success with Test Automation”, 2001, Available at: http://www.io.com/~wazmo/succpap.htm [4] Kent Beck, “Introduction to Test Driven Development (TDD)”. [5] Dan Lavender, Pete Dignan “Test Automation with Open Source Tools in an Agile SDLC Process”

> About the author Mallika Singh is an ISTQB and Rational certified tester working with Infosys Tools Group, Bangalore, India. She has a master degree in Bioinformatics and started her career as a tester in 2003. Her core area of work is Automation Testing and deploying of effective Automation accelerators to deliver effective solutions to clients.

Agile

TESTING DAYS

Agile Testing Days 2010 © iStockphoto.com/naphtalina

4–7 October 2010, Berlin

The Agile Testing Days is the European conference for the worldwide professionals involved in the agile world. We chose Berlin, one of the best-connected capitals in Europe to host this event due to the affordability/service ratio for hotels and flights. Berlin also offers a lot of fabulous sights to visit in your spare time. Please have a look at the program at www.agiletestingdays.com and enjoy the conference!

Agile

TESTING DAYS Berlin, Germany

October 4

Tutorials

Lisa Crispin

Janet Gregory

Elisabeth Hendrickson

Stuart Reid

Isabel Evans

Linda Rising

Michael Bolton

Jennitta Andrea

Anko Tijman

Eric Jimmink

Shane Parkinson

Pekka Klärck

Juha Rantanen

Janne Härkönen

October 5

Conference

Day 1

Track 1

Track 2

Track 3

08:00

Opening

09:30

Keynote – Lisa Crispin Incremental Scenario Testing: Beyond Exploratory Testing

Experiences on test planning practices in Agile mode of operation

Matthias Ratert

Eveliina Vuolli

11:30 11:50

a Díaz & Hilterscheid Conference

Testing Web Applications in practice using Robot Framework, Selenium and Hudson

Mike Scott

Thomas Jaspers

Test Driven Migration of Complex Systems

Making GUI Testing Agile and Productive

Real World Test Driven Development

Dr. Martin Wagner and Thomas Scherm

Geoffrey Bache

Emanuele DelBono

Continuous Deployment and Agile Testing Alexander Grosse

Acceptance Test Driven Development using Robot Framework

Talk 5.2

Pekka Klärck

Lunch

14:20

Keynote – Linda Rising Test Center and agile testers – a contradiction? Dr. Erhardt Wunderlich

Reinvigorate Your Project Retrospectives

Error-driven development

Jennitta Andrea

Alexandra Imrie

16:20 16:40

Testability and Agility – “Get your quality for nothing and your checks for free” Break

12:50 15:20

Track 5 – Vendor Track

Registration

09:25 10:30

Track 4

Flexible testing environments in the cloud

Talk 5.3

Jonas Hermansson

Break Solving the puzzles of agile testing

Structures kill testing creativity

Matthew Steer

Rob Lambert

Integration Test in agile development

Waterfall to an Agile Testing Culture

Anne Kramer

Ray Arell

17:40

Keynote – Elisabeth Hendrickson

19:00

Chill Out/Event

Talk 5.4

Agile

TESTING DAYS Berlin, Germany

October 6

Conference

Day 2

Track 1

Track 2

Track 3

08:00

Track 4

Registration

09:25

Opening

09:30

Keynote – Michael Bolton

10:30

Top 10 reasons why teams fail with ATDD, and how to avoid them

Agile hits Formal – Development meets Testing

Gojko Adzic

Matthias Zieger

A lucky shot at agile? Zeger Van Hese

TDD vs BDD: from developers to customers

How can the use of the People Capability Maturity Model® (People CMM®) improve your agile test process?

Mitigating Agile Testing Pitfalls Anko Tijman

Maximizing Feedback – On the importance of Feedback in an Agile Life Cycle

12:50

Lunch

14:20

Keynote – Stuart Reid Alternative paths for self-education in software testing

Hitting a Moving Target – Fixing Quality on Unfixed Scope

Fully Integrated Efficiency Testing in Agile Environment

The Flexible Art of Managing a Multi- layered Agile team

Cirilo Wortel

David Evans

Ralph van Roosmalen

Shoubhik Sanyal

16:20

Talk 5.2

Lior Friedman

Cecile Davis

16:40

Talk 5.1

Break

Alessandro Melchiori

15:20

The Leaner Tester: Providing true Quality Assurance Hemal Kuntawala

11:30 11:50

Track 5 – Vendor Track

Talk 5.3

Break Mastering Start-up Chaos: Implementing Agile Testing on the Fly Christiane Philipps

Building Agile testing culture

Implementing collective test ownership

Emily Bache and Fredrik Wendt

Eric Jimminik

Markus Gärtner

17:40

Keynote – Janet Gregory

19:00

Chill Out/Event

October 7

Open Space

Alternative paths for self-education in software testing

Exhibitors

Open Space hosted by Brett L. Schuchert. Day 3

Track

08:00

Registration

09:25

Opening

09:30

Keynote – Isabel Evans

10:30

Open Space

11:30

Break

11:50

Open Space

12:50

Lunch

14:20

Keynote – Jennitta Andrea

15:20

Open Space

17:20

Keynote – Tom Gilb

18:20

Closing Session

Agile

Record

Talk 5.4

Agile

Please fax this form to +49 (0)30 74 76 28 99 or go to http://www.agiletestingdays.com/onlinereg.html.

TESTING DAYS Berlin, Germany

Participant

Billing Address (if different from participant)

Company:

Company:

First Name:

First Name:

Last Name:

Last Name:

Street:

Street:

Post Code:

Post Code:

City, State:

City, State:

Country:

Country:

Phone/Fax:

Phone/Fax:

E-mail:

E-mail:

Remarks/Code:

Tutorial (4 October 2010) Making Test Automation Work on Agile Teams by Lisa Crispin

The Foundations of Agile Software Development by Jennitta Andrea

A Rapid Introduction to Rapid Software Testing by Michael Bolton

Testing2.0 – agile testing in practice by Anko Tijman & Eric Jimmink

A Tester’s Guide to Navigating an Iteration by Janet Gregory

Managing Testing in Agile Projects by Stuart Reid & Isabel Evans

Patterns for Improved Customer Interaction/Influence Strategies for Practitioners by Linda Rising

Agile Transitions by Elisabeth Hendrickson

Executable Requirements in Practice by Pekka Klärck, Juha Rantanen & Janne Härkönen Tutorial by Shane Parkinson

750,– EUR (plus VAT)

Conference (5–7 October 2010) 1 day (first day)

550,– EUR

3 days

1 day (second day)

550,– EUR

2 days (first and second day) 1.100,– EUR

1 day (third day)

350,– EUR

1.350,– EUR

Included in the package: The participation at the exhibition, the social event and the catering during the event.

Settlement Date Payment becomes due no later than at the start of the event.

Notice of Cancellation No fee is charged for cancellation up to 60 days prior to the event. Up to 15 days prior to the event a payment of 50 % of the course fee becomes due and after this a payment of 100 % of the course fee becomes due. An alternative participant can be designated at any time at no extra cost.

Liability Except in the event of premeditation or gross negligence, the course holders and Díaz & Hilterscheid GmbH reject any liability either for themselves or for those they employ. This particularly includes any damage which may occur as a result of computer viruses.



Date

1.350,– EUR (plus VAT)

Applicable Law and Place of Jurisdiction Berlin is considered to be the place of jurisdiction for exercising German law in all disputes arising from enrolling for or participating in events by Díaz & Hilterscheid GmbH.

Signature, Company Stamp

© Morpheus - Fotolia.com

The Visionary Story Teller by Geert Bossuyt

This story tells you how to fulfill Product Owner responsibilities in the most interactive and efficient way. To make a clear distinction between the known Product Owner role and this implementation of the Product Owner role, the new guy is called the “Visionary Story Teller”. As many things, this is not a silver bullet, and therefore it is not implementable in every situation. But keep in mind that when you have the opportunity to do so, you will gain enormous productivity, achieve the highest quality and deliver faster than ever before. Eliminate the overhead in Scrum Agile, SCRUM and Lean each have their own philosophy with their own basic ideas. Agile, in its heart, is about getting feedback: Interaction between people to deliver working software in close collaboration with the customer delivers good and early feedback, which leads to adapting the plan if needed. This is exactly what Scrum does. All Scrum roles and practices are meant to achieve closer interaction or getting quicker and better feedback. Scrum is an Agile implementation with a strong focus on close interaction and collaboration. On the other hand, Lean, in its core, is about eliminating as much waste as possible. Similarities between Scrum and Lean are easy to see. Self-organizing teams are the Scrum equivalent of the Lean flexible teams. Kai Sen comes alive through the follow-up actions of the retrospective, etc. That is not the topic of this article. This article is about implementing Scrum in a Lean way. It is about getting the benefits from Scrum without the waste. How to achieve this will of course strongly depend on your specific organization and the specific people guiding the change. However, some patterns can be described.

What is waste? If we want to talk about waste, we should agree on the definition of ‘waste‘. For now, ‘waste’ is defined as ‘any action or interaction that doesn’t directly lead to business added value’. In this definition, waste in the Scrum process can be found in different places. In fact, most of the Scrum process would be considered ‘waste’ when applying the above definition. Let’s take a look at the retrospective. Does having a good retrospective lead to business added value? No, it does not. It might lead to doing things smarter in the following Sprint, so that the next Sprint will deliver more or better business added value, but the retrospective in itself does not deliver any business added value. Is the retrospective to be considered waste then? No, it sure is not. Without doing good retrospectives, you will loose a lot of business added value because of their contribution to improving the cycles. Therefore the definition of waste should be ‘Waste is any action or interaction that doesn’t lead to business added value or where no business added value is lost, when not doing it’. Does the Product Owner deliver real business added value? Looking at Scrum, most of the potential overhead is in the Product Owner part. Although a definite must-have in many organizations, the role of the Product Owner and its artifact do not deliver any direct business added value. The art of describing the needs of the business in implementable stories is really hard, and sometimes these Product Owners are the true heroes that empower the team, but still … it does not deliver any real business added value. What about the second half of our definition of “waste”? Would any business added value be lost if there was no Product Owner? Anyone implementing Scrum somewhere should ask himself and the organization this question. Filling the product backlog may

www.agilerecord.com

37

seem a sine qua non, but it really is not. It’s worth investigating how to implement Scrum in your organization without implementing the Product Owner role. What questions should we ask ourselves to be sure we really need a Product Owner? • What is it that a Product Owner should bring me? • Are there other ways to tell my teams what to do? • What format of my product backlog can I imagine that would contain the lowest overhead possible? Can I imagine … • Can I create a team that is able to understand business needs and priorities? Many good Product Owners work hard to have the top of their product backlog ready for Sprint planning sprint after sprint. It’s hard work to stay ahead of the team, preparing stuff so the team can implement real business added values as fast as possible. During the Sprint a Product Owner should be available at all times to answer the questions of the team, and at Sprint end, the Product Owner also needs to acknowledge that the team has built what he’s asked for. To me this sounds like an awful lot of work for one person. That’s why I’ve seen teams of more than 20 people, called “ready teams”, working hard to make the Product Owner miracle come alive. Struggling to keep ahead of the team and then struggling even more to explain their user stories to the team, the Product Owner hardly has any time left to answer the team’s questions during Sprint, and certainly not to test delivered software. To be sure the team does build the right thing, user stories are extended with stuff like acceptance criteria, how to demo, GUI descriptions, etc. Where did the interaction go? What about collaboration? Sounds a bit like waterfall, don’t you think? Another, even bigger issue with the Product Owner role is that Scrum teams should be responsible for the result. They should feel it as their responsibility to understand the business needs, because that’s the only way they are able to slice these needs into buildable bits. With a good Product Owner on the project, the team can sit back and wait for new slices to be presented. If the PO is too slow, teams blame him for not being fast enough and feel that it is not their fault when a Sprint is not really delivering anything useful. Where did ‘Let the team decide!’ go when the Product Owner decides just about everything. Everything  – from the slicing of the product up to deciding whether it has been implemented correctly? A good Product Owner makes teams lazy. This is unacceptable. So, what can be done? How to eliminate the Product Owner waste: A Product Owner should be responsible for 4 things. No more, no less. 1. Enlightening the project vision 2. Telling the story 3. Giving the team feedback on their work, and 4. BEING THERE.

38

www.agilerecord.com

A team also has responsibilities: 1. Understand the Product Owner 2. Do the work 3. Learn from feedback, and 4. Feel responsible for the result.

What does this mean? A Product Owner must have a clear vision of the project. The vision statement should be there and visible in all places. Everyone that is, even slightly, involved in the project should know and understand this vision. It’s not just a statement. It justifies every action in the project. Everyone must understand the vision. Understanding the vision is no guarantee to build the right system, but not having a clear vision is almost a guarantee for building the wrong system. Each vision can be realized in different ways. The vision tells you something about the problem and something about the ultimate goal for the project, but it does not explain how the system will behave and what to do with the dozens of micro-problems the team must conquer. Therefore the Product Owner must tell the story.We already call them “user stories”, so let’s tell them. A good Product Owner should be a story teller with a vision. The “Visionary Story Teller”. Someone who can fascinate people and make them enthusiastic for the product. Telling the story must lead the team to real understanding of the business needs, and will put the team (back) in the driver seat. Remember, the team is responsible for the result. As in every good story, there is a start and an end, there is the red line and the details, there are actors and a plot, and most of all there’s some good action! The Product Owner has the skills to tell the story in a way that enables the team to write it down. User story by user story, or slice by slice, depending on the technique you want to use. Actors, benefits, actions, it all should become clear by listening to the story. This is part of “Do the work”. While the team does the work, the Visionary Story Teller can spend his time on rethinking parts of the story, answering questions, giving feedback on some other work delivered by the team, or by another team. Or he can have discussions with other stakeholders, etc. In short, the Visionary Story Teller has time again to interact, and most of all, team and story teller are working together on the same thing. No more running to stay ahead, but getting things done together. This will deliver extreme focus and efficiency to the project. Depending on your organization, you can choose to have the team write down the stories before implementing or just go to implementation right away. Real feedback only comes based on working software, but you need a lot of trust and flexibility in your organization to work like this. Naturally, as you will have already noticed, to accomplish the above, your team should not only consist of developers, DBAs

and QA people. You should probably add an analyst and an end user to your team. I don’t believe every team can do anything, but I do believe you can always construct a team that can do everything.

As a final remark I would like to state that you should always strive to the highest quality possible. Quality without compromise! Look for opportunities to do things better, faster or cheaper, but without reducing the quality of your product! ■

So, is the Product Owner complete waste? Definitely not. It’s not hard to imagine circumstances where it is impossible to accomplish the complete elimination of waterfall actions. When time consuming specialized research is needed or when a true cross-functional team cannot be created, the Product Owner role in its conventional implementation can still be of great use. In these cases this is not a problem, because ditching the Product Owner under such circumstances would lead to a loss of business added value, and therefore is not to be considered “waste”. Ideal circumstances for a Visionary Story Teller would inlcude: • The project must have one single vision • The team only serves one vision • The team is truly cross-functional, and thus capable of deeply understanding the business and its needs. • There is an atmosphere of trust, or • there is enough urgency to rectify this approach because of its extra boost to delivery speed. Even in less ideal circumstances, a Visionary Story Teller or parts of this pattern can be implemented to gain efficiency and to deliver real business added value faster than ever. Try to add an end user to your teams and pick your Product Owners not based on their writing skills or their authority on deciding priorities, but on their story telling skills and the art of persuasion. Choose to bring the Visionary Story Teller alive wherever you can, and benefit from the boost of efficiency and the shortest time to market ever. What else? The next steps toward hyper-focus will include having a look at some other roles and parts of Scrum that don’t deliver direct business added value and that, under certain conditions, do not cost anything when skipped or transferred to a lighter version. Think about: • Testing. When Teams really take on their responsibility, testing effort should be minimal (zero error tolerance from Lean). • Sprint Review. When the Product Owner has time to be around, he should give feedback and approval story by story. The Sprint review becomes obsolete. • Definition of Done. What is in your “Definition of Done” that does not really brings any business added value. Which of these would not cost you any business added value if you didn’t do them, or did them differently with lower effort?

> About the author Geert Bossuyt is Agile Consultant and Agile Coach at Xebia, the leading Agile company in The Netherlands. Geert has 12 years of experience with ICT projects in different roles such as Java consultant, test coordinator, project leader and project manager. For the last 3 years, he has worked as Scrum Master and Agile Coach in companies like LeasePlan/The Netherlands, Unive and De Nederlandse Bank, with amazing results in guiding the change process that goes naturally with an Agile implementation. He is a passionate speaker and knows how to bring out the best in people. In his work, he guides teams and organizations to a higher level of focus and efficiency by letting them experience the real power of working TOGETHER.

www.agilerecord.com

39

© Clivia - Fotolia.com

The Agile Bible by Simon Romans

Part 2

Read the first pa rt Agile Record N in o. 2.

Creating Story Cards

Story cards are used throughout an Agile project. They are created, sometimes from the client’s requirements, at the pre-project planning stage; re-estimated at the sprint planning stage; used to develop, test and demo the functionality during a sprint demo. They are the glue of the project. So it is essential that they are well-written. The following elements can be on a story card: • Theme • Title • Story Number • Story Complexity

_number.story_number’ i.e. 1.1 = theme number one, story number one, 1.2 = theme number one, story number 2, 2.1 = theme number two, story number one etc.

• Story Description • Linked Requirement Number(s) • Acceptance Criteria

Theme: Giving each story card a theme helps when picking stories for sprints. It keeps stories in categories and allows you to group stories together when scheduling work for the next sprint. Try to keep the dependencies soft not hard. For instance a theme would be ‘Payment’ and have stories relating to the payment page but can be developed independently from each other.

Diagram 2.0: back of card

Story Complexity: Complexity points also known as story points are used to gauge how long the story will take to develop and test. The complexity point scale consists of 0,1,2,3,5,8,13,21. Complexity points are covered in more depth in chapter two. Story Description: When writing a story description stick to one format across projects. This allows team members to move from one project to another more efficiently. Story descriptions have three elements: • Role – the individual or team that will benefit from the feature • Goal – what the individual or team is aiming to achieve • Value – what the individual or team benefits from the goal For example:

Diagram 1.0: front of card

Title: When talking about a story card it can be difficult to visualize which story someone is talking about when using story numbers. Adding a title gives a clearer indication of what piece of functionality is being talked about. Story Number: A story number is an optional element for a story card. It is used in the traceability matrix to map story cards to client requirements. Story numbers can be in the form of ‘theme 40

www.agilerecord.com

Diagram 3.0: front of card

The whole team should write story descriptions. The product manager can represent the client if not present.

the acceptance criteria they can stop development. The product manager or client uses the acceptance criteria during the sprint demo to verify what has been delivered.

The Six Rules Independent: Stories should be as independent as possible from each other. Dependencies can lead to estimating, planning and prioritization problems. If stories are dependent on each other then combine them into one larger story and add acceptance criteria for the combined parts. If the combined story is too big then think of a different way to split the story. Negotiable: A story should open up conversation between the team. If a story is written in a way that is set in concrete then the team is less likely to debate when anyone believes it is the wrong way to create the feature. Client requirements should be covered in the acceptance criteria.

When writing acceptance criteria try not to write them as questions. “Is the user allowed to login with a user name and password?” This leads to problems when testing. A tester would not know if it passes when the statement is true or is false. It would be better written without ambiguity. For instance “The user is allowed to login when entering a valid user name and password“.

Valuable to business or client: Product features should have some value to the business or client. For instance a feature brings an increase in revenue or customer satisfaction. Estimable: The developers and testers should be able to estimate the story. If the story is too big or the developers/testers lack the knowledge, the story may not be estimable. Small: If a story is too big it can be un-estimable or take a number of days to complete leading to nothing being released at the end of the sprint. Small stories need to be independent so if there is a necessity to create a big story then task out the story. In this way progress can be seen on the storyboard. Testable: If the story is unable to be tested then it is hard to prove that the functionality is working. The acceptance criteria should be able to be proved through testing.

Linked Requirement Number(s): Stories can be written from the client requirements. By adding the requirement numbers to the story card any changes to the card can be cross-referenced against the requirements, removing or adding requirements as necessary. The traceability matrix tracks story cards against requirements to make sure all requirements have story cards written for them. Acceptance Criteria: Acceptance criteria are written on the back of the story card. The acceptance criteria expand on the story adding more detail. Both the developers and testers use the acceptance criteria to prove the story cards goal has been met.

Diagram 5.0

From a tester’s point of view acceptance criteria are the minimum requirements to pass the story, however exploratory testing outside the acceptance criteria may still be done. Developers use acceptance criteria to further understand the story and to know when to stop developing. In other words once they have met all the acceptance criteria they can stop development. The product manager or client uses the acceptance criteria during the sprint demo to verify what has been delivered. When writing acceptance criteria try not to write them as questions. “Is the user allowed to login with a user name and password?” This leads to problems when testing. I tester would not know if it passes when the statement is true or is false. It would be better written without ambiguity. For instance “The user is allowed to login when entering a valid user name and password“. Too Big/Too Small Too Big: when a story is too big there is a risk that the story won’t get completed during the sprint. Big stories are also difficult to estimate. Tasking a big story out can help to understand the story and even help in splitting the story into two smaller ones. Too Small: when stories are too small they can end up with dependencies on other stories. This makes them difficult to estimate without estimating them as a group of small stories. Pull them together into one bigger story.

Feature Rich Diagram 4.0: back of card

From a tester’s point of view acceptance criteria are the minimum requirements to pass the story, however exploratory testing outside the acceptance criteria may still be done. Developers use acceptance criteria to further understand the story and to know when to stop developing. In other words once they have met all

When creating stories consider if the features are really going to be used. Adding more and more features to a product can create a very feature rich product but will these entire set of features be used?

When first creating story cards they should not contain too much detail. This is so they can be created quickly in the pre-project planning meeting and are simple to alter when requirements change. During the sprint planning meeting more detail can be www.agilerecord.com

41

added so estimating is more accurate and acceptance criteria can be expanded on. Big stories are given even more detail by tasking them out. Then finally during development the fine detail is talked over by the developers and the feature coded.

Global cards can also be used as a reminder that an acceptance criterion applies to all cards with a certain theme. For instance a browser compatibility global story card would remind the team to test GUI’s on IE7, IE8 and Firefox.

Global and Bug Story Cards

On the back of a global story card the acceptance criteria should be written as a checklist of things to remember.

Global Story Cards Bug Story Cards Global story cards can be used as reminders to add acceptance criteria to the back of cards. For instance performance acceptance criteria may be needed on all stories that contain a client performance KPI.

When fixing bugs the developer should time box a bug fix to 3060 minutes. If the bug looks like it will take longer then download keyboards and write a bug story card for the bug. The bug story should then be estimated, given a complexity and tracked in the sprint burndown. If a group of bugs is unlikely to be fixed during the sprint then create a bug story card for the group of bugs. Add the bug summaries as acceptance criteria to the back of the story card and estimate the complexity.

Diagram 6.0: front of card

Diagram 7.0: back of card

Diagram 10.0

The Storyboard The Storyboard (Diagram 11.0)

Diagram 8.0: front of card

The focal point of an agile project, the storyboard tracks the progress of the current sprint. Daily standup meetings are held in front of the storyboard, using the storyboard as a visual aid while each team member talks. The main bulk of the storyboard is the swim lanes that show the progress of story cards, tasks and bugs in the current sprint. Other elements to a storyboard can be: Backlog/Check In Mostly contains story cards which still need to be worked on, but can contain tasks and bugs. Automation/ Cucumber Patch

Diagram 9.0: back of card

42

www.agilerecord.com

Story cards, which require more automated regression tests, are placed here. The story cards should have at least been exploratory tested. The test automation tools Cucumber (www.cukes.info) and CubicTest (cubictest.seleniumhq.org) will be covered in another chapter.

Diagram 11.0 Bug Corral

Lower priority bugs (P3 and P4) are placed here. They can be moved to the ‘Not Started’ swim lane if they need to be fixed in the current sprint.

Questions

Any questions that are raised during the day can be placed on the storyboard to be answered at the next stand-up meeting.

Impediments

Anything holding up stories or interrupting the flow of the sprint can be placed on the storyboard to be talked about at the stand-up meeting.

Sprint Burndown

Drawing the sprint burndown on the storyboard allows the team to see if the velocity of the sprint is going to be met.

Team Holidays

Tracking team holidays/sick days on the board allows for better velocity tracking at the next sprint planning meeting.

Swim Lanes Swim lanes are used to keep track of the progress of work across the storyboard. They are generally labeled ‘Not Started’, ‘In Progress’, ‘Done’ and ‘Done Done’, however they can be labeled in a more fun way, for instance ‘Departure Lounge’, ‘In Flight’, ‘Customs’, ‘At Beach’. Not Started

Work to be completed during the current sprint is placed in the swim lane. This can include story cards, tasks and bugs.

In Progress

Any story card, task or bug that is currently being developed is placed in this swim lane. The swim lane can be broken down into ‘pair’ and ‘single’ to show which work is being done by pair programming and by a single developer.

Done

Once development is complete and the story card, task or bug is ready to test, it is moved to the swim lane.

Done Done

The story card, task or bug has been passed by testing and is ready to demo to the client.

The Sprint Burndown Chart (Diagram 12.0) The sprint burndown chart is used to give a quick overview of the sprints progress. The team can use the chart to track their velocity and see if they are on or ahead of their target velocity. When a team is tracking ahead do not add more work until all the story cards have been ‘Done Done’. Only then bring in more work from the backlog. This can be tracked on the sprint burndown as shown in Diagram 1.0. When a team is tracking behind the product manager needs to access what is delaying the team. The story cards should have been prioritized so at least the high priority cards should be completed. If a deadline is looming and all the story features are required then something may need to take hit until the next sprint. Bear in mind anything that does not get completed in a sprint becomes agile debt and needs to be scheduled in for the following sprints. The following is a list of things that could be done to hit a deadline: • Stop creating automated regression test cases (Cucumber Tests) • Stop fixing minor and medium bugs • Reduce stand-up meetings to 5 minutes • Increase knowledge by bringing in people who know about the product features • Stop interrupting the team • Remove features • Stop pair programming The sprint days are listed along the X-axis of the burndown chart and the velocity points along the Y-axis. During each morning stand-up count the remaining story complexity points and add www.agilerecord.com

43

progress to the stakeholders and track progress on the project. At minimum the project burndown chart should contain ‘story points left’ and ‘story points completed’, however this type of chart does not track extra story cards added to the project.

Diagram 12.0

them to the burndown chart. If the team completes all the stories then take the highest priority story(s) from the backlog and track them on the burndown chart.

Diagram 14.0 shows a project burndown chart tracking completed points, outstanding points and points added. To complement the burndown a chart that tracks estimated against actual sprint velocity can be created (see Diagram 13.0). These types of charts can be used historically to estimate future projects. Release Early/Release Often

At the end of the sprint the actual team velocity is added to the project burndown chart. On-Site Customer In an ideal world the client will be able to base a person where the agile team are working, however this is mostly not the case. Without the client being deeply involved it is difficult to end up with a product that the client wanted.

In Agile the short development/test cycle allows the team to release more often. Each cycle releases a small part of the bigger project. Cycles (Sprints) can be from 1 to 4 weeks long. Releasing in this way improves communication between the product managers, developers and testers as they collaborate on the development of the client requirements.

It is important to involve the client when story grooming and for sprint demos. The product manager can represent the customer on a day-today basis and can represent the customer when story grooming and in sprint demos but they would need to be very confident in their knowledge of the client’s needs.

The Project Burndown Chart (Diagram 14.0)

Diagram 15.0

Stand-up Meetings and Sprint Retrospectives Agile Feedback

Diagram 13.0

Feedback is an important factor for an Agile project. Feedback from daily stand-ups allows the team to react to impediments and refine the work within the sprint. Sprint retrospectives allow the team to feed information into the sprint planning meeting so they can re-prioritize the backlog, adjust deadlines, remove low priority features, put on hold less important work so deadlines can be met. Project retrospectives allow the team to assess if the agile processes are working, add, adjust or remove processes so the next project will be more likely to create continues delivery of working software. Agile Process Selection and Review

Diagram 14.0

There are many ways to display data on the progress of a project. The product manager should decide on the best way to report 44

www.agilerecord.com

When selecting an agile process two rules should be applied. The process needs to be simple to understand and implement and the process needs to be measureable to gauge its effectiveness.

Agile processes should be constantly reviewed to see if they are working. When a process is not effective then look at ways to improve the process or alternatively replace or remove the process. Simple – Embrace simple processes Measurable – Track process effectiveness Improvable – Recognize constant room for improvement

times. May have forgotten what they did the day before. • Lunchtime: • Advantages – helps keep the stand-up length short, as team members will want to be quick so they can have lunch. • Disadvantages – breaks the flow of work by splitting the day into two sections. • End of the Day: • Advantages – Allows the team to start as soon as they arrive in the morning. Team can leave with a sense of closer on the day’s work, ready to start fresh in the morning. • Disadvantages – the next day the team may have forgotten what they planned to do that day. Some teams hold a 2nd stand-up that allows the team to rearrange programming pairs and inform the product manager of impediments that need resolving. Stand-up meetings are best held around the storyboard and should be at the same time each day with the whole team. Each developer and tester in turn talks about three items: 1. What have I completed since the last stand-up. 2. What I intend to complete before the next stand-up. 3. What impediments are holding up my progress?

Diagram 16.0

Sprint Demos At the end of each sprint the finished features should be demoed to the client or product manager representing the client. Before the sprint demo the developers should carry out some preparation so the story cards can be confirmed as finished. Each story card should be taken in turn and acceptance criteria, that has some value to the client, should be picked from the back of the story card. Scripts should be written to prove the story card has been finished. Notes should be taken on how to demo the functionality to the client. To help speed up the demo preparation, while developing the stories scripts can be created to demo the acceptance criteria. Any bugs found during the demo should be recorded and fixed before release. Client changes in functionality should be raised as story cards and flagged in the next sprint planning meeting. In Agile a measurement of progress is ‘working software’ this makes it important to always run a sprint demo to confirm working software.

Stand-up Meetings

The team should stand in a semi circle so the next person knows when to start talking. This session should be kept short to about 15 minutes or less. Everyone standing up helps to keep the meeting focused and short. After everyone has finished talking about the three items, the product manager can talk about anything the team needs to know. This could be a change in requirements, a re-prioritizing of story cards, a release timeline change, a new member joining the team etc. Testers can talk about any bugs found in the system, adding them to the ‘Not Started’ swim lane if the product manager/client requires them to be fixed in this sprint. Developer’s talk about which story cards should be pair programmed or requires just a single developer. Try to keep these conversations as short as possible and allow team members to leave if they do not think they need to hear what is being talked about. At each stand-up meeting the sprint burndown chart should be updated on the storyboard to show the progress of the sprint.

Daily stand-up meetings are a way for the team to keep communication flowing between the product manager, developers and testers; it also is a way of tracking the progress of an agile project.

Distributed Agile Teams

Stand-up meetings can be held at anytime during the day, however holding stand-ups first thing in the morning, just before lunch or at the end of the day are better for the following reasons:

Communication is Key: Agile, even more so than other development methods, requires a constant stream of communication. With daily stand-ups, planning and retrospective meetings and the day to day conversation between developers, testers , product managers and clients. Barriers to effective team communication can be time zones, language, technology and cultural differences. However with today’s technology and finding the right-minded staff these barriers can be mostly resolved.

• Start of the Day: • Advantages – Allows the team to start work with a fresh idea of what they need to do during that day. • Disadvantages  – Team members may turn up at different

Distributed teams raises the question ‘Can distributed teams deliver software as efficiently as centrally located teams?’

www.agilerecord.com

45

2010

November 22–24 Sydney, Australia

November 22

Patterns for Improved Customer Interaction & Influence Strategies for Practitioners

Tutorials

A Tester’s Guide to Navigating an Iteration

Principles of Agile Methods

Managing Testing in Agile Projects

by Janet Gregory

by Shane Parkinson

by Stuart Reid

by Linda Rising

OZ Agile Days is for all IT professionals and software testers interested in learning about Agile, or just staying ahead of the curve. Learn from the best. Over three thought-provoking days, explore new developments and key concepts as local and internationally recognised authorities share their unique experience in Agile – including North American experts Janet Gregory and Linda Rising and UK expert Stuart Reid. Please have a look at the program at www.ozagile.com and enjoy the conference!

Registration

Cost

Tutorials (Mon 22 November) Early Bird Tutorial Standard 2-Day Conference Registration Single Registration Early Bird Group Registration (5–9) Group Registration (10+) Single Registration Standard Group Registration (5–9) Group Registration (10+) 1-Day Conference Registration Early Bird Day Registration Standard

$500.00 $650.00 $995.00 $895.00 $795.00 $1,200.00 $1,100.00 $1,000.00 $595.00 $700.00

Supporting Organisations: A Díaz & Hilterscheid and Planit Conference Conference Managed by ICE Australia

November 23 Start

End

08:30

08:50

08:50

09:00

09:00

10:30

10:30

11:00

11:00

12:00

Conference Track 1

Track 2 Registration Conference Opening Keynote: About Learning Janet Gregory, Co-author of Agile Testing Morning Tea

12:00

Waterfall vs. Agile – As a Tester Are They Really that Different? Is it All in the Mind?

01:00

Andrew Hammond Moving a Major Project From Waterfall Methodology to Agile – A Testing Experience Linda Brunker

01:00 02:00

02:00 03:00

03:00

03:30

03:30

05:00

November 24 Start

End

09:00

10:30

10:30

11:00

11:00

12:00

01:00

01:00 02:00 03:00

02:00 03:00 03:30

03:30

05:00

User Stories Are a Testers Best Friend

Vendor 1

Leanne Howard, Planit Stay Agile with Model-Based Testing

Vendor 2

Jelle Calsbeek Lunch

Agile Methodologies and SoX Requirements

It’s Really Hard to Assess Soft Skills

Saurabh Chharia

Werner Lieblang

Vendor 3

Afternoon Tea Keynote: TBD Shane Parkinson, Planit

Conference Track 1

Track 2

Vendor Track

Keynote: Agile Testing Certification – How Could That Be Useful? Stuart Reid, CTO, Testing Solutions Group

Zen and the Art of Agile Testing or Being Agile without Doing Agile Matt Mansell

12:00

Vendor Track

Vendor 4

Mark Feldman

The Creation of an Agile Vendor Mitch Denny

Morning Tea Rapid-Result Tools for Test Automation: Code Generators – A Good Solution for Agile? Agile Tester: A Profession with Profile Stephan Goericke Lunch Panel Session Afternoon Tea

Keynote: Deception and Estimation: How We Fool Ourselves Linda Rising, PHD in Object-based design metrics

Vendor 5

When creating a distributed agile team consider the following as tools for increasing communication between the team: Google Wave: Real-time threaded discussions can be created using Google wave. Users can also step in and rewind the conversation at anytime. Google wave can also for share text, photos, and videos within the conversation. Can be a substitute for a whiteboard. Instant Messaging: Real time communication between two or more people using typed text. There are a number of instant messaging applications available. Select one for the whole team to use. Some IMs (MSN Messenger and Skype for example) have VoIP (Voice Over Internet) capabilities. Company Blogs: Having a company blog that can be accessed by the whole team can help with sharing information. The blog should be able to email the team when new blogs are posted or comments are added. Video/Web Conferencing: Video conferencing would be useful for sprint meetings and retrospectives, sprint demos and daily stand-ups.

• Actions (!): What should we do to resolve the things that did not go well, answer the outstanding questions and remove any remaining impediments. WWW • Released all features • No bugs in sprint demo • Got velocity right

WCBB • Some regression test cases not automated • Acceptance criteria need to be clearer

? • When will the new staging server be ready?

! • The whole team to review acceptance criteria • Review the auto regression test process

Diagram 17.0

Any outstanding impediments should be discussed in the sprint retrospective. It is the product manager’s job to remove impediments. Actions required to remove the impediments should be entered into the action section. If a large number of bugs are still in the system then the reasons why this is so should also be discussed and an action plan added to the board. ■

Shared Repositories: Developers need a shared repository for their code, testers need a shared location for their test documents and everyone needs to share tools and project resources.

> About the author Remote Desktops/Virtual Machines: can be used for the sprint demos. Everyone logs in and watches the demo on the virtual machine with one developer controlling the demo. Agile Project Software: It is difficult to keep track of story cards moving across the swim lanes or new bugs in the system. With an agile project management software team members can be emailed when a story card is updated or a new bug raised or its status updated. The Sprint Retrospective The sprint retrospective usually held on the Monday morning (see the first part of my article in Agile Record No. 2, 2-week sprint timeline) reflects on the work carried out in the previous sprint. All the team should be present, however if team members know that they are not going to be present they should send an Email to the product manager containing their comments. (See below.) The product manager controls the meeting and using a white board or flip chart draws a cross (see Diagram 16.0). The team then fills out each segment of the cross in turn starting from the top-left hand corner. The four segments consist of: • What Went Well (WWW): In the previous sprint what went according to plan, was done well. • What Could Be Better (WCBB): In the previous sprint what did not go according to plan, wasn’t done so well. • Questions (?): What are the previous sprint’s outstanding questions. 48

www.agilerecord.com

Simon Romans has worked in testing for 14 years, starting his career as a games tester at Electronic Arts and most recently working as Test Manager for Mobile Interactive Technology. At MIT Simon has set-up the testing department and was responsible for the company’s transition to Agile Development and Testing Methodologies. Simon says, “When it comes to testing it can’t rain all the time!”

© Alterfalter - Fotolia.com

Task Boards and Caution Signs!! by Sowmya Karunakaran

In the last two decades, a large number of different approaches were introduced in the field of software development. One such approach is “Agile Development”. Since its introduction, Agile has created lots of interest among practitioners, since Agile provides a solution to the software community in terms of lighter weight and flexibility and to the business community in terms of accelerated time to market. Success is possible by applying the various good practices that Agile practitioners recommend. One such practice is “Task boarding”. A task board is representative of all the work being done for the sprint. It has to be updated every day (the SCRUM Master is generally responsible for keeping it alive), and it acts as a ready-reckoner for the daily SCRUMs. A simple task board consists of dedicated rows for each story and the various sub-tasks involved in completing the story are placed in the states “TO DO”, “IN PROGRESS” and “DONE”. Additional states like “IN DEV”, “ANALYSIS”, “REVIEW”, “ACCEPTED” could be added based on the level of workflow complexity needed. One typical state is “IN QA”. A quick look at the task board gives anyone an indication of how well the sprint is progressing.

this. However, in complex environments consisting of multiple teams distributed across different locations, it can be tedious to maintain physical task boards. Most popular Agile project management tools support online task boards these days. The tools dynamically generate the task boards based on the status of the stories and tasks. In fact, in one of the teams I noticed that the SCRUM Master had cleverly made use of the notes option in Outlook using it like a task board; he had used different colored notes to indicate the status of various tasks. I’ve tried to recreate a sample (see Figure 2).

Figure 2: A digital task board using Outlook notes feature

Sample Task Board Caution Signs Figure 1: A simple task board

I have inquired with one of the Agile teams that practices task boarding in my organization about task boarding and its usefulness. The teams feel that it gives a quick snapshot of the sprint progress. Indeed, one of the team member points out that it increases the transparency within the team. Everyone in the team is able to note the progress of each other’s stories. It is quite evident that Agile teams prefer highly visible communication and coordination tools. Task boards are a great tool to accomplish

The task board contains in-built caution indicators. The Scrum Master ensures that the team acts upon the caution signs. The various caution indicators help SCRUM Masters and teams to use task boards effectively and interpret the warning signs. Not Concentrating on high priority stories Most high-priority stories are in TODO state, while the low-priority ones have been picked up and completed.

www.agilerecord.com

49

Sprint not loaded completely There can be instances where most of the work for the sprint is completed much ahead of time. Figure 5 indicates such a scenario. This could arise due to good productivity, or due to over estimation (pessimistic). Choosing shorter sprint lengths or withdrawing more stories can be a way out. Figure 3: Task board caution sign #1

It’s important to start working on top-priority stories first, since they are of greater importance to business Progress rate is slow In some cases the progress on tasks might be very slow. This could be due to impediments in carrying out tasks, or it could be due to low productivity. However, this has to be identified as early as possible in the sprint. Figure 4 shows a case where the progress is slow with the deadline approaching fast.

Figure 5: Task board caution sign #3

Choosing all high priority stories The stories that constitute the sprint backlog need to be chosen in order of priority, but for practical reasons it is better to address some stories that are of medium or low priority, since they will come in handy while a re-estimate is called for. There are many more indications that task boards can give. It’s important that the SCRUM Master and the team are watchful of this and take the necessary steps to handle the risks.

Figure 4: Task board caution sign #2

The concept of visually capturing the work and progress in the form of task boards has proven to be so useful that Scrum ex-

Subscribe at

www.agilerecord.com 50

www.agilerecord.com

perts also include the burn-downs, unplanned items and sprint goals as part of the task board and have gone to the extent of defining color coding (story cards-blue, bugs-yellow). Few other teams maintain a defect task board separately to track and fix defects.

Figure 7 shows a standard Task board view of the tool “GreenHopper”. Simple columns are populated with the issues based on the mapping that has been defined. Users will be able to drag and drop the issues from one column to another based on their permissions and the mapping. The project administrator can also add additional columns and have customized task boards to suit the specific project requirements. ■

> About the author Figure 6: Task board caution sign #4

Task boards for Distributed Teams As mentioned earlier in the article, there could be teams spread across different geographic locations, and it may become tedious to maintain and collaborate using a physical task board. In case of distributed teams, a digital picture of the task board is posted on the team Wiki, but this can get tedious with time. These days most Agile project management tools provide a virtual task board feature, where most of what can be accomplished using a physical task board can be done in a virtual way, which is then easily accessible for team members in any part of the world. It also lowers the burden of maintaining a physical task board and the required stationery, and also removes the constraint of dedicating a separate space for the task board.

Sowmya Karunakaran has been engaged in Agile software development since 2005. She has worked in different flavors of Agile, XP, Scrum, FDD, and XP/Scrum hybrid. Currently she is working as an Agile expert at the Agile Center of Excellence, HCL Technologies. She has presented many papers at various IEEE conferences and has co-authored the book “Model driven software development and integrated quality assurance”, published by the IDEA group. Her interests involve model driven architecture, Agile methodologies and Human Machine Interface computing.

Figure 7: A virtual task board view using the Green Hopper tool [Courtesy: http://confluence.atlassian.com/]

www.agilerecord.com

51

© Dmitry Knorre - Fotolia.com

SCRUM & Testing: Assessing the risks by Erik van Veenendaal

Food for thought One of the Agile methods currently being applied in many organizations is SCRUM, a method for project management that uses incremental work cycles known as sprints to provide frequent opportunities to assess and revise direction. As so often, however, it is simple but not easy! The SCRUM method doesn’t say much about testing, and in most books only unit testing and user acceptance testing are addressed. Have integration and system testing now become obsolete? Developers and business representatives should do the major part of the testing activities within Agile developments. It seems like utopia, but what does it look like in real-life? Exploratory testing is often identified as the main technique; what about our traditional test design techniques are they no longer needed? These and many more questions need to be addressed when moving from a traditional V-model type development methodology to an Agile methodology, such as SCRUM. When reading this column, you may get the impression that I’m against SCRUM, Agile development and the like. You could not be more wrong! However, I would like to point out some testing issues from practice that one encounters when starting to apply SCRUM. In other words: “food for thought” for the reader when moving from a traditional development methodology to Agile development/SCRUM. A checklist of risks that should be mitigated or at least considered during the change process. Note that most of the risk items are not even new, but were already a challenge during traditional V-model development and testing. By the way, my personal experiences are not from the games and internet industry, like many simplified stories one hears at conferences, but from more critical environments such as finance, embedded software and medical systems, where quality matters and is a key business driver. Risk item 1: Test professionals One needs to assess the current set of testers and decide whether they are “fit for Agile”.

52

www.agilerecord.com

Within Agile testing, quality is the team’s responsibility. The test analysts now have a different role. In addition to testing, they have to coach business representatives and developers on testing issues, review unit tests, etc. The tester is also involved in estimation sessions, defining the exit criteria (definition-of-done), reviewing stories and making them testable. All of this requires a senior person with good communication skills. It’s almost like we require ISTQB Advanced Level testers; people that understand and are able to explain technical testing, business testing, test design and test management issues. What do we do with our junior testers? What do we do if we don’t have senior testers with the right skills? Lisa Crispin in her book “Agile Testing” defines a number of qualities that agile testers should possess: deliver value to customers, have courage, respond to change, continuous feedback, etc. If you study those in more detail, there is little to no difference to what I would call a senior test analyst (in a traditional environment). If we analyse things, Lisa Crispin says that we need real professional senior testers with the right knowledge, skills and mindset. So what is new? Doesn’t this sound familiar? Risk item 2: Developers Within Agile software development, unit testing is essential. Why is it essential only in Agile, and why does it now get all the focus? It should have been essential in every lifecycle methodology! Can developers all of a sudden apply test design techniques? Most of them have never had any training in structured testing, not even at foundation level. Unit testing is not as easy as it seems, understanding test design is something not so common for most developers. Writing test code that makes the code fail as in XP does provide structural coverage, but not a high level of functional coverage. Getting developers into testing needs a practical approach. We at Improve Quality Services often provide workshops with hands-on real-life practical cases to get them started. Test automation, essential with any incremental development methodology, is also needed. As test professionals have already

known for years, this is still a big challenge for most organizations for various reasons. All Agile is saying is, we need high quality unit tests and fully automated regression tests. Things that have never been easy in the past. So what is new? Doesn’t this sound familiar? Risk 3: Test levels and test types Most books on Agile (testing) have a strong focus on unit testing and user acceptance testing. Whatever happened to good old integration and system testing? What about system integration testing in a systems-of-systems environment? Of course, there isn’t just one answer, since these terms mean different things in different organizations. The main problem I have with this approach is that again, after all these years, we have to re-explain to management why integration testing and system testing are needed. Caper Jones has already taught us that unit testing doesn’t get far beyond a Defect Detection Percentage (DDP) of 35% to 40%, and together with only validation-oriented use cases used in user acceptance testing, just doesn’t get the job done! Thorough test cases using, for example, decision tables or classification trees are still required in many instances. Also, exploratory testing has its limitations (sorry, James, Michael). Some test levels or test types take place outside a sprint, which seems impossible according to the Agile theory, but this is what I see successfully happening in practice. Reliability and performance testing for example are often test types that run for more than four weeks, and organizing an operational acceptance test or a system integration test within a sprint has been shown to be very difficult in practice. As a result, in practice some of the testing often takes place outside the SCRUM sprint. A major issue is then to align the testing efforts and approaches inside and outside the sprint. What needs to be done? Establish a test strategy that covers all testing activities (levels and types). To unambiguously define testing is usually a huge step in the right direction. This has been the issue in the past with the V-model and is also needed for Agile software development. So what is new? Doesn’t this sound familiar? Many more challenges The issues raised above are by no means the full risk list. I wanted to prioritize, keep it short and “write Agile”. Some other risk items to be considered: • Risk item 5: The Test Manager What happens to the test manager whose role is now obsolete? • Risk item 6: Stress If we deliver software every four weeks, there will be stressful release periods more often. What does this mean for those involved?

• Risk item 7: Distributed teams How do we organize Agile testing with distributed teams, and how does it fit with outsourcing? • Risk item 8: Management understanding Does management really understand the background to the Agile manifesto? Even within SCRUM, there are limitations to change! • Risk item 9: Business involvement How easy is it to get the right business representatives onboard and get them to do some testing? (In my experience, even reviewing test cases and providing input to a product risk analysis is often asking too much.) • Etc. The manifestos Again, I would like to emphasize I’m not against SCRUM. I’m actually a big fan of team-based working and Agile. In practice, however, it just isn’t as easy as explained in the books and presented by some of the so-called gurus. If you are able to handle some or all of the risks presented, SCRUM projects have shown to be very successful. It usually helps enormously to have a detailed discussion about the Agile manifesto with all those involved. What does it really mean? It’s all about the philosophy behind the manifesto, understanding what is meant, and not about the actual wordings. Someone who really understands the Agile manifesto may even notice that there are a lot of similarities with the test process improvement manifesto [Testing Experience, Issue 4, 2008]. • Flexibility over detailed processes • Best practices over templates • Deployment orientation over process orientation • Peer reviews over Quality Assurance (departments) • Business-driven over model-driven Most of these statements can easily be adapted to Agile software development. So what is really new? I “even” have a number of clients at TMMi levels 2 or 3, that practice SCRUM. In fact, those organizations that had the structured testing in place and/ or were at CMMI level X seem to be more successful at SCRUM than others. Again “food for thought” … I hope this short paper makes you aware of some of the testing issues that come with the implementation of SCRUM in an organization or project. Discuss them with team members inside and outside testing and management, and find practical result-driven solutions. Good luck in mastering SCRUM. ■

www.agilerecord.com

53

> About the author Erik van Veenendaal (www.erikvanveenendaal. nl) is a leading international consultant and trainer, and a recognized expert in the area of software testing and quality management. He is the founder of Improve Quality Services BV (www.improveqs.nl). At EuroStar 1999, 2002 and 2005, he was awarded the best tutorial presentation. In 2007 he received the European Testing Excellence Award for his contribution to the testing profession over the years. He has been working as a test manager and consultant in various domains for more than 20 years. He has written numerous papers and a number of books, including “The Testing Practitioner”, “ISTQB Foundations of Software Testing” and “Testing according to TMap”. Erik is also a former part-time senior lecturer at the Eindhoven University of Technology, vice-president of the International Software Testing Qualifications Board (2005–2009) and currently vice chair of the TMMi Foundation.

the tool for test case design and test data generation

© Pitopia/Klaus-Peter Adler, 2007

www.casemaker.eu

54

www.agilerecord.com

© Alexey Klementiev - Fotolia.com

Skills for SCRUM Agile Teams by Prasad Prabhakaran

Engineering uniqueness of Agile projects

4) Unit testing

1) Set up development environment

In a highly fluid environment with multiple developers, shifting requirements and changing priorities, it’s essential to ensure that what worked yesterday works today. We also had challenges with integration errors. In practice, we have learnt the hard way that we must use unit tests so that code changes do not break existing functionality. We started writing unit test cases before coding.

In a traditional project, the team can spend sufficient time in setting up the environment. In the case of Agile teams, they need to be productive from the first hour. From our experience, we have realized that the lack of documentation on setting up the development environment is a key reason why the set-up time is long. The second key reason is the number of manual steps involved in the set-up process. At sprint 0, where we document the fine details of what a developer needs to do in order to start writing code and to integrate with the rest of the team’s work. 2) Automated builds Let us fail early! We have learnt that manual builds are liable to be both fragile and specific to a single machine - and the time lost in making those builds work is time lost to development and testing. On anything but the smallest projects, having an automated build process is essential. We have realized that even if you have to take time out to create an automated build environment, it’s time you’ll get back later. It also makes it simpler to ensure that we have a standardized build that everyone on a project can share. The key tools we used were Ant, Maven, Nant. 3) Continuous integration From our past experience we have learnt that waiting for weeks on end before integrating code from different team members is a recipe for disaster. If you’ve got an automated build in place, the next thing is to go for continuous integration. Of course, an automated build and continuous integration environment presupposes version control (or software configuration management to give it a more formal name). The key lesson learnt is that the sooner you identify integration errors, the sooner you can fix them. The key tools we used were CruiseControl, CruiseControl. Net, Bamboo.

The key tools we used were Junit (and other xUnit tools such as NUnit, HTTPUnit etc), MockObjects. 5) Refactoring In a traditional environment, individuals normally protect their code base until integration. In Agile environments, however, we practice code ownership, which means that all code belongs to all developers, who are free to improve the code when they feel it’s necessary. Martin Fowler popularized the term “refactoring” in his book of the same name. Refactoring essentially boils down to code changes, which improve the structure and clarity of the code without necessarily changing the functionality. The key lesson learnt is to have ‘unit tests’ as a safety net before refactoring the code. The key tools used are Eclipse, NetBeans, IntelliJ IDEA, Visual Studio.NET. As it is clearly evident, there is a certain uniqueness of the engineering practices in Agile projects, and the teams need to be orientated towards it. Behavioral traits required to work in Agile teams As Agile teams work differently to other teams and, since they depend a lot on effective and efficient communication and fast execution, there is an increased need for the team to possess soft skills. If we include deliberate intervention and awareness to the traits and skills, then the Agile teams will be more meaningful and productive. www.agilerecord.com

55

Self-organization usually relies on basic ingredients like positive feedback, negative feedback, balance between exploitation and exploration, and multiple interactions. From our experience, teams sometimes fail to give the right kind of feedback and shy away from interaction, due to various cultural and social issues. From my experience, this remains a ‘myth’. We tend to always have a so-called ‘predictability syndrome’: the more planning we do, the more predictable we will be.

(Co-location) • Projects are built around motivated individuals, who should be trusted • Continuous attention to technical excellence and good design • Simplicity • Self-organizing teams • Regular adaptation to changing circumstances • Reduced risk Conclusion

The team needs to have the right discipline, the ability to take on responsibility, be committed and take accountability and ownership. One of the key skills that the team needs to have is the ability to ask for help and to seek out review. In certain cases, we have seen ‘egos’ appearing as major impediments. Taking responsibility, being committed and a spirit of collaboration are sometimes taken for granted. From our experience, external intervention can sometimes be required to make these happen. Certain key skills that we normally tend to ignore are the ability to take initiative, enjoy working in intense environments and adapt to new situations and frameworks easily. Most of our projects are distributed, meaning there will be a codevelopment Scrum between client and the service provider. In these contexts, skills like managing diversity, time management, diplomacy and leadership are absolutely essential. Success ‘Mantra’ for Agile teams More

Less

Enthusiasm

Individual opinion about what’s important

Learning from peers

Reliance on individual abilities

Comfort in knowing that help is there

Panic when workload peaks

Camaraderie

Backbiting

Shared responsibility

Protecting information

Focus on the organization

What’s in it for me?

Responsibility for the team

Stress on the „supervisor“

Simple, visible measurement

Feeling unaccomplished

Outcomes • Customer satisfaction through rapid, continuous delivery of useful software • Working software is delivered frequently (weeks rather than months) • Working software is the principal measure of progress • Even late changes in requirements are welcomed • Close, daily cooperation between business people and developers • Face-to-face conversation is the best form of communication 56

www.agilerecord.com

From my experience and observations, the skills required in Agile projects to be hyper-productive are slightly different form those required in traditional projects. We have identified behavioral and technical skills required for teams to have that edge. Anyone who acquires these ‘delta’ traits will be equipped with right set of behavioral and technical skills, which will enable them to work effectively in Agile projects. The summary of the skills are presented in the table below.

Skill table Role

Technical skills (in respective platforms)

Behavioral skills

Developer

• CRUD operations, interfacing with different layers of the development framework • Unit testing (tools: N-unit, J-unit ) • Code coverage concepts and tools • Code review concepts and tools • Continuous integration tools • Refactoring concepts • Code smelling concepts • SCRUM process

• Communication • Collaboration • Time management/planning • Thinking • Conflict management • Dealing with change/flexibility • Decision making • Teamwork/team building • Handling stress • Problem solving • Leadership • Diplomacy

QA

• Definition of done → acceptance criteria • Test management • Automation/scripting • Environment set-up • Database concepts

• Same as developers (see above)

SCRUM Master

• SCRUM process • Templates and usage • Project management tools • Continuous integration tools • Development environment set-up

• Developer skills + facilitation

■

> About the author Prasad Prabhakaran Prasad Prabhakaran has 10 years of experience in the IT services industry. His first exposure towards Agile came through Microsoft in 2005. From then onwards, he has carried out solution, coaching, consulting, teaching on Agile and its flavors for various companies, such as GE, Cisco, Coke etc. Currently, he is working as manager at Agile Labs at Symphony Services (www.symphonysv.com). 40% of projects at Symphony are in some form of Agile and its flavors, and they have provided business-critical value for customers through Agile since 2004. Prasad can be reached in [email protected].

www.agilerecord.com

57

© tlorna - Fotolia.com

Dangers Lurking in Tasks and Breakdowns by Alexander Tarnowski

Over the course of three years, the Scrum team that I’m a part of has had plenty of time to try different ways of writing tasks during the Sprint planning phase. Some have been successful, some have not. In this article we look at some types of tasks that carry potential danger, and the appearance of which on the Scrum board may result in a failed Sprint. You could argue that the planning phase of Scrum is the heart of the process. The team is given full autonomy and authority to plan its upcoming work (load) in a way that maximizes customer satisfaction, while being based on realistic and unanimous estimates. At one point or another, the team gets down to the dirty business of detailed estimation, where stories are broken down into manageable tasks of reasonable duration. What “manageable” and “reasonable” means varies from team to team, but for the sake of fast feedback and sense of completion, it’s safer to go with smaller tasks, lasting a couple of hours to a couple of days. Given a usable granularity of the story breakdown, which is why we prefer small tasks to large, composing a good list of tasks is not an easy undertaking. The final result of the breakdown is dependent on the team’s ability to learn from past experience, as well as its self-knowledge. Needless to say, teams lacking these two attributes, and probably some more that are overlooked in this article, run the risk of creating poor breakdowns that will result in poor execution in the implementation phase. In a perfect world, it would be easy to deem some tasks as inherently evil and take their presence as a sign of warning. However, in a realistic world, such tasks are two-edged swords, that might just work out well, or make your Sprint fail. Here are seven examples of task types and breakdown strategies. Horizontal slicing A traditional approach is taken and the work is divided into tasks that correspond to doing implementation at different layers of 58

www.agilerecord.com

the system. If we have a web UI that talks to a database through some kind of middle business logic layer and we need to add some new functionality, we consequently put up three tasks: one implementation task per layer. Evidently this leads to perfect parallelization (three team members may work on the story at the same time). On the other hand, people may end up waiting for each other, while resolving problems with interfaces, dependencies and integration. As always, communication will help, but deadlocks generated by horizontal slicing may just introduce unwanted delays. Vertical slicing Based on experience with horizontal slicing, the planning has resulted in the conclusion that it’s best to operate in silo mode: each task is a vertical silo through the entire system. The task may look something like “Clicking on button X in the GUI updates the price on item Y” (in the database). This guarantees that no developer will be blocked waiting for work on an underlying layer to be completed by another developer. On the other hand, vertical silos may end up in duplicated effort and layers lacking conceptual integrity, since everyone just augments the appropriate layer with functionality they need without taking the whole into account. Again, communication is the key, but there also needs to be a task for refactoring and unifying the silos, otherwise they will become technical debt as soon as they are implemented. Pre-study/design tasks During the planning, it wasn’t quite clear how some problems appearing in the story would be solved. Nonetheless the team felt quite comfortable about the overall complexity and could come up with tasks and estimates. The first of these tasks turned out to be a spike/pre-study/design task that would clarify the rest of the story and the remaining tasks. There’s nothing wrong with this kind of task, apart from two catches.

While waiting for the outcome of the pre-study/design, the majority of or the entire story is blocked. There’s simply no point in picking implementation tasks unless the overall design is solved or a pre-study completed. In general, such tasks appear in more complex stories, meaning that a big chunk of work is off limit to the team. Secondly, if a team falls into the habit of creating these tasks, the quality of its planning may drop, as it tries to push all intellectual effort into these tasks. Actually, there’s a third potential problem lurking here as well. If a story needs further “investigation”, it maybe shouldn’t have made it as far as it did at all. This doesn’t need to be the case. The story really may require some thinking up front, such as how it is to be integrated in the overall system design, but beware of the alternative scenario. Tasks with external dependencies The team has committed to a task, the outcome of which depends on an external party, such as the customer, a third-party vendor, or just a piece of hardware. Naturally, this can’t be avoided in the real world, but special attention should be paid to these tasks. Their number should be kept down, and they should be picked early to mitigate the risk of Sprint overrun due to calendar time/availability issues. Short general verb phrases The team has spent a lot of time in the planning meeting having heated discussions. Finally, it agrees on a breakdown, and it’s perfectly clear to everybody what the task saying “Implement” means. It has been discussed so thoroughly! Believe it or not, but this short general verb phrase isn’t obvious if the story gets a low priority and is done late in the Sprint, or even worse, moved to the next one. Hence somewhat more verbose and precise tasks are better. Final integration tasks These tasks emerge when the team realizes that the effort of completing all the tasks of the story still won’t result in its completion. The planning session may have produced some unresolved questions, the story may feel too complex, or there’s a lot of slicing going on (see above). Previous experience indicates that tying everything together does require some additional effort, which is not easily captured in the individual tasks. For these reasons, final integration tasks are great, but as with the other tasks discussed, their blade cuts both ways. The obvious pitfall is that tasks won’t get completed, simply because the people doing them start over-relying on the final integration tasks: “It doesn’t work as expected, but I don’t care, since someone else will surely fix it in the final integration”, might be a common but disastrous thought. This kind of thinking shifts your Sprint towards a “mini waterfall”, and you run the risk of creating code and fix cycles within the very same Sprint.

Another problem with these tasks is that they are inherently hard to estimate. If your previous Sprint was delayed because of intricate third-party driver and race condition issues found no sooner than in the final integration phase, this Sprint’s time estimate will be high. On the other hand, if everything just worked the last time, why create a big final integration task, or why create one at all? Finally, I’ve seen a third version of final integration failure. Namely, picking this task too early. This can happen if the majority of the tasks in a story are either done or in progress, and only the final integration task remains. A savvy team member will then pick that task, while some other team members are working to complete the remaining ones. In this scenario, the person doing the final integration may finish first, reporting that there were no or few integration/round-up difficulties, which of course is true, since the tasks containing the difficult functionality are unfinished. In the worst of worlds, this results in an unplanned new final integration, and the first effort is wasted. Integration test tasks For the team to be done, the story must pass some kind of integration test or possibly even a user acceptance test. Being the last task of the story, this type of task is a close cousin of the final integration task. To make tings more interesting, this task may involve external dependencies, such as end users or dedicated testing environments. Normally, this is something you have to do unless you have the luxury of a second team responsible for roll-outs and bug fixing, so shorten your mental image of the sprint by at least a day. Hidden critical paths The observant reader has by now noticed that the underlying theme of this article has been throughput achieved by striving for a high degree of parallelism, which in turn depends on atomic self-contained tasks. Given this assumption, there’s another dimension to task breakdown – being on alert for hidden critical paths. As some tasks depend on other tasks in a normal story breakdown, critical paths are more or less unavoidable: pre-studies must be completed first, and then followed by implementation tasks, which are integrated one last time before going through final testing and documentation. Estimation without taking such critical paths into account may lead to introduction of unnecessary sequential dependencies among tasks. Suddenly we have a long critical path, whose elements must be completed in strict order. Mini waterfall? This doesn’t have to be a bad thing, since it’s limited to one Sprint, but it does decrease overall flexibility and dynamics of the work within the Sprint.

www.agilerecord.com

59

Summary You may have encountered these tasks, or you may have found other problems in your breakdowns. It should be perfectly natural that the list of problematic tasks and breakdowns would appear different for every team. These are the ones I have encountered. As said at the beginning of this article, the task archetypes discussed here are not dangerous in themselves. You just have to be aware of the pitfalls in them. By the way, if these are the dangerous ones, which are the safe ones that didn’t make this list? ■ Alexander Tarnowski, May 2010

> About the author Alexander Tarnowski Alexander Tarnowski is a software developer with a decade of experience in the field, and a broad definition of the term “software development”. He has a master’s degree in computer science and a bachelor’s degree in business administration, which makes him interested in both technical and economic aspects of the industry.

© iStockphoto.com/ScantyNebula

Having worked in all phases of the development process, he believes in craftsmanship and technical excellence at every stage. He’s currently interested in how introduction of agile methodologies on a larger scale will redefine the tester and developer roles.

60

www.agilerecord.com

© drizzd - Fotolia.com

Significance of Tools in Agile Software Development by Chaitanya Sudha Nakka

Cycle time improvement is the most essential and desired factor in Agile development. Cycle time reduction can be achieved if the activities involved in the development life cycle can be automated or accelerated. Standard Engineering tools like Rational Requisite Pro, Visual Studio Team Suite (VSTS), Team Foundation Server (TFS), and Rational Functional Tester provide different features to automate the activities involved at different life cycle stages. This article presents on how standard engineering tools can be deployed, without overhead, in an Agile development environment to gain the desired results in cycle time reduction and in quality. Introduction Agile software development is a software development methodology where requirements and the application software evolve through the collaboration and communication between specialized groups. Agile development methodology can be described as iterative and incremental. Every aspect of development, i.e. requirements, design, coding etc., is continually revisited throughout the development life cycle. This kind of continual ”inspect and adapt” approach helps in reducing development costs significantly. There are different methods that are designed around Agile development: DSDM (Dynamic Systems Development Method), XP (Extreme Programming) and SCRUM. They differ from each other in the mode of execution, but all of them are built on the Agile principles: satisfy customer through early and continuous delivery of software, welcome changing requirements even late in development, deliver working software frequently, working software is the principle measure of progress, face-to-face communication, projects built around

motivated individuals, continuous attention to technical excellence and good design, simplicity, self-organizing teams, sustainable development and regular adaptation to changing circumstances. Hence continuous delivery of software and reduced cycle time are core requirements of Agile development. Below are some of the several principles that can contribute to achieve these core requirements. • • • • • •

Requirements prioritization & ability to include changing requirements Continuous integration Collective code ownership Continuous automated testing Transparency & improved communication Effective tracking of work progress

Software tools help in accelerating the development effort by providing different features to automate the manual work involved in different life cycle stages. The sections below will describe in

Fig. 1 Organizing requirements with hierarchy & traceability views

www.agilerecord.com

61

detail how the regular features provided by the tools can help in implementing the different principles of Agile methodologies in order to achieve the core requirements of early and continuous delivery of software and reduced cycle time. Deployment Of Tools In Agile Methodology Requirements prioritization & ability to include changing requirements– Changing requirements are natural in a software development process. Agile processes embrace change with the notion that requirements will evolve throughout a project. The whole bunch of requirements is broken into different sets, and each of these sets is included in the corresponding iterations based on the prioritization provided by the stakeholders. Each of the iterations in the life cycle covers these sets of requirements. Hence requirements organization, prioritization and tracking are very much vital in Agile methodology.

Fig. 2 Query feature and traceability matrix for Requisite Pro

Requisite Pro is a powerful, easy-to-use, and integrated product for requirements and use case management that promotes better communication, enhances teamwork, and reduces project risk. It provides features for the creation of different categories of requirements through packages, for creating and tracking requirements, for assigning priorities to the requirements, for detailed traceability views that display parent/child relationships, and for showing requirements that may be affected by upstream or downstream change. The tool also provides a powerful database infrastructure with real-time Word document synchronization to facilitate requirements organization, integration and analysis. Similarly, Team Foundation Server provides features like work items, queries and reports through which the requirements can be managed. The tool provides a specific template for Agile proj62

www.agilerecord.com

Fig. 3 User story in TFS (Team Foundation Server)

ects in which all the artifacts in the team project are aligned to Agile software development. In the Agile team project, user story work items can be created and tracked effectively through different in-built queries and reports. Product backlogs provide information on the list of requirements desired by the customer in the application. And the iteration backlog provides information on the user stories and queries on the user stories for a specific iteration. So generally, when the user stories are created, they are included in a product backlog and then, based on the prioritization, they are included in iteration backlogs. This helps in better planning and categorization of the requirements, Fig. 4 TFS Work items, queries which is very much essential in an Agile environment. Continuous Integration In order to deliver artifacts at regular intervals, continuous integration is essential in Agile methodology. Continuous integration is a practice of integrating one’s new or modified code to the code repository early and often. This should be carried out very frequently, so that there is no gap between commit and build, such that the errors that arise can be detected and corrected early. The important factors that are considered during continuous integration are: • • • •

Code repository Automate build Make the build self-testing Everyone commits everyday

• • •

Every commit is built Make it easy to get latest deliverables Everyone can see results of latest build

TFS provides different features to implement these factors, which are essential for continuous integration. The tool provides a code repository through the integration with the SQL server and good version control features to get the latest deliverables. It also provides features like build automation, ability to schedule builds for each check-in (continuous integration), atomic check-ins, and it provides build reports which are visible to the whole team.

duces a significant amount of effort in the coding life cycle stage. Continuous Automated Testing – Continuous testing involves regular and frequent execution of tests to verify whether the modifications done in the code impact the application’s behavior. Continuous unit/regression testing is one of the key parts in an Agile methodology, since it helps to detect and correct the errors at an early stage as and when they are created. The VSTS unit testing framework, which comes inbuilt in the Integrated Development Platform (IDE), helps the developers to automate the unit testing process so that the same test scripts that are created can be executed again and again on the code.

Fig. 5 TFS build definition

Collective Code Ownership Collective code ownership encourages everyone in the team to contribute ideas to different segments in the project. The user stories created for the requirements and the code base are visible across the whole team in Team Foundation Server. The developers can contribute in a better way by taking collective ownership. In addition, VSTS provides forward engineering capability to automatically generate code from the design models, and this re-

Fig. 6 VSTS unit testing

Fig. 7 TFS share point portal

www.agilerecord.com

63

Similarly, functional and regression testing automation can be achieved through Rational Functional Tester. The tool provides features like automatic script generation, datapools, verification points, etc., which help in automating the regression testing of the application. The ability to enhance scripts and script assurance features provided by the tool reduces script maintenance activities and increases script reliability. Transparency & Improved Communication Face-to-face communication is more important in Agile development. In cases where the team is distributed, information sharing becomes more crucial for effective development. TFS provides share point portal and other mechanisms like shelving etc. for better communication among the team. Dashboards provide a quick access to view the assignments, project status, and software quality, test progress and build quality. The reports that are created in TFS give an indication of the work progress, of the quality of the code delivered, and of the defect status. Reports provided include bug status and bug trends, build quality indicators and build summary, burn-down and velocity, reactivations, remaining work, stories overview and progress, and test case readiness and test plan progress. These different mechanisms supported by TFS to access information and status provide transparency and improved communication.

Fig. 8 User stories overview

Fig 9 Burn-down and burn rate

Fig. 10 Remaining work

Effective Tracking of Work Progress

Conclusion

In Agile methodologies, it is highly important that the work progress is tracked effectively. Each of the iterations has a deliverable, and these deliverables need to be tracked so that no requirement is missed out. Work items and the powerful reporting feature provided by TFS help the project manager to track the work progress in an effective way. In addition, VSTS provides specific capabilities for Agile projects to track user stories through ”User stories progress” and ”Status on all iterations” reports.

A proposed solution for the reduction of cycle time in Agile development is through the usage of the right set of tools at each life cycle stage.

64

www.agilerecord.com

Tools help in creating a collaborative platform, which connects geographically distributed teams for effective & transparent communication to manage changes done to the project artifacts, e.g. communicating requirements changes to the developer and tester communities, code changes to the testers etc. Tools help in accelerating the development process by providing capabilities to automate the manual work involved at various life cycle stages. Along with automation, end-to-end integration of tools helps in reducing the transition time between the life cycle stages, thereby reducing the overall cycle time. ■

References [1] Feature of Rational Requisite Pro Available at, http://www01.ibm.com/software/awdtools/reqpro/features/ [2] VSTS & TFS - http://msdn.microsoft.com/enus/library/ ms181232.aspx [3] Rational Functional Tester - http://www-01.ibm.com/software/awdtools/tester/functional/

> About the author Chaitanya Sudha Nakka Chaitanya is a Technological Lead at Infosys Technologies Ltd and has an experience of 7.5 years in software development. She has considerable experience on tools related to .NET/C++ technologies. She has worked for embedded domains and is currently responsible for deploying and implementing engineering tools related to .NET across the projects in the organization. She has obtained her certifications on Rational Requisite Pro and Rational Functional Tester tools.

Want to write for... Next issue Deadline Proposal Deadline Article

October 2010 August 20th September 10th

www.agilerecord.com www.agilerecord.com

65

© iStockPhoto.com / Andresr

The Abilene Paradox and Team Collaboration by Badri N Srinivasan

Background

increase teamwork and personal involvement.

Team collaboration is an important aspect in any complex activity, and it is even more important for software development. Software development is a complex process, and to achieve the end goals of the customer, team collaboration and interaction are very important. The team needs to work together cohesively, so that delivery is made according to schedule, quality, cost and other parameters.

A good analogy for team collaboration is given below -

A single individual cannot guarantee successful customer delivery. It is the team which, if it works cohesively, ensures successful delivery to the customer. In projects that are implementing Scrum, the role of the Scrum Master, who facilitates the team to achieve the end goal of the customer, is very crucial. The Scrum Master focuses on ensuring that any impediments and “road blocks” faced by the team are removed, and he ensures that the core focus of the team is on developing the product/service for the customer under optimal conditions. Thus, he is in effect practicing “Servant Leadership”, where the focus is on giving priority attention to the needs of the team members and those they serve (customer). It encourages leaders to serve others while staying focused on achieving results in line with the organization’s values, integrity and business objectives. In the ancient Hindu text, Arthashastra, Chanakya commented in the 4th century B.C. : The king [leader] shall consider as good, not what pleases himself but what pleases his subjects [followers]”. “The king [leader] is a paid servant and enjoys the resources of the state together with the people.” “Servant Leadership” emphasizes collaboration, trust, empathy, and the usage of power ethically. The objective is to enhance and 66

www.agilerecord.com

Migrating geese fly in a ‘V’ formation on account of various factors. As each goose flaps its wings, it creates an upward lift for the following goose. In a V-formation, the whole flock adds at least about 70% more flying range than if each goose flew alone. Whenever a goose falls out of the planned formation, it suddenly feels the drag and resistance of trying to fly alone…and it quickly gets back into formation. Like geese, people who share a common direction and a sense of community can go where they are going quicker and easier than those who try to do it alone. When a goose gets tired, it goes back into the next level of the planned formation and another goose flies at the pole point position. This highlights the fact that people will realize that ultimately their success depends on working as a team, taking turns doing the hard tasks, and sharing leadership. Geese in the rear of the planned formation honk to encourage those up front to increase their speed. It is important that our “honking from behind” should also be encouraging to the other team members. When a goose gets sick or wounded, two other geese drop out of the planned formation and follow it down to help and provide protection. They stay with the unhealthy member of the flock until it is either able to fly again or dies. Then they fly off again with another passing flock or try to catch up with their own flock. In our daily life, it is very difficult for the Scrum Master to constantly ensure that all team members work together cohesively to achieve the final delivery for the customer, as people are complex personalities. The Scrum Master is constantly battling with various issues that arise during his daily work in order to ensure that the team does not face any “road blocks” while executing

their work. The Daily Scrum serves as an important barometer for the Scrum Master to know the progress made on a daily basis during the iteration. However, in his zeal to ensure that the team collaboration is not compromised, the Scrum Master should focus not only on the visible issues, but also on various other factors that are in reality hidden “road blocks” for team collaboration. These issues are subliminal and are not directly visible during the course of the iteration. Scrum promotes self-organizing teams, which are expected to choose the tasks in a self-organized manner and execute the work accordingly. The Scrum Master needs to monitor that these tasks are done in a coordinated way so that the final goal of the iteration is met. In a typical iteration, in teams that are initially learning how to implement Scrum in their project, and also sometimes in mature teams, there is an initial hesitation on the part of the team members to volunteer for a specific task, as the member is not sure how he will be able to execute the task and also ensure that he delivers the selected task as committed. In such a situation, in the initial iterations, the Scrum Master facilitates the team in ensuring that they become self-organized over a period of time. However, this is easier said than done. Many Feature team leads delegate the work to the team members and slowly build the selforganizing capability in the team over a period of time.

As the project team learns to form self-organizing teams, they encounter various issues regarding the tasks which they may want to choose to work. In an Agile Scrum team, the team is populated with cross-functional team members. However, the “Abilene Paradox” can still occur and this creates issues for the Scrum Master. These issues need to be managed appropriately. The team member(s) in a Scrum team may be hesitant to pick a particular task, as he feels other members in the team may be better suited for the task. This mistaken belief can lead to the “Abilene Paradox”. The team member subsequently chooses an alternative task, which he feels will not disrupt the team work. Other members also think in a similar manner. This leads to some tasks not being optimized adequately. This is on account of the fact that on a cross-functional team, more than one member may be focused on a specific activity like implementation of code. This leads to a scenario of a mini group simulated within the team, and it leads to reduced optimal team collaboration on account of group-related issues. The issues can disrupt team collaboration, and the Scrum Master needs to be alert and focus on these issues, which can lead to a reduced level of team collaboration. This type of team behavior can also affect the team decision-making abilities when they have to decide other options for various alternatives. Thus, it leads to defective team decision-making.

Self-organization in teams is assumed to be simpler as compared to self-organization in groups. In order to understand this concept, we first need to define what a team and what a group is. A team’s strength depends on the commonality of purpose and interconnectivity between individual members, whereas a group’s strength may come from the willingness to carry out a single leader’s commands. Many people use the words team and group interchangeably, but there are actually a number of differences between a team and a group in the real world.

During the Iteration Retrospective Workshop, when the team discusses the task allocation activity, the team can intuitively feel that if the task order execution had been different, they could have delivered still better value to the customer. This highlights the fact that even though the self-organizing team members are the only members who know intimately about all the tasks to be executed in a particular iteration, they may still not be aware of various other factors which influence the team and which may lead to less value being delivered to the customer.

Abilene Paradox

The Scrum Master in this case should observe these patterns and have a dialog with the team on the specific activity that needs to be improved during the Iteration Retrospective Workshop and suggest whether the specific activity could have been improved further in order to deliver more value to the customer. This is a case of continuous process improvement and a case for the “Inspect and Adapt” technique.

Self-organization in teams takes a lot of time and optimal selforganized teams are few in an organization. In teams, a phenomenon called the “Abilene Paradox”, that generally occurs in a group, can also occur. The “Abilene Paradox” is a paradox in which a group of people collectively decide on a course of action that is counter to the preferences of any of the individuals in the group. It involves a common breakdown of group communication, in which each member mistakenly believes that their own preferences are a contradiction to the group and, therefore, does not raise objections. In effect, the desire is not to “rock the boat”. This theory explains the behavior of groups in a social context.

Psychological theories of social conformity and social influence highlight that human beings are often very averse to acting contrary to the trend of the group. It is also observed that indirect cues and hidden motives often lie behind peoples’ statements and acts, as the social context in which they operate discourages them from openly voicing their feelings or pursuing their desires.

The crux is that teams have just as many problems managing their agreements as they do their disagreements.

One way to avoid this issue: When the time comes for a team to make decisions, they should ask each other, “Are we going to Abilene?”, in order to determine whether their decision is legitimately desired by the team’s members or merely a result www.agilerecord.com

67

of groupthink. Groupthink is a type of thought within a deeply cohesive group, whose members try to minimize conflict and reach consensus without critically testing, analyzing, and evaluating ideas. This can also apply to larger cross-functional teams consisting of multiple mini groups that simulate group behavior within a team. During groupthink, members of the group avoid promoting viewpoints outside the comfort zone of consensus thinking. A variety of motives for this may exist, such as a desire to avoid being seen as foolish, or a desire to avoid embarrassing or angering other members of the group. Groupthink may cause groups to make hasty, irrational decisions, where individual doubts are set aside for fear of upsetting the group’s balance. These issues occur at the subliminal level, and hence it is very difficult for the Scrum Master to identify the core issues in team collaboration. Thus, he must be watchful, and when a team is not observed to be very effective, one way of improving team collaboration is to check out if the “Abilene Paradox” is in vogue and make all the members aware of this paradox. Once this paradox is highlighted to the team, this issue does not repeat again, and if it does, only very rarely, as the team understands the hidden “road blocks” affecting the team collaboration. Reasons for “Abilene Paradox” Some of the reasons why “Abilene Paradox” may exist are: • • • • • •

There is a bias in collecting the required information Failure to examine risks for the preferred choices Contingency plans have not been worked out properly The selected alternatives and the objectives are not completely evaluated Failure to re-evaluate previously rejected alternatives Searching the relevant information has not been done properly

The above reasons may create a feeling of hesitancy in all the team members, and they are not sure of the decision that they are going to individually select. Thus, while selecting an option, they begin to think how others will feel instead of thinking in a rational manner. This sets off the “Abilene Paradox”. The focus has to be on rationalized conformity – an open philosophy which holds that group values are not only expedient but right and good as well; when compared to instinctive conformity. Some steps to avoid “Abilene Paradox” Some of the steps that could be taken to avoid the “Abilene Paradox” are: •

•

68

The senior team members should encourage junior team members. They should not express their opinion before the junior member has given his opinion. The team should assign one member to perform the role of the critical evaluator. This will help other team members to www.agilerecord.com

• •

•

know the areas of concern and express their doubts. All the alternatives should be explicitly examined. This helps to check previously rejected alternatives. The team should also discuss key ideas with other teams who may have faced a similar situation. This helps to share best practices/lessons learnt and will help the team focus on the core issue. At least one group member should be assigned the role of Devil’s advocate (murder board). This role could be rotated among the team members.

However, the above steps need not be taken for every single decision, as lower-level decisions and other non-critical decisions can be taken with minimal data. Only critical decisions which influence the customer goal directly and impact the business value need to be analyzed fully, and all the possible options and opportunities need to be explored so that the probability of success in meeting the customer goal is increased. We should also ensure that Lean principles are kept in mind so that unnecessary time is not wasted in trying to find hidden motives for the decisions taken. Conclusions Thus, one of the ways to resolve crucial team interaction issues which occur during the iterations can be by focusing on the question “Are we going to Abilene?”, and if the team is able to say “No”, it means we are hopefully on the right track in meeting the customer goals. Thus, the “Abilene Paradox” leads to another implicit paradox: Teams need to be cohesive but at the same time should not be cohesive! This means that the team cohesion should help to complete the work successfully, but at the same time the team cohesion should not impede individual and rational thinking of a solution to a problem or an issue. ■

> About the author Badri N Srinivasan Badri N Srinivasan is working as Head of Quality for Valtech India Systems Pvt. Ltd., Bangalore, India. He has extensive experience in process implementation and organizational change management processes and process improvement initiatives in the travel, retail, manufacturing, banking and financial services domains. He is a Certified Scrum Master (CSM) and Project Management Professional (PMP).

Masthead EDITOR Díaz & Hilterscheid Unternehmensberatung GmbH Kurfürstendamm 179 10707 Berlin, Germany Phone: +49 (0)30 74 76 28-0

Fax: +49 (0)30 74 76 28-99

E-Mail: [email protected]

Díaz & Hilterscheid is a member of “Verband der Zeitschriftenverleger Berlin-Brandenburg e.V.” EDITORIAL José Díaz



LAYOUT & DESIGN Díaz & Hilterscheid WEBSITE www.agilerecord.com ARTICLES & AUTHORS [email protected] ADVERTISEMENTS [email protected] PRICE online version: free of charge

In all publications Díaz & Hilterscheid Unternehmensberatung GmbH makes every effort to respect the copyright of graphics and texts used, to make use of its own graphics and texts and to utilise public domain graphics and texts. All brands and trademarks mentioned, where applicable, registered by third-parties are subject without restriction to the provisions of ruling labelling legislation and the rights of ownership of the registered owners. The mere mention of a trademark in no way allows the conclusion to be drawn that it is not protected by the rights of third parties. The copyright for published material created by Díaz & Hilterscheid Unternehmensberatung GmbH remains the author’s property. The duplication or use of such graphics or texts in other electronic or printed media is not permitted without the express consent of Díaz & Hilterscheid Unternehmensberatung GmbH. The opinions expressed within the articles and contents herein do not necessarily express those of the publisher. Only the authors are responsible for the content of their articles. No material in this publication may be reproduced in any form without permission. Reprints of individual articles available.

Index Of Advertisers Agile Record

25, 50, 65

bitzen.net

17, 19

Bredex

27

CaseMaker

54

Díaz & Hilterscheid GmbH

2, 33-36, 46-47, 70

gebrauchtwagen.de

5

Kanzlei Hilterscheid

21

www.agilerecord.com

69

Training with a View

also onsite training worldwide in German, English, Spanish, French at http://training.diazhilterscheid.com/ [email protected] “A casual lecture style by Mr. Lieblang, and dry, incisive comments in-between. My attention was correspondingly high. With this preparation the exam was easy.” Mirko Gossler, T-Systems Multimedia Solutions GmbH “Thanks for the entertaining introduction to a complex topic and the thorough preparation for the certification. Who would have thought that ravens and cockroaches can be so important in software testing” Gerlinde Suling, Siemens AG - subject to modifications -

Kurfürstendamm, Berlin © Katrin Schülke

06.07.10-09.07.10

Certified Tester Foundation Level

München

12.07.10-16.07.10

Certified Tester Advanced Level – TESTMANAGER

Düsseldorf/Köln

26.07.10-29.07.10

Certified Tester Foundation Level

Berlin

02.08.10-06.08.10

Certified Tester Advanced Level – TEST ANALYST

Berlin

10.08.10-13.08.10

Certified Tester Foundation Level

Frankfurt

16.08.10-21.08.10

Certified Tester Advanced Level – TESTMANAGER

Berlin

23.08.10-24.08.10

Testen für Entwickler

Berlin

25.08.10-27.08.10

Certified Professional for Requirements Engineering – Foundation Level

Berlin

31.08.10-03.09.10

Certified Tester Foundation Level

Barcelona

06.09.10-10.09.10

Certified Tester Advanced Level – TECHNICAL TEST ANALYST

Berlin

13.09.10-16.09.10

Certified Tester Foundation Level

Berlin

20.09.10-24.09.10

Certified Tester Advanced Level – TESTMANAGER

Berlin

04.10.10-07.10.10

Certified Tester Foundation Level

Berlin

11.10.10-13.10.10

Certified Tester Foundation Level – Kompaktkurs

Hannover

11.10.10-15.10.10

Certified Tester Advanced Level – TESTMANAGER

München

18.10.10-19.10.10

Testen für Entwickler

Berlin

19.10.10-21.10.10

Certified Tester Foundation Level – Kompaktkurs

Frankfurt

25.10.10-29.10.10

Certified Tester Advanced Level – TEST ANALYST

Stuttgart

26.10.10-28.10.10

Certified Professional for Requirements Engineering – Foundation Level

Berlin

02.11.10-05.11.10

Certified Tester Foundation Level

München

08.11.10-12.11.10

Certified Tester Advanced Level – TEST ANALYST

Berlin

15.11.10-18.11.10

Certified Tester Foundation Level

Berlin

22.11.10-26.11.10

Certified Tester Advanced Level – TESTMANAGER

Frankfurt

29.11.10-30.11.10

Testen für Entwickler

Berlin

01.12.10-03.12.10

Certified Professional for Requirements Engineering – Foundation Level

Berlin

07.12.10-09.12.10

Certified Tester Foundation Level – Kompaktkurs

Düsseldorf/Köln

13.12.10-17.12.10

Certified Tester Advanced Level – TESTMANAGER

Berlin