The Magazine for Agile Developers and Agile Testers

July 2010

www.agilerecord.com free digital version made in Germany issue 3

© Val Thoermer - Fotolia.com
© 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 suc-
cess 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 tuto-
rial. 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 sup-
porting 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 Mas-
ter  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 7. A lot of time was invested in keeping an up-to-date traceability

between requirements and code, but estimation of changes
An important question with respect to implementing a software does not appear to be any quicker.
development method is how to concretize the method in the or-
ganization and the project which it should serve. This step is eas- In this article, we provide seven rules of thumb which help you
ily forgotten in introducing and applying a new method, and it is to make the development method of your choice more effective.
easy to slip into the habit of regarding a full and clean applica- These rules were developed during our experiences in various
tion of a method as a goal in itself. Many development methods enterprises, in which we helped to implement modern develop-
(DSDM, Scrum, XP) presuppose this concretization step without ment methods. Following these rules will help to avoid the situa-
making it explicit. In the Rational Unified Process (RUP), this step tions described above.
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 Seven Rules of Thumb
method is needed.
All rules presented here follow the same principle: balance cost
Which rules could you use in performing this step? How do you and revenues. A measure (document, procedure, application or
get to a clear and concrete development process that optimally a tool) is effective if it yields the correct effect, i.e. an optimal bal-
supports your project? Which tools do you apply and who will use ance of costs and revenues. Costs and revenues not only apply to
them? Below we have listed a few situations, in which this step the period of software development, but to the complete lifecycle
should have been taken more consciously: of the application and to the context within which the application
is developed and used. An important question in this respect is
1. An enterprise bought an expensive tool but did not anticipate what the expected lifetime of the application is and how many
the large amounts of time it costs to implement it and keep it changes are expected.
up-to-date. This results in the tool remaining unused.
2. Review forms are developed, but it takes so much time to fill We often see people being so enthusiastic about the expected
them in that everyone avoids reviewing. revenues that they lose sight of the costs. Or the other way
3. RUP defines 128 work products. It is decided that all need to around: because of the costs, a “smart” solution is not chosen,
be created. This results in the project coming to a complete although in the long run the revenues would have outweighed the
standstill. costs. Costs or revenues in themselves are not the criterion for a
4. The project needs to be finished quickly, so a large develop- good decision, but the balance of both is.
ment team is rolled out, but the demanding organization can-
not supply sufficient input to the team. Rule 1: Keep the level of ceremony as low as possible
5. The change procedure takes 3 months at least. This leads to
a large part of the changes not being relevant anymore by the The level of ceremony can be defined as the amount of additions
time they are finally implemented. to the development process for the sake of controlling the pro-
6. People responsible for requirements are not available during cess and its resulting work products. A higher level of ceremony
system implementation, and therefore the system does not implies more formal recording, review and approval and often
comply with the customer’s needs. more work products, procedure descriptions and more detailed
means of control.

6 www.agilerecord.com
Every organization knows its own “ceremonies”. Usually the big- Rule 3: Make as few work products as possible
ger the organization, the more formal it is. Some examples of
lower and higher levels of ceremony are listed in the table below: If you make a list of work products, the questions you need to
ask yourself are:
Lower level of ceremony Higher level of ceremony • Who will miss this work product?
Information is available in a WIKI, It is explicitly recorded who must • What will go wrong if we don’t make it?
everyone can look there. be informed, and in what way.
The work products themselves Minutes of every meeting are This approach will clarify the purpose of the work product. Will
mirror what is agreed upon. made and formally approved. this work product only be needed for development, or will it also
Informal exchange of information Information is usually exchanged play a role in future system administration? By knowing who will
in writing. need the work product, you can involve this person in producing
Quality is acknowledged and as- There is a Quality Assurance it, validating its contents and balancing production effort with the
sured by the team. department. expected revenues.
Changes can be processed easily. There is a committee which must
approve changes. The amount of work products for software development depends
Reviews are held informally. All review results are recorded. on the circumstances of the project, as do their specific form and
comprehensiveness. If a sketch on a whiteboard suffices, it is not
Standards and guidelines are There are extensive lists of stan-
implicit. dards and guidelines.
necessary to produce a comprehensive document.

Some work products will be part of the final product, for instance
Many organizations are unaware of the costs as well as the reve- because they are needed for system administration or future
nues of their level of ceremony. Many people see formal reviews, maintenance and support. If the only thing you deliver is the
an extensive approval procedure and detailed plans with Gantt application, and the demand organization can use and admin-
charts as simply indispensable. We have found that asking for istrate it, that is fine for the short term. This is even more likely if
explicit estimates of costs and revenues helps people to become an Agile way of development is applied and all code is accompa-
aware of the amount of overhead brought about by the level of nied by unit tests and code documentation and kept as simple
ceremony. as possible by refactoring. However, most applications must be
maintained long after the original developers are gone. In this
Rule 2: Keep the team as small as possible case it might be better to have some documentation in place, like
use case specifications, a software architecture document and
A development team of exactly 1 experienced person who unifies system administration document.
all roles in himself is most efficient in avoiding handovers. Howev-
er, not only the availability of one person with all knowledge and Rule 4: Apply the simplest possible approval procedure on as
skills needed prohibits this option, but also development speed few work products as possible
(time to market), vulnerability (what happens if this single person
gets sick) and safeguarding of knowledge. Not all work products need to be approved in a formal way. A
similar question as above applies here:
Adjust the number of team members to the level of input the de- • What goes wrong if a work product is not formally approved?
mand organization can supply on a continuous basis. It does not
make much sense to install a team of 3 ana- If the answer is “nothing”, it is clear
lysts and 8 developers if the maximum input that formal approval is not needed. Of-
the key users can supply is only sufficient for ten the work products that define the
Often a few separate,
1 analyst and 2 developers. scope of the project are candidates for
specialized tools better meet
formal approval. Also use case specifi-
the requirements than a
Moreover, a bigger team does not have a pro- cations could be approved in order to
complete integrated toolset.
portionally bigger productivity, due to a larger have a common point of reference for
overhead in planning, handovers and depen- accepting the solution.
dencies. It may well be the case that a well-
functioning team of 3 developers, an architect, an analyst and a Formal approval takes time and energy. On the other hand, it
tester are more productive than the same team but now enlarged delivers clarity, baselines and reference points. If there is a clear
with 3 more developers, an analyst and a tester to meet the time- mandate of one person approving a work product, this will sim-
to-market. If such a scaling operation takes place toward the end plify the process tremendously. For example, a subject matter
of the project to meet the deadline, the net effect will be nega- expert who has mandate can decide very quickly if a use case
tive. Many people forget to take into account the learning curve specification is correct. He can do the formal acceptance as well.
of new team members and the extra overhead.1 It does not add much value to have a person higher in the man-
agement hierarchy accept the use case specification.

www.agilerecord.com 7
 Rule 5: Take the simplest toolset that meets your needs detailing requirements, you gain more insight. High-level require-
ments formulated (much) earlier might no longer be relevant.
It is often underestimated how well requirements and manage- Hence, we need human inspection here as well. Maintaining
ment can be done using only a big whiteboard, brown paper and traceability between changing requirements is time-consuming,
post-its, a word processor, spreadsheet, simple modeling tool even when tools are used. A solution using just human inspection
and WIKI. Add more only if there is a very clear need or bottle- might be cheaper.
neck. Be sure that a solution is already proven in practice and
that you have a good picture of how it will help you before choos- Traceability can be kept implicit in many cases, which is a cheap
ing it. Do not only formulate requirements for a tool, but look approach. For example, naming conventions and object-oriented
at the costs as well. Tools need to be installed, configured and development may help. If something is called ‘dossier’ by the
maintained. The time and expertise needed to do this is often business, then it is a good idea to give the object in the code
underestimated. which represents the dossier the name ‘dossier’ as well. Things
you can do in reality with a dossier will then be associated with
Formulate tool requirements with concrete improvements in the dossier in the code. The more perspicuous an application is
mind, which can be expressed in terms of revenue. If you balance built, the better the implicit traceability is.
costs (purchase, configuration, maintenance, keeping informa-
tion up-to-date) against revenues (savings in time), this balance The worst scenario is that in which explicit traceability is installed
may easily turn out negative. but not kept up-to-date. Outdated information renders the trace-
ability unreliable and hence useless. In this case the investment
If you have a set of prioritized tool requirements, look at the sim- in traceability has a negative result, since the effort that has
plest tools that meet them. Often a few separate, specialized been put in does not pay at all. Consider explicit traceability only
tools better meet the requirements than a complete integrated when its maintenance is guaranteed throughout the applica-
toolset. Integrated toolsets are inherently complex and may lack tion’s lifecycle.
the features of specialized tools.
Rule 7: Choose the most effective form of communication
Rule 6: Maintain (explicit) traceability as little as possible
The quicker and better your intentions are understood, the more
Traceability may mean two things: there is a connection made effective your communication is. The best way to reach this is
between decisions in time, or between work products belonging to have a live conversation and be enabled to visualize your in-
together in one baseline. The connection may be made explicitly tentions. The worst way is to send a text document without any
(in a tool or spreadsheet) or implicitly by following design rules explanation or possibility to raise questions about it. In the figure
or naming conventions. Traceability is often desired because it below, various communication channels and their effectiveness
may help with: are shown.
• Keeping business requirements, high-
level and detailed software require-
ments, test cases and implemented
functionality in line;
• Impact estimation, especially when the
original developers are no longer avail-
able;
• Tracing why certain decisions were
made, by whom, and when.

Explicit traceability from high-level to

detail software requirements and imple-
mented functionality may be useful, for
example in situations in which changed
laws or government rules may lead to ad-
aptations 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 intel-
ligent, human inspection.

Traceability may be used to ensure that

all high-level requirements are met. While Figure 1: Effectiveness of communication channels

8 www.agilerecord.com
Do not trust blindly in this figure. Keep in mind how a communi-
cation channel is used. In order to convey an intention, a piece > About the authors
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 Remi-Armand Collaris
support the conversation and capture the result for future refer- Remi-Armand Collaris is
ence. It then functions as a means to support the “real” com- a consultant at Ordina,
munication. based in The Netherlands.
He has worked for a num-
Conclusion ber of financial, insurance
and semi-government in-
We have presented seven tested rules of thumb, which can be stitutions. In recent years,
used to tailor any software development method. They help you his focus shifted from
to implement an effective development process or to improve an project management to
existing process: coaching organizations in
adopting Agile using RUP and Scrum. An important part
of his work at Ordina is contributing to the company’s
1. Keep the level of ceremony as low as possible
Agile RUP development case and giving presentations
2. Keep the team as small as possible
and workshops on RUP, Agile and project management.
3. Make as few work products as possible
With co-author Eef Dekker, he wrote the Dutch book
4. Apply the simplest possible approval procedure on as few work RUP op Maat: Een praktische handleiding voor IT-pro-
products as possible jecten, (translated as RUP Tailored: A Practical Guide to
5. Take the simplest toolset that meets your needs IT Projects), second revised edition published in 2008
6. Maintain (explicit) traceability as little as possible (see www.rupopmaat.nl). They are now working on a
7. Choose the most effective form of communication new book: ScrumUP, Agile Software Development with
Scrum and RUP (see www.scrumup.eu).
Each of these rules supports balancing of costs and revenues.
Especially revenues that will show up only in the long run might Eef Dekker
be hard to quantify, but might be very worthwhile investigating. is a consultant at Ordina,
Making expected revenues explicit gives you a tool for measuring based in The Netherlands.
the effectiveness of the measures taken. The results of such a He mainly coaches orga-
measurement are in turn indispensable for further optimization nizations in implementing
of your development process. ■ RUP in an agile way. Fur-
thermore he gives presen-
tations and workshops on
[1] See Frederick P. Brooks Jr., The Mythical Man-Month. Essays on
RUP, Use Case Modeling
Software Engineering, Anniversary Edition 1995. The insights that Brooks
and software estimation
formulated in 1975 are still valid.
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

working alone. I would like to propose that pair programming is

productive thanks in part to the fact that the verbal reflection
“I can’t seem to figure out what is wrong with this loop is in constant motion.
function. Jim, can you help me out?”
So what is pair programming? Pair programming is a technique in
“Of course.” which two developers sit at a single computer and collaborate on
the same problem. Usually one person is “driving,” with control of
“Okay, so first you get rid of the element through the form mouse and keyboard, although the driver is frequently changed.
post. Then, you look up the model from the database and During the process, communication between the two program-
ask it to update itself. That, in turn, tells it  … EUREKA! mers is constant, as they explain to one another the nature of
That’s it! Thanks, Jim, for the help.” what they are doing in real time, as they type it. This set-up al-
lows the passive member of the duo an opportunity to reflect
“Sure, but I didn’t even do anything.” 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
Does this one-sided conversation sound familiar? For many the (Cogley 1).
simple process of explaining a problem to a coworker allows
them to arrive at the answer independently. (Then, if you’re any- The simulated conversation with Jim is a demonstration of what
thing like me, you run back to your computer in order to get the is referred to as the “Rubber Ducky Syndrome”; a joke that por-
solution into code as quickly as possible!) Meanwhile, bystanders tends that you might as well have been talking to an inanimate
like Jim are left to wonder why they were credited with the solu- rubber duck instead of a person. “Rubber Ducky Syndrome,” as
tion when their feedback -- or lack thereof -- didn’t actually solve we all know, is not technically true: when trying to solve a prob-
the problem. In fact, in many instances it isn’t the feedback that lem you can’t simply explain it to an inanimate object and expect
allows us to overcome our hurdles; it is the very act of communi- a solution every time. Nonetheless, everyone can relate to the
cation that triggers the solution. need to talk through certain problems out loud. For this reason,
the spirit of the “Rubber Ducky Syndrome” is relevant; since the
The idea that verbal communication can positively affect the so- act of explaining a problem to another person creates the mental
lutions and designs of a system is pretty powerful, because, let’s context that is necessary for solving the problem.
face it, creating software is no easy task. It is difficult to consis-
tently design simple solutions for complicated problems. Still, the According to Robert M. Krauss and Susan R. Fussell, authors of
proven positive effects that communication has on both design Models of Interpersonal Communication, there is “evidence that
and problem-solving makes me wonder why more developers creating a message can affect the way the creator perceives,
aren’t actively seeking out opportunities to work together. There remembers, and thinks about the message’s contents (99).” In
is evidence that shows that pair programming -- similar to what is other words, communicating a message will, in effect, alter it. Al-
being done currently by members of the eXtreme programming though his alteration can have a negative effect when you are try-
community -- is more productive than individual programmers ing to do something specific, like recognize a facial structure or

10 www.agilerecord.com
explain a memory, it has a very positive effect when you want to Bibliography
solve a problem. The communication lays out an explanation of
the known parts of the problem. Then, by linking together these http://en.wikipedia.org/wiki/Pair_programming
known parts of the problem, a solution frequently appears by vir- Arisholm, Erik; Hans Gallis, Tore Dybå, Dag I.K. Sjøberg (Febru-
tue of verbalizing the problem itself. ary 2007). “Evaluating Pair Programming with Respect to System
Complexity and Programmer Expertise”. IEEE Transactions on
In a study that Annekatrin Wetzstein and Winfried Hacker pub- Software Engineering 33 (2): 65–86. doi:10.1109/TSE.2007.17.
lished in 2004, they asked a group of students to put together a http://simula.no/research/engineering/publications/Aris-
complex garden grill. The control group was asked to assemble holm.2006.2/simula_pdf_file. Retrieved 2008-07-21.
the grill and then left alone until their design was complete. The Models of Interpersonal Communication (Robert M. Krauss and
experimental group was asked to, at some point, stop what they Susan R. Fussell)
were doing and explain any difficulties they were having, along Jonathan Cogley: http://weblogs.asp.net/jcogley/archive/2007/​
with their proposed solution. The results of the study indicated 03/19/pair-programming-improves-your-communication-skills.
that the experimental group that had been asked to stop and aspx
verbalize their plan had a much better final design than the con-
trol 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 expla-
nations 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 an-
> About the author
other person about a problem, you load a full context into your
memory, which provides you with more information and framing Paul Pagel
for the problem. Then, with this clear mental snapshot of the is co-founder and software
challenges at hand, it is more likely that you will arrive at a solu- craftsman at 8th Light. He
tion that you had not previously considered. has been working in the
software industry for over
The results are similar within the realm of computer program- 5 very unique years. Paul
ming. Pair programming has been shown to be more effective is among the first formally
through a number of metrics. The Williams (2000) study showed trained software crafts-
an improvement in [programming] correctness of around 15%, men. He spent about 3
as well as a 20–40% decrease in time and an increase in effort and a half years apprentic-
of between 15–60%. The overall quality of the code is increased, ing under the tutelage of
which over the life of a software application drives down all nega- the renowned developers at Object Mentor.
tive metrics. Imagine if your application had 15% fewer mistakes
which took you 20–40% less time to fix. This quality makes the Paul has been a driving force in the realm of Software
application stable and able to adapt to changes. Craftsmanship. He was the primary organizer of the
Software Craftsmanship Summit in December 2008
The importance of this research is that programming is shown and major contributor to the Manifesto for Software
to demonstrate consistent benefits when employing some form Craftsmanship (manifesto.softwarecraftsmanship.org).
of a communication loop. It is through explanation and verbal Not only is Paul a practicing craftsman, but he is also
reflection that we solve problems most effectively, in addition to an active mentor for software apprentices. Participating
creating solutions that are simple and readable for the rest of in the software community is important to Paul.
the world. ■

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 is that really the right story?
but they can be misleading. This is the story behind the chart.
This is the number of found and fixed defects during an iteration, What Really Happened
and more importantly, this is what really happened.
Background
The Chart
This project is a software solution being developed by a Boston-
based 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. De-
fects are logged by machines (automatically with scripts) and by
humans. Any test that does not complete successfully is consid-
ered 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
The Memorial Day holiday occurred on May 31, 2010 in the Unit-
ed States. The office was closed, and little to no work was done.
This chart shows the number of defects found (red) and the num- The drop in the number of defects identified and in the number
ber of defects resolved (green) over a thirty-day period on a single of defects fixed has nothing to do with the software. Rather, it’s
project. This is the middle of a project, with new features being because no humans were finding or fixing defects.
coded and checked in, ongoing tests being conducted, and de-
fects being identified, fixed, and verified. 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 get-
ting found, and bugs are getting fixed in about equal measure. In the first week of June 2010, Boston experienced a heat wave
The code is churning, which is normal for the middle of a devel- and high humidity. It’s not uncommon, but this happened earlier
opment cycle, but isn’t trending toward stability. The number of in the summer than normal. The building was unprepared, and
bugs found slightly exceeds the number of bugs being fixed, so the air conditioners were not yet turned on for summer weather.
this is a project to keep an eye on. The developers (and testers) The spike in defects is the lab getting warm. Several machines
may need some intervention! simply got too hot and died. When they died, the tests that hap-

