Académique Documents
Professionnel Documents
Culture Documents
Buy 2
from informIT and
Save 35%
informit.com/agile Enter the coupon code
AGILE2009
during checkout.
Agile 2009
eSampler
eBOOK TABLE OF CONTENTS
Google
Bookmarks Delicious Digg Facebook StumbleUpon Reddit Twitter
The authors and publisher have taken care in the preparation of this book, but make no expressed
or implied warranty of any kind and assume no responsibility for errors or omissions. No liability
is assumed for incidental or consequential damages in connection with or arising out of the use of
the information or programs contained herein.
BROUGHT TO YOU BY
UPPER SADDLE RIVER, NJ | BOSTON | INDIANAPOLIS | SAN FRANCISCO | NEW YORK | TORONTO | MONTREAL | LONDON | MUNICH
PARIS | MADRID | CAPETOWN | SYDNEY | TOKYO | SINGAPORE | MEXICO CITY
Save 35%
Robert C. Martin Enter the coupon code
AGILE2009 during checkout.
Clean Code
A Handbook of Agile Software Craftsmanship
Even bad code can function. But if code isn’t clean, it can bring a development
organization to its knees. Every year, countless hours and significant resources available
are lost because of poorly written code. But it doesn’t have to be that way. • Book: 9780132350884
• Safari Online
Noted software expert Robert C. Martin presents a revolutionary paradigm with
• EBOOK: 0136083226
Clean Code: A Handbook of Agile Software Craftsmanship. Martin has teamed up
• KINDLE: B001GSTOAM
with his colleagues from Object Mentor to distill their best agile practice of clean-
ing code “on the fly” into a book that will instill within you the values of a software
craftsman and make you a better programmer—but only if you work at it. About the Author
What kind of work will you be doing? You’ll be reading code—lots of code. Robert C. “Uncle Bob” Martin
And you will be challenged to think about what’s right about that code, and has been a software professional
what’s wrong with it. More importantly, you will be challenged to reassess your since 1970 and an international
professional values and your commitment to your craft. software consultant since 1990.
He is founder and president of
Clean Code is divided into three parts. The first describes the principles, patterns,
Object Mentor, Inc., a team of
and practices of writing clean code. The second part consists of several case stud-
experienced consultants who
ies of increasing complexity. Each case study is an exercise in cleaning up code—
mentor their clients worldwide
of transforming a code base that has some problems into one that is sound and
in the fields of C++, Java, C#,
efficient. The third part is the payoff: a single chapter containing a list of heuristics
Ruby, OO, Design Patterns,
and “smells” gathered while creating the case studies. The result is a knowledge
UML, Agile Methodologies,
base that describes the way we think when we write, read, and clean code.
and eXtreme programming.
Readers will come away from this book understanding
• How to tell the difference between good and bad code
• How to write good code and how to transform bad code into good code
• How to create good names, good functions, good objects, and good classes
• How to format code for maximum readability
• How to implement complete error handling without obscuring code logic
• How to unit test and practice test-driven development
This book is a must for any developer, software engineer, project manager, team
lead, or systems analyst with an interest in producing better code.
informit.com/ph
01_Martin.fm Page 1 Wednesday, July 2, 2008 10:21 AM
1
Clean Code
You are reading this book for two reasons. First, you are a programmer. Second, you want
to be a better programmer. Good. We need better programmers.
1
01_Martin.fm Page 2 Wednesday, July 2, 2008 10:21 AM
This is a book about good programming. It is filled with code. We are going to look at
code from every different direction. We’ll look down at it from the top, up at it from the
bottom, and through it from the inside out. By the time we are done, we’re going to know a
lot about code. What’s more, we’ll be able to tell the difference between good code and bad
code. We’ll know how to write good code. And we’ll know how to transform bad code into
good code.
Bad Code 3
Bad Code
I was recently reading the preface to Kent Beck’s
book Implementation Patterns.1 He says, “. . . this
book is based on a rather fragile premise: that
good code matters. . . .” A fragile premise? I dis-
agree! I think that premise is one of the most
robust, supported, and overloaded of all the pre-
mises in our craft (and I think Kent knows it). We
know good code matters because we’ve had to
deal for so long with its lack.
I know of one company that, in the late 80s,
wrote a killer app. It was very popular, and lots of
professionals bought and used it. But then the
release cycles began to stretch. Bugs were not
repaired from one release to the next. Load times
grew and crashes increased. I remember the day I
shut the product down in frustration and never
used it again. The company went out of business
a short time after that.
Two decades later I met one of the early employees of that company and asked him
what had happened. The answer confirmed my fears. They had rushed the product to
market and had made a huge mess in the code. As they added more and more features, the
code got worse and worse until they simply could not manage it any longer. It was the bad
code that brought the company down.
Have you ever been significantly impeded by bad code? If you are a programmer of
any experience then you’ve felt this impediment many times. Indeed, we have a name for
it. We call it wading. We wade through bad code. We slog through a morass of tangled
brambles and hidden pitfalls. We struggle to find our way, hoping for some hint, some
clue, of what is going on; but all we see is more and more senseless code.
Of course you have been impeded by bad code. So then—why did you write it?
Were you trying to go fast? Were you in a rush? Probably so. Perhaps you felt that you
didn’t have time to do a good job; that your boss would be angry with you if you took the
time to clean up your code. Perhaps you were just tired of working on this program and
wanted it to be over. Or maybe you looked at the backlog of other stuff that you had prom-
ised to get done and realized that you needed to slam this module together so you could
move on to the next. We’ve all done it.
We’ve all looked at the mess we’ve just made and then have chosen to leave it for
another day. We’ve all felt the relief of seeing our messy program work and deciding that a
1. [Beck07].
01_Martin.fm Page 4 Wednesday, July 2, 2008 10:21 AM
working mess is better than nothing. We’ve all said we’d go back and clean it up later. Of
course, in those days we didn’t know LeBlanc’s law: Later equals never.
Figure 1-1
Productivity vs. time
01_Martin.fm Page 5 Wednesday, July 2, 2008 10:21 AM
Attitude
Have you ever waded through a mess so grave that it took weeks to do what should have
taken hours? Have you seen what should have been a one-line change, made instead in
hundreds of different modules? These symptoms are all too common.
Why does this happen to code? Why does good code rot so quickly into bad code? We
have lots of explanations for it. We complain that the requirements changed in ways that
thwart the original design. We bemoan the schedules that were too tight to do things right.
We blather about stupid managers and intolerant customers and useless marketing types
and telephone sanitizers. But the fault, dear Dilbert, is not in our stars, but in ourselves.
We are unprofessional.
This may be a bitter pill to swallow. How could this mess be our fault? What about the
requirements? What about the schedule? What about the stupid managers and the useless
marketing types? Don’t they bear some of the blame?
No. The managers and marketers look to us for the information they need to make
promises and commitments; and even when they don’t look to us, we should not be shy
about telling them what we think. The users look to us to validate the way the requirements
will fit into the system. The project managers look to us to help work out the schedule. We
01_Martin.fm Page 6 Wednesday, July 2, 2008 10:21 AM
are deeply complicit in the planning of the project and share a great deal of the responsi-
bility for any failures; especially if those failures have to do with bad code!
“But wait!” you say. “If I don’t do what my manager says, I’ll be fired.” Probably not.
Most managers want the truth, even when they don’t act like it. Most managers want good
code, even when they are obsessing about the schedule. They may defend the schedule and
requirements with passion; but that’s their job. It’s your job to defend the code with equal
passion.
To drive this point home, what if you were a doctor and had a patient who demanded
that you stop all the silly hand-washing in preparation for surgery because it was taking
too much time?2 Clearly the patient is the boss; and yet the doctor should absolutely refuse
to comply. Why? Because the doctor knows more than the patient about the risks of dis-
ease and infection. It would be unprofessional (never mind criminal) for the doctor to
comply with the patient.
So too it is unprofessional for programmers to bend to the will of managers who don’t
understand the risks of making messes.
2. When hand-washing was first recommended to physicians by Ignaz Semmelweis in 1847, it was rejected on the basis that
doctors were too busy and wouldn’t have time to wash their hands between patient visits.
01_Martin.fm Page 7 Wednesday, July 2, 2008 10:21 AM
Writing clean code requires the disciplined use of a myriad little techniques applied
through a painstakingly acquired sense of “cleanliness.” This “code-sense” is the key.
Some of us are born with it. Some of us have to fight to acquire it. Not only does it let us
see whether code is good or bad, but it also shows us the strategy for applying our disci-
pline to transform bad code into clean code.
A programmer without “code-sense” can look at a messy module and recognize the
mess but will have no idea what to do about it. A programmer with “code-sense” will look
at a messy module and see options and variations. The “code-sense” will help that pro-
grammer choose the best variation and guide him or her to plot a sequence of behavior
preserving transformations to get from here to there.
In short, a programmer who writes clean code is an artist who can take a blank screen
through a series of transformations until it is an elegantly coded system.
to describe the consequence of that inelegance. He uses the word “tempt.” There is a deep
truth here. Bad code tempts the mess to grow! When others change bad code, they tend to
make it worse.
Pragmatic Dave Thomas and Andy Hunt said this a different way. They used the meta-
phor of broken windows.3 A building with broken windows looks like nobody cares about
it. So other people stop caring. They allow more windows to become broken. Eventually
they actively break them. They despoil the facade with graffiti and allow garbage to col-
lect. One broken window starts the process toward decay.
Bjarne also mentions that error handing should be complete. This goes to the disci-
pline of paying attention to details. Abbreviated error handling is just one way that pro-
grammers gloss over details. Memory leaks are another, race conditions still another.
Inconsistent naming yet another. The upshot is that clean code exhibits close attention to
detail.
Bjarne closes with the assertion that clean code does one thing well. It is no accident
that there are so many principles of software design that can be boiled down to this simple
admonition. Writer after writer has tried to communicate this thought. Bad code tries to do
too much, it has muddled intent and ambiguity of purpose. Clean code is focused. Each
function, each class, each module exposes a single-minded attitude that remains entirely
undistracted, and unpolluted, by the surrounding details.
3. http://www.pragmaticprogrammer.com/booksellers/2004-12.html
01_Martin.fm Page 9 Wednesday, July 2, 2008 10:21 AM
the reader that “Aha! Of course!” as the issues and tensions are resolved in the revelation
of an obvious solution.
I find Grady’s use of the phrase “crisp abstraction” to be a fascinating oxymoron!
After all the word “crisp” is nearly a synonym for “concrete.” My MacBook’s dictionary
holds the following definition of “crisp”: briskly decisive and matter-of-fact, without hesi-
tation or unnecessary detail. Despite this seeming juxtaposition of meaning, the words
carry a powerful message. Our code should be matter-of-fact as opposed to speculative.
It should contain only what is necessary. Our readers should perceive us to have been
decisive.
4. [Knuth92].
01_Martin.fm Page 10 Wednesday, July 2, 2008 10:21 AM
beyond names, however. I also look at whether an object or method is doing more than one
thing. If it’s an object, it probably needs to be broken into two or more objects. If it’s a
method, I will always use the Extract Method refactoring on it, resulting in one method
that says more clearly what it does, and some submethods saying how it is done.
Duplication and expressiveness take me a very long way into what I consider clean
code, and improving dirty code with just these two things in mind can make a huge differ-
ence. There is, however, one other thing that I’m aware of doing, which is a bit harder to
explain.
After years of doing this work, it seems to me that all programs are made up of very
similar elements. One example is “find things in a collection.” Whether we have a data-
base of employee records, or a hash map of keys and values, or an array of items of some
kind, we often find ourselves wanting a particular item from that collection. When I find
that happening, I will often wrap the particular implementation in a more abstract method
or class. That gives me a couple of interesting advantages.
I can implement the functionality now with something simple, say a hash map, but
since now all the references to that search are covered by my little abstraction, I can
change the implementation any time I want. I can go forward quickly while preserving my
ability to change later.
In addition, the collection abstraction often calls my attention to what’s “really”
going on, and keeps me from running down the path of implementing arbitrary collection
behavior when all I really need is a few fairly simple ways of finding what I want.
Reduced duplication, high expressiveness, and early building of simple abstractions.
That’s what makes clean code for me.
Here, in a few short paragraphs, Ron has summarized the contents of this book. No
duplication, one thing, expressiveness, tiny abstractions. Everything is there.
“. . . pretty much what you expected.” When was the last time you saw a module that
was pretty much what you expected? Isn’t it more likely that the modules you look at will
be puzzling, complicated, tangled? Isn’t misdirection the rule? Aren’t you used to flailing
about trying to grab and hold the threads of reasoning that spew forth from the whole sys-
tem and weave their way through the module you are reading? When was the last time you
read through some code and nodded your head the way you might have nodded your head
at Ward’s statement?
Ward expects that when you read clean code you won’t be surprised at all. Indeed, you
won’t even expend much effort. You will read it, and it will be pretty much what you
expected. It will be obvious, simple, and compelling. Each module will set the stage for
the next. Each tells you how the next will be written. Programs that are that clean are so
profoundly well written that you don’t even notice it. The designer makes it look ridicu-
lously simple like all exceptional designs.
And what about Ward’s notion of beauty? We’ve all railed against the fact that our lan-
guages weren’t designed for our problems. But Ward’s statement puts the onus back on us.
He says that beautiful code makes the language look like it was made for the problem! So
it’s our responsibility to make the language look simple! Language bigots everywhere,
beware! It is not the language that makes programs appear simple. It is the programmer
that make the language appear simple!
Schools of Thought
What about me (Uncle Bob)? What do I think
clean code is? This book will tell you, in hideous
detail, what I and my compatriots think about
clean code. We will tell you what we think makes
a clean variable name, a clean function, a clean
class, etc. We will present these opinions as abso-
lutes, and we will not apologize for our stridence.
To us, at this point in our careers, they are abso-
lutes. They are our school of thought about clean
code.
Martial artists do not all agree about the best
martial art, or the best technique within a martial
art. Often master martial artists will form their
own schools of thought and gather students to
learn from them. So we see Gracie Jiu Jistu,
founded and taught by the Gracie family in Brazil. We see Hakkoryu Jiu Jistu, founded
and taught by Okuyama Ryuho in Tokyo. We see Jeet Kune Do, founded and taught by
Bruce Lee in the United States.
Martin_ch01.fm Page 13 Friday, January 16, 2009 6:11 PM
We Are Authors 13
We Are Authors
The @author field of a Javadoc tells us who we are. We are authors. And one thing about
authors is that they have readers. Indeed, authors are responsible for communicating well
with their readers. The next time you write a line of code, remember you are an author,
writing for readers who will judge your effort.
You might ask: How much is code really read? Doesn’t most of the effort go into
writing it?
Have you ever played back an edit session? In the 80s and 90s we had editors like Emacs
that kept track of every keystroke. You could work for an hour and then play back your whole
edit session like a high-speed movie. When I did this, the results were fascinating.
The vast majority of the playback was scrolling and navigating to other modules!
...
You get the drift. Indeed, the ratio of time spent reading vs. writing is well over 10:1.
We are constantly reading old code as part of the effort to write new code.
Because this ratio is so high, we want the reading of code to be easy, even if it makes
the writing harder. Of course there’s no way to write code without reading it, so making it
easy to read actually makes it easier to write.
There is no escape from this logic. You cannot write code if you cannot read the sur-
rounding code. The code you are trying to write today will be hard or easy to write
depending on how hard or easy the surrounding code is to read. So if you want to go fast,
if you want to get done quickly, if you want your code to be easy to write, make it easy to
read.
If we all checked-in our code a little cleaner than when we checked it out, the code
simply could not rot. The cleanup doesn’t have to be something big. Change one variable
name for the better, break up one function that’s a little too large, eliminate one small bit of
duplication, clean up one composite if statement.
Can you imagine working on a project where the code simply got better as time
passed? Do you believe that any other option is professional? Indeed, isn’t continuous
improvement an intrinsic part of professionalism?
5. This was adapted from Robert Stephenson Smyth Baden-Powell’s farewell message to the Scouts: “Try and leave this world a
little better than you found it . . .”
01_Martin.fm Page 15 Wednesday, July 2, 2008 10:21 AM
Bibliography 15
Conclusion
Books on art don’t promise to make you an artist. All they can do is give you some of the
tools, techniques, and thought processes that other artists have used. So too this book can-
not promise to make you a good programmer. It cannot promise to give you “code-sense.”
All it can do is show you the thought processes of good programmers and the tricks, tech-
niques, and tools that they use.
Just like a book on art, this book will be full of details. There will be lots of code.
You’ll see good code and you’ll see bad code. You’ll see bad code transformed into good
code. You’ll see lists of heuristics, disciplines, and techniques. You’ll see example after
example. After that, it’s up to you.
Remember the old joke about the concert violinist who got lost on his way to a perfor-
mance? He stopped an old man on the corner and asked him how to get to Carnegie Hall.
The old man looked at the violinist and the violin tucked under his arm, and said: “Prac-
tice, son. Practice!”
Bibliography
[Beck07]: Implementation Patterns, Kent Beck, Addison-Wesley, 2007.
[Knuth92]: Literate Programming, Donald E. Knuth, Center for the Study of Language
and Information, Leland Stanford Junior University, 1992.
Google
Bookmarks Delicious Digg Facebook StumbleUpon Reddit Twitter
Buy 2 from informIT and
Lisa Crispin Save 35%
Janet Gregory Enter the coupon code
AGILE2009 during checkout.
Agile Testing
A Practical Guide for Testers and Agile Teams
“As agile methods have entered the mainstream, we’ve learned a lot about how the
testing discipline fits into agile projects. Lisa and Janet give us a solid look at available
what to do, and what to avoid, in agile testing.” • Book: 9780321534460
— Ron Jeffries, www.XProgramming.com • Safari Online
“An excellent introduction to agile and how it affects the software test community!” • EBOOK: 0321616928
— Gerard Meszaros, • KINDLE: B001QL5N4K
Agile Practice Lead and Chief Test Strategist at Solution Frameworks, Inc.,
an agile coaching and lean software development consultancy
About the Authors
“In sports and music, people know the importance of practicing technique until it
becomes a part of the way they do things. This book is about some of the most Lisa Crispin specializes in showing
fundamental techniques in software development—how to build quality into code— testers and agile teams how testers
techniques that should become second nature to every development team. The book can add value and how to guide
provides both broad and in-depth coverage of how to move testing to the front of the development with business-facing
development process, along with a liberal sprinkling of real-life examples that bring tests. Since 2003, she’s been a
the book to life.” tester on a Scrum/XP team at ePlan
— Mary Poppendieck, Author of Services, Inc., and frequently leads
Lean Software Development and Implementing Lean Software Development tutorials and workshops on agile
Two of the industry’s most experienced agile testing practitioners and consultants, testing at conferences. Lisa regu-
Lisa Crispin and Janet Gregory, have teamed up to bring you the definitive answers larly contributes articles about agile
to these questions and many others. In Agile Testing, Crispin and Gregory define testing to publications such as Better
agile testing and illustrate the tester’s role with examples from real agile teams. Software magazine, IEEE Software,
They teach you how to use the agile testing quadrants to identify what testing is and Methods and Tools. Lisa also
needed, who should do it, and what tools might help. The book chronicles an agile coauthored Testing Extreme
software development iteration from the viewpoint of a tester and explains the Programming (Addison-Wesley,
seven key success factors of agile testing. 2002) with Tip House.
Readers will come away from this book understanding
Janet Gregory is the founder of
• How to get testers engaged in agile development
DragonFire, Inc., an agile quality
• Where testers and QA managers fit on an agile team process consultancy and training
• What to look for when hiring an agile tester firm. Her passion is helping teams
• How to transition from a traditional cycle to agile development build quality systems. Since 1998,
• How to complete testing activities in short iterations she has worked as a coach and tester
• How to use tests to successfully guide development introducing agile practices into both
large and small companies. Janet is
• How to overcome barriers to test automation
a frequent speaker at agile and test-
This book is a must for agile testers, agile teams, their managers, and their customers. ing software conferences, and she
is a major contributor to the North
American agile testing community.
informit.com/aw
Crispin_book.fm Page 3 Tuesday, November 25, 2008 11:06 AM
Chapter 1
WHAT IS AGILE
TESTING, ANYWAY?
Whole-Team
Agile Values
Approach
What We Mean
What Is Agile by “Agile Testing”
Testing, Anyway?
Like a lot of terminology, “agile development” and “agile testing” mean different
things to different people. In this chapter, we explain our view of agile, which
reflects the Agile Manifesto and general principles and values shared by different
agile methods. We want to share a common language with you, the reader, so
we’ll go over some of our vocabulary. We compare and contrast agile develop-
ment and testing with the more traditional phased approach. The “whole team”
approach promoted by agile development is central to our attitude toward qual-
ity and testing, so we also talk about that here.
A GILE V ALUES
“Agile” is a buzzword that will probably fall out of use someday and make
this book seem obsolete. It’s loaded with different meanings that apply in dif-
ferent circumstances. One way to define “agile development” is to look at the
Agile Manifesto (see Figure 1-1).
Using the values from the Manifesto to guide us, we strive to deliver small
chunks of business value in extremely short release cycles.
3
Crispin_book.fm Page 4 Tuesday, November 25, 2008 11:06 AM
We use the word “agile” in this book in a broad sense. Whether your team is
Chapter 21, “Key
Success Factors,”
practicing a particular agile method, such as Scrum, XP, Crystal, DSDM, or
lists key success FDD, to name a few, or just adopting whatever principles and practices make
factors for agile sense for your situation, you should be able to apply the ideas in this book. If
testing. you’re delivering value to the business in a timely manner with high-quality
software, and your team continually strives to improve, you’ll find useful in-
formation here. At the same time, there are particular agile practices we feel
are crucial to any team’s success. We’ll talk about these throughout the book.
Several core practices used by agile teams relate to testing. Agile program-
mers use test-driven development (TDD), also called test-driven design, to
write quality production code. With TDD, the programmer writes a test for a
tiny bit of functionality, sees it fail, writes the code that makes it pass, and
then moves on to the next tiny bit of functionality. Programmers also write
code integration tests to make sure the small units of code work together as
intended. This essential practice has been adopted by many teams, even those
that don’t call themselves “agile,” because it’s just a smart way to think
through your software design and prevent defects. Figure 1-2 shows a sample
unit test result that a programmer might see.
This book isn’t about unit-level or component-level testing, but these types
of tests are critical to a successful project. Brian Marick [2003] describes
these types of tests as “supporting the team,” helping the programmers know
what code to write next. Brian also coined the term “technology-facing tests,”
tests that fall into the programmer’s domain and are described using pro-
grammer terms and jargon. In Part II, we introduce the Agile Testing Quad-
rants and examine the different categories of agile testing. If you want to
learn more about writing unit and component tests, and TDD, the bibliogra-
phy will steer you to some good resources.
If you want to know how agile values, principles, and practices applied to test-
ing can help you, as a tester, do your best work, and help your team deliver
more business value, please keep reading. If you’ve bothered to pick up this
book, you’re probably the kind of professional who continually strives to grow
and learn. You’re likely to have the mind-set that a good agile team needs to
succeed. This book will show you ways to improve your organization’s prod-
uct, provide the most value possible to your team, and enjoy your job.
Lisa’s Story
During a break from working on this chapter, I talked to a friend who works in
quality assurance for a large company. It was a busy time of year, and management
expected everyone to work extra hours. He said, “If I thought working 100 extra
hours would solve our problems, I’d work ‘til 7 every night until that was done. But
the truth was, it might take 4,000 extra hours to solve our problems, so working
extra feels pointless.” Does this sound familiar?
—Lisa
If you’ve worked in the software industry long, you’ve probably had the op-
portunity to feel like Lisa’s friend. Working harder and longer doesn’t help
when your task is impossible to achieve. Agile development acknowledges
the reality that we only have so many good productive hours in a day or
week, and that we can’t plan away the inevitability of change.
When we say “agile testing” in this book, we’re usually talking about business-
facing tests, tests that define the business experts’ desired features and func-
tionality. We consider “customer-facing” a synonym for “business-facing.”
“Testing” in this book also includes tests that critique the product and focus
on discovering what might be lacking in the finished product so that we can
improve it. It includes just about everything beyond unit and component
level testing: functional, system, load, performance, security, stress, usability,
exploratory, end-to-end, and user acceptance. All these types of tests might
be appropriate to any given project, whether it’s an agile project or one using
more traditional methodologies.
Crispin_book.fm Page 7 Tuesday, November 25, 2008 11:06 AM
Agile testing doesn’t just mean testing on an agile project. Some testing ap-
proaches, such as exploratory testing, are inherently agile, whether it’s done
an agile project or not. Testing an application with a plan to learn about it as
you go, and letting that information guide your testing, is in line with valuing
working software and responding to change. Later chapters discuss agile
forms of testing as well as “agile testing” practices.
Customer Team
The customer team includes business experts, product owners, domain ex-
perts, product managers, business analysts, subject matter experts—every-
one on the “business” side of a project. The customer team writes the stories
or feature sets that the developer team delivers. They provide the examples
that will drive coding in the form of business-facing tests. They communi-
cate and collaborate with the developer team throughout each iteration, an-
swering questions, drawing examples on the whiteboard, and reviewing
finished stories or parts of stories.
Testers are integral members of the customer team, helping elicit require-
ments and examples and helping the customers express their requirements as
tests.
Developer Team
Everyone involved with delivering code is a developer, and is part of the de-
veloper team. Agile principles encourage team members to take on multiple
activities; any team member can take on any type of task. Many agile practi-
tioners discourage specialized roles on teams and encourage all team mem-
bers to transfer their skills to others as much as possible. Nevertheless, each
team needs to decide what expertise their projects require. Programmers,
system administrators, architects, database administrators, technical writers,
security specialists, and people who wear more than one of these hats might
be part of the team, physically or virtually.
Crispin_book.fm Page 8 Tuesday, November 25, 2008 11:06 AM
Testers are also on the developer team, because testing is a central compo-
nent of agile software development. Testers advocate for quality on behalf of
the customer and assist the development team in delivering the maximum
business value.
Some agile teams don’t have any members who define themselves as “testers.”
However, they all need someone to help the customer team write business-
facing tests for the iteration’s stories, make sure the tests pass, and make sure
that adequate regression tests are automated. Even if a team does have testers,
the entire agile team is responsible for these testing tasks. Our experience
with agile teams has shown that testing skills and experience are vital to
project success and that testers do add value to agile teams.
Interaction of Roles
Programmer Domain
Expert
Tester
Our development cycles were generally long. Projects at a company that pro-
duced database software might last for a year. The six-month release cycles
Lisa experienced at an Internet start-up seemed short at the time, although it
was still a long time to have frozen requirements. In spite of much process
and discipline, diligently completing one phase before moving on to the
next, it was plenty of time for the competition to come out ahead, and the
applications were not always what the customers expected.
Crispin_book.fm Page 10 Tuesday, November 25, 2008 11:06 AM
Traditional teams are focused on making sure all the specified requirements
are delivered in the final product. If everything isn’t ready by the original tar-
get release date, the release is usually postponed. The development teams
don’t usually have input about what features are in the release, or how they
should work. Individual programmers tend to specialize in a particular area
of the code. Testers study the requirements documents to write their test
plans, and then they wait for work to be delivered to them for testing.
We’ll share our stories from our first agile experiences to show you that ev-
eryone has to start somewhere.
Lisa’s Story
My first agile team embraced Extreme Programming (XP), not without some “learn-
ing experiences.” Serving as the only professional tester on a team of eight pro-
grammers who hadn’t learned how to automate unit tests was disheartening. The
first two-week iteration felt like jumping off a cliff.
Fortunately, we had a good coach, excellent training, a supportive community of
agile practitioners with ideas to share, and time to learn. Together we figured out
some ins and outs of how to integrate testing into an agile project—indeed, how
to drive the project with tests. I learned how I could use my testing skills and
experience to add real value to an agile team.
The toughest thing for me (the former Quality Boss) to learn was that the custom-
ers, not I, decided on quality criteria for the product. I was horrified after the first
iteration to find that the code crashed easily when two users logged in concur-
rently. My coach patiently explained, over my strident objections, that our cus-
tomer, a start-up company, wanted to be able to show features to potential
customers. Reliability and robustness were not yet the issue.
I learned that my job was to help the customers tell us what was valuable to them
during each iteration, and to write tests to ensure that’s what they got.
—Lisa
Crispin_book.fm Page 11 Tuesday, November 25, 2008 11:06 AM
Janet’s Story
My first foray into the agile world was also an Extreme Programming (XP) engage-
ment. I had just come from an organization that practiced waterfall with some
extremely bad practices, including giving the test team a day or so to test six
months of code. In my next job as QA manager, the development manager and I
were both learning what XP really meant. We successfully created a team that
worked well together and managed to automate most of the tests for the func-
tionality. When the organization downsized during the dot-com bust, I found
myself in a new position at another organization as the lone tester with about
ten developers on an XP project.
On my first day of the project, Jonathan Rasmusson, one of the developers, came
up to me and asked me why I was there. The team was practicing XP, and the pro-
grammers were practicing test-first and automating all their own tests. Participating
in that was a challenge I couldn’t resist. The team didn’t know what value I could
add, but I knew I had unique abilities that could help the team. That experience
changed my life forever, because I gained an understanding of the nuances of an
agile project and determined then that my life’s work was to make the tester role
a more fulfilling one.
—Janet
customer to help write test cases that defined success for upcoming sto-
ries. She paired with developers looking for gaps in tests.
But perhaps most importantly, she helped reinforce an ethos of quality
and culture, dispensing happy-face stickers to those developers who
had done an exceptional job (these became much sought-after badges
of honor displayed prominently on laptops).
Working with Janet taught me a great deal about the role testers play on
agile projects, and their importance to the team.
Agile teams work closely with the business and have a detailed understanding
of the requirements. They’re focused on the value they can deliver, and they
might have a great deal of input into prioritizing features. Testers don’t sit
and wait for work; they get up and look for ways to contribute throughout
the development cycle and beyond.
In the phased approach diagram, it is clear that testing happens at the end,
right before release. The diagram is idealistic, because it gives the impression
there is as much time for testing as there is for coding. In many projects, this
is not the case. The testing gets “squished” because coding takes longer than
expected, and because teams get into a code-and-fix cycle at the end.
Agile is iterative and incremental. This means that the testers test each incre-
ment of coding as soon as it is finished. An iteration might be as short as one
week, or as long as a month. The team builds and tests a little bit of code,
making sure it works correctly, and then moves on to next piece that needs to
be built. Programmers never get ahead of the testers, because a story is not
“done” until it has been tested. We’ll talk much more about this throughout
the book.
There’s tremendous variety in the approaches to projects that agile teams take.
One team might be dedicated to a single project or might be part of another
Crispin_book.fm Page 13 Tuesday, November 25, 2008 11:06 AM
Requirements
Specifications
Code
Testing
Release
Time
Agile:
F Iterative & incremental
E
• Each story is expanded, coded, and tested
D D • Possible release after each iteration
C C C
A B A B A B A B
It 0 It 1 It 2 It 3 It 4
bigger project. No matter how big your project is, you still have to start some-
where. Your team might take on an epic or feature, a set of related stories at an
estimating meeting, or you might meet to plan the release. Regardless of how
a project or subset of a project gets started, you’ll need to get a high-level un-
derstanding of it. You might come up with a plan or strategy for testing as you
prepare for a release, but it will probably look quite different from any test
plan you’ve done before.
Every project, every team, and sometimes every iteration is different. How
your team solves problems should depend on the problem, the people, and
the tools you have available. As an agile team member, you will need to be
adaptive to the team’s needs.
Rather than creating tests from a requirements document that was created by
business analysts before anyone ever thought of writing a line of code, some-
one will need to write tests that illustrate the requirements for each story days
or hours before coding begins. This is often a collaborative effort between a
Crispin_book.fm Page 14 Tuesday, November 25, 2008 11:06 AM
If you attended agile conferences and seminars in the early part of this de-
cade, you heard a lot about TDD and acceptance testing but not so much
about other critical types of testing, such as load, performance, security, us-
ability, and other “ility” testing. As testers, we thought that was a little weird,
because all these types of testing are just as vital on agile projects as they are
on projects using any other development methodology. The real difference is
that we like to do these tests as early in the development process as we can so
that they can also drive design and coding.
If the team actually releases each iteration, as Lisa’s team does, the last day or
two of each iteration is the “end game,” the time when user acceptance test-
ing, training, bug fixing, and deployments to staging environments can oc-
cur. Other teams, such as Janet’s, release every few iterations, and might even
have an entire iteration’s worth of “end game” activities to verify release
readiness. The difference here is that all the testing is not left until the end.
Agile projects have a variety of flavors. Is your team starting with a clean
slate, in a greenfield (new) development project? If so, you might have fewer
challenges than a team faced with rewriting or building on a legacy system
that has no automated regression suite. Working with a third party brings
additional testing challenges to any team.
Whatever flavor of development you’re using, pretty much the same ele-
ments of a software development life cycle need to happen. The difference
Crispin_book.fm Page 15 Tuesday, November 25, 2008 11:06 AM
with agile is that time frames are greatly shortened, and activities happen
concurrently. Participants, tests, and tools need to be adaptive.
The most critical difference for testers in an agile project is the quick feed-
back from testing. It drives the project forward, and there are no gatekeepers
ready to block project progress if certain milestones aren’t met.
An agile team must possess all the skills needed to produce quality code that
delivers the features required by the organization. While this might mean in-
cluding specialists on the team, such as expert testers, it doesn’t limit particu-
lar tasks to particular team members. Any task might be completed by any
team member, or a pair of team members. This means that the team takes re-
sponsibility for all kinds of testing tasks, such as automating tests and man-
ual exploratory testing. It also means that the whole team thinks constantly
about designing code for testability.
Most importantly, on an agile team, anyone can ask for and receive help. The
team commits to providing the highest possible business value as a team, and
the team does whatever is needed to deliver it. Some folks who are new to ag-
ile perceive it as all about speed. The fact is, it’s all about quality—and if it’s
not, we question whether it’s really an “agile” team.
Your situation is unique. That’s why you need to be aware of the potential
testing obstacles your team might face and how you can apply agile values
and principles to overcome them.
Crispin_book.fm Page 17 Tuesday, November 25, 2008 11:06 AM
S UMMARY 17
S UMMARY
Understanding the activities that testers perform on agile teams helps you
show your own team the value that testers can add. Learning the core prac-
tices of agile testing will help your team deliver software that delights your
customers.
In this chapter, we’ve explained what we mean when we use the term “agile
testing.
We showed how the Agile Manifesto relates to testing, with its empha-
sis on individuals and interactions, working software, customer col-
laboration, and responding to change.
We provided some context for this book, including some other terms
we use such as “tester,” “programmer,” “customer,” and related terms
so that we can speak a common language.
We explained how agile testing, with its focus on business value and
delivering the quality customers require, is different from traditional
testing, which focuses on conformance to requirements.
We introduced the “whole-team” approach to agile testing, which
means that everyone involved with delivering software is responsible
for delivering high-quality software.
We advised taking a practical approach by applying agile values and
principles to overcome agile testing obstacles that arise in your
unique situation.
Google
Bookmarks Delicious Digg Facebook StumbleUpon Reddit Twitter
Walker Royce Buy 2 from informIT and
Kurt Bittner Save 35%
Michael Perrow Enter the coupon code
AGILE2009 during checkout.
informit.com/aw
0321509358_royceCh03.qxd:Royce_book.qxd 3/4/09 8:26 PM Page 23
3
• • •
T R E N D S I N S O F T WA R E E C O N O M I C S
Over the past two decades, the software industry has moved progres-
sively toward new methods for managing the ever-increasing com-
plexity of software projects. We have seen evolutions and
revolutions, with varying degrees of success and failure. Although
software technologies, processes, and methods have advanced
rapidly, software engineering remains a people-intensive process.
Consequently, techniques for managing people, technology,
resources, and risks have profound leverage.
The early software approaches of the 1960s and 1970s can
best be described as craftsmanship, with each project using custom
or ad-hoc processes and custom tools that were quite simple in
their scope. By the 1980s and 1990s, the software industry had
matured and was starting to exhibit signs of becoming more of an
engineering discipline. However, most software projects in this era
were still primarily exploring new technologies and approaches
that were largely unpredictable in their results and marked by dis-
economies of scale. In recent years, however, new techniques that
aggressively attack project risk, leverage automation to a greater
degree, and exhibit much-improved economies of scale have
begun to grow in acceptance. Much-improved software economics
23
0321509358_royceCh03.qxd:Royce_book.qxd 3/4/09 8:26 PM Page 24
24 • • • CHAPTER 3 T R E N D S I N S O F T WA R E E C O N O M I C S
A S I M P L I F I E D M O D E L O F S O F T WA R E
ECONOMICS
There are several software cost models in use today. The most popu-
lar, open, and well-documented model is the COnstructive COst
MOdel (COCOMO), which has been widely used by the industry
for 20 years. The latest version, COCOMO II, is the result of a col-
laborative effort led by the University of Southern California (USC)
Center for Software Engineering, with the financial and technical
support of numerous industry affiliates. The objectives of this team
are threefold:
A S I M P L I F I E D M O D E L O F S O F T WA R E E C O N O M I C S • • • 2 5
26 • • • CHAPTER 3 T R E N D S I N S O F T WA R E E C O N O M I C S
S O F T WA R E E N G I N E E R I N G : A 4 0 - Y E A R
HISTORY
S O F T WA R E E N G I N E E R I N G : A 4 0 - Y E A R H I S T O RY • • • 2 7
28 • • • CHAPTER 3 T R E N D S I N S O F T WA R E E C O N O M I C S
Software ROI
Software Complexity
Early Modern
Craftsmanship Software Engineering Software Engineering
Complexity/size:
30% component based 70% component based
100% custom 70% custom 30% custom
Process:
Ad hoc Repeatable Managed/measured
Team:
Predominantly Mix of trained Predominantly
untrained and untrained trained
Environments/tools:
Proprietary Mix of proprietary Commercial and
Not integrated and commercial integrated
Not integrated
K E Y S T O I M P R O V E M E N T: A B A L A N C E D A P P R O A C H • • • 2 9
30 • • • CHAPTER 3 T R E N D S I N S O F T WA R E E C O N O M I C S
SUMMARY
S U M M A RY • • • 3 1
Save 35%
Bruce Powel Douglass Enter the coupon code
AGILE2009 during checkout.
Real-Time Agility
The Harmony/ESW Method for Real-Time and
Embedded Systems Development
“Regardless of your perceptions of agile, this is a must read! Douglass’s book is available
a powerful and practical guide to a well-defined process that will enable engineers
• Book: 9780321545497
to confidently navigate the complexity, risk, and variability of real-time and
• Safari Online
embedded systems–including CMMI compliance. From requirements specification
• EBOOK: 0321617118
to product delivery, whatever your modeling and development environment,
this is the instruction manual.”
–Mark Scoville, Software Architect
About the Author
Real-time and embedded systems face the same challenges as traditional software
Bruce Powel Douglass
development: shrinking budgets and shorter timeframes. However, these systems
is chief evangelist for IBM
can be even more difficult to successfully develop due to additional requirements
Rational, a leading producer
for timeliness, safety, high reliability, minimal resource usage, and, in some cases,
of tools for real-time systems
the need to support rigorous industry standards.
development. He contributed to
In Real-Time Agility, leading embedded-systems consultant Bruce Powel Douglass the original specication of the
reveals how to leverage the best practices of agile development to address all Unified Modeling Language and
these challenges. Douglass introduces the Harmony process: a proven, start-to- is former co-chair of the Object
finish approach to software development that can reduce costs, save time, and Management Group’s Real-Time
eliminate potential defects. Analysis and Design Working
Group. He consults to many
Replete with examples, this book provides an ideal tutorial in agile methods for companies and organizations
real-time and embedded-systems developers. It also serves as an invaluable on building both small- and
reference guide “in the heat of battle” for developers working to advance projects, large-scale, real-time, safety-
both large and small. critical systems. He is the author
Coverage includes of several books showing how
to apply software development
• How Model-Driven Development (MDD) and agile methods work synergistically
best practices in real-time and
• T he Harmony process, including roles, workflows, tasks, and work products embedded systems development,
• Phases in the Harmony microcycle and their implementation including Doing Hard Time,
• Initiating a real-time agile project, including the artifacts you may Real-Time UML, Real-Time
(or may not) need Design Patterns (all from
• Agile analysis, including the iteration plan, clarifying requirements, Addison-Wesley) and Real-Time
and validation UML Workshop for Embedded
Systems (Elsevier).
• T he three levels of agile design–architectural, mechanistic, and detailed
• Continuous integration strategies and end-of-the-microcycle validation testing
• How Harmony’s agile process self-optimizes by identifying and managing
issues related to schedule, architecture, risks, workflows, and the process itself
informit.com/aw
Douglass_ch01.qxd 5/15/09 2:02 PM Page 1
Chapter 1
Different people mean different things when they use the term agile. The term
was first used to describe a lightweight approach to performing project develop-
ment after the original term, Extreme Programming (XP),1 failed to inspire le-
gions of managers entrusted to oversee development projects. Basically, agile
refers to a loosely integrated set of principles and practices focused on getting
the software development job done in an economical and efficient fashion.
This chapter begins by considering why we need agile approaches to soft-
ware development and then discusses agile in the context of real-time and em-
bedded systems. It then turns to the advantages of agile development processes
as compared to more traditional approaches.
1. Note that important acronyms and terms are defined in the Glossary.
2. http://agilemanifesto.org. Martin Fowler gives an interesting history of the drafting
at http://martinfowler.com/articles/agileStory.html.
1
Douglass_ch01.qxd 5/15/09 2:02 PM Page 2
To support these statements, they give a set of 12 principles. I’ll state them
here to set the context of the following discussion:
• Our highest priority is to satisfy the customer through early and continu-
ous delivery of valuable software.
• Business people and developers must work together daily throughout the
project.
Why Agile? 3
agile and XP have been mostly concerned with IT systems and are heavily
code-based. In this book, I will focus on how to effectively harness the mani-
festo’s statements and principles in a different vertical market—namely, real-
time and embedded—and how to combine them with modeling to gain the
synergistic benefits of model-driven development (MDD) approaches.4
Note
Agility isn’t limited to small projects. Agile@Scale is an IBM initiative
to bring the benefits of agility to larger-scale systems and projects. This
initiative includes agile project tool environments such as Rational
Team Concert (RTC; based on the Jazz technology platform). Inter-
ested readers are referred to www-01.ibm.com/software/rational/agile
and www-01.ibm.com/software/rational/jazz/features.
Why Agile?
But why the need for a concept such as “agile” to describe software develop-
ment? Aren’t current software development processes good enough?
No, not really.
A process, in this context, can be defined as “a planned set of work tasks per-
formed by workers in specific roles resulting in changes of attributes, state, or
other characteristics of one or more work products.” The underlying assump-
tions are the following:
• The results of using the process are repeatable, resulting in a product with
expected properties (e.g., functionality and quality).
• The production of the goal state of the work products is highly predictable
when executing the process in terms of the project (e.g., cost, effort, calendar
time) and product (e.g., functionality, timeliness, and robustness) properties.
4. A good place for more information about agile modeling is Scott Ambler’s agile
modeling Web site, www.agilemodeling.com.
Douglass_ch01.qxd 5/15/09 2:02 PM Page 4
Two people stand before a cave. One is the sagely manager of a cave ex-
ploring company whose wisdom is only exceeded by his wit, charm, and
humility. Let’s call him, oh, “Scott.” The other is a cave explorer of inde-
terminate gender who bears no resemblance to any programmers past or
present that this author may have worked with and whose size may be big
or little. Let’s call him/her “Endian.”
“Endian,” said Scott in a sagely voice that was both commanding and
compassionate, “I need you to explore this cave. But before you do, I need
to know how long you think it will take, so that I may build a schedule
and tell the sales team when the cave will be ready.”
“Great Scott,” replied Endian using the title bestowed upon Scott by
his admiring employees, “how can I give you an answer when surely you
know I have never been in this cave before? The cave may be vast, with
deep chasms. It may contain a labyrinth of underwater passages. It may
contain fearsome creatures that must first be vanquished. How can I say
how long it will take to explore?”
Scott pondered Endian’s words and after a thorough analysis that
might have taken days for others but was completed in but a moment for
him, he replied, “Surely this is not the first cave you explored. Are there
no other caves in this district? Use your knowledge of those caves to form
an estimate.”
5. Used with permission of the author, Scott Westfall. The SlickEdit Web site can be
found at http://blog.slickedit.com/?p207.
Douglass_ch01.qxd 5/15/09 2:02 PM Page 5
Why Agile? 5
Endian heard these words and still his doubt prevailed. “Your words
are truly wise,’’ said Endian, “but even within a district the caves may
vary, one from another. Surely, an estimate based on the size of another
cave cannot be deemed accurate.”
“You have spoken truly, good Endian,” replied Scott in a fatherly, sup-
porting tone that lacked any trace of being patronizing as certain cynical
readers may think. “Here, take from me this torch and this assortment of
cheeses that you may explore the cave briefly. Return ere the morrow and
report what you have learned.”
The parable continues like this for pages, as parables are known to do.
Let’s see, Endian enters the cave . . . something about a wretched beast of
surpassing foulness . . . he continues on . . . hmm, that’s what the assort-
ment of cheeses were for. Ah! Here we go.
Endian returns to Scott, his t-shirt ripped and his jeans covered in mud.
Being always concerned with the well-being of his employees, Scott offers
Endian a cool drink, then asks, “Endian, what news of the cave? Have you
an estimate that I can use for my schedule? What shall I tell the sales team?”
Endian considers all that he has seen and builds a decomposition con-
taining the many tasks necessary to explore the cave based on his earlier
reconnoitering. He factors in variables for risk and unknowns, and then
he responds, “Two weeks.”
6. I know I’m dating myself, but my IBM PC was my fifth computer. I still remember
fondly the days of my TRS-80 model I computer with its 4kB of memory . . .
Douglass_ch01.qxd 5/15/09 2:02 PM Page 6
machine did, plus detect a wide range of arrhythmias, track patient data,
produce reports, and measure noninvasive blood pressure, blood oxygen con-
centration, a variety of temperatures, and even cardiac output.
Last, software development is really invention, and invention is not a highly
predictable thing. In electronic and mechanical engineering, a great deal of the
work is conceptually simply putting pieces together to achieve a desired goal,
but in software those pieces are most often invented (or reinvented) for every
project. This is not to oversimplify the problems of electronic or mechanical
design but merely to point out that the underlying physics of those disciplines is
far more mature and well understood than that of software.
But it doesn’t really matter if you believe my explanations; the empirical re-
sults of decades of software development are available. Most products are late.7
Most products are delivered with numerous and often significant defects. Most
products don’t deliver all the planned functionality. We have become used to re-
booting our devices, but 30 years ago it would have been unthinkable that we
would have to turn our phones off, remove the batteries, count to 30, reinsert
the batteries, and reboot our phones.8 Unfortunately, that is the “state of the
art” today.
To this end, many bright people have proposed processes as a means of com-
bating the problem, reasoning that if people engineered software rather than
hacked away at it, the results would be better. And they have, to a large degree,
been better. Nevertheless, these approaches have been based on the premise that
software development can be treated the same as an industrial manufacturing
process and achieve the same results. Industrial automation problems are highly
predictable, and so this approach makes a great deal of sense when the underly-
ing mechanisms driving the process are very well understood and are inherently
linear (i.e., a small change in input results in an equally small change in output).
It makes less sense when the underlying mechanisms are not fully understood or
the process is highly nonlinear. Unfortunately, software development is neither
fully understood nor even remotely linear.
It is like the difference in the application of fuzzy logic and neural networks
to nonlinear control systems. Fuzzy logic systems work by applying the concept
of partial membership and using a centroid computation to determine outputs.
7. See, for example, Michiel van Genuchten, “Why Is Software Late? An Empirical
Study of Reasons for Delay in Software Development,” IEEE Transactions on Soft-
ware Engineering 17, no. 6 (June 1991).
8. Much as I love my BlackBerry, I was amazed that a customer service representative
recommended removing the battery to reboot the device daily.
Douglass_ch01.qxd 5/15/09 2:02 PM Page 7
Why Agile? 7
• Schedules
• Management plans
• Progress reports
And so on.
The idea is that the execution of these tasks and the production of the work
products correlate closely with project timeliness and product functionality and
quality. However, many of the tasks and measures used don’t correlate very
well, even if they are easy to measure. Even when they do correlate well, they
incur extra cost and time.
Agile methods are a reaction in the developer community to the high cost and
effort of these industrial approaches to software development. The mechanisms by
which we invent software are not so well understood as to be highly predictable.
Further, small changes in requirements or architecture can result in huge differ-
ences in development approach and effort. Because of this, empiricism, discipline,
Douglass_ch01.qxd 5/15/09 2:02 PM Page 8
quality focus, and stakeholder focus must all be present in our development
processes. To this end, agile methods are not about hacking code but instead are
about focusing effort on the things that demonstrably add value and defocusing on
efforts that do not.
9. It even had a small file system to manage different pacing and monitoring applications.
Douglass_ch01.qxd 5/15/09 2:02 PM Page 9
custom hardware for which drivers do not exist, but even when they do exist,
they often do not meet the platform constraints. This means that not only must
the primary functionality be developed, but the low-level device drivers must be
written as well.
The real-time nature of many embedded systems means that predictability
and schedulability affect the correctness of the application. In addition, many
such systems have high reliability and safety requirements. These characteristics
require additional analyses, such as schedulability (e.g., rate monotonic analy-
sis, or RMA), reliability (e.g., failure modes and effects analysis, or FMEA),
and safety (e.g., fault tree analysis, or FTA) analysis. In addition to “doing
the math,” effort must be made to ensure that these additional requirements
are met.
Last, a big difference between embedded and traditional applications is the
nature of the so-called target environment—that is, the computing platform on
which the application will run. Most desktop applications are “hosted” (writ-
ten) on the same standard desktop computer that serves as the target platform.
This means that a rich set of testing and debugging tools is available for verify-
ing and validating the application. In contrast, most embedded systems are
“cross-compiled” from a desktop host to an embedded target. The embedded
target lacks the visibility and control of the program execution found on the
host, and most of the desktop tools are useless for debugging or testing the ap-
plication on its embedded target. The debugging tools used in embedded sys-
tems development are almost always more primitive and less powerful than
their desktop counterparts. Not only are the embedded applications more com-
plex (due to the optimization), and not only do they have to drive low-level de-
vices, and not only must they meet additional sets of quality-of-service (QoS)
requirements, but the debugging tools are far less capable as well.
It should be noted that another difference exists between embedded and
“IT” software development. IT systems are often maintained systems that con-
stantly provide services, and software work, for the most part, consists of small
incremental efforts to remove defects and add functionality. Embedded systems
differ in that they are released at an instant in time and provide functionality at
that instant. It is a larger effort to update embedded systems, so that they are
often, in fact, replaced rather than being “maintained” in the IT sense. This
means that IT software can be maintained in smaller incremental pieces than
can embedded systems, and “releases” have more significance in embedded
software development.
A “real-time system” is one in which timeliness is important to correctness.
Many developers incorrectly assume that “real-time” means “real fast.” It clearly
does not. Real-time systems are “predictably fast enough” to perform their tasks.
Douglass_ch01.qxd 5/15/09 2:02 PM Page 10
If processing your eBay order takes an extra couple of seconds, the server
application can still perform its job. Such systems are not usually considered real-
time, although they may be optimized to handle thousands of transactions per
second, because if the system slows down, it doesn’t affect the system’s correct-
ness. Real-time systems are different. If a cardiac pacemaker fails to induce cur-
rent through the heart muscle at the right time, the patient’s heart can go into
fibrillation. If the missile guidance system fails to make timely corrections to its
attitude, it can hit the wrong target. If the GPS satellite doesn’t keep a highly pre-
cise measure of time, position calculations based on its signal will simply be
wrong.
Real-time systems are categorized in many ways. The most common is the
broad grouping into “hard” and “soft.” “Hard” real-time systems exhibit signif-
icant failure if every single action doesn’t execute within its time frame. The
measure of timeliness is called a deadline—the time after action initiation
by which the action must be complete. Not all deadlines must be in the microsec-
ond time frame to be real-time. The F2T2EA (Find, Fix, Track, Target, Engage,
Assess) Kill Chain is a fundamental aspect of almost all combat systems; the end-
to-end deadline for this compound action might be on the order of 10 minutes,
but pilots absolutely must achieve these deadlines for combat effectiveness.
The value of the completion of an action as a function of time is an important
concept in real-time systems and is expressed as a “utility function” as shown in
Figure 1.1. This figure expresses the value of the completion of an action to the
user of the system. In reality, utility functions are smooth curves but are most often
“Utility Function”
Criticality
Importance
Time
Deadline
Urgency
Action
Action A Action W
Alpha
Action B
Action
Action Y
Beta
Action D Action C
Action
Action Z
Gamma
Action E
Synchronization Point
Action
Action F Action X
Zeta
Execution Time
Running
Task State
Blocking
Waiting
Deadline
Period Time
Jitter
between the end of the execution and the deadline is known as the slack time. In
real-time systems, it is important to capture, characterize, and manage all these
task properties.
Real-time systems are most often embedded systems as well and carry those
burdens of development. In addition, real-time systems have timeliness and
schedulability constraints. Real-time systems must be timely—that is, they must
meet their task completion time constraints. The entire set of tasks is said to
be schedulable if all the tasks are timely. Real-time systems are not necessarily
(or even usually) deterministic, but they must be predictably bounded in time.
Methods exist to mathematically analyze systems for schedulability,10 and there
are tools11 to support that analysis.
10. See Doing Hard Time: Developing Real-Time Systems with UML, Objects,
Frameworks, and Patterns and Real-Time UML: Advances in the UML for Real-
Time Systems, both written by me and published by Addison-Wesley (1999 and
2004, respectively).
11. For example, see www.tripac.com for information about the RapidRMA tool.
Douglass_ch01.qxd 5/15/09 2:02 PM Page 14
12. Nancy Leveson, Safeware: System Safety and Computers (Reading, MA: Addison-
Wesley, 1995).
13. See Scott Ambler’s discussion of acceleration metrics at www.ibm.com/developerworks/
blogs/page/ambler?tag=Metrics.
Douglass_ch01.qxd 5/15/09 2:02 PM Page 15
primary goal, but it is key to remember that those activities are secondary and
performed only as a means of achieving your primary goal. Too often, both
managers and developers forget this and lose focus. Many projects spend
significant effort without even bothering to assess whether that effort aids in the
pursuit of the development of the software.
The second most important goal of an agile project is to enable follow-on
software development. This means that the previously developed software must
have an architecture that enables the next set of features or extensions, docu-
mentation so that the follow-on team can understand and modify that software,
support to understand and manage the risks of the development, and an infra-
structure for change and configuration management (CM).
The benefits of agile methods usually discussed are:
• Satisfied stakeholders
• Increased control
• Responsiveness to change
These are real, if sometimes intangible, benefits that properly applied agile
methods bring to the project, the developers, their company, the customer, and
the ultimate user.
Rapid Learning
Rapid learning means that the development team learns about the project earlier
because they are paying attention. Specifically, agile methods focus on early feed-
back, enabling dynamic planning. This is in contrast to traditional approaches
that involve ballistic planning. Ballistic planning is all done up front with the
expectation that physics will guide the (silver) bullet unerringly to its target
Ballistic Planning
Dynamic Planning
(see Figure 1.4). Agile’s dynamic planning can be thought of as “planning to re-
plan.” It’s not that agile developers don’t make plans; it’s just that they don’t
believe their own marketing hype and are willing to improve their plans as more
information becomes available.
Since software development is relatively unpredictable, ballistic planning, for
all its popularity, is infeasible. The advantage of early feedback is that it enables
dynamic planning. A Law of Douglass15 is “The more you know, the more you
know.” This perhaps obvious syllogism means that as you work through the proj-
ect, you learn. This deeper understanding of the project enables more accurate
predictions about when the project will be complete and the effort the project will
require. As shown in Figure 1.5, the ongoing course corrections result in decreas-
ing the zone of uncertainty.
Waterfall
Agile Process
Process
% Value Returned
Time
delivers all-or-none functionality at the end point, and the former delivers
incremental functionality frequently throughout the duration of the develop-
ment. As you can see in Figure 1.6, agile delivers high value early, with less
incremental value as the system becomes increasingly complete, whereas the
waterfall process delivers nothing until the end.
Another way to view this is by looking at incremental value over time, as
shown in Figure 1.7. We see that an agile process delivers increasing value over
time, whereas the waterfall process delivers no value until the end.
Delivering value early is good for a couple of reasons. First, if the funding is re-
moved or the project must end early, something of value exists at the point of ter-
mination. This is not true for the waterfall process, but it is a primary value in an
agile process. Additionally, delivering validated, if partial, functionality early
Douglass_ch01.qxd 5/15/09 2:02 PM Page 18
Waterfall
Process
Agile
Incremental Value
Process
Returned
Time
Waterfall
Process
Risk
Agile
Process
Time
reduces risk, as we see in Figure 1.8. Exactly how early deliveries do this is a topic
we will discuss in more detail later, but let us say for now that because we validate
each incremental build and we tend to do high-risk things early, we significantly
and quickly reduce the project risk. The waterfall process reduces risk slowly at
first because you only really know about the quality and correctness of things that
you validate, and validation comes only at the end in a waterfall process.
How can we return incremental value for a system that is delivered exter-
nally, such as a cell phone or a missile? Every increment period (which the
Harmony/ESW16 process refers to as a microcycle), a system is designed,
implemented, and validated in accordance with its mission statement. This mis-
sion statement identifies the functionality, target platform, architectural intent,
and defect repairs to be included. The incremental functionality is organized
16. Harmony/Embedded Software. This is one of the members of the IBM Rational Har-
mony family of processes and is the basis of the content of this book. The process
basics will be discussed at some length in Chapter 3.
Douglass_ch01.qxd 5/15/09 2:02 PM Page 19
around a small set of use cases running on an identified (but not necessarily
final) target environment. Through the use of good engineering practice, we can
encapsulate away the platform details and ensure that the delivered functional-
ity is correct, given the current target. For example, for one tracking system,
our team originally targeted laptops with simulated radars and created actual
validated functionality on that environment. Over the course of the project, as
hardware became available, we migrated to target hardware of the actual mili-
tary systems. Through this approach, we had high-quality, testable software
earlier than expected.
Satisfied Stakeholders
Stakeholders are simply people who have a stake in the successful outcome of a
project. Projects have all kinds of stakeholders. Customers and marketers are
focused on the functional benefits of the system and are willing to invest real
money to make it happen. Their focus is on specifying to the developers the
needs of the users in a realistic and effective fashion. Managers are stakeholders
who manage that (real or potential) investment for the company to achieve a
timely, cost-effective delivery of said functionality. Their job is to plan and
schedule the project so that it can be produced to satisfy the customer and meet
the users’ needs. The users are the ones who use the system in their work envi-
ronment and need high-quality functionality that enables their workflow to be
correct, accurate, and efficient. All these stakeholders care about the product
but differ in the focus of their concern. The customers care how much they pay
for the system and the degree to which it improves the users’ work. The man-
agers primarily care how much the system costs to develop and how long that
effort takes. The users primarily care about the (positive) impact the system
makes on their work.
Agile methods provide early visibility to validated functionality. This func-
tionality can be demonstrated to the stakeholders and even delivered. This is in
stark contrast to traditional preliminary design review (PDR) and critical design
review (CDR) milestones in which text is delivered that describes promised
functionality in technological terms. Customers can—and should—be involved
in reviewing the functionality of the validated incremental versions of the sys-
tem. Indeed, the functionality can be implemented using a number of different
strategies, depending on what the process optimization criterion is. Possible cri-
teria include the following:
• Highest-risk first
• Infrastructure first
All other things being equal, we prefer to deliver high-risk first, because this
optimizes early risk reduction. However, if the users are to deploy early versions
of the system, then criticality-first makes more sense. In some cases, we deploy
architectural infrastructure early to enable more complex functionality or prod-
uct variations. And sometimes we don’t have all the necessary information at
our fingertips before we must begin, so the things we don’t know can be put off
until the necessary information becomes available.
Improved Control
Many, if not most, software projects are out of control, to some degree or
another. This is largely because although projects are planned in detail, they
aren’t tracked with any rigor. Even for those projects that are tracked, tracking
is usually done on the wrong things, such as SLOC delivered. Thus most proj-
ects are either not tracked or track the wrong project properties.
Project tracking requires the answers to three questions:
• Why track?
Why track? Project teams that don’t know exactly why they are tracking
project properties rarely do a good job. Only by identifying the goals of track-
ing can you decide what measures should be tracked and how to implement the
tracking procedures.
The biggest single reason for project tracking is that plans are always
made in the presence of incomplete knowledge and are therefore inaccurate
to some degree. Tracking enables the project deviance from plan to be identi-
fied early enough to effectively do something about it. Projects should be
tracked so that they can be effectively managed, replanned as appropriate,
and even scrapped if necessary. You can effectively replan only when you
know more than you did when the original plan was made, and that infor-
mation can come from tracking the right things. Put another way, the funda-
mental purpose of tracking is to reduce uncertainty and thereby improve
project control.
Douglass_ch01.qxd 5/15/09 2:02 PM Page 21
Responsiveness to Change
Life happens, often in ways that directly conflict with our opinions about how it
ought to happen. We make plans using the best available knowledge, but that
knowledge is imprecise and incomplete and in some cases just wrong. The impre-
cision means that small incremental errors due to fuzziness in the data can add up
to huge errors by the end of the project—the so-called butterfly effect in chaos
theory.17 Chaos theory is little more than the statement that most systems are
17. See Edward N. Lorenz, The Essence of Chaos (The Jessie and John Danz Lecture
Series) (Seattle: University of Washington Press, 1996).
Douglass_ch01.qxd 5/15/09 2:02 PM Page 22
actually nonlinear; by nonlinear we mean that small causes generate effects that
are not proportional to their size. That sums up software development in a nut-
shell: a highly nonlinear transfer function of user needs into executable software.
The incompleteness problem means that not only do we not know things
very precisely, but some things we don’t know at all. I remember one project in
which I was working on a handheld pacemaker program meant to be used
by physicians to monitor and configure cardiac pacemakers. It was a based on
a Z-80-based embedded microcomputer with a very nice form factor and
touch screen. The early devices from the Japanese manufacturer provided a
BIOS to form the basis of the computing environment. However, once the
project began and plans were all made, it became apparent that the BIOS
would have to be rewritten for a variety of technically inobvious reasons.
Documentation for the BIOS was available from the manufacturer—but only
in Japanese. The technical support staff was based in Tokyo and spoke only—
you guessed it—Japanese. This little bit of missing information put the project
months behind schedule because we had to reverse-engineer the documenta-
tion from decompiling the BIOS. It wouldn’t be so bad if that was the only
time issues like that came up, but such things seem to come up in every project.
There’s always something that wasn’t planned on—a manufacturer canceling a
design, a tool vendor going out of business, a key person being attracted away
by the competition, a change in company focus, defects in an existing product
sucking up all the development resources, . . . the list goes on and on.
Worst, in some way, is that knowledge you have about which you are both
convinced and incorrect. This can be as varied as delivery dates, effort to per-
form tasks, and availability of target platforms. We all make assumptions, and
the law of averages dictates that when we make 100 guesses, each of which is
90% certain, 10 are still likely to be wrong.
Despite these effects of nonlinearity, incompleteness, and incorrectness, we
still have to develop systems to meet the stakeholders’ needs at a cost they’re
willing to pay within the time frames that meet the company’s schedules. So in
spite of the nonlinearity, we do our best to plan projects as accurately as possi-
ble. And how well do we do that? The answer, from an industry standpoint, is
“not very well at all.”
The alternative to plan-and-pray is to plan-track-replan. Agile methods ac-
cept that development plans are wrong at some level and that you’ll need
to adjust them. Agile methods provide a framework in which you can capture
the change, adjust the plans, and redirect the project at a minimal cost and
effort. The particular agile approach outlined in this book, known as the
Harmony/ESW process, deals with work at three levels of abstraction, as
shown in Figure 1.9.
Douglass_ch01.qxd 5/15/09 2:02 PM Page 23
Deployment
Macrocycle
Stakeholder Focus Optimization
Secondary Concept
Months
Key Concept
Project Plan
Microcycle
Demo-able
Team Focus
or
Shippable
Build
Weeks
Iteration Plan
Nanocycle
Personal Focus
Revision of
Work Items
Hours
Project Work Item
18. Also known as the “party phase” because it is not only a review, but also a “celebra-
tion of ongoing success”—as opposed to a postmortem, which is an analysis designed
to discover why the patient died.
Douglass_ch01.qxd 5/15/09 2:02 PM Page 24
case will be less than in a traditional “Oh, God, I hope this works” development
approach. In agile methods this kind of an experiment is known as a spike.21
The risk list is a dynamic document that is reviewed at least every iteration
(during the party phase22). It is updated as risks are reduced, mitigated, or dis-
covered. Because we’re focusing attention on risk, we can head off an undesir-
able situation before it surprises us.
Planning
It is a common and well-known problem in numerical analysis that the preci-
sion of a computational result cannot be better than that of the elements
used within the computation.24 I have seen schedules for complex system de-
velopment projects that stretch on for years yet identify the completion time
to the minute. Clearly, the level of knowledge doesn’t support such a precise
conclusion. In addition (pun intended J), errors accumulate during compu-
tations; that is, a long computation compounds the errors of its individual
terms.
If you are used to working in a traditional plan-based approach, agile meth-
ods may seem chaotic and intimidating. The problem with the standard water-
fall style is that although plans may be highly detailed and ostensibly more
complete, that detail is wrong and the computed costs and end dates are in error.
Further, not only is the information you have about estimates fuzzy at best, it
is also usually systematically biased toward the low end. This is often a result of
management pressure for a lower number, with the misguided intention of pro-
viding a “sense of urgency” to the developers. Sometimes this comes from engi-
neers with an overdeveloped sense of optimism. Maybe it comes from the
marketing staff who require a systematic reduction of the schedule by 20%, re-
gardless of the facts of the matter. In any event, a systematic but uncorrected
bias in the estimates doesn’t do anything but further degrade the accuracy of
the plan.
Beyond the lack of precision in the estimates and the systematic bias, there is
also the problem of stuff you don’t know and don’t know that you don’t know.
Things go wrong on projects—all projects. Not all things. Not even most things.
But you can bet money that something unexpected will go wrong. Perhaps a team
member will leave to work for a competitor. Perhaps a supplier will stop producing
a crucial part and you’ll have to search for a replacement. Maybe as-yet-unknown
errors in your compiler itself will cause you to waste precious weeks trying to find
the problem. Perhaps the office assistant is really a KGB25 agent carefully placed to
bring down the Western economy by single-handedly intercepting and losing your
office memo.
It is important to understand, deep within your hindbrain, that planning the
unknown entails inherent inaccuracy. This doesn’t mean that you shouldn’t plan
software development or that the plans you come up with shouldn’t be as accu-
rate as is needed. But it does mean that you need to be aware that they contain
errors.
Because software plans contain errors that cannot be entirely removed,
schedules need to be tracked and maintained frequently to take into account the
“facts on the ground.” This is what we mean by the term dynamic planning—it
is planning to track and replan when and as necessary.
Depth-First Development
If you look at a traditional waterfall approach, such as is shown in Figure 1.10,
the process can be viewed as a sequential movement through a set of layers. In the
traditional view, each layer (or “phase”) is worked to completion before moving
on. This is a “breadth-first” approach. It has the advantage that the phase and the
artifacts that it creates are complete before moving on. It has the significant disad-
vantage that the basic assumption of the waterfall approach—that the work
within a single phase can be completed without significant error—has been
shown to be incorrect. Most projects are late and/or over budget, and at least part
of the fault can be laid at the feet of the waterfall lifecycle.
An incremental approach is more “depth-first,” as shown in Figure 1.11.
This is a “depth-first” approach (also known as spiral development) because
only a small part of the overall requirements are dealt with at a time; these
are detailed, analyzed, designed, and validated before the next set of require-
ments is examined in detail.26 The result of this approach is that any defects
in the requirements, through their initial examination or their subsequent im-
plementation, are uncovered at a much earlier stage. Requirements can be se-
lected on the basis of risk (high-risk first), thus leading to an earlier reduction
in project risk. In essence, a large, complex project is sequenced into a series
of small, simple projects. The resulting incremental prototypes (also known
as builds) are validated and provide a robust starting point for the next set of
requirements.
26. The astute reader will notice that the “implementation” phase has gone away. This is
because code is produced throughout the analysis and design activities—a topic we
will discuss in much more detail in the coming chapters.
Douglass_ch01.qxd 5/15/09 2:02 PM Page 28
First
Requirements
Analysis
Second
Design
Implementation
Test
Final Build
Put another way, we can “unroll” the spiral approach and show its progress
over linear time. The resulting figure is a sawtooth curve (see Figure 1.12) that
shows the flow of the phases within each spiral and the delivery at the end of each
iteration. This release contains “real code” that will be shipped to the customer.
The prototype becomes increasingly complete over time as more requirements
and functionality are added to it during each microcycle. This means not only
Douglass_ch01.qxd 5/15/09 2:02 PM Page 29
Second
Requirements
Analysis
Design
Test
Release
Time
that some, presumably the high-risk or most critical requirements, are tested first,
but also that they are tested more often than low-risk or less crucial requirements.
Test-Driven Development
In agile approaches, testing is the “stuff of life.” Testing is not something done
at the end of the project to mark a check box, but an integral part of daily
work. In the best case, requirements are delivered as a set of executable test
cases, so it is clear whether or not the requirements are met. As development
proceeds, it is common for the developer to write the test cases before writing
the software. Certainly, before a function or class is complete, the test cases
exist and have been executed. As much as possible, we want to automate this
testing and use tools that can assist in creating coverage tests. Chapter 8 deals
with the concepts and techniques for agile testing.
Embracing Change
Unplanned change in a project can occur either because of the imprecision of
knowledge early in the project or because something, well, changed. Market con-
ditions change. Technology changes. Competitors’ products change. Develop-
ment tools change. We live in a churning sea of chaotic change, yet we cope.
Remember when real estate was a fantastic investment that could double your
money in a few months? If you counted on that being true forever and built long-
range inflexible plans based on that assumption, then you’re probably reading
this while pushing your shopping cart down Market Street in San Francisco look-
ing for sandwiches left on the curb. We cope in our daily lives because we know
that things will change and we adapt. This doesn’t mean that we don’t have goals
and plans but that we adjust those goals and plans to take change into account.
Embracing change isn’t just a slogan or a mantra. Specific practices enable
that embracement, such as making plans that specify a range of successful
states, means by which changing conditions can be identified, analyzed, and
adapted to, and methods for adapting what we do and how we do it to become
as nimble and, well, agile, as possible.
In the final analysis, if you can adapt to change better than your competitors,
then evolution favors you.27
27. As the saying goes, “Chance favors the prepared mind.” I forget who said it first, but
my first exposure to it was Eric Bogosian in Under Siege 2: Dark Territory (Warner
Bros., 1995).
Douglass_ch01.qxd 5/15/09 2:02 PM Page 31
Coming Up 31
Coming Up
This chapter provided some basic background information to prepare you for
the rest of the book. Agile approaches are important because of the increasing
burden of complexity and quality and the formidable constraint of a decreasing
time to market. Following the discussion of the need for agility, the context of
real-time systems was presented. The basic concepts of timeliness, such as exe-
cution time, deadline, blocking time, concurrency unit, criticality, and urgency,
are fundamental to real-time systems. Understanding them is a prerequisite to
understanding how agile methods can be applied to the development of such
systems. The discussion went on to the actual benefits of agile methods, such as
lowered cost of development, improved project control, better responsiveness
to change, and improved quality. Finally, agile and traditional methods were
briefly compared and contrasted. Agile methods provide a depth-first approach
that embraces change and provides a continual focus on product quality.
The next chapter will introduce the concepts of model-driven development.
Although not normally considered “agile,” MDD provides very real benefits in
terms of conceptualizing, developing, and validating systems. MDD and agile
methods work synergistically to create a state-of-the-art development environ-
ment far more powerful than either is alone.
Chapter 3 introduces the core principles and practices of the Harmony/ESW
process. These concepts form the repeated themes that help define and under-
stand the actual roles, workflows, tasks, and work products found in the
process.
Then, in Chapter 4, the Harmony/ESW process itself is elaborated, including
the roles, workflows, and work products. Subsequent chapters detail the phases
in the Harmony/ESW microcycle and provide detailed guidance on the imple-
mentation of those workflows.
Google
Bookmarks Delicious Digg Facebook StumbleUpon Reddit Twitter
Pollyanna Pixton
Niel Nickolaisen Buy 2 from informIT and
Todd Little Save 35%
Kent McDonald Enter the coupon code
AGILE2009 during checkout.
C H A P T E R 1
Have you ever done things by the book, but the book was out of print?
Such was the case for a large, successful product company. This company
had developed what it considered to be a revolutionary new product. With
its heavy engineering background, the company did product development
by the book—the way it had worked many times before.
Through its research and development activities, the company had dis-
covered that it could use a waste material as the basic raw material for a
new product. Imagine the possibilities: Currently the company pays to dis-
pose of this material, but now it could use this “waste material” to make an
industrial product. The company did what it had always done. It selected
one of its best engineers to sort through the product design and manufac-
turing options. It set up the engineer with all of the development and test-
ing equipment he would need. It gave the engineer the time and flexibili-
ty he needed to design what he thought the market needed.
Within a year, the engineer had perfected a formulation that worked.
The resulting product had impressive characteristics. It had high worka-
bility and could be formed into various shapes and sizes. The engineer pro-
duced small batches of the product that the company used to generate
early customer interest. Using these small batches, the company formed
several industry joint ventures and alliances. The future looked bright.
The engineer next worked on the manufacturing processes needed to
produce the product. In parallel with this effort, the company issued press
1
001_0321572882_ch01.qxd 5/27/09 4:08 PM Page 2
releases and featured the new product in its annual report: “Coming soon,
a revolutionary, green product.” One year later, the engineer announced
that his work was done. He documented the product formulation. He
described in great detail how to scale the manufacturing process from the
small batches he had created to full-scale production. The company built
the first of what it planned would be multiple manufacturing plants and
hired a plant manager to follow the engineer’s scale-up process. In the
meantime, the market waited for the formal product release. The company
hired a dedicated sales force to start generating interest in the product. The
development engineer was promoted and assigned to a different project.
Five months later, the first manufacturing plant came on line. As the
first full-size batches of the product came out of processing and into pack-
aging, problems arose. When subjected to full-sized manufacturing, the
product had tiny cracks. In the small batches prepared by the development
engineer, there had never been any cracks. In expanding the product batch
size by a factor of 10, however, there they were—tiny cracks. At first, no
one gave the cracks much thought, because they did not affect the product
characteristics or performance. But then the company shipped its first
order. As the delivery truck rolled down the road, the cracks propagated
throughout the product. By the time the truck arrived at the customer’s
facility, some of the product had broken into pieces. After two years of
engineering and five months of manufacturing scale-up, the company had
a great product, so long as it did not have to ship the product to anyone!
In retrospect, it is easy to identify some of the mistakes this company
made. We have spent hours with groups dissecting this true story to learn
from—and to not repeat—the mistakes of the past. The development engi-
neer developed the product in isolation and did not think through scale-up
issues. The company did not produce any full-sized product samples until
after it had built the manufacturing plant and then discovered the propaga-
tion of the cracks. It is easy to mock management for the wasted investment.
Before being too critical, however, we should consider this point: If the
final product had not developed the tiny cracks that spread during ship-
ping, the product and the process would have been a success. In fact, many
times previously, the company had used a similar process and gotten good
results. Using what had worked before, those involved in this project were
clueless about the risks that lurked in the shadows of their process. What is
now obvious to us became obvious to them only after this product failure.
The most important lesson we can draw from this story is that we, too,
are brilliant but sometimes clueless. We live in an environment of increas-
ing global competition, an increasing pace of market changes, and a need
to develop solutions that are increasingly complex. In this environment, we
001_0321572882_ch01.qxd 5/27/09 4:08 PM Page 3
do not have the luxury of missteps and hidden risks. There is increasing
pressure to deliver complex solutions in less time and to get it “right the
first time.” If we don’t, we can completely miss our business value goals.
The good news is that we can make sure that our brilliance results in things
that work. To see how, we continue our story.
For example, the team could delay the go/kill decision until after the
members had determined whether there was a form factor the market was
dying to have. Likewise, the team could delay research into the cause of
the large-batch cracking if the market would accept form factors that could
be made with small batch sizes. To explore these issues further, the team
members signed up for the assignments that best matched their interests
and capabilities.
Over the next few weeks, the team worked through the assignments
and options. Based on the work of the sales team and the early-adopter cus-
tomer, the team revised the form factor. The new form factor actually met
a previously unknown—at least to the company—market need. Revising
the form factor enabled the company to manufacture the product in the
small batch sizes it could produce without cracks. Taking this approach let
the company retain most of its current investment in the manufacturing
plant; it just needed to redesign its consumable molds. The team members
took a more measured approach by eliminating uncertainty and complexi-
ty at each step of the process. They solved the problems they could when
they could and postponed work on the most uncertain and complex issues.
Because the product was not “right the first time,” the expected rev-
enue was delayed. Also, because of the initial problems, the revenue
stream grew more slowly than projected. Nevertheless, the company
learned the value of the foundation tools of agile leadership.
We were all sitting around one afternoon talking about this story. Each of
us found ourselves identifying a different aspect of the story that we
thought was the cause of all the travails of the organization.
We identified the initial failure of the organization to properly align its
approach to the project with its true strategic nature.
We also determined that, initially, the organization did not properly
lead collaboration; in fact, it did not initially have any collaboration on this
particular project.
We found that the organization chose the wrong approach for the
project, tackling a very complex project filled with uncertainty with a
process more suited for a low-complexity and low-uncertainty project. It
also assigned a leader who did not recognize the uncertainties and the
complexities.
001_0321572882_ch01.qxd 5/27/09 4:08 PM Page 6
We realized that the organization did not gather all of the information
it needed to make proper decisions about how to market the product and
in which markets to sell the product. We also identified several cases where
the company made commitments earlier than it needed to, especially with
potential customers and industry partners.
As we talked about this case more, we realized that there was no one
cause for the project’s initial problems, but rather several contributing fac-
tors. When we discussed the various tools we would have used to help the
company, we realized that while each tool was powerful in its own right, when
put together the entire toolset could really help an organization succeed.
What are the tools we would use to address the situation described earlier
in this chapter? Through our experiences and sharing stories, we found
that a collection of tools apply to how organizations approach their work,
especially work that involves change and innovation; when used in moder-
ation and in conjunction with each other, these tools can have a dramatic
impact on the success of the organization. We drew the “napkin drawing”
shown in Figure 1.1 to capture our thoughts, and we chose to organize this
book around four main applications of those tools.
Purpose
The Purpose Alignment Model, described in Chapter 2, generates imme-
diately usable decision filters that leaders and teams can use to improve
design. This tool evaluates business activities and options in terms of their
capability to differentiate an organization’s products and services in the
marketplace and their mission criticality. This tool helps teams identify
areas to focus their creativity and those activities and features for which
“good enough” is good enough. This approach lowers direct and opportu-
nity costs and accelerates market leadership. This simple, yet powerful,
concept recognizes that not all activities should be treated in the same way.
Some activities will help the organization win in the marketplace; others
will help keep it in the game. We risk under- and over-investing in activi-
ties if we treat all of them as if they were identical.
001_0321572882_ch01.qxd 5/27/09 4:08 PM Page 7
Collaboration
As the proverb states, “No one of us is as smart as all of us.” The proper use of
the tools described in this book is dependent on a culture of collaboration. In
the story presented earlier in this chapter, when a single person developed a
product, it took more than two years to produce something that did not
work. When a leader considered purpose, business value, uncertainty, and
001_0321572882_ch01.qxd 5/27/09 4:08 PM Page 8
Delivery
Delivery is the ultimate measure of success. Any experienced leader knows
that all projects are not created equal and no single approach is applicable
to every project. The tool described in Chapter 4 provides a practical
model for evaluating uncertainty and complexity as well as guidance for tai-
loring an appropriate leadership approach. The characterization of uncer-
tainty and complexity also correlates to project risk, and we provide a
roadmap for potentially reducing risk. For example, it is possible to break
projects that are both highly complex and uncertain into components with
lower uncertainty and risk. This process reduces the overall project risk.
An understanding of complexity and risk also allows leadership to match
the skills of project leaders to the needs of the project.
Here are the big ideas of Chapter 4:
Summary 9
Decisions
The tools we describe in this book will help you to make the key decisions
you face on a regular basis, but we felt it important to discuss the actual
approach to decision making. Knowing when to make your decisions and
which information you need to make those decisions is very important.
Chapter 5 introduces the value model tool, which provides a structure for
organizing information—such as purpose, considerations, costs, and bene-
fits—that you can use to aid your decision making.
Here are the big ideas of Chapter 5:
Summary
This chapter introduced the issues involved in involving the right players
in your organization to gain a competitive advantage. It also introduced the
framework of concepts and tools for doing so.
Google
Bookmarks Delicious Digg Facebook StumbleUpon Reddit Twitter
Buy 2 from informIT and
Save 35%
Jim Highsmith Enter the coupon code
AGILE2009 during checkout.
Today, the pace of project management moves faster. Project management needs
to become more flexible and far more responsive to customers. Using Agile available
Project Management (APM), project managers can achieve all these goals without • Book: 9780321658395
compromising cost, quality, or business discipline. In Agile Project Management, • Safari Online
Second Edition, renowned Agile pioneer Jim Highsmith thoroughly updates his • EBOOK: 0321659228
classic guide to APM, extending and refining it to support even the largest projects
and organizations.
About the Author
Writing for project leaders, managers, and executives at all levels, Highsmith
integrates the best project management, manufacturing, and software development Jim Highsmith is a founding
practices into an overall framework designed to support unprecedented speed member of the AgileAlliance,
and mobility. The many topics added in this new edition include incorporating co-author of the Agile Manifesto,
agile values, scaling Agile projects, release planning, portfolio governance, and and director of the Agile Project
enhancing organizational agility. Project and business leaders will especially Management Advisory Service
appreciate Highsmith’s new coverage of promoting agility through performance for the Cutter Consortium. He
measurements based on value, quality, and constraints. consults with development
organizations throughout the
This edition’s coverage includes:
U.S., Europe, Canada, South
• Understanding the Agile revolution’s impact on product development Africa, Australia, Japan, India,
• Recognizing when Agile methods will work in project management, and New Zealand on accelerating
and when they won’t development in today’s
• S etting realistic business objectives for Agile Project Management increasingly complex, uncertain
• Promoting Agile values and principles across the organization environments. Highsmith is
author of Adaptive Software
• Utilizing a proven Agile Enterprise Framework that encompasses
Development, winner of the 2000
governance, project and iteration management, and technical practices
Jolt Award, and (with Alistair
• Optimizing all five stages of the Agile project: Envision, Speculate, Cockburn) co-editor of The Agile
Explore, Adapt, and Close Software Development Series.
• Organizational and product-related processes for scaling Agile to the He has more than 25 years’
largest projects and teams experience as an IT manager,
• Agile project governance solutions for executives and management product manager, project
• T he “Agile Triangle”: measuring performance in ways that encourage manager, consultant,
agility instead of discouraging it and software developer.
• T he changing role of the Agile project leader
informit.com/aw
05_0321502752_ch04.qxd 6/17/09 12:39 PM Page 63
Chapter 4
Adapting over
Conforming
When customer value and quality are the goals, then a plan becomes a
means to achieve those goals, not the goal itself. The constraints embedded
in those plans are still important; they still guide the project; we still want to
understand variations from the plans, but—and this is a big but—plans are
not sacrosanct; they are meant to be flexible; they are meant to be guides,
not straightjackets.
(http://www.standishgroup.com/chaos_resources/chronicles.php).
• 63 •
05_0321502752_ch04.qxd 6/17/09 12:39 PM Page 64
Both traditional and agile leaders plan, and both spend a fair amount of
time planning. But they view plans in radically different ways. They both
believe in plans as baselines, but traditional managers are constantly trying
to “correct” actual results to that baseline. In the PMBOK2, for example,
the relevant activity is described as “corrective action” to guide the team
back to the plan. In agile project management, we use “adaptive action” to
describe which course of action to take (and one of those actions may be to
correct to the plan).
The agile principles documents—the Agile Manifesto and the Declara-
tion of Interdependence—contain five principle statements about adapta-
tion, as shown in Figure 4-1.
Figure 4-1
Adaptive Principle Adaptive Principle Statements
Statements
(DOI) We expect uncertainty and manage for it through
iterations, anticipation, and adaptation.
(DOI) We improve effectiveness and reliability through
situationally specific strategies, processes, and practices.
(AM) Responding to change over following a plan.
(AM) Welcome changing requirements, even late in
development. Agile processes harness change for the
customer's competitive advantage.
(AM) At regular intervals, the team reflects on how to
become more effective, and then tunes and adjusts its
behavior accordingly
2
The Project Management Institute’s Project Management Body of Knowledge, known as
the PMBOK.
age features so customers feel they have software specifically customized for
them (and the cost to maintain the software remains low).
Teams must adapt, but they can’t lose track of the ultimate goals of the
project. Teams should constantly evaluate progress, whether adapting or
anticipating, by asking these four questions:
The dictionary defines change as: “To cause to be different, to give a com-
pletely different form or appearance to.” It defines adapt as: “To make suit-
able to or fit for a specific use or situation.” Changing and adapting are not
the same and the difference between them is important. There is no goal
inherent in change—as the quip says, “stuff happens.” Adaptation, on the
other hand, is directed towards a goal (suitability). Change is mindless;
adaptation is mindful.
In the last two decades a vanguard of scientists and managers have artic-
ulated a profound shift in their view about how organisms and organizations
evolve, respond to change, and manage their growth. Scientists’ findings
about the tipping points of chemical reactions and the “swarm” behavior of
ants have given organizational researchers insights into what makes success-
ful companies and successful managers. Practitioners have studied how
innovative groups work most effectively.
As quantum physics changed our notions of predictability and Darwin
changed our perspective on evolution, complex adaptive systems (CAS) the-
ory has reshaped scientific and management thinking. In an era of rapid
change, we need better ways of making sense of the world around us. Just as
biologists now study ecosystems as well as species, executives and managers
need to understand the global economic and political ecosystems in which
their companies compete.
rules, on the other hand, often become bureaucratic. How these rules are
formulated has a significant impact on how the complex system operates.
Newtonian approaches predict results. CAS approaches create emer-
gent results. “Emergence is a property of complex adaptive systems that cre-
ates some greater property of the whole (system behavior) from the
interaction of the parts (self-organizing agent behavior). Emergent results
cannot be predicted in the normal sense of cause and effect relationships,
but they can be anticipated by creating patterns that have previously pro-
duced similar results” (Highsmith 2000). Creativity and innovation are the
emergent results of well functioning agile teams.
An adaptive development process has a different character from an
optimizing one. Optimizing reflects a basic prescriptive Plan-Design-Build
lifecycle. Adapting reflects an organic, evolutionary Envision-Explore-
Adapt lifecycle. An adaptive approach begins not with a single solution, but
with multiple potential solutions (experiments). It explores and selects the
best by applying a series of fitness tests (actual product features or simula-
tions subjected to acceptance tests) and then adapting to feedback. When
uncertainty is low, adaptive approaches run the risk of higher costs. When
uncertainty is high, optimizing approaches run the risk of settling too early
on a particular solution and stifling innovation. The salient point is that
these two fundamental approaches to development are very different, and
they require different processes, different management approaches, and dif-
ferent measurements of success.
Newtonian versus quantum, predictability versus flexibility, optimiza-
tion versus adaptation, efficiency versus innovation—all these dichotomies
reflect a fundamentally different way of making sense about the world and
how to manage effectively within it. Because of high iteration costs, the tra-
ditional perspective was predictive and change averse, and deterministic
processes arose to support this traditional viewpoint. But our viewpoint
needs to change. Executives, project leaders, and development teams must
embrace a different view of the new product development world, one that
not only recognizes change in the business world, but also understands the
power of driving down iteration costs to enable experimentation and emer-
gent processes. Understanding these differences and how they affect prod-
uct development is key to understanding APM.
Exploring
Agility is the ability to both create and respond to change in order to profit
in a turbulent business environment (from Chapter 1). The ability to
respond to change is good. The ability to create change for competitors is
even better. When you create change you are on the competitive offensive.
When you respond to competitors’ changes you are on the defensive. When
you can respond to change at any point in the development lifecycle, even
late, then you have a distinct advantage.
3 This
sentence should not be interpreted as saying these things are unimportant,
because properly used, each can be useful to the project leader. It is when they
become the focal point that trouble ensues.
4 Ken Delcol observes, “Most PMs are not selected for their ability to inspire peo-
ple! Leadership and business influencing skills are hard to establish in an inter-
view. Most managers have a difficult time identifying and evaluating people with
these skill sets.”
Exploring • 69 •
05_0321502752_ch04.qxd 6/17/09 12:39 PM Page 70
Responding to Change
We expect change (uncertainty) and respond accordingly rather than
follow outdated plans.
This statement reflects the agile viewpoint characterized further by
envisioning and then exploring into that vision rather than detailed planning
and relatively strict execution of tasks. It’s not that one is right and the other
wrong, but that each style is more or less applicable to a particular project
type.
Another factor that impacts project management style is the cost of an
iteration; that is, the cost of experimenting. Even if the need for innovation
is great, high iteration costs may dictate a process with greater anticipatory
work. Low-cost iterations, like those mentioned earlier, enable an adaptive
style of development in which plans, architectures, and designs evolve con-
currently with the actual product.
Barriers or Opportunities
One of the constant excuses, complaints, or rationalizations about some
agile practices are “They would take too much time,” or “They would cost
too much.” This has been said about short iterations, frequent database
updates, continuous integration, automated testing, and a host of other agile
practices. All too often companies succumb to what colleague Israel Gat
calls the “new toy” syndrome—placing all their emphasis on new develop-
ment and ignoring legacy code. Things like messy old code then become
excuses and barriers to change. Some activities certainly are cost-prohibi-
tive, but many of these are artificial barriers that people voice. Experienced
agilists turn these barriers into opportunities. They ask, “What would be the
benefit if we could do this?”
Working with a large company—and a very large program team (multi-
ple projects, one integrated product suite) of something over 500 people—
several years ago we wanted them to do a complete multi-project code
integration at the end of every couple of iterations. The reply was, “We can’t
do that, it would take multiple people and several weeks of time out of
development.” This was from a group who had experienced severe prob-
lems in prior releases when they integrated products very late in the release
cycle. Our response was, “What would the benefit be if you could do the
integration quickly and at low cost?” and, “You don’t have a choice; if you
want to be agile you must integrate across the entire product suite early and
often.” Grumbling, they managed the first integration with significant
effort, but with far less time than they anticipated. By the time 3–4 integra-
tions had occurred, they had figured out how to do them in a few days with
limited personnel. The benefits from frequent integration were significant,
eliminating many problems that previously would have lingered, unfound,
until close to release date.
Most, but not all, of the time perceived barriers to change (it costs too
much) really point out inefficiencies—opportunities to streamline the
process and enhance the organization’s ability to adapt. Agile development
demands short-cycle iterations. Doing short-cycle iterations demands find-
ing ways to do repetitive things quickly and inexpensively. Doing things
quickly and inexpensively enables teams to respond to changes in ways they
never anticipated previously. Doing things quickly and inexpensively fosters
Principles to Practices
We adapt our processes and practices as necessary.
Ultimately, what people do, how they behave, is what creates great products.
Principles and practices are guides; they help identify and reinforce certain
behaviors.
Although principles guide agile teams, specific practices are necessary
to actually accomplish work. A process structure and specific practices form
a minimal, flexible framework for self-organizing teams. In an agile project
there must be both anticipatory and adaptive processes and practices.
Release planning uses known information to “anticipate” the future. Refac-
toring uses information found later in the project to “adapt” code. Ron Jef-
fries once said, “I have more confidence in my ability to adapt than in my
ability to plan.” Agilists do anticipate, but they always try to understand the
limits of anticipation and try to err on the side of less of it.
Principles to Practices • 75 •
05_0321502752_ch04.qxd 6/17/09 12:39 PM Page 76
Final Thoughts
Developing great products requires exploration, not tracking against a plan.
Exploring and adapting are two behavioral traits required to innovate—
having the courage to explore into the unknown and having the humility to
recognize mistakes and adapt to the situation. Magellan had a vision, a goal,
and some general ideas about sailing from Spain down the coast of South
America, avoiding Portuguese ships if at all possible, exploring dead end
after dead end to finding a way around Cape Horn, then tracking across the
Pacific to once-again known territory in the Southeast Asia archipelagoes.
Great new products come from similarly audacious goals and rough plans
that often include large gaps in which “miracles happen,” much like the mir-
acle of finding the Straits of Magellan.
The authors begin by explaining how agile works: how it differs from traditional About the Authors
“plan-driven” methodologies, the benefits it promises, and the real-world results
Michele Sliger has extensive
it delivers. Next, they systematically map the Project Management Institute’s
experience in agile software
classic, methodology-independent techniques and terminology to agile practices.
development, having transitioned
They cover both process and project lifecycles and carefully address vital issues to Scrum and XP practices in 2000
ranging from scope and time to cost management and stakeholder communication. after starting her career following
Finally, drawing on their own extensive personal experience, they put a human the traditional waterfall approach.
face on your personal transition to agile — covering the emotional challenges, Michele is the owner of Sliger
personal values, and key leadership traits you’ll need to succeed. Consulting Inc., where she consults
with businesses ranging from small
Coverage includes
startups to Fortune 500 companies,
• Relating the PMBOK® Guide ideals to agile practices: similarities, helping teams with their agile
overlaps, and differences adoption, and helping organizations
• Understanding the role and value of agile techniques such as iteration/release prepare for the changes that agile
planning and retrospectives adoption brings. She is a certified
• Using agile techniques to systematically and continually reduce risk Project Management Professional
(PMP ® ) and a Certified Scrum
• Implementing quality assurance (QA) where it belongs: in analysis, design,
Trainer (CST).
defect prevention, and continuous improvement
• Learning to trust your teams and listen for their discoveries Stacia Broderick has worked
as a project manager for fifteen
• P rocuring, purchasing, and contracting for software in agile, collaborative
years, the last eight in software
environments
development. She was fortunate to
• Avoiding the common mistakes software teams make in transitioning to agile be helped across the bridge under
• Coordinating with project management offices and non-agile teams the mentorship of Ken Schwaber
• “Selling” agile within your teams and throughout your organization while working for Primavera
Systems in 2003 and ever since
has helped hundreds of teams the
world over embrace the principles
of and transition to an agile way of
creating products. Stacia founded
her company, AgileEvolution, Inc.,
informit.com/aw in 2006 and is a Certified Scrum
Trainer as well as a PMP ®.
08_0321502752_ch05.qxd 4/18/08 3:13 PM Page 67
Chapter 5
Scope Management
It is not the strongest of the species that survive, nor the most
intelligent, but the ones most responsive to change.
—Charles Darwin, The Origin of Species
“Scope creep” has always been the bane of traditional project managers, as
requirements continue to change in response to customer business needs,
changes in the industry, changes in technology, and things that were learned
during the development process. Scope planning, scope definition, scope
verification, and scope control are all processes that are defined in the
PMBOK® Guide to prevent scope creep, and these areas earn great atten-
tion from project managers. Those who use agile methods believe these
deserve great attention as well, but their philosophy on managing scope is
completely different. Plan-driven approaches work hard to prevent changes
in scope, whereas agile approaches expect and embrace scope change. The
agile strategy is to fix resources and schedule, and then work to implement
the highest value features as defined by the customer. Thus, the scope
• 67 •
08_0321502752_ch05.qxd 4/18/08 3:13 PM Page 68
Figure 5-1
Waterfall vs. Agile:
The paradigm shift
(original concept
courtesy of the DSDM Traditional Agile
Consortium)
Fixed Features Resources Schedule
Value/Vision
Agile flips the Driven
triangle. Plan
Driven
Scope Planning
The PMBOK® Guide defines the Project Scope Management Plan as the out-
put of the scope planning process.1 This document defines the processes that
will be followed in defining scope, documenting scope, verifying and accept-
ing scope and completed deliverables, and controlling and managing
requests for changes to the scope. In agile, the iterative and incremental
process itself is what manages scope. Unless documentation is required for
auditing purposes, no additional document outlining procedures for scope
management is needed. Scope is defined and redefined constantly in agile, as
part of the planning meetings—in particular, release planning and iteration
planning—and by the management of the product backlog. Remember,
resources and time are typically fixed in agile approaches, and it’s the scope
that is allowed to change. However, when fixed-scope projects are required,
it is the number of iterations that will change, in order to accommodate the
need for a full feature set prior to release. Additionally, one of the success cri-
teria in traditional projects is the extent to which we can “stick to the scope”;
in agile, it is more important to be able to efficiently and effectively respond
to change. The success criteria in agile thus changes to “Are we providing
value to our customer?” The primary measure of progress is working code.
• 68 • SCOPE MANAGEMENT
08_0321502752_ch05.qxd 4/18/08 3:13 PM Page 69
Table 5-1
Scope Planning
Traditional Agile
Prepare a Project Scope Management Commit to following the framework as
Plan document. outlined in the chosen agile process.
Scope Definition
SCOPE PLANNING • 69 •
08_0321502752_ch05.qxd 4/18/08 3:13 PM Page 70
of detail, the ability to plan, manage, and control the work is enhanced
because the short timeframe of the iteration reduces the amount of detail
and the complexity of estimating. The agile approach assumes that because
things change so often, you shouldn’t spend the time doing “excessive
decomposition” until you’re ready to do the work.
Let’s look at how scope is defined throughout an agile project by exam-
ining five levels of planning common to most agile projects: the product
vision, the product roadmap, the release plan, the iteration plan, and the
daily plan.4
Product Vision
At the outset of a project, it is typical to hold a kickoff meeting. Agile is no
different; however, the way the agile vision meeting is conducted is unlike
what a traditional project manager might be accustomed to. Although the
vision is defined and presented by the customer or business representative,
it is the team that clarifies the vision during the discussions and subsequent
exercises. Therefore, the team is heavily involved, and group exercises are a
big part of determining the final outcomes. See Chapter 4, “Integration
Management,” for more detail on vision meetings.
The vision meeting is designed to present the big picture, get all team
members on the same page, and ensure a clear understanding of what it is
that they’ve been brought together to do. The vision defines the mission of
the project team and the boundaries within which they will work to achieve
the desired results. The project’s goal should be directly traceable to a cor-
porate strategic objective.
Here the scope is defined at a very high level. It is not uncommon to
leave the vision meeting with only a dozen or so features identified, such as
“provide online order capabilities,” “enable international ordering and
delivery,” “create data warehouse of customer orders to use for marketing
purposes,” and “integrate with our current brick-and-mortar inventory sys-
tem.” Clearly these are all very large pieces of functionality with little-to-no
detail—and this is what is appropriate at this stage of the project. The far-
ther away the delivery date, the broader the stroke given to feature details.
Product Roadmap
A product roadmap shows how the product will evolve over the next three
to four releases or some period of calendar time, typically quarters. The
• 70 • SCOPE MANAGEMENT
08_0321502752_ch05.qxd 4/18/08 3:13 PM Page 71
Technology/ What
technology
Architecture should we use?
Roadmap Linux
?
Market Events COMDEX
/Rhythms
SCOPE PLANNING • 71 •
08_0321502752_ch05.qxd 4/18/08 3:13 PM Page 72
• 72 • SCOPE MANAGEMENT
08_0321502752_ch05.qxd 4/18/08 3:13 PM Page 73
Figure 5-3
Release planning
Release Planning meeting agenda
Meeting Agenda
Figure 5-4
Release plan
SCOPE PLANNING • 73 •
08_0321502752_ch05.qxd 4/18/08 3:13 PM Page 74
Teams that are not co-located should make every effort to bring every-
one together for this meeting. Agile emphasizes face-to-face communication
because of its benefits. However, balancing this with the realities of geo-
graphically dispersed teams means that budget constraints force teams to be
selective about when they can gather together as a group. The vision and
release planning meetings should receive high priority, because the informa-
tion shared and decisions made in these meetings guide the team through-
out the remainder of the release.
Iteration Planning
Traditional scope definition and many of the practices defined in the
PMBOK® Guide knowledge area of Project Time Management are done as
part of iteration planning. Here, features are elaborated (creating the equiv-
alent of PMBOK® Guide work packages), tasks are identified, and the time
needed to accomplish the tasks is estimated (see Figures 5-5 and 5-8). At the
beginning of each iteration, the team should hold an iteration planning
meeting to conduct this work. The team reviews the release plan and the pri-
oritized items in the backlog, reviews the features requested for the current
• 74 • SCOPE MANAGEMENT
08_0321502752_ch05.qxd 4/18/08 3:13 PM Page 75
iteration, and tasks out and estimates those features. See Figure 5-6 for a
typical iteration planning meeting agenda. In keeping with the agile practice
of just-in-time design, it is here that the details of the features are discussed
and negotiated.
Figure 5-5
Iteration plan
Figure 5-6
Iteration planning
Iteration Planning meeting agenda
Meeting Agenda
SCOPE PLANNING • 75 •
08_0321502752_ch05.qxd 4/18/08 3:13 PM Page 76
Again, planning and design work is done only for the pieces that are
being readied to code in that iteration, not for the entire system. It’s often
discovered during iteration planning that the sum of the task efforts exceeds
the size of the iteration timebox. When this occurs, some of the work needs
to be shifted either into the next iteration or back into the backlog. Similarly,
if a team discovers that it has chosen too little work for the iteration, it will
consult with the customer, who can then give the team an additional feature
or two to make up the difference. This allows the team to make a realistic
commitment to the scope of the work being defined.
Daily Stand-Up
One of the key heartbeats of agile development involves the practice of daily
stand-up meetings. It is just what it sounds like: a daily meeting, where all
team members attend, and while remaining standing, they each relate their
status to the other team members and their plan for the day based on the
progress that they’ve made. Standing helps keep the meetings short—stand-
ups should run only 5 to 15 minutes. Its primary purpose is for the team
members to inspect and adapt its work plan (iteration backlog) by quickly
sharing information about the progress (or lack of) being made by each
individual regarding the tasks that were committed to during the iteration
planning meeting. These stand-ups help the team to remain focused on the
agreed-to scope and goals of the iteration.
Summary Comparison
Table 5-2 provides a summary comparison of traditional and agile
approaches to scope definition. In agile projects this is called “multilevel
planning.”
Table 5-2
Scope Definition
Traditional Agile
Prepare a Project Scope Statement document Conduct a vision meeting to share the
that includes items such as the following: product vision; confirm and clarify the
Project boundaries and objectives, product boundaries, objectives, and product
scope description… scope description using exercises such as
the elevator statement and design the box.
• 76 • SCOPE MANAGEMENT
08_0321502752_ch05.qxd 4/18/08 3:13 PM Page 77
Traditional Agile
And major milestones and project Conduct a planning meeting to prepare the
deliverables… product roadmap, as well as release or quarterly
planning meetings that also include milestones
and deliverables at an iteration level.
And assumptions and constraints. All planning meetings identify and/or review
assumptions and constraints.
Create a WBS
Agile teams do not tend to create formal WBSs (work breakdown struc-
tures). Instead, flipcharts and whiteboards are used to capture the break-
down of work. You’ve seen examples of these in Figures 5-4 and 5-5. So at
the end of release planning, the agile equivalent of a WBS—a feature break-
down structure—would look like the sample release plan feature break-
down structure in Figure 5-7. If having iterations as work packages is not
sufficient for your organization/billing needs, then breaking the work down
further into smaller work packages would look like the results of an iteration
planning meeting, as illustrated in Figure 5-8.
Table 5-3 compares the traditional and agile approaches to work break-
down. In agile projects, the work breakdown structure is captured in the
release plan and the iteration plan.
Table 5-3
WBS Creation
Traditional Agile
Create a work breakdown structure Conduct planning meetings and give the team
diagram. the responsibility for breaking down the work
into smaller work packages (features and
tasks), displayed as the release plan at the
high level, and the iteration plan at the more
detailed level.
SCOPE PLANNING • 77 •
08_0321502752_ch05.qxd 4/18/08 3:13 PM Page 78
Customer Inventory
Profile Report
Security
Options
Figure 5-8
Iteration plan (partial) Iteration 1
Order
Entry
Cancel
Order
• 78 • SCOPE MANAGEMENT
08_0321502752_ch05.qxd 4/18/08 3:13 PM Page 79
Scope Verification
Table 5-4
Scope Verification
Traditional Agile
Document those completed deliverables Documentation of accepted features may
that have been accepted and those that be done informally (by moving the sticky
have not been accepted, along with the reason. notes to the “done” pile) or formally.
Scope Control
SCOPE PLANNING • 79 •
08_0321502752_ch05.qxd 4/18/08 3:13 PM Page 80
know today, this is the work that I am expecting by the end of the iteration,
and during that time I will not mess with the iteration backlog” (that is,
scope). The iteration backlog is thus locked in.
It is important to set the length of your iteration accordingly, because
the customer must wait until the next iteration to make changes. If there
happens to be lots of “requirements churn” (that is, requests for changes are
coming in very frequently), you may want to discuss shorter iteration cycles
with the team in order to enable more frequent changes. Maintenance teams
may have iteration lengths of only one week, whereas larger system develop-
ments with known requirements may have an iteration length of four to six
weeks. If the customer keeps trying to interrupt the team with changes, the
iteration length may be too long.
There will always be exceptions, and in those cases a discussion
between the customer and the agile project manager should help identify
potential resolutions. Iterations can be aborted and restarted, but this
should be the rare exception.
Given the short duration of iterations, it is easy to protect the iteration
backlog from change. However, changes in the product roadmap and the
release plan are expected and therefore should be reviewed regularly.
Table 5-5 lists out the differences between the traditional and agile
approaches to scope control. Agile users refer to scope control as “managing
the product backlog.”
Table 5-5
Scope Control
Traditional Agile
Use a change control system to The customer manages the product backlog; once
manage change. the team commits to the work to be done in an
iteration, the scope is protected for that duration.
Update all documents as appropriate The team revisits release plans and product
with the approved changes. roadmaps regularly, making changes as needed to
better reflect the team’s progress and changes
requested by the customer.
• 80 • SCOPE MANAGEMENT
08_0321502752_ch05.qxd 4/18/08 3:13 PM Page 81
Summary
The main points of this chapter can be summarized as follows:
Table 5-6
Agile Project Manager’s Change List for Scope Management
Create the WBS. Facilitate the release planning meeting so that the
team can create the plan showing the breakdown
of work across several iterations.
(continued)
SUMMARY • 81 •
08_0321502752_ch05.qxd 4/18/08 3:13 PM Page 82
Table 5-6
Agile Project Manager’s Change List for Scope Management (continued)
Manage the delivery of tasks to Allow team members to manage their daily tasks
prevent or correct scope creep and facilitate conversations with the customer to
at the task level. avoid unnecessary work or “gold plating.”
Endnotes
1. PMBOK® Guide, 107.
2. Ibid, 114.
3. Ibid.
4. Mike Cohn. Agile Estimating and Planning (Upper Saddle River, NJ: Pearson
Education, Inc., 2006), 28.
5. Luke Hohmann. Beyond Software Architecture (Boston: Addison-Wesley,
2003), 287.
6. Poppendieck. Lean Software Development, 57.
• 82 • SCOPE MANAGEMENT
Google
Bookmarks Delicious Digg Facebook StumbleUpon Reddit Twitter
Buy 2 from informIT and
Save 35%
Amr Elssamadisy Enter the coupon code
AGILE2009 during checkout.
Agile methods promise to help you create software that delivers far more business
value — and do it faster, at lower cost, and with less pain. However, many available
organizations struggle with implementation and leveraging these methods to their • Book: 9780321514523
full benefit. In this book, Amr Elssamadisy identifies the powerful lessons that • Safari Online
have been learned about successfully moving to agile and distills them into 30 • EBOOK: 0321579437
proven agile adoption patterns. • KINDLE: B001E50WTY
Elssamadisy walks you through the process of defining your optimal agile adoption
strategy with case studies and hands-on exercises that illuminate the key points.
He systematically examines the most common obstacles to agile implementation,
About the Author
identifying proven solutions. You’ll learn where to start, how to choose the best Amr Elssamadisy (elssamadisy.
agile practices for your business and technical environment, and how to adopt com) is a software development
agility incrementally, building on steadily growing success.
practitioner who works with his
Next, he presents the definitive agile adoption pattern reference: all the clients to build better, more valuable
information you need to implement the strategy that you’ve already defined. software. He and his colleagues at
Utilizing the classic pattern format, he explains each agile solution in its proper Gemba Systems help both small
context, revealing why it works — and how to make the most of it. The pattern and large development teams learn
reference prepares you to new technologies, adopt and adapt
• Understand the core drivers, principles, and values associated appropriate agile development
with agile success practices, and focus their efforts
• Tightly focus development on delivering business value — and recognize to maximize the value they bring
the “smells” of a project headed off track to their organizations.
• Gain rapid, effective feedback practices: iteration, kickoff and stand-up
meetings, demos, retrospectives, and much more Amr is also the author of Patterns
of Agile Practice Adoption:
• Foster team development: co-location, self-organization, cross-functional
The Technical Cluster. He is an
roles, and how to bring the customer aboard
editor for the AgileQ at InfoQ, a
• Facilitate technical tasks and processes: testing, refactoring, continuous
contributor to the Agile Journal, and
integration, simple design, collective code ownership, and pair programming
a frequent presenter at software
• Act as an effective coach, learning to engage the community and
development conferences.
promote learning
• Integrate “clusters” of agile practices that work exceptionally well together
Agile Adoption Patterns will help you whether you’re planning your first agile
project, trying to improve your next project, or evangelizing agility throughout your
organization. This actionable advice is designed to work with any agile method,
from XP and Scrum to Crystal Clear and Lean. The practical insights will make you
more effective in any agile project role: as leader, developer, architect, or customer.
informit.com/aw
09_0321514521_ch05.fm Page 37 Tuesday, June 10, 2008 12:38 PM
Chapter 5
So far you have read about business value and smells. You have also done the
exercises at the end of each chapter and come up with a prioritized list of
business values and a prioritized list of smells that need fixing. If you have
not done so yet, please stop now and go back and do so. Armed with an
understanding of your customers’ priorities and the main pains your com-
pany is experiencing, you are ready to determine what practices you should
consider adopting to alleviate those pains and get the most value for your
efforts.
T HE P RACTICES
The bulk of this book contains patterns of Agile practice adoption—that is,
Agile practices written up in pattern format with a focus on adoption. In this
chapter, your goal is to choose the practices that fit your organization’s con-
text. That comes down to relying on the work you’ve done in the previous
chapter in prioritizing your business values and smells and using it to choose
which practices to adopt to improve your business values and reduce your
smells.
37
09_0321514521_ch05.fm Page 38 Tuesday, June 10, 2008 12:38 PM
Continuous
Iteration
Integration
Release Often
Iteration
Done State
Backlog
Less Effective
Small steps and failing fast are the most effective methods to get things out
quickly. Weed out defects early because the earlier you find them, the less
they will cost, and you won’t be building on a crumbling foundation. That
is why Iteration and Continuous Integration lead the practices that most
positively affect time to market. They are both, however, dependent on
other practices. Consider starting with automated tests and the Iteration
trio—Iteration, Done State, and Iteration Backlog—when you want to im-
prove time to market.
Figure 5-2 gives the practices that increase product utility. By far, the most ef-
fective practice is Customers Part of Team. Go there first. Then consider
functional tests if you are already doing automated developer tests or an iter-
ation ending with a demo.
More Effective
Customer Part
of Team
Product Utility
(Value to Market)
Does not improve
product utility unless
customerpart
customer partofofthem
tem
Test Driven
(If customer does Requirements
not know the exact
utilityofofproduct.)
utility product
Iteration Demo Functional
Tests Improved by
Requirements Documents
Release Often
Prioritized
Backlog User Story Use Case
Less Effective
Quality to Market
More Effective
Test-Driven Test-Driven
Development Requirements
Automated Developer Tests
Test-First
Development
Test-Last
Development Functional Tests
Refactoring
Pair
Programming
Continuous
Collective Code Evolutionary Integration Iteration
Ownership Design
Release Often
Simple Design
Stand-Up
Meeting
Less Effective
More Effective
Evolutionary
Design Flexibility
Retrospective
Iteration Demo
Automated Developer Tests
Test-First Test-Last
Development Development Functional Tests
Less Effective
There are two general types of flexibility in software development: team flex-
ibility and technical flexibility. Team flexibility is the team’s ability to recog-
nize and respond to changes that happen. For a team to respond to changes
by changing the software, there needs to be technical flexibility. Therefore,
you need both team flexibility and technical flexibility. Start with Automated
Developer Tests, a self-organizing team, and the trio of Iteration, Done State,
and Backlog. The testing gets you on your way to technical flexibility, and the
remaining practices enable your team’s flexibility.
09_0321514521_ch05.fm Page 42 Tuesday, June 10, 2008 12:38 PM
More Effective
Visibility
Information Test-Driven
Backlog Requirements Functional Tests
Radiator
Continuous
Release Often Iteration Done State
Demo Integration
Stand-Up
Kickoff Meeting Meeting
Less Effective
The backlog and information radiators are your first easy steps toward in-
creased visibility. Depending on your need for increasing visibility, you
can take an easy route and consider iterations with a done state and a
demo or a more difficult but effective route with functional tests and test-
driven requirements.
More Effective
Reduce Cost
Evolutionary
Refactoring Design
Automated Developer Tests
Backlog
Cross- Self-Organizing
Functional Team Team Retrospective Iteration Done State
Continuous
Integration User Story
Less Effective
You can reduce cost in two ways: make the code easier to maintain and write
less code—that is, code for the most important features first. Automated
tests, followed by refactoring, simple design, and evolutionary design, are
your path toward reducing the cost of maintenance. A backlog, iteration, and
done state reduce the amount of code written.
Self-Organizing Cross-
Simple Design Team Functional Team
Evolutionary Evocative
Design Document
Continuous
Integration
Less Effective
The remaining smells have their own mappings to patterns of Agile practices
(see Figures 5-8 through 5-15).
More Effective
Us Versus Them
Information Prioritized
Radiator Backlog
Demo
Done State
Less Effective
The Us Versus Them smell can best be alleviated by having frequent conver-
sations about the true nature of the project. Start with increasing visibility by
creating information radiators that show the key points in your develop-
ment. Create a prioritized backlog by involving the whole development
team—including the customers. Use these practices to increase visibility and
build trust. When you are ready, take it further and build more trust by deliv-
ering often by adopting the iteration, demo, and done state trio.
More Effective
Customer Part
of Team
Test-Driven
Requirements Functional Tests Backlog Planning Poker
Co-located
Team
Demo
Information
Release Often Radiator
Stand-Up
Kickoff Iteration Meeting
Less Effective
Test-Driven
Requirements Backlog
Information
Functional Tests Radiator Iteration Demo
Stand-Up
Release Often Meeting
Less Effective
If direct input from the customer is not possible, mitigate this problem by re-
ducing the number of communication errors. You can do this by building
functional tests and slowly working toward test-driven requirements, where
the customer’s requirements document becomes an executable specification.
This particular practice will take a long time to adopt correctly, so start early
and be patient. In the meantime, create a backlog and start delivering work
incrementally, with iterations ending with a demo.
09_0321514521_ch05.fm Page 46 Tuesday, June 10, 2008 12:38 PM
More Effective
Management Is
Surprised
Information
Backlog Radiator
Done State
Iteration
Continuous Stand-Up
Kickoff
Integration Meeting
Less Effective
Pair
Programming
Test-First Test-Last
Development Development Functional Tests
Co-located
Team
Less Effective
More Effective
Churning Projects
Backlog
Co-located Information
Team Radiator
Less Effective
More Effective
Hundreds of
Bugs
Test-First Test-Last
Development Development Functional Tests
Pair
Simple Design Programming Done State Iteration
Refactoring
Continuous
Integration
Less Effective
More Effective
Hardening Phase
Test-First Test-Last
Development Development Functional Tests Done State
Iteration
Continuous
Integration
Demo
Release Often
Less Effective
If you have a hardening phase, you’ve let a significant number of defects ac-
cumulate. Stop doing what you’ve been doing and add tests as you develop
code via automated developer tests. Choose a good done state—one that
takes you as close to deployment in every iteration as possible—to weed out
those difficult-to-find bugs early.
09_0321514521_ch05.fm Page 49 Tuesday, June 10, 2008 12:38 PM
The information found in the figures at the beginning of this chapter is pri-
oritized by effectiveness. Therefore, the first practice in the figure is the most
effective practice for increasing the business value or alleviating the smell.
Get your feet wet with the first practice, and after you’ve successfully adopted
that, come back and take another look at the remaining practices and clusters
related to your business value or smell.
No matter how you prioritize your list of practices to adopt, you should
adopt those practices as iteratively as possible. Armed with the list of prac-
tices, here is how you can successfully adopt the Agile practices on your list.
1. Start with an evaluation of the status quo. Take readings (even if they
are subjective) of the current business value(s) you want to improve
and the smell(s) you want to alleviate.
2. Set goals that you want to reach. How much do you want to increase
the business value? How much do you want to reduce the smell? What
is the time frame? Take a guess initially and modify it as you know
more through experience.
3. Pull the first practice or cluster off the list you created.
09_0321514521_ch05.fm Page 50 Tuesday, June 10, 2008 12:38 PM
So where is the test-driven part of this approach? Your tests are your goal val-
ues that you set in step 2. In step 6, you check your readings after adopting a
practice. This is a test of how effectively the practice(s) you adopted has al-
ready met the goal set earlier. This loop—set a goal, adopt a practice, and
then validate the practice against the expected goal—is a test-driven adop-
tion strategy.1
W HERE N EXT ?
With the completion of this chapter, you are ready to create your own Agile
adoption strategy that focuses on the business values and smells of your or-
ganization. This is not a one-shot deal—remember to be agile about your
adoption. Measure your progress against your goals and revisit them regu-
larly. Modify your strategy as you learn more about each practice and your
own environment. It is natural to make a few wrong turns, but fail fast and
quickly recover.
1. In management practices, this is commonly referred to as the PDCA cycle (Plan, Do,
Check, Act), originally developed by Walter Shewhart at Bell Laboratories in the 1930s
and promoted effectively in 1950s by the quality management guru W. Edward
Deming.
09_0321514521_ch05.fm Page 51 Tuesday, June 10, 2008 12:38 PM
For the remainder of this book, we dig into the details of each practice. There
is a pattern for each practice mentioned in the mappings that describes the
practice, what problems it solves, how others have successfully adopted and
adapted practices in various environments, and what missteps they have
taken upon adoption so you can watch out for them.
1. What are your goals for adopting Agile practices? Do you want to alle-
viate smells or add business value? Be specific. If you have more than
one goal, prioritize them.
2. Take readings of the current business value(s) and smell(s) you want
to address. Don’t worry if they are subjective or fuzzy. Know, to the
best of your ability, where your organization is today with respect to
business values and smells.
3. Choose an adoption strategy. Choose practices using that strategy to
adopt.
4. Read the next chapter, which introduces the patterns. Then start fol-
lowing the steps outlined in this chapter to adopt your first practice.
Don’t forget to periodically take readings of your business value/smell
to make sure the practice is effective.
5. Congratulations and good luck! Youve started on your path to Agile
practice adoption!
Google
Bookmarks Delicious Digg Facebook StumbleUpon Reddit Twitter
Buy 2 from informIT and
Craig Larman Save 35%
Bas Vodde Enter the coupon code
AGILE2009 during checkout.
informit.com/aw
book.book Page 149 Sunday, November 2, 2008 5:43 PM
Chapter
FEATURE TEAMS
7
Better to teach people and risk they leave, than not and risk they stay
—anonymous
149
book.book Page 150 Sunday, November 2, 2008 5:43 PM
7 — Feature Teams
lean thinking In lean thinking, minimizing the wastes of handoff, waiting, WIP,
wastes p. 58 information scatter, and underutilized people is critical; cross-func-
tional, cross-component feature teams are a powerful lean solution
to reduce these wastes.
Scrum team A proper Scrum team is by definition a feature team, able to do all
p. 309 the work to complete a Product Backlog item (a customer feature).
Note that Scrum team (feature team) members have no special title
other than “team member.” There is not emphasis on ‘developer’ ver-
sus ‘tester’ titles. The goal is to encourage multi-skilled workers and
“whole team does whole feature.” Naturally people have primary
specialities, yet may sometimes be able to help in less familiar areas
to get the job done, such as an ‘analyst’ helping out with automated
testing. The titles in Figure 7.1 should not be misinterpreted as pro-
moting working-to-job-title, one of the wastes in lean thinking.
150
book.book Page 151 Sunday, November 2, 2008 5:43 PM
Feature teams are not a new or ‘agile’ idea; they have been applied
to large software development for decades. They are a refinement of
cross-functional teams, a well-researched proven practice to cross-functional
speed and improve development. The term and practice was popu- team p. 196
larized at Microsoft in the 1980s and discussed in Microsoft Secrets
[CS95]. Jim McCarthy [McCarthy95], the former development lead
of Visual C++, described feature teams:
151
book.book Page 152 Sunday, November 2, 2008 5:43 PM
7 — Feature Teams
152
book.book Page 153 Sunday, November 2, 2008 5:43 PM
Feature Team
❑ long-lived—the team stays together so they can ‘jell’ for long-lived teams
higher performance; they take on new features over time p. 199
❑ cross-functional and cross-component
❑ co-located
❑ work on a complete customer-centric feature, across all com-
ponents and disciplines (analysis, programming, testing, …)
❑ composed of generalizing specialists
❑ in Scrum, typically 7 ± 2 people
Feature teams work independently by being empowered and given work redesign
the responsibility for a whole feature. Advantages include: p. 234
153
book.book Page 154 Sunday, November 2, 2008 5:43 PM
7 — Feature Teams
154
book.book Page 155 Sunday, November 2, 2008 5:43 PM
AVOID…SINGLE-FUNCTION TEAMS
AVOID…COMPONENT TEAMS
155
book.book Page 156 Sunday, November 2, 2008 5:43 PM
7 — Feature Teams
156
book.book Page 157 Sunday, November 2, 2008 5:43 PM
… Because the design that occurs first is almost never the best
possible, the prevailing system concept [the design] may need to
change. Therefore, flexibility of organization is important to
effective design. Ways must be found to reward design manag-
ers for keeping their organizations lean and flexible.
Disadvantages
157
book.book Page 158 Sunday, November 2, 2008 5:43 PM
7 — Feature Teams
Fortunately, there has been much innovation since the 1960s. New
life cycle and team structures have been discovered, as have power-
ful new version-control, integration, and testing practices.
Component
Feature A B C D E …
Feature 1 x x x
Feature 2 x x x
…
158
book.book Page 159 Sunday, November 2, 2008 5:43 PM
times long after, as they need the work of multiple component teams
and these teams seldom finish their work at the same time. Plus,
they have a backlog of other features to test.
159
book.book Page 160 Sunday, November 2, 2008 5:43 PM
7 — Feature Teams
Limits Learning
160
book.book Page 161 Sunday, November 2, 2008 5:43 PM
Observations:
❑ slack5
❑ a structure to support continual learning
– but there’s a systemic flaw in component teams…
161
book.book Page 162 Sunday, November 2, 2008 5:43 PM
7 — Feature Teams
And on the other hand, there are always a few wonderful people who
know a lot about the system—the people you would go to for help on
an inexplicable bug. Now, when you ask how that’s possible, a com-
mon answer will be, “He knows everything since he always reads
everybody’s code.” Or, “He’s worked on a lot of different code.” Inter-
estingly, such people are more common in large open source prod-
ucts; there is a culture and value of “Use the source, Luke”
[Raymond] that promotes reading and sharing knowledge via code.
Isao Kato, one of the students of Taichii Ohno (father of the Toyota
Production System), said:
162
book.book Page 163 Sunday, November 2, 2008 5:43 PM
163
book.book Page 164 Sunday, November 2, 2008 5:43 PM
7 — Feature Teams
Comp A Component
Item 1 Team A
Item 2
Item 3
...
Comp B Component
Item 8 Team B
6. Not only do more lines of code (LOC) not imply more value, more
code can make things worse. Why? Because there is a relationship
between LOC and defect rates and evolution effort. More code
equals more problems and effort. Great development groups strive
to reduce their LOC while creating new features, not increase it.
Since component teams have a narrow view of the code base, they
don’t see reuse or duplication issues.
164
book.book Page 165 Sunday, November 2, 2008 5:43 PM
❑ lower motivation and job satisfaction—I often lead a “love/ work redesign
hate” exercise with many people in an enterprise to learn what p. 234
they, well… hate. In large groups focused around resource pools
and project groups, “we hate being part of a resource pool
thrown into multiple short-term groups” is always at or near
the top.
165
book.book Page 166 Sunday, November 2, 2008 5:43 PM
7 — Feature Teams
Go See p. 52 Observe the relationship between the lean “Go See” attitude and the
belief that it is skillful to have resource pools that optimize around
single-specialist constraints. People that do not spend regular time
physically close to the real value-add workers may believe in
resource pools and short-lived project groups because it appears on
paper—as with machine parts—to be flexible and efficient. Yet those
frequently involved in the real work directly see the subtle (but non-
trivial) problems.
166
book.book Page 167 Sunday, November 2, 2008 5:43 PM
Consider duplication: Good code is free of it, and great developers see Legacy Code
strive to create less code as they build new features, through con- in companion
stant refactoring. It’s difficult to see duplication or opportunities for book
reuse in a code base with single-component specialists, because one
never looks broadly. Single-component specialists increase duplica-
tion. And so the code base grows ever larger than necessary, which
in turn demands more single-component specialists…9
167
book.book Page 168 Sunday, November 2, 2008 5:43 PM
7 — Feature Teams
168
book.book Page 169 Sunday, November 2, 2008 5:43 PM
instead of hiring more people. But this rarely happens. The other
component team already has work chosen for the release, so they
won’t wish to lose people. And there is a fear it will take too long to
learn anything to be helpful. Also, the mindset is that “it would be a
waste of our specialist to move her to another component team.”
Finally, moving people is inhibited by political and management sta-
tus problems—many managers don’t want to have a smaller group
(another force of local optimization). Conway formulated this well:
Thus, the component-A team will grow, as will the component itself.
It may even eventually split into two new components, and hence
two new teams. The people will specialize on the new components.
In this way large product organizations tend to grow even larger.
Comp A Component
Item 1 Team A
Item 2
Item 3
...
Comp B Component
Item 20 Team B
169
book.book Page 170 Sunday, November 2, 2008 5:43 PM
7 — Feature Teams
Project
Manager
Comp A Component
Item 1 Team A
Item 2
Item 3
Item 4
Comp C Component
Team C
170
book.book Page 171 Sunday, November 2, 2008 5:43 PM
the iteration (see Figure 7.7)—a task that is often handled by a sep-
arate project manager. Even if we successfully plan the complex
interdependencies for this iteration, a delay in one team will have a
ripple effect through all component teams, often across several itera-
tions.
Example:
171
book.book Page 172 Sunday, November 2, 2008 5:43 PM
7 — Feature Teams
see Design in Perhaps the greatest irony of component teams is this: A mistaken
companion belief behind their creation is that they yield components with good
code/design. Yet, over the years we have looked closely at the code
across many large products, in many companies, and it is easy to see
that the opposite is true—the code in a component maintained by a
single-component team is often quite poor.10 For example, we will sit
to start pair programming with a component team member (who
knows we’ll be looking for great code), and with a slightly apologeti-
cally grin the programmer will say, “Yeah, we know it’s messy, but
we understand it.” What is going on?
172
book.book Page 173 Sunday, November 2, 2008 5:43 PM
Summary of Disadvantages
173
book.book Page 174 Sunday, November 2, 2008 5:43 PM
7 — Feature Teams
groups, with feature teams that work across all code. This is a multi-
year learning journey.
TRY…FEATURE TEAMS
174
book.book Page 175 Sunday, November 2, 2008 5:43 PM
Team Component
Item 1 Red A
Item 2
Item 3
...
Team Component
Item 8 Blue B
175
book.book Page 176 Sunday, November 2, 2008 5:43 PM
7 — Feature Teams
Feature teams are not feature projects. A feature project is organized around one fea-
ture. At the start, the needed specialists (usually developers from component teams or a
resource pool) are identified and organized into a short-lived group—a virtual project
group. The specialists are usually allocated a percentage of their time to work for the fea-
ture project. Feature teams and feature projects have important differences:
Long-life teams—A feature team, unlike a project group, may stay together for several
years. The team has an opportunity to jell and learn to work together. A well-working
jelled team leads to higher performance [KS93].
Shared ownership—In a feature team, the whole team is responsible for the whole fea-
ture. This leads to shared code ownership and cross-learning, which in the long run
increases degrees of freedom and reduces bottlenecks. In feature projects, developers only
update their particular single-specialty section of code.
First, not all people need to know the whole system and all skills.
The Product Owner and teams usually select a qualified feature
team for a feature, unless they have the time and desire for a ‘virgin’
team to invest in some deep learning in less familiar territory. In the
common case, the team members together need to already know
enough—or be able to learn enough without herculean effort—to
complete a customer-centric feature. Notice that feature teams do
176
book.book Page 177 Sunday, November 2, 2008 5:43 PM
…
Team Green
with ABEF
skills
Item 2 will be given to
Team Blue or Green; skill
A or D will need learning
Learning new areas of the code base is not a profound problem for
“moderately large” products, but beyond some tipping point12 it
starts to be a challenge.
177
book.book Page 178 Sunday, November 2, 2008 5:43 PM
7 — Feature Teams
178
book.book Page 179 Sunday, November 2, 2008 5:43 PM
on new code and in new domains all the time; indeed, it’s an empha-
sis of their university education.
Still, to dig deeper: Why is it hard to learn new areas of the code
base? Usually, the symptom is incredibly messy code and bad
design—a lack of good abstraction, encapsulation, constant refactor-
ing, automated unit tests, and so forth. That should be a warning
sign to increase refactoring, unit tests, and learning, not to avoid
new people touching fragile code—to strengthen rather than to live
with a weakness.
Learning new code and changing an existing code base is indeed a potential skills
learnable skill. It takes practice to become good, and people in fea- p. 206
ture teams get that practice and learn this skill.
The principles laid out in Belshee’s paper are not for the faint of
heart. They require dedication, commitment and courage. Dedi-
cation is required of each team member to strive for self
179
book.book Page 180 Sunday, November 2, 2008 5:43 PM
7 — Feature Teams
see Continuous Old-generation and complex (and costly) version control systems
Integration in such as ClearCase defaulted to strict locking in which the person
companion making a change locked the source file so that no one else could
change it. Much worse, vendors promoted a culture of avoiding con-
current access, delaying integration, complex integration processes
involving manual steps, integration managers, and tool administra-
tors. This increased costs, complexity, bottlenecks, waiting, and rein-
forced single-team component ownership.
On the other hand, the practices and tools in agile and in open
source development are faster and simpler. Free open source tools
such as Subversion14 default to optimistic locking (no locking),
14. Subversion is likely the most popular version control tool worldwide,
and a de facto standard among agile organizations. Tip: It is no
longer necessary to pay for tools for robust large-scale development;
for example, we’ve seen Subversion used successfully on a 500-per-
son multisite product that spanned Asia and Europe.
180
book.book Page 181 Sunday, November 2, 2008 5:43 PM
When developers practice continuous integration (CI) they inte- see Continuous
grate their code frequently—at least twice a day. Integrations are Integration in
small and frequent (for example, five lines of code every two hours) companion
rather than hundreds or thousands of lines of code merged after
days or weeks. The chance of conflict is lower, as is the effort to parallel releases
resolve. Developers do not normally keep code on separate “devel-
p. 209
oper branches” or “feature branches”; rather, they frequently inte-
grate all code on the ‘trunk’ of the version-control system, and
minimize branching. Furthermore, CI includes an automated build
environment in which all code from the hundreds of developers is
endlessly, relentless compiled, linked, and validated against thou-
sands of automated tests; this happens many times each day.15
15. Note that this implies driving down the build time of a large system.
181
book.book Page 182 Sunday, November 2, 2008 5:43 PM
7 — Feature Teams
182
book.book Page 183 Sunday, November 2, 2008 5:43 PM
16. A typical reason for concern about delicate components is that the
code is not clean, well refactored, and surrounded by many unit
tests. The solution is to clean it up (“Stop and Fix”), after which a
component guardian may not be necessary.
17. But the roles are not identical. Guardians (or ‘stewards’) do more
teaching and pair programming, and allow commits at any time.
Committers also teach, but less so, and control the commit of code.
183
book.book Page 184 Sunday, November 2, 2008 5:43 PM
7 — Feature Teams
see Design in Another practice to foster successful shared design is the design
companion workshop. Each iteration, perhaps multiple times, the feature
team gets together for between “two hours and two days” around
giant whiteboard spaces. They do collaborative agile modeling,
sketching on the walls in a creative design conversation. If there are
component guardians or other technical leaders (that are not part of
the feature team) who can help guide and review the agile modeling,
they ideally also participate. See Figure 7.10.
18. Solutions for multisite joint design workshops are explored in the
Design chapter.
184
book.book Page 185 Sunday, November 2, 2008 5:43 PM
With feature teams, new—and just plain better—stability tech- see Test and
niques are used. Massive test automation with continuous integra- Continuous
tion (CI) is a key practice. When developers implement new Integration in
functionality, they write automated tests that are added to the CI companion
system and run constantly. When a test breaks:
185
book.book Page 186 Sunday, November 2, 2008 5:43 PM
7 — Feature Teams
Difficult-to-Learn Skills
A feature team may not have mastery of all skills needed to finish a
potential skill feature. This is a solvable problem if there is the potential skill
p. 206 [KS01]. On the other hand, some skills are really tough to learn,
such as graphic art or specialized color mathematics. Solutions:
186
book.book Page 187 Sunday, November 2, 2008 5:43 PM
Organizational Structure
Handling Defects
187
book.book Page 188 Sunday, November 2, 2008 5:43 PM
7 — Feature Teams
for the team, and by avoiding learning and reinforcing the weakness
and bottleneck of depending upon single points of success or failure.
TRANSITION
188
book.book Page 189 Sunday, November 2, 2008 5:43 PM
Transition
A specialist
A specialist
A specialist C specialist
A specialist B specialist
A specialist
B specialist
B specialist C specialist
B specialist B specialist
… and so forth
189
book.book Page 190 Sunday, November 2, 2008 5:43 PM
7 — Feature Teams
One Nokia product took this path, and formed AB teams based on
the guideline of combining from closely interacting components; that
is, they chose A and B components (and thus teams) that directly
interacted with each other. Consequently, the original team A and
team B developers already had some familiarity with each other’s
components, at least in terms of interfaces and responsibilities.
CONCLUSION
RECOMMENDED READINGS
190
book.book Page 191 Sunday, November 2, 2008 5:43 PM
Transition
191
Try Safari Books Online FREE
Get online access to 7,500+ Books and Videos
InformIT is a brand of Pearson and the online presence
for the world’s leading technology publishers. It’s your source
for reliable and qualified content and knowledge, providing
access to the top brands, authors, and contributors from
the tech community.
LearnIT at InformIT
Looking for a book, eBook, or training video on a new technology? Seeking
timely and relevant information and tutorials? Looking for expert opinions,
advice, and tips? InformIT has the solution.
• L
earn about new releases and special promotions by
subscribing to a wide variety of newsletters.
Visit informit.com /newsletters.
• A
ccess thousands of books and videos in the Safari Books
Online digital library at safari.informit.com.
Visit informit.com /learn to discover all the ways you can access the
hottest technology content.
Agile Estimating and Planning is the definitive, practical Thoroughly reviewed and eagerly anticipated by the agile
guide to estimating and planning agile projects. In this community, User Stories Applied offers a requirements
book, Agile Alliance cofounder Mike Cohn discusses process that saves time, eliminates rework, and leads
the philosophy of agile estimating and planning and directly to better software. The best way to build software
shows you exactly how to get the job done, with real- that meets users’ needs is to begin with “user stories”:
world examples and case studies. Concepts are clearly simple, clear, brief descriptions of functionality that will
illustrated and readers are guided, step by step, toward be valuable to real users. In User Stories Applied, Mike
how to answer the following questions: What will we Cohn provides you with a front-to-back blueprint for
build? How big will it be? When must it be done? How writing these user stories and weaving them into your
much can I really complete by then? You will first learn development lifecycle.
what makes a good plan-and then what makes it agile.
Using the techniques in Agile Estimating and Planning,
you can stay agile from start to finish, saving time,
conserving resources, and accomplishing more.
More Titles of Interest
Straight from the programming trenches, The Pragmatic This is the definitive guide for managers and students
Programmer cuts through the increasing specialization to agile and iterative development methods: what they
and technicalities of modern software development to are, how they work, how to implement them — and why
examine the core process — taking a requirement you should.
and producing working, maintainable code that
delights its users. It covers topics ranging from Using statistically significant research and large-scale
personal responsibility and career development to case studies, noted methods expert Craig Larman
architectural techniques for keeping your code flexible presents the most convincing case ever made for iterative
and easy to adapt and reuse. development. Larman offers a concise, information-
packed summary of the key ideas that drive all agile and
iterative processes, with the details of four noteworthy
iterative methods: Scrum, XP, RUP, and Evo.
More Titles of Interest
• L
iveLessons provides the ability
to learn at your own pace and
avoid hours in a classroom.
Package includes:
• 1 DVD featuring 3 - 8 hours of
instructor-led classroom sessions
divided into 15-20 minute
step-by-step hands-on labs
• S ample code and printed
study guide
35
+ FREE
SHIPPING
%