12 www.agilerecord.com
pened to be using those machines failed with an error and auto- Conclusion
matically logged a defect.
The chart shown above implies a story. At first glance it’s a story
So a spike in heat led to a spike in defects created. There is a of some churning code and some developers who just can’t keep
spike in resolved defects just afterwards, as the team replaced up. That story is wrong. A look at what really happened points
the dead machines and tracked the test failures to those ma- to two things: a small team, and an unstable test lab. A more
chines. “spikey” chart is a consequence of a small team, where the
effects of one team member being gone are highly visible; on
Episode 3: The File Server Update larger teams the effect of any one person is generally smaller,
so charts are smoother. For the manager looking at this chart,
All test machines in the lab use a central file server for storing understanding the story behind the lines of the chart points to
logs and other shared information. On May 24, the IT team de- needing to spend more effort on stabilizing the test lab rather
ployed a new file server. This would have been fine had no tests than on changing a development team’s behavior. ■
been running, but one set of tests was still going. When the cen-
tral file server went down (for replacement), it exposed a bug in
the test infrastructure. The test infrastructure panicked, discard-
ing 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. > About the author

One bug in the test infrastructure, and one triggering event in the Catherine Powell
form of file server downtime caused 24 defects to be logged. The has been testing and man-
fix took 10 minutes to implement. aging for about ten years.
She is a manager, a tester,
Episode 4: The New Operating System an author and a formal
mentor to testers and test
This project is software running on various flavors of Linux. In managers. Catherine has
general, the various flavors of Linux are roughly similar, but they worked with a broad range
are each quirky in their own way. In mid-June, the team decided of software, including an
to start supporting a new type of Linux: Red Hat Enterprise Linux. enterprise storage system,
A team member installed Red Hat Enterprise on a few machines, a web-based healthcare
put them in the lab, and configured the tests to start running on system, data synchronization applications on mobile
those machines. That night, some of the tests failed, and the devices, and web apps of various flavors.
team came in the next day to find some bugs specific to Red Hat
Enterprise Linux. Some were fixed, and another spike occurred With a focus on the human side of software develop-
the next day as follow-on issues showed up. ment, Catherine builds strong teams spanning testers,
developers, support, product management, and all the
This spike in defects logged is the result of a new feature of the people involved in turning an idea into reality. She em-
software – support for a new operating system. phasizes the generation of information and pragmatic
decision making using a myriad of approaches. With
Episode 5: The Vacation thoughtful techniques that access the strengths of the
human team members combined with the needs of the
In mid-May one of the developers took a week of vacation. With a system and its users, Catherine guides both developers
small team like this, the developer’s vacation meant that 20% of and testers to be a valuable part of the decision making
the team was gone for a week. The chart shows an unusually low required to create rock-solid software.
number of defects fixed; this is because a significant portion of
the team simply wasn’t around to fix things. The following week – Catherine focuses primarily on the realities of ship-
when the developer returned from vacation – shows a jump in ping software in small and mid-size companies. Spe-
the number of defects fixed. cifically, she highlights and works to explicate the “on-
the-ground” pragmatism necessary for an engineering
Is that indicative of a problem? No. It’s indicative of a vacation. 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 testing after every build to make sure the already implemented
will be familiar with the words iterative builds, regression testing, features are still working properly and that the newly added fea-
automation, feedback, code excellence, unit testing, and other tures have not introduced new bugs.
terminologies that indicate testing and quality. Why testing and
quality? Because this is what differentiates one organization In Agile teams, testers are no longer intruders. They are team
from another, because quality is the reason why people use cer- members, they work together with the rest of the team to de-
tain products and and not others, because quality means safety, liver the highest quality to satisfy their customers. In some Agile
reliability, efficiency and outstanding performance. Nowadays, teams the relation between testers and developers is not the tra-
organizations are very competitive. The market changes rapidly, ditional relation with each of them defending their side as if in a
and customers’ demands are sometimes challenging, so if we battle. In Agile teams, the testers and the developers have the
did not do our best to catch up the technology train, we will be same vision and the same goal to reach.
way behind. How can we do this? The answer is by raising our
work quality standards, because  – believe me  – it is all about Who are Agile Testers?
quality.
An Agile tester is not just a quality control person, but is a good
As quality is a basic objective in our work, and because we are tester with excellent knowledge of the Agile practices and the
committed to delivering high-quality products, we will look at development lifecycle. He is the team member who helps guide
some basic definitions of Agile Testing. Who are the Agile testers, the whole development team in a way that ensures the product
what is their role in Agile teams, and why do we need Agile testers behaves as intended, and the implemented features are exactly
in our teams anyway? what was agreed with the customer in the stories of the iteration
or the release.
What is Agile Testing?
The Agile tester works with the customer and the stakeholders to
Agile Testing is software testing based on the principles of the understand every feature of the project to facilitate the commu-
Agile Manifesto. It differs from the traditional software testing in nication between team and customer and to ensure that they are
the approach of the tester and in how he sees the software ap- all on the same page and speak the same language. For exam-
plication. It is based mainly on “Personas” that are using/buying ple, the team and the customer have agreed on the definition of a
the system, i.e. testing from the customer perspective. Also Agile Done-Done feature/story, agreeing on the acceptance criteria for
testing is not an activity that comes at the end of the software each story (which can be a major conflict issue between custom-
development lifecycle, but it is an iterative activity that comes er and team); they therefore need to have the same understand-
within the project iterations throughout the whole lifecycle of the ing of the definition of the acceptance criteria. You have to take
project. It is a “test early and test often” activity. into consideration that every customer has his own personality
and his own business background. So even if the development
Agile testers should use automation testing to eliminate the re- team has predefined what the acceptance criteria are, they still
petitive manual testing of the acceptance tests and the regres- need to be discussed with the customer. This way they will know
sion test suites. Automated testing is essential in Agile testing be- their customer better and know exactly what is expected.
cause of the repetitive builds. Testers need to perform regression

14 www.agilerecord.com
Do We Need Agile Testers in our Team? Agile tester attends the iteration planning, release planning, ac-
ceptance criteria writing, feedback meetings with clients, demo
Some Agile teams which practice unit testing, test driven devel- meeting with clients, functionality testing for each story during
opment or any other type of code testing think that they do not the iteration, performs acceptance tests per story, and regres-
need an Agile tester in their team. They see it this way: we code, sion testing after each build. The Agile tester verifies and vali-
we test our code, we get feedback from the customer, and we dates every story delivered to the customer and makes sure that
work on that feedback, what is the value of a tester in our team. the “Done-Done” criteria are met.

Let me show you the value of testers in any development team, In the real world, the Agile tester’s role may vary from this spe-
not only an Agile team. What distinguishes the tester from the cific defined role. Because we live in an imperfect world, we can
rest of the development team is that when a tester tests the ap- expect complications along the way. Throughout any project the
plication, he keeps in mind a couple of things: 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 Complications may be from the team side or from the customer
application against the requirements. Or in an Agile team they side, or maybe both. It could be the performance of one team
verify the application against the stories, and he does so using member that affects the rest of the team, it could be a misunder-
the predefined acceptance criteria. This standing of the project scope and/or re-
type of testing is called positive testing. quirements that cause a conflict between
Sometimes we have to change team members or between team and
Second: Testers think about ways to our plans and our goals to cope customer, it could be a misunderstanding
break the application, testing the re- with world imperfection. of Agile implementation or absence of an
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 be-
the 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 af-
stories 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 elimi-
Another 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 ques- work 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 par-
ticular 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. Wachsen Sie mit uns!
The good understanding of the project requirements/stories,
good knowledge of the Agile process, understanding the custom-
er needs, and, of course, excellent understanding of the testing Wir suchen
techniques used within your project will empower the tester to
decide whether the project meets the quality standards agreed Senior Consultants
with the customer, or whether it is a disaster and the customer
IT Management & Quality Services
should know nothing about it.
(m/w)
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 qual-
www.diazhilterscheid.de
ity is the whole team’s responsibility. We may face some obsta-
cles 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? ■

> About the author

Sara Medhat
is a senior software test
engineer, ISTQB® (Interna-
tional Software Testing and
Qualifications Board) certi-
fied, and software testing
trainer with five years of ex-
perience in the quality con-
© iStockphoto.com/mariusFM77

trol 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 ses-
sion about “How an Agile Project can Fail; and what to
do about it.”

16 www.agilerecord.com
 © Mikhail Tolstoy - Fotolia.com
Value-Driven Development
Principles and Values – Agility
is the Tool, Not the Master
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 I fear this article may not correct the narrow-mindedness of the
coder community, and my principles do apply to a higher level of
The Agile Manifesto [2] has its heart in the right place, I am only thinking than coding. I am going to try to formulate a much clear-
worried about its ‘mind’. And its first principle “Our highest prior- er set of principles, a more explicit set; and in the subsequent ar-
ity is to satisfy the customer through early and continuous deliv- ticle, I will formulate clearer ‘values’ than the Agilistas managed
ery of valuable software”, is central to the ideas in this article. to do. I have one decided advantage: I am not subject to lowest
It is not strange that I agree, since many of the Agilistas, for ex- common denominator politics, as they were; I can express my
ample Kent Beck, explicitly point to my 1988 book as a source of own opinion – unopposed! I hereby give them specific permission
some of their ideas [4, 5, 6, 7, 8, 9, 12]. to update their wooly and dangerous ideals with these more fo-
cussed ideals. And because they won’t (chiselled in stone, unag-
My problem with agile is not in its ideals, but in the everyday ile documentation Manifesto) I give the reader the right to spread
teaching and practices we see. What we see is the same problem it, and update, and improve it, as they like.
that has been afflicting all software and IT projects long before
agile appeared. Our technocratic culture has forgotten our stake- ‘Value Principles’
holders and their values.
Principle 1. Control projects by quantified critical-few results.
The practices are far too ‘programmer centric’, and far too little 1 page in total! (Not stories, functions, features, use cases, ob-
‘stakeholder value’ centric. The result is that ‘working software’ jects,  …)
[2] is delivered to a ‘customer’ [2].
Most of our so-called functional requirements are not actually re-
However, necessary values are not necessarily, and all too rarely, quirements. They are designs to meet unarticulated, higher-level,
delivered to all critical stakeholders. Code has no value in itself. and critical requirements [14]. For example the requirement to
We can deliver bug-free code, that has little or none of the an- have a ‘password’ is hiding the real ‘Security’ quality requirement
ticipated value. We can deliver software functions, as defined in [13]. Most of the really critical project objectives are almost al-
requirements, to the ‘customer’ – but totally fail to deliver critical ways buried in old management slides, and formulated in a wooly
value to many critical stakeholders. and un-testable way. They are never used in architecture, con-
tracting or testing. This is a major cause of project failure [14].
The Opera ticket system at the magnificent new Oslo Opera Management and project sponsors are led to believe the project
House is a simple example. In the old days, a ticket was ripped will deliver certain improvements. In practice the agile culture
off a stack and immediately delivered to the ticket buyer. The has no mechanism for following up and delivering expected val-
new system, at opening, took 10–20 minutes for the ticket sell- ues. Scrum would argue that that is the job of the product owner.
ers to negotiate what to do and how to do things like senior and However, even top Scrum gurus openly acknowledge that the sit-
child discounts. With frequent access to supervisors, who were uation in practice is nowhere near what it should be. We simply
not sure of what or how. No bugs, all the functions, but some- do not teach and practice the necessary mechanisms. Software
thing was catastrophically wrong. ‘Working software’  – working people were always bad at this, but agile did not deliver clear
badly. Thank God, the Agilistas did not design the Opera House ideals on its own.
itself! That was done by real first-class architects! [3]

18 www.agilerecord.com
 Principle 2. Make sure those results are business results, not one example earlier (a real one, Ohio), where a ‘password’ was
technical. Align your project with your financial sponsor’s inter- required, but ‘security’ (the real requirement) was not at all de-
ests! fined.

People do not do development projects to get function, features We are so bad at this, that you can safely assume that almost
and stories. Yet these seem primary in the current agile methods. all so-called requirements are not real requirements, they are
We need functions, stories and perhaps ‘features’ to make sure bad designs. All you have to do to see this is ask: WHY? Why
the application will do the fundamental business activities that ‘password’? (Security, stupid!)  – Oh! Where is the security re-
are expected (e.g. ‘issue an opera ticket’, ‘give a child discount’). quirement? Not there, or worse, stated in management slides
But these fundamentals are never the primary drivers for the in- as ‘state-of-the-art security’ – and then left to total amateurs to
vestment in a development project. As a rule, the stakeholders design it in!
already have those functions in place, in current systems. If you
look at the project documentation, someone ‘sold’ management Imagine if Test Driven Development (TDD) actually tested the
on better systems – some improvements. Faster, cheaper, more quality levels, like the security levels, to start with? Far from it;
reliable etc. and TDD is another disappointment in the agile kitbag.

These are always improvements that are specifically stated I analyze real requirements about once a week, internationally,
somewhere, and they are always quantifiable,. Unfortunately, we and find very few exceptions – i.e. situations where the real re-
in agile development avoid being specific at this level. We use ad- quirements are defined, quantified, and then designed (engi-
jectives like ‘better’, ‘improved’, ‘enhanced’ and leave it at that. neered, architected) towards. Agile culture has no notion of real
We have learned long ago that our customer is too uneducated engineering at all. Softcrafting [4], sure. But not engineering –
and too stupid (common sense should compensate for lack of totally alien.
education) to challenge us on these points. And they happily pay
us a lot of money for worse systems than they already have. You cannot design correctly towards a vague requirement (‘better
security’). How do I know if a password is a good design? If the
We need to make it part of our development culture to care- security requirements are clear and quantified (and I simplify!)
fully analyze business requirements (‘save money’), to carefully like “Less than 1% chance that expert hackers can penetrate the
analyze stakeholder needs (reduce employee training costs’), to system within 1 hour of effort”, then we can have an intelligent
carefully analyze application quality requirements (‘vastly better discussion about the 4-digit pin code that some think is an OK
usability’). We need to express these requirements quantitatively. password.
We need to systematically derive stakeholder requirements from
the business requirements. We need to derive the application I have one client (Confirmit, [16]) who pointedly refuses to accept
quality requirements from the stakeholder requirements. Then functions and features requirements from any customer or sales-
we need to design and architect the systems to deliver the quan- person. They focus on a few critical product qualities (like usabil-
tified requirement levels on time. We are nowhere near trying to ity, intuitiveness) and let their developers engineer technical so-
do this in current conventional agile methods. So we consistently lutions to measurably meet the quantified quality requirements.
fail the business, the stakeholders, and fail to deliver the quality
levels required [15]. This gets the right job (design) done by the right people (devel-
opers) towards the right requirements (higher level overall views
Let me be clear here. You can do this as the system evolves, of the qualities of the application). They even do their ‘refactor-
and it can be expressed on a single page of quantified top level ing’ by iterating towards a set of long-term quality requirements
requirements [examples 14]. So don’t try the ‘up front bureau- regarding maintainability, and testability. Probably just a coinci-
cracy’ argument on me! dence that their leaders have real engineering degrees?

Principle 3. Give developers freedom, to find out how to deliver Principle 4. Estimate the impacts of your designs, on your
those results. quantified goals.

The worst scenario I can imagine is when we allow real custom- I take quantified improvement requirements for granted. So do
ers, users, and our own salespeople to dictate ‘functions and engineers. Agilistas do not seem to have heard of the ‘quantified
features’ to the developers, carefully disguised as ‘customer re- quality’ concept. This means they cannot deal with specific, or
quirements’. Maybe conveyed by our product owners. ‘high’, quality levels.

If you go slightly below the surface of these false ‘requirements’ The concept of ‘design’ also seems alien. The only mention of de-
(‘means’, not ‘ends’), you will immediately find that they are not sign or architecture in the Agile Manifesto is “The best architec-
really requirements. They are really bad amateur design for the tures, requirements, and designs emerge from self-organizing
‘real’ requirements  – implied, but not well defined [17]. I gave 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 i d

www.agilerecord.com 21
 on architecture and design is missing most all essential ideas of lazily taken advantage of it.
real engineering and architecture [18].
Principle 6. Decompose the workflow into weekly (or 2% of
We have to design and architect with regard to many stakehold- budget) time boxes.
ers, many quality and performance objectives, many constraints,
many conflicting priorities. We have to do so in an ongoing evo- At one level, the Agilistas and I agree that dividing up big projects
lutionary sea of changes with regard to all requirements, all into smaller chunks, of a week or so, is much better than a Wa-
stakeholders, all priorities, and all potential architectures. Simply terfall/Big Bang approach [21].
pointing to ‘self-organizing teams’ is a method falling far short of
necessary basic concepts of how to architect and engineer com- However, I would argue that we need to do more than chunk
plex, large-scale critical systems. Indeed, even for much smaller by ‘product owner prioritized requirements’. We need to chunk
systems such as the 13-developer Confirmit system [16]. 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, Sometimes the quantified value/cost. We need to select, next week
then measurements, of how well it meets quality and value requirements (next value delivery step to stakeholders)
the multitude of performance and qual- are overambitious. the greatest value we can produce in an
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 quan-
many requirements [19, 10, 4]. It has been proven to be consis- tified value requirements (above), and the quantified design esti-
tent with agile ideals and practices, and has been given far bet- mates (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) deliv-
of 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 confront-
gested design on our requirements, then the designer is incom- ed 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 If you get stepwise numeric feedback on the actual delivered
their costs, do them first. value of a design, compared to estimated and perceived value,
as is normal at Confirmit [16], then you will occasionally be disap-
Assuming we find the assertion above, that we should estimate pointed with the value achieved. This will give you the opportunity
and measure the potential, and real, impacts of designs and to reconsider your design, or your design implementation, in or-
architecture on our requirements, to be common sense. Then der to get the value you need, irrespective of your previous lack
I would like to argue that our basic method of deciding ‘which of understanding. You might even learn that ‘coding alone is not
designs to adopt’ should be based on which ones have the best enough’ to deliver value to stakeholders.
value for money. Scrum, like other methods, focuses narrowly
on estimating effort. This is not the same as also estimating I fear that this realistic insight possibility is largely lost; since the
the multiple values contributed to the top ten project objectives agile methods neither quantify the value required, nor do they
(which ‘Impact Estimation’ does routinely) [19]. It seems strange quantify the value expected from a step or a design at a given
to me that agile methods understand the secondary concept of delivery step.
estimating costs, but never deal with the primary concept of es-
timating value to stakeholders, and to their requirements. There The result is that we get stuck with bad designs until it is too late.
is little point in managing cost, if you cannot first manage value. To me, that does not seem very ‘agile’.
The deeper problem here is probably not Agile methods, but is
a total failure of our business schools to teach managers much Principle 8. Change requirements based on quantified value
more about finance, and nothing about quality and values [20]. and cost experience, new inputs.
If management were awake and balanced, they would demand
far more accountability with regard to value delivered by software Sometimes the quantified quality and value requirements are
developers and IT projects. But the development community has overambitious. It is too easy to dream of perfection, and impos-
long since realized that management was asleep on the job, and sible to actually get it. It is too easy to dream of great improve-

22 www.agilerecord.com
ment, without being aware of its true cost, or state-of-the-art limi- even recognizing the stakeholder concept. Head in the sand, if
tations. Sometimes we have to learn the reality of what we can or you ask me!
should require by practical experience. This is of course normal
engineering and science. To learn technical and economic reali- Principle 10. Involve the stakeholders, every week, in actually
ties step by step. using value increments.

The agile community, however, has, as we have pointed out, little Finally – the stakeholders are the ones who should get value de-
concept of quantifying any requirements. Consequently, they livered incrementally, at every increment of development.
cannot learn what is realistic. They will just get what they get by
chance or custom. I believe that this should be the aim of each increment and not
‘delivering working code to customers’. This means you need to
If they actually quantified their key requirements, and if they recognize exactly which stakeholder type is projected to receive
measured the incremental numeric results, then if requirements exactly which value improvement, and plan to have them, or a
were either overambitious or unacceptably costly, we would have useful subset of them, on hand to get the increment, and evalu-
a chance to react quickly (agility!). Learning and agile change ate the value delivered. Current agile methods are not set up
are threatened by the lack of quantification and measurement to do this, and in fact do not seem to care at all about value or
in the normal development process. But today’s agile community stakeholders.
remains unconcerned.
In fact, developers would have to consider the whole system, not
Principle 9. Involve the stakeholders, every week, in setting just the code, in order to deliver real value – and coders feel very
quantified value goals. uncomfortable with anything outside their narrow domain.

Agile methods refer to users and customers. The terms used are Isn’t it is amazing that they have been given so much power by
‘sponsors, developers, and users, customers’. In systems engi- ‘managers’ to screw up society? ■
neering (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 Here is an overview of my Agile Values, the subject of a more
mention the concept. In real projects of moderate size, there are detailed article in the next issue.
20 to 40 interesting stakeholder roles worth considering. Stake-
holders are sources of critical requirements. Microsoft did not My 10 Agile Values? © Tom Gilb 2004-10
worry enough about a stakeholder called the EU – a costly mis-
take. In every failed project – and we have far too many – you will Simplicity
find a stakeholder problem at the root. Stakeholders have priori- 1. Focus on real stakeholder values
ties, and their various requirements have different priorities. We Communication
have to keep systematic track of these. Sorry, if it requires mental 2. Communicate stakeholder values quantitatively
effort. We cannot be lazy and then fail. I doubt if a Scrum product 3. Estimate expected results and costs in weekly steps and get
owner is trained or equipped to deal with the richness of stake- quantified measurement feedback on your estimates the same
holders and their needs In fact, the PO seems to be a dangerous week
bottleneck in this concern. 4. Install real quantified improvements for real stakeholders weekly
5. Measure the critical aspects in the improved system weekly
However, it can never be a simple matter of analyzing all stake-
6. Analyze deviations from value and cost estimates
holders and their needs and the priorities of those needs up
Courage
front. The fact of actual value delivery on a continuous basis
7. Change plans to reflect weekly quantified learning
will change needs and priorities. The external environment of
8. Immediately implement the most valued stakeholder needs by
stakeholders (politics, competitors, science, economics) will con-
next week
stantly change their priorities, and indeed even change the fact
Don’t wait, don’t study (analysis paralysis), don’t make excuses.
of who the stakeholders are. So we need to keep some kind of
Just do it!
line open to the real world, on a continuous basis. We need to try
9. Tell stakeholders exactly what quantified improvement you will
to sense new prioritized requirements as they emerge, in front
deliver next week
of earlier winners. It is not enough to think of requirements as
10. Use any design, strategy, method, process that works well quan-
simple functions and use cases. The most critical and pervasive
titatively in order to get your results
requirements are overall system quality requirements, and it is
Be a systems engineer, not a just a programmer (a ‘Softcrafter’).
the numeric levels of the ‘ilities’ that are critical to adjust, so that
Do not be limited by your craft background, in serving your
they are in balance with all other considerations.
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 the book describes in detail Planguage, a specification language
for systems engineering, the methodological advice alone is worth
1. Gilb’s Agile Principles and Values the price of the book. Evo is one of the truly underappreciated agile
The draft basis for a full paper. Originally formulated for conference methodologies and as a result Gilb’s thought-provoking work isn’t as
speeches in November 2004 (London, XP Days Keynote, What’s well known as it should be, although I suspect that this will change
Wrong with Agile?). http://xpday4.xpday.org/slides.php Original with this book. The book describes effective practices for require-
slides still here. Slides 38-39 the Principles and Values statements. ments and design specification that are highly compatible with the
This is why I am copyrighting from 2004. I literally wrote the values principles and practices of Agile Modeling, yet it goes on to address
and principles at the conference just before my speech, and they planning activities, quality, and impact estimation. I suspect that this
first appeared in my slides. I have updated the principles to stress book will prove to be one of the “must read” software development
“values, stakeholders and costs” in 2007 and 2010 for this article. books of 2006.

2. Agile Manifesto: 12. http://leansoftwareengineering.com/2007/12/20/tom-gil​bs-

URL http://agilemanifesto.org/principles.html evolutionary-delivery-a-great-improvement-over-its-successors/
“But if you really want to take a step up, you should read Tom Gilb.
3. http://en.wikipedia.org/wiki/Oslo_Opera_House The ideas expressed in Principles of Software Engineering Manage-
ment aren’t quite fully baked into the ADD-sized nuggets that today’s
4. Gilb, Principles of Software Engineering management, 1988. developers might be used to, but make no mistake, Gilb’s thinking on
http://books.google.co.uk/books?q=gilb+principles+of+software+e requirements definition, reliability, design generation, code inspec-
ngineering+management&spell=1&oi=spell tion, and project metrics are beyond most current practice.” Corey
Ladas
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 13. Re Security Requirements:
more than 2% of the total project schedule). This was long before the http://www.gilb.com/tiki-download_file.php?fileId=40
rest of us had it figured out.” A paper on how to quantify security requirements.
http://blog.mountaingoatsoftware.com/?p=77
14. Top Level Objectives:
6. Comment of Kent Beck on Tom Gilb, Principles of Software En- http://www.gilb.com/tiki-download_file.php?fileId=180
gineering Management: “ A strong case for evolutionary delivery – A handful of real case studies regarding top level project require-
small releases, constant refactoring, intense dialog with the custom- ments, or lack of them.
er”. (Beck, page 173).
In a mail to Tom, Kent wrote: “I’m glad you and I have some align- 15. One example of systematic quantitative analysis and connection
ment of ideas. I stole enough of yours that I’d be disappointed if we of business, stakeholder and quality levels of requirements in the
didn’t :-), Kent” (2003) Norwegian Post case study by Kai Gilb. http://www.gilb.com/tiki-
download_file.php?fileId=277
7. Jim Highsmith (an Agile Manifesto signatory) commented: “Two
individuals in particular pioneered the evolution of iterative devel- 16. Confirmit Case: Paper
opment approached in the 1980’s  – Barry Boehm with his Spiral http://www.gilb.com/tiki-download_file.php?fileId=32
Model and Tom Gilb with his Evo model. I drew on Boehm’s and Confirmit case slides:
Gilb’s ideas for early inspiration in developing Adaptive Software De- http://www.gilb.com/tiki-download_file.php?fileId=278
velopment. … Gilb has long advocated this more explicit (quantita-
tive) valuation in order to capture the early value and increase ROI” 17. Real Requirements: How to find out what the requirements really
(page 4, July 2004). are, paper.
http://www.gilb.com/tiki-download_file.php?fileId=28
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 18. Architecture, a View.
community is paying attention to your work. We know (now) that you http://www.gilb.com/tiki-download_file.php?fileId=47
were out there ahead of most of us. Best regards. – Ward, http://
19. Design Evaluation: Estimating Multiple Critical Performance and
c2.com
Cost Impacts of Designs
9. Robert C. Martin (Agile Manifesto initial signatory, aka Uncle Bob): http://www.gilb.com/tiki-download_file.php?fileId=58
“Tom and I talked of many things, and I found myself learning a great
20. Hopper: The Puritan Gift: Reclaiming the American Dream
deal from him. The item that sticks most prominently in my mind is
Amidst Global Financial Chaos’, http://www.puritangift.com/
the definition of progress.”, “Tom has invented a planning formalism
This is not least a direct and deep attack on Business Schools to
that he calls Planguage that captures this idea of customer need. I
teach much more than a narrow financial agenda (aka greed), for-
think I’m going to spend some serious time investigating this.” from
getting the broader set of values that lead to long-term financial
http://www.butunclebob.com/ArticleS.UncleBob.TomGilbVisit
soundness.
10. Gilb, Competitive Engineering, 2005, http://books.google.co.uk/ http://twitter.com/puritangift
books?q=gilb+competitive+engineering&btnG=Search+Books
21. Decomposition:
11. Scott Ambler on Amazon reviews, of Competitive Engineering: http://www.gilb.com/tiki-download_file.php?fileId=41
Tom Gilb, the father of the Evo methodology, shares his practical,
22. Susanne Robertson’s several papers regarding stakeholders:
real-world experience for enabling effective collaboration between
http://www.systemsguild.com/GuildSite/Guild/Articles.html
developers, managers, and stakeholders in this book. Although

24 www.agilerecord.com
> About the author
Tom Gilb
(born 1940, California) has
lived in UK since 1956,
and Norway since 1958.
He is the author of 9 pub-
lished books, including
Competitive Engineering: A
Handbook For Systems En-
gineering, Requirements
Engineering, and Software
Engineering Using Plan-
guage, 2005.

He has taught and consulted world-wide for decades,

including having direct corporate methods-change in-
fluence 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 ‘Soft-
ware Inspection’ (1993). He is known for his stimulating
and advanced presentations, and for consistently avoid-
ing 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 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
It’s always easy to leave things for later, but the consequences track of your schedules and commitments. Thinking about that
are almost always bad. Usually, there is no logical reason to defer fine line again…
anything, starting with simple things such as paying your bills,
and ending with dealing with your project’s problems. They won’t Don’t Micromanage
just get solved by themselves; they are only going to get worse as
time passes. What is more, there are for sure some people rely- While being confronted with stressful situations or tight commit-
ing on you and waiting for you to finish, in order to be able to do ments, you can easily turn into a control freak. You may feel the
their job. You owe these people to get your job done as soon and need to know every aspect, every detail, in order to be able to
as well as you can. have everything under control. Humans, however, are not that
“multi-threaded”, so they need to surround themselves with trust-
Respect Your People worthy and skilled people who they can rely on, rather than trying
to squeeze every bit of information into their 20%-used brain.
They’ve made it to this team thanks to their qualities and
strengths. They have developed into experienced professionals, Listen and Make Sure They Listen to You
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 fac- You want to be constantly aware of your people’s needs and prob-
tors in any good relationship. lems, while making sure they know your expectations. You have
every reason in the world to be attentive while in meetings with
Trust Them your fellow leaders and managers, but also to be able to leave
relieved that they all know your team’s status or your personal
There are two kinds of people. The ones thinking that trust is to points of view, when the meeting is over. Finding the right ways to
be earned, and the others who trust people from the beginning, communicate is therefore crucial, and yet so different from one
only to lose it if they get let down. I personally belong to the latter, situation to another.
but I find worth mentioning that trusting someone doesn’t mean
being naive. You still have deadlines to meet, you still have to Never Wait
make sure your team is producing quality work, so there is a very
thin line between being trusting and being too loose. Leaders aren’t waiting, they’re acting. Being reactive, or even
worse – passive, isn’t part of a leader’s job description. A good
Don’t Lose Control way to tell if you are being proactive enough is to ask yourself
this question: Usually, when my manager asks me something, do
There is an old saying: Trust is good, control is better. You may be I know the answer on the spot, or do I have to find it out? If you
shocked to find out it belongs to no other than Joseph Stalin, but are always being told what to do, you probably aren’t much of a
I consider this only proves that even villains can be pretty wise leader after all.

26 www.agilerecord.com
Be What You Want Them to Be
> About the author
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 be- Alex Rosiu
ing, more or less consciously. Your behavior is therefore crucially is a Technical Project Man-
determinative for their own, so unless you don’t want to be sur- ager at BitDefender, a se-
rounded by jerks, make sure you’re not one. Unfortunately, nega- curity software company.
tive behaviors are easy to imitate, but the good news is, positive As a computer science
things are also quite catchy. ■ graduate, he started his
career as a software de-
veloper, moving on to tech-
nical 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 automation coding effort couldn’t even commence until sections

of the code were complete and stable.
Software test automation has been available for over a quarter
of a century, but the practice still has many skeptics, and the It got worse. Most of each script that needed to be coded had
biggest barrier to adoption remains the level of maintenance re- nothing to do with testing the application. The engineers had to
quired to sustain it. Achieving just a moderate level of automa- overcome many challenges before they could even get that far –
tion coverage requires considerable investment of budget and handling unpredictable response times, retrieving displayed data
resource. With increasing software development complexity and needed for validation, and establishing checkpoints to signify
more and more IT departments taking on an agile approach, tra- when the application had completed a logical step.
ditional test automation has become too cumbersome for most
to sustain. But the death knell was what happened when the application to
be tested changed. Suddenly all these laboriously created ‘as-
But Why is Test Automation so Cumbersome? sets’ were worth nothing and would not execute until the entire
process had been repeated.
Traditional test automation systems originated in a world that
moved at a much slower pace, where waterfall developments What happened next ranged from the sane to the almost comi-
were the only game in town and no-one attempted to tackle fast cal. The sane organisations did what came naturally and gave up.
moving, mission-critical applications – they knew that the tech- Others were not to be defeated and threw even more expensive
nology simply couldn’t keep up. resources at the problem, some hiding the failure by outsourc-
ing the entire test burden – often to companies who did most of
These products all get their capabilities from powerful scripting the testing manually. All this for an initiative which was meant to
languages; something that sounds good in a presentation, but reduce the need for resources, save time and improve quality!
has become a horror in the real world, requiring a cult of high
priests, who are highly skilled and paid test automation engi- To put this in perspective, industry analysts state that the high
neers, to communicate with the complex and mysterious deity; water mark in automation success is when 20% of an applica-
the test automation tool. tion has been automated. This is the high water mark, mind you,
not the average, 20% is the peak of what you can expect after
Worse still, the script library took weeks and months to develop. a financial investment measured in hundreds of thousands of
This was something that was rationalized as OK, because you dollars and an effort investment measured in many man years.
could write the scripts in parallel with code development. The
truth was somewhat different as the script required knowledge The Current Need for Speed
of how the developers were naming the visual components  –
something that was neither consistent nor predictable. Because The way we work has also changed. In the last decade the rate
of this, the code-based tools reverted to a ‘record’ mode to es- of business change has risen beyond anything we could have
tablish the initial script, which made them only usable once the expected. The availability of new technology and the strategic
application was complete. This was more practical, but now the advantage that it can potentially provide businesses has fuelled

28 www.agilerecord.com
this, along with the need to adapt quickly to changing market suggests an almost static application, not one that is a subject of
requirements. The recession has arguably exasperated the situa- active development efforts. This sort of automation is fine for re-
tion. As the fortunes of markets change and move with a frighten- gression tests, but will not make any impact on current QA bottle-
ingly sudden pace, every business finds itself needing to achieve necks. The need is for a solution that is faster, lighter and better
more, with static or reduced budgets and resources. able to respond to dynamic application developments.

Agile development is experiencing increasing popularity in IT de- In short, the modern business with all its need for speed and agil-
partments, because today’s fast-paced business environment re- ity just has no place left for these types of solutions, regardless
quires an organisation’s development process to be flexible and of how much organizations have already invested in them, and
adaptable to changing needs. The Agile model provides frequent regardless of how much resource is tied up in trying to maintain
delivery, increased customer involvement and helps to deal with them. The need for change is now.
the problem of rising complexity in systems. However, with all the
benefits of a more fluid, flexible process, come challenges in how “The Rate of Obsolescence Outpaces the Pace of Change.” *
to assure the quality and governance of these ever-changing ap-
plications. So says Ray Wang, industry analyst and the author of the popular
enterprise software blog “A Software Insider’s Point of View”
QA teams now have to accept that requirements can often
change during and after each iteration, depending on the feed- He’s right. Technology changes too quickly for any one company
back from the customer. These changes in requirements are con- to stay on top of it. New software is released so regularly that it
sequently reflected in the code and the tests that QA teams have is already out of date by the time it is launched – consider the
to develop, which in turn can lead to a large amount of rework frequency of SAP or even Microsoft updates, keeping on top of
and script maintenance. these pose a real headache to most IT departments. We’ve got
to a state where traditional testing processes and tools are too
With delivery cycles getting shorter, and with security concerns cumbersome and development is pulling away. Testing becomes
and new regulations to manage, applications are becoming more the bottleneck. We don’t need test assets which have cost com-
like living things; beings that grow and mature, morphing from panies thousands of dollars and man-hours to develop. What the
new-born status to an almost unrecognizable fully grown adult business needs now is test assets that are quick and easy to de-
with all the associated trappings and documents that adults tend velop, that can be re-used or adapted easily, or can be discarded
to collect throughout their lives. without a second thought.

How on earth is outdated and cumbersome test automation So Why Throw Such Perfection Away?
technology supposed to cope with this level of change and com-
plexity? It simply can’t. Now it would be foolish to dispose of the entire concept purely
based on what came before. We need to recalibrate our expecta-
Still Stuck in the 90’s tions and remind ourselves of excellent potential benefits from
test automation, if only the capabilities were delivered in a form
I read an interesting comment by James A. Whittaker in his blog usable by all.
post Still Stuck in the 90s.
The ability of any automation technology to adapt to changes
“Don’t get me wrong, software testing has been full of innova- in the underlying application will always have some limitations.
tion. We’ve minted patents and PhD theses. We built tools and Is it reasonable to expect that a test script created for a legacy
automated the crud out of certain types of interfaces. But those mainframe application to still be valid on the replacement .Net
interfaces change and that automation, we find to our distress, WPF architecture? Can you expect the test scripts created for the
is rarely reusable. How much real innovation have we had in this English version of your web site to be applicable to the newly
discipline that has actually stood the test of time?I argue that developed Japanese version?
we’ve thrown most of it away. A disposable two decades. It was
too tied to the application, the domain, the technology. Each By freeing automation from the burden of a script based on code,
project we start out basically anew, reinventing the testing wheel we can begin to imagine a solution that could be used by subject
over and over. Each year’s innovation looks much the same as matter experts and not limited to frustrated developers, a solu-
the year before. 1990 quickly turns into 2010 and we remain tion that could adapt to changes in the application under test,
stuck in the same old rut.” an intelligent solution that inherently understood the application
under test, removing the need to develop logic in addition to the
HP in a refreshing burst of honesty now state that unless you will validation itself.
run a script a minimum of seven times, there will not be any pay-
back from automation. That is one heck of a statement. Any part The exciting thing is that modern automation goes a surprisingly
of an application that needs to be tested at least seven times, 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 > About the author
the existing test assets have little or no value.
George Wilson
If that loss represents an investment in intellectual property, resource is Operations Director re-
and time at a level so large that there is no appetite to redevelop sponsible for sales, con-
those assets for the version of the application, then automation will sulting services & product
have failed. Thus we arrive at the acid test – if it is deemed easier support delivery to Original
to return to a manual test approach, then automation has failed and Software’s worldwide cli-
deserves to be thrown away. ent base.

Summary Another founding member;

George’s strong software
Test automation has failed to date simply because we could not af- quality and customer care
ford to throw it away. Creating any form of automation takes effort orientation is reinforced by extensive software product
and time, when the application under test changes and the automa- and large-scale development project experience within
tion ceases to work you are faced with a stark choice – either main- many areas of IT.
tain 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, He has helped shaped the solutions Original offer today
thus bringing the whole concept into question. with practical experience from the field, combining well
with Colin’s insight and innovation. An engineer by train-
The reality is that you have to be in a position to throw away the ing, his background served him to great effect at Osprey
automation you have created, as sooner or later the application will Computer Services (to 1995) where, as a main board
change in such a way that no amount of automatic healing can tack- director, he drove development and marketing of new
le. So by definition, the creation of the automation must have been applications into new markets for the company.
so fast and painless and the investment minimal, that you can afford,
both financially and emotionally, to throw it away. Later, as Business Group Manager at AIG Computer
Services, George rapidly broadened his platform experi-
Think about your own test assets? Can you even estimate the cost in ence, simultaneously managing IBM Midrange, NT and
time and effort in building them? How constricted are you by that in- PC development projects – in a rigorous ISO9001 and
vestment? Can you hand on heart claim that you don’t grimace every TickIT management environment, where George’s natu-
time you have to throw them away? ■ ral ‘quality evangelism’ served him well.

* From: http://www.altimetergroup.net/ He has been a keen dinghy sailor, enthusiastic wind-

surfer but these days golf seems to take precedence.

30 www.agilerecord.com
 © DIREKTHIER - Fotolia.com
Test Automation in
Agile Environments
by Mallika Singh

I. Introduction 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,
In today’s competitive world, most of the software organizations all this has to be decided on the go. At the end of each iteration
are churning out the processes that can reduce the time to mar- working software must be delivered to the stakeholder. So there
ket with customer satisfaction. Whether it is Scrum, XP, Crystal or is a need to have a very smart approach to testing.
any other Agile methodology, the basis will remain the continual
improvement. And this has to happen with an unclear project To achieve this, no doubt well done unit testing is the foundation
scope and a lot less documentation in small installments, typi- to any Agile methodology. If unit testing is not done properly, a
cally referred to as iterations in Agile. With this the final outcome large degree of code change will happen during the testing phase
should be delivery on time with good ROI (return on investment) to fix the bugs which make the system more fragile and prone to
for the business. Literature available on Agile defines it this way: have a higher number of defects. Since the tester is more depen-
dent on the interaction with stakeholders and team members,
• Individuals and interactions over processes and tools. the two approaches of risk-based testing and exploratory testing
• Working software over comprehensive documentation play a very crucial role. In a risk-based approach, the tests are
• Customer collaboration over contract negotiation performed according to priority, which helps to detect the impor-
• Responding to change over following a plan tant defects early in the test execution. This also lays the founda-
• Being proactive rather than reactive tion 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 chal- III. Role of the Tester in Agile Environments
lenges to tackle.
An agilist tester needs to be proactive rather than reactive. There
II. Role of Testing in Agile Environments 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 In an Agile environment, the tester needs to think analytically in
should be a part of user stories. Acceptance tests check each order to find difficult bugs earlier in the execution. The real chal-
iteration to verify that business values are present. This way lenge for the tester lies in the fact that requirements keep on
they start to also serve as a documentation of customer require- changing; the very evidence for this is constant bug reports get-
ments. Commonly in Agile practices, yellow sticky notes are used ting rejected. In a traditional development environment this is
for the active user stories, orange sticky notes for tests in prog- considered not a positive sign for testers, whereas in Agile meth-
ress, and the red sticky notes are bugs reported during daily odologies the tester is evaluated not on the number of bugs but
stand-up meetings. the quality of the product.

The challenge for testing in Agile is that the short iterations do The change in attitude is required for the whole team that is
not allow test systems to be in place. In waterfall or any other tra- working in an Agile way. Whereas testers need to be precise
ditional model, the test cases are written on the basis of the re- and consistent, the team should also try to implement variation

www.agilerecord.com 31
 through different test techniques and methodologies, especially The key to tackling these limitations would be to find out the sce-
since there is no test strategy that could resolve the issue of narios that will fit into automation. The solution could be to do
changing system. manual testing initially for the first few iterations, and to then
develop automated regression test scripts with the right set of
Testers working on Agile projects should be able to understand scenarios. These can then be executed in consecutive iterations
the root cause analysis of problems (e.g. a similar bug that oc- and also before the final release. This is illustrated in Figure 1.
curs 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 fi-
nal release of a bug-free and stable product that will satisfy the
customer.

IV. Test Automation in Agile Environments

To keep up with the pace of developers, test automation is re-

quired 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 Figure 1
become stable and can be used to develop scripts that check
the functionality of application. Otherwise opting for an automa- VI. Conclusion
tion very early could become a chaotic, unstructured and uncon-
trolled venture. Here the maintenance of scripts will become an- Since testing is a very crucial part of an Agile environment, it is
other major task of the tester, and the crucial areas to be tested very important for a tester to have the right attitude to keep up
will be left aside. with rest of the team and the stakeholders. Testing should be
automated to reach the objective of adopting the Agile methodol-
As the code that worked in the last iteration gets modified in ogy and to deliver faster. This can be done by opting for the right
consecutive releases, the risk of regressions is higher in Agile tool within a feasible framework and by selecting the right set of
methodologies. Therefore it is very important to pick up the right tests to automate. ■
areas as candidates for automation. Areas, which are repetitive,
are obvious candidates for test automation. References

Automated regression scripts can also help. These will check [1] Addison Wesley, “Software Test Automation”, 1999.
faster to ensure nothing has been broken, as more stress id put Available at: http://www.stickyminds.com/books.asp?Objec
on high-value critical paths and on the standards parts of the tId=299&Function=DETAILBROWSE&ObjectType=BOOK
application. [2] Geek Interview, “Testing articles”, Available at:
http://www.geekinterview.com/articles/61
V. Choice of Automation Tools [3] Bret Pettichord, “Success with Test Automation”, 2001,
Available at: http://www.io.com/~wazmo/succpap.htm
Once it has been decided to automate testing (or parts of it), it is [4] Kent Beck, “Introduction to Test Driven Development (TDD)”.
very important to do a feasibility check beforehand to see which [5] Dan Lavender, Pete Dignan “Test Automation with Open
automation tool(s) should be used. Whether it is a commercial, Source Tools in an Agile SDLC Process”
open-source or home grown tool, all of these come with a set of
limitations.

> About the author

Commercial tools such as IBM Rational, Functional Tester, or hp
Mercury Quick Test Pro are some of the best tools available to Mallika Singh
do functional testing, and they are compatible with most of the is an ISTQB and Rational
latest technologies used. However, the limitation is that most of certified tester working
these record and playback tools work on test last kind of scenar- with Infosys Tools Group,
ios, whereas Agile is all about testing early and testing continu- Bangalore, India. She has
ously. Also the cost of the licenses might be prohibitive. a master degree in Bioin-
formatics and started her
Open-source or home grown tools will need a lot of modification career as a tester in 2003.
before they suit the need of an application, where changes hap- Her core area of work is
pen frequently depending on the regular inputs from the cus- Automation Testing and
tomer. Moreover, if scripts are developed which are based on deploying of effective Au-
screen content and location, they are inflexible and expensive tomation accelerators to deliver effective solutions to
to maintain. clients.

32 www.agilerecord.com
 Agile TESTING DAYS

Agile Testing Days 2010

4–7 October 2010, Berlin
© iStockphoto.com/naphtalina

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 Janet Elisabeth Stuart Isabel Linda Michael

Crispin Gregory Hendrickson Reid Evans Rising Bolton

Jennitta Anko Eric Shane Pekka Juha Janne

Andrea Tijman Jimmink Parkinson Klärck Rantanen Härkönen

October 5
Conference

Day 1 Track 1 Track 2 Track 3 Track 4 Track 5 –

Vendor Track
08:00 Registration
09:25 Opening
09:30 Keynote – Lisa Crispin
10:30 Incremental Scenario Experiences on test Testability and Agility – Testing Web Applica- Continuous Deployment
Testing: Beyond planning practices in “Get your quality for tions in practice using and Agile Testing
Exploratory Testing Agile mode of operation nothing and your checks Robot Framework,
for free” Selenium and Hudson Alexander Grosse
Matthias Ratert Eveliina Vuolli
Mike Scott Thomas Jaspers
11:30 Break
11:50 Test Driven Migration Making GUI Testing Real World Test Driven Acceptance Test Driven Talk 5.2
of Complex Systems Agile and Productive Development Development using
Robot Framework
Dr. Martin Wagner and Geoffrey Bache Emanuele DelBono
Thomas Scherm Pekka Klärck
12:50 Lunch
14:20 Keynote – Linda Rising
15:20 Test Center and Reinvigorate Your Error-driven Flexible testing Talk 5.3
agile testers – a Project Retrospectives development environments
a Díaz & Hilterscheid Conference

contradiction? in the cloud

Jennitta Andrea Alexandra Imrie
Dr. Erhardt Wunderlich Jonas Hermansson
16:20 Break
16:40 Solving the puzzles of Structures kill testing Integration Test in Waterfall to an Agile Talk 5.4
agile testing creativity agile development Testing Culture
Matthew Steer Rob Lambert Anne Kramer Ray Arell
17:40 Keynote – Elisabeth Hendrickson
19:00 Chill Out/Event
 Agile TESTING DAYS
Berlin, Germany

October 6
Conference

Day 2 Track 1 Track 2 Track 3 Track 4 Track 5 –

Vendor Track
08:00 Registration
09:25 Opening
09:30 Keynote – Michael Bolton
10:30 Top 10 reasons why Agile hits Formal – A lucky shot at agile? The Leaner Tester: Talk 5.1
teams fail with ATDD, and Development meets Providing true Quality
how to avoid them Testing Zeger Van Hese Assurance
Gojko Adzic Matthias Zieger Hemal Kuntawala
11:30 Break
11:50 TDD vs BDD: from How can the use of Mitigating Agile Testing Maximizing Feedback – Talk 5.2
developers to customers the People Capability Pitfalls On the importance of
Maturity Model® (People Feedback in an Agile
Alessandro Melchiori CMM®) improve your Anko Tijman Life Cycle
agile test process?
Lior Friedman
Cecile Davis
12:50 Lunch
14:20 Keynote – Stuart Reid
15:20 Alternative paths for Hitting a Moving Target – Fully Integrated The Flexible Art of Talk 5.3
self-education in software Fixing Quality on Unfixed Efficiency Testing Managing a Multi-
testing Scope in Agile Environment layered Agile team
Cirilo Wortel David Evans Ralph van Roosmalen Shoubhik Sanyal
16:20 Break
16:40 Mastering Start-up Building Agile testing Implementing collective Alternative paths for Talk 5.4
Chaos: Implementing culture test ownership self-education in software
Agile Testing on the Fly testing
Emily Bache and Fredrik Eric Jimminik
Christiane Philipps Wendt Markus Gärtner
17:40 Keynote – Janet Gregory
19:00 Chill Out/Event

October 7 Exhibitors
Open Space

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
Agile
15:20 Open Space
Record
17:20 Keynote – Tom Gilb
18:20 Closing Session
Please fax this form to +49 (0)30 74 76 28 99
or go to http://www.agiletestingdays.com/onlinereg.html.
Agile 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 The Foundations of Agile Software Executable Requirements in
Agile Teams by Lisa Crispin Development by Jennitta Andrea Practice by Pekka Klärck, Juha
Rantanen & Janne Härkönen
A Rapid Introduction to Rapid Testing2.0 – agile testing in practice
Software Testing by Michael Bolton by Anko Tijman & Eric Jimmink Tutorial by Shane Parkinson

A Tester’s Guide to Navigating an Managing Testing in Agile Projects

Iteration by Janet Gregory by Stuart Reid & Isabel Evans
750,– EUR
Patterns for Improved Customer Agile Transitions by Elisabeth (plus VAT)
Interaction/Influence Strategies for Hendrickson
Practitioners by Linda Rising

Conference (5–7 October 2010)

1 day (first day) 550,– EUR 3 days 1.350,– EUR
1.350,– EUR
1 day (second day) 550,– EUR 2 days (first and second day) 1.100,– EUR (plus VAT)
1 day (third day) 350,– EUR

Included in the package: The participation at Settlement Date Applicable Law and Place of Jurisdiction
the exhibition, the social event and the cater- Payment becomes due no later than at the start Berlin is considered to be the place of jurisdic-
ing during the event. of the event. tion for exercising German law in all disputes
Notice of Cancellation Liability arising from enrolling for or participating in
No fee is charged for cancellation up to 60 days Except in the event of premeditation or gross events by Díaz & Hilterscheid GmbH.
prior to the event. Up to 15 days prior to the negligence, the course holders and Díaz & Hil-
event a payment of 50 % of the course fee be- terscheid GmbH reject any liability either for
comes due and after this a payment of 100 % themselves or for those they employ. This par-
of the course fee becomes due. An alternative ticularly includes any damage which may occur
participant can be designated at any time at no as a result of computer viruses.
extra cost.

Date Signature, Company Stamp

 © Morpheus - Fotolia.com
The Visionary
Story Teller
by Geert Bossuyt

This story tells you how to fulfill Product Owner responsibilities in What is waste?
the most interactive and efficient way. To make a clear distinction
between the known Product Owner role and this implementation If we want to talk about waste, we should agree on the definition
of the Product Owner role, the new guy is called the “Visionary of ‘waste‘. For now, ‘waste’ is defined as ‘any action or interaction
Story Teller”. that doesn’t directly lead to business added value’.

As many things, this is not a silver bullet, and therefore it is not In this definition, waste in the Scrum process can be found in
implementable in every situation. But keep in mind that when different places. In fact, most of the Scrum process would be
you have the opportunity to do so, you will gain enormous pro- considered ‘waste’ when applying the above definition. Let’s take
ductivity, achieve the highest quality and deliver faster than ever a look at the retrospective. Does having a good retrospective lead
before. 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
Eliminate the overhead in Scrum deliver more or better business added value, but the retrospec-
tive in itself does not deliver any business added value. Is the
Agile, SCRUM and Lean each have their own philosophy with their retrospective to be considered waste then? No, it sure is not.
own basic ideas. Agile, in its heart, is about getting feedback: In- Without doing good retrospectives, you will loose a lot of busi-
teraction between people to deliver working software in close col- ness added value because of their contribution to improving the
laboration with the customer delivers good and early feedback, cycles. Therefore the definition of waste should be ‘Waste is any
which leads to adapting the plan if needed. This is exactly what action or interaction that doesn’t lead to business added value or
Scrum does. All Scrum roles and practices are meant to achieve where no business added value is lost, when not doing it’.
closer interaction or getting quicker and better feedback. Scrum
is an Agile implementation with a strong focus on close interac- Does the Product Owner deliver real business added value?
tion and collaboration. On the other hand, Lean, in its core, is
about eliminating as much waste as possible. Looking at Scrum, most of the potential overhead is in the Prod-
uct Owner part. Although a definite must-have in many organiza-
Similarities between Scrum and Lean are easy to see. Self-orga- tions, the role of the Product Owner and its artifact do not de-
nizing teams are the Scrum equivalent of the Lean flexible teams. liver any direct business added value. The art of describing the
Kai Sen comes alive through the follow-up actions of the retro- needs of the business in implementable stories is really hard,
spective, etc. That is not the topic of this article. This article is and sometimes these Product Owners are the true heroes that
about implementing Scrum in a Lean way. It is about getting the empower the team, but still … it does not deliver any real busi-
benefits from Scrum without the waste. ness added value.

How to achieve this will of course strongly depend on your spe- What about the second half of our definition of “waste”? Would
cific organization and the specific people guiding the change. any business added value be lost if there was no Product Owner?
However, some patterns can be described. 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 A team also has responsibilities:
how to implement Scrum in your organization without implement-
1. Understand the Product Owner
ing the Product Owner role.
2. Do the work
3. Learn from feedback, and
What questions should we ask ourselves to be sure we really
4. Feel responsible for the result.
need a Product Owner?

• What is it that a Product Owner should bring me? What does this mean?
• Are there other ways to tell my teams what to do?
• What format of my product backlog can I imagine that would A Product Owner must have a clear vision of the project. The vi-
contain the lowest overhead possible? Can I imagine … sion statement should be there and visible in all places. Every-
• Can I create a team that is able to understand business needs one that is, even slightly, involved in the project should know and
and priorities? understand this vision. It’s not just a statement. It justifies every
action in the project. Everyone must understand the vision. Un-
Many good Product Owners work hard to have the top of their derstanding the vision is no guarantee to build the right system,
product backlog ready for Sprint planning sprint after sprint. but not having a clear vision is almost a guarantee for building
It’s hard work to stay ahead of the team, preparing stuff so the the wrong system.
team can implement real business added values as fast as pos-
sible. During the Sprint a Product Owner should be available at Each vision can be realized in different ways.
all times to answer the questions of the team, and at Sprint end,
the Product Owner also needs to acknowledge that the team has The vision tells you something about the problem and something
built what he’s asked for. To me this sounds like an awful lot of about the ultimate goal for the project, but it does not explain
work for one person. That’s why I’ve seen teams of more than 20 how the system will behave and what to do with the dozens of
people, called “ready teams”, working hard to make the Product micro-problems the team must conquer. Therefore the Product
Owner miracle come alive. 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
Struggling to keep ahead of the team and then struggling even a vision. The “Visionary Story Teller”. Someone who can fascinate
more to explain their user stories to the team, the Product Owner people and make them enthusiastic for the product. Telling the
hardly has any time left to answer the team’s questions during story must lead the team to real understanding of the business
Sprint, and certainly not to test delivered software. To be sure the needs, and will put the team (back) in the driver seat. Remember,
team does build the right thing, user stories are extended with the team is responsible for the result.
stuff like acceptance criteria, how to demo, GUI descriptions, etc.
Where did the interaction go? What about collaboration? Sounds As in every good story, there is a start and an end, there is the red
a bit like waterfall, don’t you think? line and the details, there are actors and a plot, and most of all
there’s some good action!
Another, even bigger issue with the Product Owner role is
that Scrum teams should be responsible for the result. They The Product Owner has the skills to tell the story in a way that
should feel it as their responsibility to understand the busi- enables the team to write it down. User story by user story, or
ness needs, because that’s the only way they are able to slice slice by slice, depending on the technique you want to use. Ac-
these needs into buildable bits. With a good Product Owner tors, benefits, actions, it all should become clear by listening to
on the project, the team can sit back and wait for new slices the story. This is part of “Do the work”. While the team does the
to be presented. If the PO is too slow, teams blame him for work, the Visionary Story Teller can spend his time on rethink-
not being fast enough and feel that it is not their fault when a ing parts of the story, answering questions, giving feedback on
Sprint is not really delivering anything useful. Where did ‘Let some other work delivered by the team, or by another team. Or
the team decide!’ go when the Product Owner decides just he can have discussions with other stakeholders, etc. In short,
about everything. Everything  – from the slicing of the product the Visionary Story Teller has time again to interact, and most of
up to deciding whether it has been implemented correctly? A all, team and story teller are working together on the same thing.
good Product Owner makes teams lazy. This is unacceptable. No more running to stay ahead, but getting things done together.
So, what can be done? This will deliver extreme focus and efficiency to the project.

How to eliminate the Product Owner waste: Depending on your organization, you can choose to have the
A Product Owner should be responsible for 4 things. No more, team write down the stories before implementing or just go to
no less. implementation right away. Real feedback only comes based on
working software, but you need a lot of trust and flexibility in your
1. Enlightening the project vision
organization to work like this.
2. Telling the story
3. Giving the team feedback on their work, and
Naturally, as you will have already noticed, to accomplish the
4. BEING THERE.
above, your team should not only consist of developers, DBAs

38 www.agilerecord.com
and QA people. You should probably add an analyst and an end As a final remark I would like to state that you should always strive
user to your team. I don’t believe every team can do anything, to the highest quality possible. Quality without compromise! Look
but I do believe you can always construct a team that can do for opportunities to do things better, faster or cheaper, but with-
everything. out 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 Prod-
uct 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 consid-
ered “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 be-
cause 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 de-
liver real business added value faster than ever.

Try to add an end user to your teams and pick your Product Own-
ers not based on their writing skills or their authority on deciding > About the author
priorities, but on their story telling skills and the art of persua- Geert Bossuyt
sion. is Agile Consultant and
Agile Coach at Xebia, the
Choose to bring the Visionary Story Teller alive wherever you can, leading Agile company in
and benefit from the boost of efficiency and the shortest time to The Netherlands.
market ever.
Geert has 12 years of ex-
What else? perience with ICT projects
in different roles such as
The next steps toward hyper-focus will include having a look at Java consultant, test coor-
some other roles and parts of Scrum that don’t deliver direct dinator, project leader and
business added value and that, under certain conditions, do not project manager. For the
cost anything when skipped or transferred to a lighter version. last 3 years, he has worked as Scrum Master and Agile
Coach in companies like LeasePlan/The Netherlands,
Think about: Unive and De Nederlandse Bank, with amazing results
in guiding the change process that goes naturally with
• Testing. When Teams really take on their responsibility, testing an Agile implementation. He is a passionate speaker
effort should be minimal (zero error tolerance from Lean). and knows how to bring out the best in people. In his
• Sprint Review. When the Product Owner has time to be around, work, he guides teams and organizations to a higher
he should give feedback and approval story by story. The Sprint level of focus and efficiency by letting them experience
review becomes obsolete. the real power of working TOGETHER.
• 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?

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 _number.story_number’ i.e. 1.1 = theme number one, story num-
ber one, 1.2 = theme number one, story number 2, 2.1 = theme
Story cards are used throughout an Agile project. They are creat- number two, story number one etc.
ed, 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 • Story Description

• Title • Linked Requirement
• Story Number Number(s)
• Story Complexity • Acceptance Criteria
Diagram 2.0: back of card
Theme: Giving each story card a theme helps when picking sto-
ries for sprints. It keeps stories in categories and allows you to Story Complexity: Complexity points also known as story points
group stories together when scheduling work for the next sprint. are used to gauge how long the story will take to develop and
Try to keep the dependencies soft not hard. For instance a theme test. The complexity point scale consists of 0,1,2,3,5,8,13,21.
would be ‘Payment’ and have stories relating to the payment Complexity points are covered in more depth in chapter two.
page but can be developed independently from each other.
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 vi-

sualize 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
Diagram 3.0: front of card

40 www.agilerecord.com
The whole team should write story descriptions. The product the acceptance criteria they can stop development. The product
manager can represent the client if not present. 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 When writing acceptance criteria try not to write them as ques-
other. Dependencies can lead to estimating, planning and prioritiza- tions. “Is the user allowed to login with a user name and pass-
tion problems. If stories are dependent on each other then combine word?” This leads to problems when testing. A tester would not
them into one larger story and add acceptance criteria for the com- know if it passes when the statement is true or is false. It would
bined parts. If the combined story is too big then think of a different be better written without ambiguity. For instance “The user is al-
way to split the story. lowed to login when entering a valid user name and password“.
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.
Valuable to business or client: Product features should have some
value to the business or client. For instance a feature brings an in-
crease 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 knowl-
edge, 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 Diagram 5.0
to create a big story then task out the story. In this way progress can
be seen on the storyboard. From a tester’s point of view acceptance criteria are the mini-
Testable: If the story is unable to be tested then it is hard to prove that mum requirements to pass the story, however exploratory testing
the functionality is working. The acceptance criteria should be able to outside the acceptance criteria may still be done. Developers use
be proved through testing. acceptance criteria to further understand the story and to know
when to stop developing. In other words once they have met all
Linked Requirement Number(s): Stories can be written from the acceptance criteria they can stop development. The product
the client requirements. By adding the requirement numbers to manager or client uses the acceptance criteria during the sprint
the story card any changes to the card can be cross-referenced demo to verify what has been delivered.
against the requirements, removing or adding requirements as
necessary. The traceability matrix tracks story cards against re- When writing acceptance criteria try not to write them as ques-
quirements to make sure all requirements have story cards writ- tions. “Is the user allowed to login with a user name and pass-
ten for them. word?” This leads to problems when testing. I tester would not
know if it passes when the statement is true or is false. It would
Acceptance Criteria: Acceptance criteria are written on the back be better written without ambiguity. For instance “The user is al-
of the story card. The acceptance criteria expand on the story lowed to login when entering a valid user name and password“.
adding more detail. Both the developers and testers use the ac-
ceptance criteria to prove the story cards goal has been met. 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 dependen-
cies 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
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
Diagram 4.0: back of card
feature rich product but will these entire set of features be used?

From a tester’s point of view acceptance criteria are the mini-

mum requirements to pass the story, however exploratory testing When first creating story cards they should not contain too much
outside the acceptance criteria may still be done. Developers use detail. This is so they can be created quickly in the pre-project
acceptance criteria to further understand the story and to know planning meeting and are simple to alter when requirements
when to stop developing. In other words once they have met all change. During the sprint planning meeting more detail can be

www.agilerecord.com 41
 added so estimating is more accurate and acceptance criteria Global cards can also be used as a reminder that an acceptance
can be expanded on. Big stories are given even more detail by criterion applies to all cards with a certain theme. For instance a
tasking them out. Then finally during development the fine detail browser compatibility global story card would remind the team to
is talked over by the developers and the feature coded. 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. When fixing bugs the developer should time box a bug fix to 30-
60 minutes. If the bug looks like it will take longer then download
For instance performance acceptance criteria may be needed on keyboards and write a bug story card for the bug. The bug story
all stories that contain a client performance KPI. 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)

The focal point of an agile project, the storyboard tracks the prog-
ress 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
Diagram 8.0: front of card 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/ Story cards, which require more automated
Cucumber Patch 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 9.0: back of card

42 www.agilerecord.com
Diagram 11.0

Bug Corral Lower priority bugs (P3 and P4) are placed here. The Sprint Burndown Chart (Diagram 12.0)
They can be moved to the ‘Not Started’ swim lane
if they need to be fixed in the current sprint. The sprint burndown chart is used to give a quick overview of the
Questions Any questions that are raised during the day can sprints progress. The team can use the chart to track their veloc-
be placed on the storyboard to be answered at ity and see if they are on or ahead of their target velocity.
the next stand-up meeting.
Impediments Anything holding up stories or interrupting the When a team is tracking ahead do not add more work until all the
flow of the sprint can be placed on the storyboard story cards have been ‘Done Done’. Only then bring in more work
to be talked about at the stand-up meeting. from the backlog. This can be tracked on the sprint burndown as
Sprint Burndown Drawing the sprint burndown on the storyboard shown in Diagram 1.0.
allows the team to see if the velocity of the sprint
is going to be met.
When a team is tracking behind the product manager needs to
Team Holidays Tracking team holidays/sick days on the board al-
access what is delaying the team. The story cards should have
lows for better velocity tracking at the next sprint
been prioritized so at least the high priority cards should be com-
planning meeting.
pleted. If a deadline is looming and all the story features are re-
quired then something may need to take hit until the next sprint.
Swim Lanes Bear in mind anything that does not get completed in a sprint
Swim lanes are used to keep track of the progress of work across the becomes agile debt and needs to be scheduled in for the follow-
storyboard. They are generally labeled ‘Not Started’, ‘In Progress’, ing sprints. The following is a list of things that could be done to
‘Done’ and ‘Done Done’, however they can be labeled in a more fun hit a deadline:
way, for instance ‘Departure Lounge’, ‘In Flight’, ‘Customs’, ‘At Beach’.
Not Started Work to be completed during the current sprint is • Stop creating automated regression test cases (Cucumber
placed in the swim lane. This can include story cards,
Tests)
tasks and bugs.
• Stop fixing minor and medium bugs
In Progress Any story card, task or bug that is currently being de-
• Reduce stand-up meetings to 5 minutes
veloped is placed in this swim lane. The swim lane can
• Increase knowledge by bringing in people who know about
be broken down into ‘pair’ and ‘single’ to show which
the product features
work is being done by pair programming and by a single
developer.
• Stop interrupting the team
• Remove features
Done Once development is complete and the story card, task
or bug is ready to test, it is moved to the swim lane. • Stop pair programming
Done Done The story card, task or bug has been passed by testing
and is ready to demo to the client. 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 14.0 shows a project

burndown chart tracking complet-
ed points, outstanding points and
Diagram 12.0 points added. To complement the
burndown a chart that tracks estimated against actual sprint ve-
them to the burndown chart. If the team completes all the stories locity can be created (see Diagram 13.0). These types of charts
then take the highest priority story(s) from the backlog and track can be used historically to estimate future projects.
them on the burndown chart.
Release Early/Release Often
At the end of the sprint the actual team velocity is added to the In Agile the short development/test cycle allows the team to release
project burndown chart. 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
On-Site Customer improves communication between the product managers, developers
and testers as they collaborate on the development of the client re-
In an ideal world the client will be able to base a person where the
quirements.
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.
It is important to involve the client when story grooming and for sprint
demos. The product manager can represent the customer on a day-to-
day basis and can represent the customer when story grooming and in
sprint demos but they would need to be very confident in their knowl-
edge of the client’s needs.

The Project Burndown Chart (Diagram 14.0)

Diagram 15.0

Stand-up Meetings and Sprint Retrospectives

Agile Feedback

Feedback is an important factor for an Agile project. Feedback

Diagram 13.0 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
When selecting an agile process two rules should be applied. The
There are many ways to display data on the progress of a project. process needs to be simple to understand and implement and
The product manager should decide on the best way to report the process needs to be measureable to gauge its effectiveness.

44 www.agilerecord.com
Agile processes should be constantly reviewed to see if they are times. May have forgotten what they did the day before.
working. When a process is not effective then look at ways to im- • Lunchtime:
prove the process or alternatively replace or remove the process. • Advantages – helps keep the stand-up length short, as team
members will want to be quick so they can have lunch.
Simple – Embrace simple processes • Disadvantages – breaks the flow of work by splitting the day
Measurable – Track process effectiveness into two sections.
Improvable – Recognize constant room for improvement • 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 rear-
range programming pairs and inform the product manager of im-
pediments 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 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
Sprint Demos 15 minutes or less. Everyone standing up helps to keep the
At the end of each sprint the finished features should be demoed to meeting focused and short.
the client or product manager representing the client.
Before the sprint demo the developers should carry out some prepara- After everyone has finished talking about the three items, the
tion so the story cards can be confirmed as finished. Each story card
product manager can talk about anything the team needs to
should be taken in turn and acceptance criteria, that has some value
know. This could be a change in requirements, a re-prioritizing of
to the client, should be picked from the back of the story card. Scripts
story cards, a release timeline change, a new member joining the
should be written to prove the story card has been finished. Notes
should be taken on how to demo the functionality to the client. team etc. Testers can talk about any bugs found in the system,
To help speed up the demo preparation, while developing the stories
adding them to the ‘Not Started’ swim lane if the product manag-
scripts can be created to demo the acceptance criteria. er/client requires them to be fixed in this sprint. Developer’s talk
Any bugs found during the demo should be recorded and fixed before about which story cards should be pair programmed or requires
release. Client changes in functionality should be raised as story cards just a single developer. Try to keep these conversations as short
and flagged in the next sprint planning meeting. as possible and allow team members to leave if they do not think
In Agile a measurement of progress is ‘working software’ this makes they need to hear what is being talked about.
it important to always run a sprint demo to confirm working software.
At each stand-up meeting the sprint burndown chart should be
Stand-up Meetings updated on the storyboard to show the progress of the sprint.

Daily stand-up meetings are a way for the team to keep com- Distributed Agile Teams
munication flowing between the product manager, developers
and testers; it also is a way of tracking the progress of an agile Distributed teams raises the question ‘Can distributed teams de-
project. liver software as efficiently as centrally located teams?’

Stand-up meetings can be held at anytime during the day, howev- Communication is Key: Agile, even more so than other develop-
er holding stand-ups first thing in the morning, just before lunch ment methods, requires a constant stream of communication.
or at the end of the day are better for the following reasons: With daily stand-ups, planning and retrospective meetings and
the day to day conversation between developers, testers , prod-
• Start of the Day: uct managers and clients. Barriers to effective team commu-
• Advantages – Allows the team to start work with a fresh idea nication can be time zones, language, technology and cultural
of what they need to do during that day. differences. However with today’s technology and finding the
• Disadvantages  – Team members may turn up at different right-minded staff these barriers can be mostly resolved.

www.agilerecord.com 45
 2010
November 22–24
Sydney, Australia

November 22
Tutorials

Patterns for Improved A Tester’s Guide to Principles of Managing Testing

Customer Interaction Navigating an Iteration Agile Methods in Agile Projects
& Influence Strategies
for Practitioners 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 stay-
Registration Cost
ing ahead of the curve. Tutorials (Mon 22 November)
Early Bird $500.00
Learn from the best. Over three thought-provoking Tutorial
Standard $650.00
days, explore new developments and key concepts as 2-Day Conference Registration
local and internationally recognised authorities share Single Registration $995.00
their unique experience in Agile – including North Early Bird Group Registration (5–9) $895.00
American experts Janet Gregory and Linda Rising and Group Registration (10+) $795.00
UK expert Stuart Reid. Single Registration $1,200.00
Standard Group Registration (5–9) $1,100.00
Please have a look at the program at www.ozagile.com Group Registration (10+) $1,000.00
and enjoy the conference! 1-Day Conference Registration
Early Bird $595.00
Day Registration
Standard $700.00

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

Start End Track 1 Track 2 Vendor Track

08:30 08:50 Registration
08:50 09:00 Conference Opening

Keynote: About Learning

09:00 10:30
Janet Gregory, Co-author of Agile Testing

10:30 11:00 Morning Tea

Waterfall vs. Agile – As a Tester
User Stories Are a Testers Best
Are They Really that Different? Is
11:00 12:00 Friend Vendor 1
it All in the Mind?
Leanne Howard, Planit
Andrew Hammond
Moving a Major Project From
Stay Agile with Model-Based
Waterfall Methodology to Agile –
12:00 01:00 Testing Vendor 2
A Testing Experience
Jelle Calsbeek
Linda Brunker
01:00 02:00 Lunch
Agile Methodologies and It’s Really Hard to Assess Soft
02:00 03:00 SoX Requirements Skills Vendor 3
Saurabh Chharia Werner Lieblang
03:00 03:30 Afternoon Tea

Keynote: TBD
03:30 05:00
Shane Parkinson, Planit

November 24
Conference

Start End Track 1 Track 2 Vendor Track

Keynote: Agile Testing Certification – How Could That Be Useful?

09:00 10:30
Stuart Reid, CTO, Testing Solutions Group

10:30 11:00 Morning Tea

Rapid-Result Tools for Test Auto-
Zen and the Art of Agile Testing
mation:
or Being Agile without Doing
11:00 12:00 Code Generators – A Good Solu- Vendor 4
Agile
tion for Agile?
Matt Mansell
Mark Feldman
Agile Tester: A Profession with
The Creation of an Agile Vendor
12:00 01:00 Profile Vendor 5
Mitch Denny
Stephan Goericke
01:00 02:00 Lunch
02:00 03:00 Panel Session
03:00 03:30 Afternoon Tea

Keynote: Deception and Estimation: How We Fool Ourselves

03:30 05:00
Linda Rising, PHD in Object-based design metrics
 When creating a distributed agile team consider the following as • Actions (!): What should we do to resolve the things that did
tools for increasing communication between the team: not go well, answer the outstanding questions and remove
any remaining impediments.
Google Wave: Real-time threaded discussions can be created
using Google wave. Users can also step in and rewind the con- WWW WCBB
versation at anytime. Google wave can also for share text, pho- • Released all features • Some regression test cases
tos, and videos within the conversation. Can be a substitute for • No bugs in sprint demo not automated
a whiteboard. • Got velocity right • Acceptance criteria need to be
clearer

Instant Messaging: Real time communication between two or ? !

more people using typed text. There are a number of instant mes- • When will the new staging • The whole team to review ac-
server be ready? ceptance criteria
saging applications available. Select one for the whole team to
• Review the auto regression
use. Some IMs (MSN Messenger and Skype for example) have
test process
VoIP (Voice Over Internet) capabilities.
Diagram 17.0
Company Blogs: Having a company blog that can be accessed
by the whole team can help with sharing information. The blog Any outstanding impediments should be discussed in the sprint
should be able to email the team when new blogs are posted or retrospective. It is the product manager’s job to remove impedi-
comments are added. ments. Actions required to remove the impediments should be
entered into the action section.
Video/Web Conferencing: Video conferencing would be useful
for sprint meetings and retrospectives, sprint demos and daily If a large number of bugs are still in the system then the reasons
stand-ups. 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 docu-
ments 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 Simon Romans
machine with one developer controlling the demo. has worked in testing for
14 years, starting his ca-
Agile Project Software: It is difficult to keep track of story cards reer as a games tester at
moving across the swim lanes or new bugs in the system. With Electronic Arts and most
an agile project management software team members can be recently working as Test
emailed when a story card is updated or a new bug raised or its Manager for Mobile Inter-
status updated. active Technology. At MIT
Simon has set-up the test-
ing department and was
The Sprint Retrospective
responsible for the com-
pany’s transition to Agile Development and Testing Me-
The sprint retrospective usually held on the Monday morning (see
thodologies. Simon says, “When it comes to testing it
the first part of my article in Agile Record No. 2, 2-week sprint
can’t rain all the time!”
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 ac-
cording 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
 © Alterfalter - Fotolia.com
Task Boards and Caution Signs!!
by Sowmya Karunakaran

In the last two decades, a large number of different approaches this. However, in complex environments consisting of multiple
were introduced in the field of software development. One such teams distributed across different locations, it can be tedious to
approach is “Agile Development”. Since its introduction, Agile maintain physical task boards. Most popular Agile project man-
has created lots of interest among practitioners, since Agile pro- agement tools support online task boards these days. The tools
vides a solution to the software community in terms of lighter dynamically generate the task boards based on the status of
weight and flexibility and to the business community in terms of the stories and tasks. In fact, in one of the teams I noticed that
accelerated time to market. Success is possible by applying the the SCRUM Master had cleverly made use of the notes option in
various good practices that Agile practitioners recommend. 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
One such practice is “Task boarding”. A task board is representa- a sample (see Figure 2).
tive of all the work being done for the sprint. It has to be updated
every day (the SCRUM Master is generally responsible for keep-
ing 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 any-
one an indication of how well the sprint is progressing.

Figure 2: A digital task board using Outlook notes feature

Sample Task Board Caution Signs

Figure 1: A simple task board The task board contains in-built caution indicators. The Scrum
Master ensures that the team acts upon the caution signs. The
I have inquired with one of the Agile teams that practices task various caution indicators help SCRUM Masters and teams to
boarding in my organization about task boarding and its useful- use task boards effectively and interpret the warning signs.
ness. The teams feel that it gives a quick snapshot of the sprint
progress. Indeed, one of the team member points out that it in- Not Concentrating on high priority stories
creases the transparency within the team. Everyone in the team
is able to note the progress of each other’s stories. It is quite Most high-priority stories are in TODO state, while the low-priority
evident that Agile teams prefer highly visible communication and ones have been picked up and completed.
coordination tools. Task boards are a great tool to accomplish

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 sce-
nario. This could arise due to good productivity, or due to over
estimation (pessimistic). Choosing shorter sprint lengths or with-
drawing 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 Figure 5: Task board caution sign #3
early as possible in the sprint. Figure 4 shows a case where the
progress is slow with the deadline approaching fast. 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 Figure 7 shows a standard Task board view of the tool “Green-
goals as part of the task board and have gone to the extent of Hopper”. Simple columns are populated with the issues based
defining color coding (story cards-blue, bugs-yellow). Few other on the mapping that has been defined. Users will be able to drag
teams maintain a defect task board separately to track and fix and drop the issues from one column to another based on their
defects. 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

Sowmya Karunakaran
Figure 6: Task board caution sign #4
has been engaged in Ag-
ile software development
Task boards for Distributed Teams
since 2005. She has
worked in different fla-
As mentioned earlier in the article, there could be teams spread
vors of Agile, XP, Scrum,
across different geographic locations, and it may become tedious
FDD, and XP/Scrum
to maintain and collaborate using a physical task board. In case
hybrid. Currently she is
of distributed teams, a digital picture of the task board is posted
working as an Agile ex-
on the team Wiki, but this can get tedious with time. These days
pert at the Agile Center
most Agile project management tools provide a virtual task board
of Excellence, HCL Tech-
feature, where most of what can be accomplished using a physi-
nologies. She has presented many papers at various
cal task board can be done in a virtual way, which is then easily
IEEE conferences and has co-authored the book “Model
accessible for team members in any part of the world. It also
driven software development and integrated quality as-
lowers the burden of maintaining a physical task board and the
surance”, published by the IDEA group. Her interests
required stationery, and also removes the constraint of dedicat-
involve model driven architecture, Agile methodologies
ing a separate space for the task board.
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 Within Agile testing, quality is the team’s responsibility. The test
analysts now have a different role. In addition to testing, they
One of the Agile methods currently being applied in many organi- have to coach business representatives and developers on test-
zations is SCRUM, a method for project management that uses ing issues, review unit tests, etc. The tester is also involved in
incremental work cycles known as sprints to provide frequent op- estimation sessions, defining the exit criteria (definition-of-done),
portunities to assess and revise direction. As so often, however, reviewing stories and making them testable. All of this requires a
it is simple but not easy! The SCRUM method doesn’t say much senior person with good communication skills. It’s almost like we
about testing, and in most books only unit testing and user ac- require ISTQB Advanced Level testers; people that understand
ceptance testing are addressed. Have integration and system and are able to explain technical testing, business testing, test
testing now become obsolete? Developers and business repre- design and test management issues. What do we do with our
sentatives should do the major part of the testing activities with- junior testers? What do we do if we don’t have senior testers with
in Agile developments. It seems like utopia, but what does it look the right skills? Lisa Crispin in her book “Agile Testing” defines
like in real-life? Exploratory testing is often identified as the main a number of qualities that agile testers should possess: deliver
technique; what about our traditional test design techniques - value to customers, have courage, respond to change, continu-
are they no longer needed? These and many more questions ous feedback, etc. If you study those in more detail, there is little
need to be addressed when moving from a traditional V-model to no difference to what I would call a senior test analyst (in a
type development methodology to an Agile methodology, such traditional environment). If we analyse things, Lisa Crispin says
as SCRUM. When reading this column, you may get the impres- that we need real professional senior testers with the right knowl-
sion that I’m against SCRUM, Agile development and the like. You edge, skills and mindset. So what is new? Doesn’t this sound
could not be more wrong! However, I would like to point out some familiar?
testing issues from practice that one encounters when starting
to apply SCRUM. In other words: “food for thought” for the reader Risk item 2: Developers
when moving from a traditional development methodology to
Agile development/SCRUM. A checklist of risks that should be Within Agile software development, unit testing is essential. Why
mitigated or at least considered during the change process. Note is it essential only in Agile, and why does it now get all the focus?
that most of the risk items are not even new, but were already a It should have been essential in every lifecycle methodology! Can
challenge during traditional V-model development and testing. developers all of a sudden apply test design techniques? Most
By the way, my personal experiences are not from the games and of them have never had any training in structured testing, not
internet industry, like many simplified stories one hears at con- even at foundation level. Unit testing is not as easy as it seems,
ferences, but from more critical environments such as finance, understanding test design is something not so common for most
embedded software and medical systems, where quality matters developers. Writing test code that makes the code fail as in XP
and is a key business driver. does provide structural coverage, but not a high level of func-
tional coverage. Getting developers into testing needs a practical
Risk item 1: Test professionals approach. We at Improve Quality Services often provide work-
shops with hands-on real-life practical cases to get them started.
One needs to assess the current set of testers and decide wheth- Test automation, essential with any incremental development
er they are “fit for Agile”. methodology, is also needed. As test professionals have already

52 www.agilerecord.com
known for years, this is still a big challenge for most organiza- • Risk item 7: Distributed teams
tions for various reasons. All Agile is saying is, we need high qual- How do we organize Agile testing with distributed teams, and
ity unit tests and fully automated regression tests. Things that how does it fit with outsourcing?
have never been easy in the past. So what is new? Doesn’t this • Risk item 8: Management understanding
sound familiar? Does management really understand the background to the
Agile manifesto? Even within SCRUM, there are limitations to
Risk 3: Test levels and test types change!
• Risk item 9: Business involvement
Most books on Agile (testing) have a strong focus on unit testing How easy is it to get the right business representatives on-
and user acceptance testing. board and get them to do some testing? (In my experience,
even reviewing test cases and providing input to a product risk
Whatever happened to good old integration and system testing? analysis is often asking too much.)
What about system integration testing in a systems-of-systems • Etc.
environment? Of course, there isn’t just one answer, since these
terms mean different things in different organizations. The main The manifestos
problem I have with this approach is that again, after all these
years, we have to re-explain to management why integration Again, I would like to emphasize I’m not against SCRUM. I’m actu-
testing and system testing are needed. Caper Jones has already ally a big fan of team-based working and Agile. In practice, how-
taught us that unit testing doesn’t get far beyond a Defect Detec- ever, it just isn’t as easy as explained in the books and presented
tion Percentage (DDP) of 35% to 40%, and together with only by some of the so-called gurus. If you are able to handle some or
validation-oriented use cases used in user acceptance testing, all of the risks presented, SCRUM projects have shown to be very
just doesn’t get the job done! Thorough test cases using, for ex- successful. It usually helps enormously to have a detailed discus-
ample, decision tables or classification trees are still required sion about the Agile manifesto with all those involved. What does
in many instances. Also, exploratory testing has its limitations it really mean? It’s all about the philosophy behind the manifesto,
(sorry, James, Michael). Some test levels or test types take place understanding what is meant, and not about the actual wordings.
outside a sprint, which seems impossible according to the Ag- Someone who really understands the Agile manifesto may even
ile theory, but this is what I see successfully happening in prac- notice that there are a lot of similarities with the test process im-
tice. Reliability and performance testing for example are often provement manifesto [Testing Experience, Issue 4, 2008].
test types that run for more than four weeks, and organizing an
operational acceptance test or a system integration test within • Flexibility over detailed processes
a sprint has been shown to be very difficult in practice. As a re- • Best practices over templates
sult, in practice some of the testing often takes place outside the • Deployment orientation over process orientation
SCRUM sprint. A major issue is then to align the testing efforts • Peer reviews over Quality Assurance (departments)
and approaches inside and outside the sprint. What needs to be • Business-driven over model-driven
done? Establish a test strategy that covers all testing activities
(levels and types). To unambiguously define testing is usually a Most of these statements can easily be adapted to Agile soft-
huge step in the right direction. This has been the issue in the ware development. So what is really new? I “even” have a num-
past with the V-model and is also needed for Agile software de- ber of clients at TMMi levels 2 or 3, that practice SCRUM. In fact,
velopment. So what is new? Doesn’t this sound familiar? those organizations that had the structured testing in place and/
or were at CMMI level X seem to be more successful at SCRUM
Many more challenges than others. Again “food for thought” …

The issues raised above are by no means the full risk list. I want- I hope this short paper makes you aware of some of the testing
ed to prioritize, keep it short and “write Agile”. Some other risk issues that come with the implementation of SCRUM in an orga-
items to be considered: nization or project. Discuss them with team members inside and
outside testing and management, and find practical result-driven
• Risk item 5: The Test Manager solutions. Good luck in mastering SCRUM. ■
What happens to the test manager whose role is now obso-
lete?
• 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?

www.agilerecord.com 53
 > About the author
Erik van Veenendaal
(www.erikvanveenendaal.
nl) is a leading internation-
al consultant and trainer,
and a recognized expert in
the area of software test-
ing and quality manage-
ment. 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 accord-
ing 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

www.casemaker.eu
© Pitopia/Klaus-Peter Adler, 2007

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 re-
quirements and changing priorities, it’s essential to ensure that
In a traditional project, the team can spend sufficient time in set- what worked yesterday works today. We also had challenges with
ting up the environment. In the case of Agile teams, they need to integration errors. In practice, we have learnt the hard way that
be productive from the first hour. From our experience, we have we must use unit tests so that code changes do not break exist-
realized that the lack of documentation on setting up the devel- ing functionality. We started writing unit test cases before coding.
opment environment is a key reason why the set-up time is long.
The second key reason is the number of manual steps involved The key tools we used were Junit (and other xUnit tools such as
in the set-up process. At sprint 0, where we document the fine NUnit, HTTPUnit etc), MockObjects.
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. 5) Refactoring

2) Automated builds In a traditional environment, individuals normally protect their

code base until integration. In Agile environments, however, we
Let us fail early! We have learnt that manual builds are liable to practice code ownership, which means that all code belongs to
be both fragile and specific to a single machine - and the time all developers, who are free to improve the code when they feel
lost in making those builds work is time lost to development and it’s necessary. Martin Fowler popularized the term “refactoring”
testing. On anything but the smallest projects, having an auto- in his book of the same name. Refactoring essentially boils down
mated build process is essential. We have realized that even if to code changes, which improve the structure and clarity of the
you have to take time out to create an automated build environ- code without necessarily changing the functionality. The key les-
ment, it’s time you’ll get back later. It also makes it simpler to en- son learnt is to have ‘unit tests’ as a safety net before refactoring
sure that we have a standardized build that everyone on a project the code. The key tools used are Eclipse, NetBeans, IntelliJ IDEA,
can share. The key tools we used were Ant, Maven, Nant. Visual Studio.NET.

3) Continuous integration As it is clearly evident, there is a certain uniqueness of the en-

gineering practices in Agile projects, and the teams need to be
From our past experience we have learnt that waiting for weeks orientated towards it.
on end before integrating code from different team members is
a recipe for disaster. If you’ve got an automated build in place, Behavioral traits required to work in Agile teams
the next thing is to go for continuous integration. Of course, an
automated build and continuous integration environment pre- As Agile teams work differently to other teams and, since they
supposes version control (or software configuration manage- depend a lot on effective and efficient communication and fast
ment to give it a more formal name). The key lesson learnt is that execution, there is an increased need for the team to possess
the sooner you identify integration errors, the sooner you can fix soft skills. If we include deliberate intervention and awareness to
them. The key tools we used were CruiseControl, CruiseControl. the traits and skills, then the Agile teams will be more meaningful
Net, Bamboo. and productive.

www.agilerecord.com 55
 Self-organization usually relies on basic ingredients like posi- (Co-location)
tive feedback, negative feedback, balance between exploitation • Projects are built around motivated individuals, who should
and exploration, and multiple interactions. From our experience, be trusted
teams sometimes fail to give the right kind of feedback and shy • Continuous attention to technical excellence and good design
away from interaction, due to various cultural and social issues. • Simplicity
• Self-organizing teams
From my experience, this remains a ‘myth’. We tend to always • Regular adaptation to changing circumstances
have a so-called ‘predictability syndrome’: the more planning we • Reduced risk
do, the more predictable we will be.
Conclusion
The team needs to have the right discipline, the ability to take on
responsibility, be committed and take accountability and owner- From my experience and observations, the skills required in Agile
ship. projects to be hyper-productive are slightly different form those
required in traditional projects. We have identified behavioral
One of the key skills that the team needs to have is the ability and technical skills required for teams to have that edge. Anyone
to ask for help and to seek out review. In certain cases, we have who acquires these ‘delta’ traits will be equipped with right set
seen ‘egos’ appearing as major impediments. of behavioral and technical skills, which will enable them to work
effectively in Agile projects. The summary of the skills are pre-
Taking responsibility, being committed and a spirit of collabo- sented in the table below.
ration 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 co-

development 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 Panic when workload peaks
help is there
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 devel-
opers
• Face-to-face conversation is the best form of communication

56 www.agilerecord.com
Skill table

Role Technical skills (in respective platforms) Behavioral skills

Developer • CRUD operations, interfacing with different layers of • Communication
the development framework • Collaboration
• Unit testing (tools: N-unit, J-unit ) • Time management/planning
• Code coverage concepts and tools • Thinking
• Code review concepts and tools • Conflict management
• Continuous integration tools • Dealing with change/flexibility
• Refactoring concepts • Decision making
• Code smelling concepts • Teamwork/team building
• SCRUM process • Handling stress
• Problem solving
• Leadership
• Diplomacy
QA • Definition of done → acceptance criteria • Same as developers (see above)
• Test management
• Automation/scripting
• Environment set-up
• Database concepts
SCRUM Master • SCRUM process • Developer skills + facilitation
• Templates and usage
• Project management tools
• Continuous integration tools
• Development environment set-up

> About the author

Prasad Prabhakaran
Prasad Prabhakaran has
10 years of experience in
the IT services industry.
His first exposure towards
Agile came through Micro-
soft in 2005. From then
onwards, he has carried
out solution, coaching, con-
sulting, 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 custom-
ers 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 the system. If we have a web UI that talks to a database through
of has had plenty of time to try different ways of writing tasks some kind of middle business logic layer and we need to add
during the Sprint planning phase. Some have been successful, some new functionality, we consequently put up three tasks: one
some have not. In this article we look at some types of tasks implementation task per layer.
that carry potential danger, and the appearance of which
tasks on the Scrum board may result in a failed Sprint. Evidently this leads to perfect parallelization (three team mem-
bers may work on the story at the same time). On the other hand,
You could argue that the planning phase of Scrum is the heart people may end up waiting for each other, while resolving prob-
of the process. The team is given full autonomy and authority to lems with interfaces, dependencies and integration. As always,
plan its upcoming work (load) in a way that maximizes customer communication will help, but deadlocks generated by horizontal
satisfaction, while being based on realistic and unanimous esti- slicing may just introduce unwanted delays.
mates. At one point or another, the team gets down to the dirty
business of detailed estimation, where stories are broken down Vertical slicing
into manageable tasks of reasonable duration. What “manage- Based on experience with horizontal slicing, the planning has
able” and “reasonable” means varies from team to team, but for resulted in the conclusion that it’s best to operate in silo mode:
the sake of fast feedback and sense of completion, it’s safer to each task is a vertical silo through the entire system. The task
go with smaller tasks, lasting a couple of hours to a couple of may look something like “Clicking on button X in the GUI updates
days. the price on item Y” (in the database). This guarantees that no
developer will be blocked waiting for work on an underlying layer
Given a usable granularity of the story breakdown, which is why to be completed by another developer. On the other hand, verti-
we prefer small tasks to large, composing a good list of tasks cal silos may end up in duplicated effort and layers lacking con-
is not an easy undertaking. The final result of the breakdown is ceptual integrity, since everyone just augments the appropriate
dependent on the team’s ability to learn from past experience, as layer with functionality they need without taking the whole into
well as its self-knowledge. Needless to say, teams lacking these account.
two attributes, and probably some more that are overlooked in
this article, run the risk of creating poor breakdowns that will Again, communication is the key, but there also needs to be a
result in poor execution in the implementation phase. task for refactoring and unifying the silos, otherwise they will be-
come technical debt as soon as they are implemented.
In a perfect world, it would be easy to deem some tasks as inher-
ently evil and take their presence as a sign of warning. However, Pre-study/design tasks
in a realistic world, such tasks are two-edged swords, that might During the planning, it wasn’t quite clear how some problems ap-
just work out well, or make your Sprint fail. Here are seven ex- pearing in the story would be solved. Nonetheless the team felt
amples of task types and breakdown strategies. quite comfortable about the overall complexity and could come
up with tasks and estimates. The first of these tasks turned out
Horizontal slicing to be a spike/pre-study/design task that would clarify the rest of
A traditional approach is taken and the work is divided into tasks the story and the remaining tasks. There’s nothing wrong with
that correspond to doing implementation at different layers of this kind of task, apart from two catches.

58 www.agilerecord.com
While waiting for the outcome of the pre-study/design, the ma- Another problem with these tasks is that they are inherently hard
jority of or the entire story is blocked. There’s simply no point in to estimate. If your previous Sprint was delayed because of intri-
picking implementation tasks unless the overall design is solved cate third-party driver and race condition issues found no sooner
or a pre-study completed. In general, such tasks appear in more than in the final integration phase, this Sprint’s time estimate
complex stories, meaning that a big chunk of work is off limit to will be high. On the other hand, if everything just worked the last
the team. time, why create a big final integration task, or why create one
at all?
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 Finally, I’ve seen a third version of final integration failure. Name-
effort into these tasks. ly, 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
Actually, there’s a third potential problem lurking here as well. final integration task remains. A savvy team member will then
If a story needs further “investigation”, it maybe shouldn’t have pick that task, while some other team members are working to
made it as far as it did at all. This doesn’t need to be the case. complete the remaining ones.
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 In this scenario, the person doing the final integration may finish
the alternative scenario. first, reporting that there were no or few integration/round-up dif-
ficulties, which of course is true, since the tasks containing the
Tasks with external dependencies difficult functionality are unfinished. In the worst of worlds, this
The team has committed to a task, the outcome of which de- results in an unplanned new final integration, and the first effort
pends on an external party, such as the customer, a third-party is wasted.
vendor, or just a piece of hardware.
Integration test tasks
Naturally, this can’t be avoided in the real world, but special at- For the team to be done, the story must pass some kind of inte-
tention should be paid to these tasks. Their number should be gration test or possibly even a user acceptance test. Being the
kept down, and they should be picked early to mitigate the risk of last task of the story, this type of task is a close cousin of the final
Sprint overrun due to calendar time/availability issues. integration task. To make tings more interesting, this task may
involve external dependencies, such as end users or dedicated
Short general verb phrases testing environments.
The team has spent a lot of time in the planning meeting having
heated discussions. Finally, it agrees on a breakdown, and it’s Normally, this is something you have to do unless you have the
perfectly clear to everybody what the task saying “Implement” luxury of a second team responsible for roll-outs and bug fixing,
means. It has been discussed so thoroughly! so shorten your mental image of the sprint by at least a day.

Believe it or not, but this short general verb phrase isn’t obvious Hidden critical paths
if the story gets a low priority and is done late in the Sprint, or The observant reader has by now noticed that the underlying
even worse, moved to the next one. Hence somewhat more ver- theme of this article has been throughput achieved by striving
bose and precise tasks are better. for a high degree of parallelism, which in turn depends on atomic
self-contained tasks.
Final integration tasks
These tasks emerge when the team realizes that the effort Given this assumption, there’s another dimension to task break-
of completing all the tasks of the story still won’t result in its down – being on alert for hidden critical paths.
completion. The planning session may have produced some un-
resolved questions, the story may feel too complex, or there’s a As some tasks depend on other tasks in a normal story break-
lot of slicing going on (see above). Previous experience indicates down, critical paths are more or less unavoidable: pre-studies
that tying everything together does require some additional ef- must be completed first, and then followed by implementation
fort, which is not easily captured in the individual tasks. For these tasks, which are integrated one last time before going through
reasons, final integration tasks are great, but as with the other final testing and documentation.
tasks discussed, their blade cuts both ways.
Estimation without taking such critical paths into account may
The obvious pitfall is that tasks won’t get completed, simply be- lead to introduction of unnecessary sequential dependencies
cause the people doing them start over-relying on the final inte- among tasks. Suddenly we have a long critical path, whose ele-
gration tasks: “It doesn’t work as expected, but I don’t care, since ments must be completed in strict order. Mini waterfall?
someone else will surely fix it in the final integration”, might be a
common but disastrous thought. This kind of thinking shifts your This doesn’t have to be a bad thing, since it’s limited to one
Sprint towards a “mini waterfall”, and you run the risk of creating Sprint, but it does decrease overall flexibility and dynamics of the
code and fix cycles within the very same Sprint. work within the Sprint.

www.agilerecord.com 59
 Summary
You may have encountered these tasks, or you may have found > About the author
other problems in your breakdowns. It should be perfectly natural
Alexander Tarnowski
that the list of problematic tasks and breakdowns would appear
Alexander Tarnowski is a
different for every team. These are the ones I have encountered.
software developer with
a decade of experience
As said at the beginning of this article, the task archetypes dis-
in the field, and a broad
cussed here are not dangerous in themselves. You just have to
definition of the term “soft-
be aware of the pitfalls in them.
ware development”. He
has a master’s degree in
By the way, if these are the dangerous ones, which are the safe
computer science and a
ones that didn’t make this list? ■
bachelor’s degree in busi-
ness administration, which
Alexander Tarnowski, May 2010
makes him interested in both technical and economic
aspects of the industry.

Having worked in all phases of the development pro-

cess, he believes in craftsmanship and technical excel-
lence at every stage. He’s currently interested in how
introduction of agile methodologies on a larger scale
will redefine the tester and developer roles.
© iStockphoto.com/ScantyNebula

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 motivated individuals, continuous attention to technical excel-
in Agile development. Cycle time reduction can be achieved if lence and good design, simplicity, self-organizing teams, sustain-
the activities involved in the development life cycle can be auto- able development and regular adaptation to changing circum-
mated or accelerated. Standard Engineering tools like Rational stances.
Requisite Pro, Visual Studio Team Suite (VSTS), Team Foundation
Server (TFS), and Rational Functional Tester provide different Hence continuous delivery of software and reduced cycle time
features to automate the activities involved at different life cycle are core requirements of Agile development. Below are some of
stages. This article presents on how standard engineering tools the several principles that can contribute to achieve these core
can be deployed, without overhead, in an Agile development en- requirements.
vironment to gain the desired results in cycle time reduction and
in quality. • Requirements prioritization & ability to include changing re-
quirements
Introduction • Continuous integration
• Collective code ownership
Agile software development is a software development method- • Continuous automated testing
ology where requirements and the application software evolve • Transparency & improved communication
through the collaboration and communication between special- • Effective tracking of work progress
ized groups. Agile development methodology can be described
as iterative and incremental. Every aspect of development, i.e. re- Software tools help in accelerating the development effort by pro-
quirements, design, coding etc., is continually revisited through- viding different features to automate the manual work involved
out the development life cycle. This kind of continual ”inspect in different life cycle stages. The sections below will describe in
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 oth-
er in the mode of execution, but all of
them are built on the Agile principles:
satisfy customer through early and con-
tinuous delivery of software, welcome
changing requirements even late in
development, deliver working software
frequently, working software is the prin-
ciple measure of progress, face-to-face
communication, projects built around 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 re-

quirements–

Changing requirements are natural in a software development Fig. 3 User story in TFS (Team Foundation Server)
process. Agile processes embrace change with the notion that
requirements will evolve throughout a project. The whole bunch ects in which all the artifacts in the team project are aligned
of requirements is broken into different sets, and each of these to Agile software development. In the Agile team project, user
sets is included in the corresponding iterations based on the pri- story work items can be created and tracked effectively through
oritization provided by the stakeholders. Each of the iterations in different in-built queries and reports. Product backlogs provide
the life cycle covers these sets of requirements. Hence require- information on the
ments organization, prioritization and tracking are very much vi- list of requirements
tal in Agile methodology. desired by the cus-
tomer in the ap-
plication. And the
iteration backlog
provides informa-
tion on the user sto-
ries and queries on
the user stories for
a specific iteration.
So generally, when
the user stories are
created, they are in-
cluded in a product
backlog and then,
based on the pri-
oritization, they are
included in iteration
backlogs. This helps
in better planning
and categorization
of the requirements, Fig. 4 TFS Work items, queries
Fig. 2 Query feature and traceability matrix for Requisite Pro
which is very much
essential in an Agile
Requisite Pro is a powerful, easy-to-use, and integrated product environment.
for requirements and use case management that promotes bet-
ter communication, enhances teamwork, and reduces project Continuous Integration
risk. It provides features for the creation of different categories
of requirements through packages, for creating and tracking re- In order to deliver artifacts at regular intervals, continuous inte-
quirements, for assigning priorities to the requirements, for de- gration is essential in Agile methodology. Continuous integration
tailed traceability views that display parent/child relationships, is a practice of integrating one’s new or modified code to the
and for showing requirements that may be affected by upstream code repository early and often. This should be carried out very
or downstream change. frequently, so that there is no gap between commit and build,
such that the errors that arise can be detected and corrected
The tool also provides a powerful database infrastructure with early. The important factors that are considered during continu-
real-time Word document synchronization to facilitate require- ous integration are:
ments organization, integration and analysis.
• Code repository
Similarly, Team Foundation Server provides features like work • Automate build
items, queries and reports through which the requirements can • Make the build self-testing
be managed. The tool provides a specific template for Agile proj- • Everyone commits everyday

62 www.agilerecord.com
• Every commit is built duces a significant amount of effort in the coding life cycle stage.
• Make it easy to get latest deliverables
• Everyone can see results of latest build Continuous Automated Testing –

TFS provides different features to implement these factors, Continuous testing involves regular and frequent execution of
which are essential for continuous integration. The tool provides tests to verify whether the modifications done in the code impact
a code repository through the integration with the SQL server and the application’s behavior. Continuous unit/regression testing is
good version control features to get the latest deliverables. It also one of the key parts in an Agile methodology, since it helps to
provides features like build automation, ability to schedule builds detect and correct the errors at an early stage as and when they
for each check-in (continuous integration), atomic check-ins, and are created.
it provides build reports which are visible to the whole team.
The VSTS unit testing framework, which comes inbuilt in the In-
tegrated 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 visi-
ble across the whole team in Team Foundation Server. The devel-
opers can contribute in a better way by taking collective owner-
ship. In addition, VSTS provides forward engineering capability to Fig. 6 VSTS unit testing
automatically generate code from the design models, and this re-

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 assur-
ance 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 develop-

ment. 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 soft-
ware quality, test progress and build quality.

The reports that are created in TFS give an indication of the work Fig 9 Burn-down and burn rate

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 veloc-
ity, 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. 10 Remaining work

Effective Tracking of Work Progress Conclusion

In Agile methodologies, it is highly important that the work prog- A proposed solution for the reduction of cycle time in Agile devel-
ress is tracked effectively. Each of the iterations has a deliver- opment is through the usage of the right set of tools at each life
able, and these deliverables need to be tracked so that no re- cycle stage.
quirement is missed out. Work items and the powerful reporting
feature provided by TFS help the project manager to track the Tools help in creating a collaborative platform, which connects
work progress in an effective way. In addition, VSTS provides spe- geographically distributed teams for effective & transparent com-
cific capabilities for Agile projects to track user stories through munication to manage changes done to the project artifacts, e.g.
”User stories progress” and ”Status on all iterations” reports. communicating requirements changes to the developer and tes-
ter 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 stag-
es. 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. ■

64 www.agilerecord.com
References
[1] Feature of Rational Requisite Pro Available at, http://www- > About the author
01.ibm.com/software/awdtools/reqpro/features/
Chaitanya Sudha Nakka
Chaitanya is a Technologi-
[2] VSTS & TFS - http://msdn.microsoft.com/enus/library/
cal Lead at Infosys Tech-
ms181232.aspx
nologies Ltd and has an
experience of 7.5 years
[3] Rational Functional Tester - http://www-01.ibm.com/soft-
in software development.
ware/awdtools/tester/functional/
She has considerable ex-
perience on tools related
to .NET/C++ technologies.
She has worked for em-
bedded 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 October 2010
Deadline Proposal August 20th
Deadline Article 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 ac- A good analogy for team collaboration is given below -
tivity, and it is even more important for software development.
Software development is a complex process, and to achieve the Migrating geese fly in a ‘V’ formation on account of various fac-
end goals of the customer, team collaboration and interaction tors. As each goose flaps its wings, it creates an upward lift for
are very important. The team needs to work together cohesively, the following goose. In a V-formation, the whole flock adds at
so that delivery is made according to schedule, quality, cost and least about 70% more flying range than if each goose flew alone.
other parameters.
Whenever a goose falls out of the planned formation, it suddenly
A single individual cannot guarantee successful customer deliv- feels the drag and resistance of trying to fly alone…and it quickly
ery. It is the team which, if it works cohesively, ensures success- gets back into formation.
ful delivery to the customer.
Like geese, people who share a common direction and a sense of
In projects that are implementing Scrum, the role of the Scrum community can go where they are going quicker and easier than
Master, who facilitates the team to achieve the end goal of the those who try to do it alone. When a goose gets tired, it goes back
customer, is very crucial. The Scrum Master focuses on ensuring into the next level of the planned formation and another goose
that any impediments and “road blocks” faced by the team are flies at the pole point position. This highlights the fact that people
removed, and he ensures that the core focus of the team is on will realize that ultimately their success depends on working as a
developing the product/service for the customer under optimal team, taking turns doing the hard tasks, and sharing leadership.
conditions. Thus, he is in effect practicing “Servant Leadership”,
where the focus is on giving priority attention to the needs of the Geese in the rear of the planned formation honk to encourage
team members and those they serve (customer). It encourages those up front to increase their speed. It is important that our
leaders to serve others while staying focused on achieving re- “honking from behind” should also be encouraging to the other
sults in line with the organization’s values, integrity and business team members.
objectives.
When a goose gets sick or wounded, two other geese drop out
In the ancient Hindu text, Arthashastra, Chanakya commented in of the planned formation and follow it down to help and provide
the 4th century B.C. : 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
The king [leader] shall consider as good, not what pleases him- another passing flock or try to catch up with their own flock.
self but what pleases his subjects [followers]”.
In our daily life, it is very difficult for the Scrum Master to con-
“The king [leader] is a paid servant and enjoys the resources of stantly ensure that all team members work together cohesively
the state together with the people.” to achieve the final delivery for the customer, as people are com-
plex personalities. The Scrum Master is constantly battling with
“Servant Leadership” emphasizes collaboration, trust, empathy, various issues that arise during his daily work in order to ensure
and the usage of power ethically. The objective is to enhance and that the team does not face any “road blocks” while executing

66 www.agilerecord.com
their work. As the project team learns to form self-organizing teams, they en-
counter various issues regarding the tasks which they may want
The Daily Scrum serves as an important barometer for the Scrum to choose to work.
Master to know the progress made on a daily basis during the
iteration. However, in his zeal to ensure that the team collabora- In an Agile Scrum team, the team is populated with cross-func-
tion is not compromised, the Scrum Master should focus not only tional team members. However, the “Abilene Paradox” can still
on the visible issues, but also on various other factors that are in occur and this creates issues for the Scrum Master. These issues
reality hidden “road blocks” for team collaboration. These issues need to be managed appropriately.
are subliminal and are not directly visible during the course of
the iteration. 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
Scrum promotes self-organizing teams, which are expected to better suited for the task. This mistaken belief can lead to the
choose the tasks in a self-organized manner and execute the “Abilene Paradox”. The team member subsequently chooses an
work accordingly. The Scrum Master needs to monitor that these alternative task, which he feels will not disrupt the team work.
tasks are done in a coordinated way so that the final goal of the Other members also think in a similar manner. This leads to
iteration is met. some tasks not being optimized adequately. This is on account
of the fact that on a cross-functional team, more than one mem-
In a typical iteration, in teams that are initially learning how to ber may be focused on a specific activity like implementation of
implement Scrum in their project, and also sometimes in ma- code. This leads to a scenario of a mini group simulated within
ture teams, there is an initial hesitation on the part of the team the team, and it leads to reduced optimal team collaboration on
members to volunteer for a specific task, as the member is not account of group-related issues.
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, The issues can disrupt team collaboration, and the Scrum Mas-
in the initial iterations, the Scrum Master facilitates the team in ter needs to be alert and focus on these issues, which can lead
ensuring that they become self-organized over a period of time. to a reduced level of team collaboration. This type of team be-
However, this is easier said than done. Many Feature team leads havior can also affect the team decision-making abilities when
delegate the work to the team members and slowly build the self- they have to decide other options for various alternatives. Thus,
organizing capability in the team over a period of time. it leads to defective team decision-making.

Self-organization in teams is assumed to be simpler as com- During the Iteration Retrospective Workshop, when the team dis-
pared to self-organization in groups. In order to understand this cusses the task allocation activity, the team can intuitively feel
concept, we first need to define what a team and what a group that if the task order execution had been different, they could
is. A team’s strength depends on the commonality of purpose have delivered still better value to the customer. This highlights
and interconnectivity between individual members, whereas a the fact that even though the self-organizing team members are
group’s strength may come from the willingness to carry out a the only members who know intimately about all the tasks to be
single leader’s commands. Many people use the words team and executed in a particular iteration, they may still not be aware of
group interchangeably, but there are actually a number of differ- various other factors which influence the team and which may
ences between a team and a group in the real world. 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
Self-organization in teams takes a lot of time and optimal self- needs to be improved during the Iteration Retrospective Work-
organized teams are few in an organization. In teams, a phe- shop and suggest whether the specific activity could have been
nomenon called the “Abilene Paradox”, that generally occurs in a improved further in order to deliver more value to the customer.
group, can also occur. This is a case of continuous process improvement and a case for
the “Inspect and Adapt” technique.
The “Abilene Paradox” is a paradox in which a group of people
collectively decide on a course of action that is counter to the Psychological theories of social conformity and social influence
preferences of any of the individuals in the group. It involves a highlight that human beings are often very averse to acting con-
common breakdown of group communication, in which each trary to the trend of the group. It is also observed that indirect
member mistakenly believes that their own preferences are a cues and hidden motives often lie behind peoples’ statements
contradiction to the group and, therefore, does not raise objec- and acts, as the social context in which they operate discourages
tions. In effect, the desire is not to “rock the boat”. This theory them from openly voicing their feelings or pursuing their desires.
explains the behavior of groups in a social context.
One way to avoid this issue: When the time comes for a team
The crux is that teams have just as many problems managing to make decisions, they should ask each other, “Are we going
their agreements as they do their disagreements. 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 know the areas of concern and express their doubts.
cohesive group, whose members try to minimize conflict and • All the alternatives should be explicitly examined. This helps
reach consensus without critically testing, analyzing, and evalu- to check previously rejected alternatives.
ating ideas. This can also apply to larger cross-functional teams • The team should also discuss key ideas with other teams
consisting of multiple mini groups that simulate group behavior who may have faced a similar situation. This helps to share
within a team. best practices/lessons learnt and will help the team focus
on the core issue.
During groupthink, members of the group avoid promoting view- • At least one group member should be assigned the role of
points outside the comfort zone of consensus thinking. A variety Devil’s advocate (murder board). This role could be rotated
of motives for this may exist, such as a desire to avoid being seen among the team members.
as foolish, or a desire to avoid embarrassing or angering other
members of the group. Groupthink may cause groups to make However, the above steps need not be taken for every single deci-
hasty, irrational decisions, where individual doubts are set aside sion, as lower-level decisions and other non-critical decisions can
for fear of upsetting the group’s balance. be taken with minimal data. Only critical decisions which influ-
ence the customer goal directly and impact the business value
These issues occur at the subliminal level, and hence it is very need to be analyzed fully, and all the possible options and oppor-
difficult for the Scrum Master to identify the core issues in team tunities need to be explored so that the probability of success in
collaboration. Thus, he must be watchful, and when a team is meeting the customer goal is increased. We should also ensure
not observed to be very effective, one way of improving team col- that Lean principles are kept in mind so that unnecessary time
laboration is to check out if the “Abilene Paradox” is in vogue and is not wasted in trying to find hidden motives for the decisions
make all the members aware of this paradox. Once this paradox taken.
is highlighted to the team, this issue does not repeat again, and
if it does, only very rarely, as the team understands the hidden Conclusions
“road blocks” affecting the team collaboration.
Thus, one of the ways to resolve crucial team interaction issues
Reasons for “Abilene Paradox” which occur during the iterations can be by focusing on the ques-
tion “Are we going to Abilene?”, and if the team is able to say
Some of the reasons why “Abilene Paradox” may exist are: “No”, it means we are hopefully on the right track in meeting the
customer goals.
• There is a bias in collecting the required information
• Failure to examine risks for the preferred choices Thus, the “Abilene Paradox” leads to another implicit paradox:
• Contingency plans have not been worked out properly Teams need to be cohesive but at the same time should not be
• The selected alternatives and the objectives are not com- cohesive! This means that the team cohesion should help to
pletely evaluated complete the work successfully, but at the same time the team
• Failure to re-evaluate previously rejected alternatives cohesion should not impede individual and rational thinking of a
• Searching the relevant information has not been done prop- solution to a problem or an issue. ■
erly

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
> About the author
rational manner. This sets off the “Abilene Paradox”. Badri N Srinivasan
Badri N Srinivasan is work-
The focus has to be on rationalized conformity – an open phi- ing as Head of Quality for
losophy which holds that group values are not only expedient but Valtech India Systems Pvt.
right and good as well; when compared to instinctive conformity. Ltd., Bangalore, India. He
has extensive experience
Some steps to avoid “Abilene Paradox” in process implementation
and organizational change
Some of the steps that could be taken to avoid the “Abilene Para- management processes
dox” are: and process improvement
initiatives in the travel, re-
• The senior team members should encourage junior team tail, manufacturing, banking and financial services do-
members. They should not express their opinion before the mains. He is a Certified Scrum Master (CSM) and Proj-
junior member has given his opinion. ect Management Professional (PMP).
• The team should assign one member to perform the role of
the critical evaluator. This will help other team members to

68 www.agilerecord.com
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 la-
belling 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 dupli-
cation 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 -

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
Kurfürstendamm, Berlin © Katrin Schülke

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