Академический Документы
Профессиональный Документы
Культура Документы
Being Agile - Your Roadmap To Successful Adoption of Agile
Being Agile - Your Roadmap To Successful Adoption of Agile
Index�������������������������������������������������������������������������������������������������������������249
CHAPTER
Getting Started
Adapt or perish, now as ever, is nature’s inexorable imperative.
—H. G. Wells
Throughout the history of the human species, people have learned to adapt to
the environment.When the weather got too cold during the ice ages, Northern
Hemisphere peoples either migrated south or adapted their clothing to live in
the cold. People have adapted their eating habits, tools, and resistance to cer-
tain germs.Theories of physical and cultural evolution postulate that successful
human populations and processes continuously adapt to their environments.
As a complex process practiced by a specialized subpopulation in a rapidly
changing technological and business environment, we are under constant
adaptive pressure to evolve. Somewhere along the way, however, many of us in
the world of software development have grown content with fixing long-term
goals, and we resist adaptive pressures to make corrective course changes.
This conservative inertia has definitely gotten in the way of how we do busi-
ness, clogging it with unwieldy upfront requirements and inflexible planning.
The good news is that companies are seeing the benefits of moving back to a
more adaptive approach.
Agile has secured its place within the software development community where
it originated and evolved, and now Agile is spreading into many other areas of
the professional workplace, where its embrace of adaptive feedback can help
businesses thrive. Many are seeing that a more iterative approach allows them
the flexibility to adjust to the changing needs of customers and the continuous
churning of market conditions. Many others would like to apply Agile effec-
tively because they are hearing it from all corners of their professional life.
No matter how prevalent and popular the adoption of Agile has become, get-
ting started with Agile and then continuing to apply its methods and practices
remain significant challenges. This is what I call “doing Agile,” by which I mean
2 Chapter 1 | Getting Started
Need for
culture
change
Figure 1-1. Agile elephant in the room. Agile requires a culture change, but most only want
to apply tool and process changes
• Agile assessments
• Grooming in-house talent
• Performance reviews in Agile world
• Agile organizational governance
• Agile adoption case studies
■■Agile Pit Stop Pay particular attention to the Agile Pit Stops throughout the book. They
illuminate ideas with examples or highlight important points, cautions, or tips.
Crossing the
Agile Chasm
Anything can be achieved in small, deliberate steps. But there are times
you need the courage to take a great leap; you can't cross a chasm in two
small jumps.
—David Lloyd George
Adopting a new concept often proves harder than it seems at first. Adopting
Agile is definitely a case in point. Although Agile is still relatively new, hav-
ing been formally defined by a meeting of seventeen signatories in February
2001 in their “Manifesto for Agile Software Development,” it has gained sig-
nificant adoption over the past decade.1 At first glance, it appears that many
software development–related companies have adopted Agile at some level.
However, on further investigation, it appears that only some parts of Agile
are being adopted and often in a spotty manner. A few data points that help
us understand Agile’s current adoption levels include the following. A 2012
study on product team performance done by Actuation Consulting indicates
that 71percent of surveyed organizations self-reported using Agile to some
degree.2 This sounds significant, right? However, that study showed that only
13 percent reported that they are using “pure” Agile in the sense that Agile
values and principles were being followed and iterative incremental techniques
were not being mixed with other methodologies. A 2009 study indicated that
1
See Kent Beck, et al. "Manifesto for Agile Software Development," (2001),
http://agilemanifesto.org.
2
Actuation Consulting and Enterprise Agility, "The Study of Product Team Performance,
2012," http://www.actuationconsultingllc.com/whitepaper_request.php.
8 Chapter 2 | Crossing the Agile Chasm
Change Type
Culture
Procedure
Skills
Figure 2-1. Dynamics of organizational change (source: adapted from Paul S. Adler and Aaron
Shenhar, “Adapting your Technological Base: The Organizational Challenge,” Sloan Management
Review, 2, no. 1 (Fall 1990), figure 2, 36)
Imagine for a moment that you are in Italy. You learn to drive a Ferrari and
enjoy driving it around. Does this make you an Italian? Of course not. You
have learned an exciting new skill on an Italian machine, but it doesn’t mean
you can interact as an Italian with locals around you.
Now imagine that you have learned enough Italian that you can walk into a
café in Rome and order a fette biscottate and caffé e latte for your colazione.
Does being able to order breakfast make you an Italian? Of course not. You
know the procedure and vocabulary for ordering breakfast, but it doesn’t
mean you can interact as an Italian with the locals. To the Italians around you,
you stick out like a sore thumb.
Now imagine that you have lived in Italy for several years, immersed yourself
in the language, and adopted the local customs (instead of shaking hands, you
air-kiss on both cheeks). You have achieved a sophisticated understanding of
Italian wines and the precise weight of the cloth needed for your clothing to
hang elegantly. You engage in animated discussions with the locals about the
various regions and subcultures within Italy. Does all this make you an Italian?
It won’t right away, but the Italians around you will credit that you are making
an honest effort to change your behavior and are really attempting to under-
stand not only how Italians do things but why they do things. Over time, your
own culture will change enough that you start internalizing the Italian culture.
There's the key correlation: a culture change of large enough magnitude to
be internalized and recognized as “being Italian” will take you a lot of effort
expended over a long time.
Many who have implemented Agile think that it is a procedural change that can
be layered into their organization with little change to their current culture.
I believe the contrary: if you don’t think Agile should fundamentally change
10 Chapter 2 | Crossing the Agile Chasm
your culture, then your half-measures will block the business benefits you are
looking for.
To gain an appreciation of the full potential of Agile within your company, read
the rest of this chapter and the next four chapters. Culture change in Agile
isn’t just for the engineering department but for the whole organization. The
Agile journey isn't just an option for the self-selected few; everyone must sign
on to adapt their behavior in alignment with Agile values and principles.
In this model, innovators are described as educated risk takers who enjoy
innovation, are willing to try out new ideas, and are more tolerant of mistakes.
They require little guidance and actually enjoy spending hours figuring out
how to adopt the innovation. Innovators are helpful critics who are ready to
invest the time and effort to get the innovation to work. The early adopters
are described as educated community leaders who are constantly seeking
Joe M. Bohlen and George M. Beal, “The Diffusion Process”, Special Report No. 18,
4
better ways and looking to gain visibility and credibility, while accepting some
level of risk. Both the innovators and early adopters have seen the intrinsic
benefits of going Agile and are fairly sincere in their efforts to change their
behavior and culture for the better.
The early majority are described as more pragmatic, open to new ideas, and
avid for ways to become more successful. Whereas innovators and early
adopters are willing to struggle to make the new innovation work, the early
majority are looking for guidance on how to adopt it so they can manage
the change more carefully. The late majority and laggards await the results of
those who blaze the trail and are often pushed, sometimes grudgingly, into the
new world. These last two groups are the ones least interested in changing
their culture.
Geoffrey A. Moore, Crossing the Chasm (New York: Harper Business Essentials, 1991).
5
12 Chapter 2 | Crossing the Agile Chasm
Agile
Cultural
Chasm
Figure 2-3. Crossing the Agile chasm requires that you apply a new set of values and
a significant shift in behavior
■■Agile Pit Stop There is a “fake chasm” crossed by those unwilling or unable to make the
behavioral changes to cross the real Agile chasm. This is exemplified by such practices as Fragile,
ScrumBut, and ScrumFall prevalent in the software industry.
I cannot overstate this point: many companies and teams within companies
are mechanically doing some form of Agile without having actually crossed
the Agile chasm, discarding the behavioral baggage that is keeping them from
being Agile. Until a team attains the state of being Agile, the business benefits
that Agile can provide will be elusive. I contend that the industry has barely
entered the early majority of true Agile cultural transformation, and many
companies continue to struggle to leap the Agile chasm or, in many cases, even
recognize that they have only crossed a fake Agile chasm.
Being Agile 13
■■Agile Pit Stop Many are only mechanically “doing” Agile and have not yet really begun to “be”
Agile (i.e., actually applying the values and principles of Agile).
Looking through the lens of the adoption lifecycle model, let’s review the
results of the surveys on Agile’s adoption levels mentioned at the beginning of
this chapter. The 2012 study referenced earlier indicated that 71 percent of
organizations self-reported using Agile to some degree. This level of adoption
would seem to suggest that Agile has reached the late majority stage. But the
same study indicated that only 13 percent said they were using “pure” Agile.
This statistic would seem to suggest that Agile is still in the early adopter
stage. The 2009 study mentioned earlier indicated that 35 percent of respon-
dents follow one form of Agile or another. This fact would seem to suggest
that Agile is in the early majority. Although both studies report significant
levels of adoption, those levels are sufficiently low as to be consistent with the
proposition that crossing the Agile cultural chasm is proving a tough challenge
for a majority of companies.
Key to meeting this challenge is identifying ways to bridge the communities of
the early adopters and the early majority. While the early adopters are very
willing to take risks and try new things, the early majority are less risk-tolerant
and look for guidance that will help them reduce the disruptive stresses of
Agile adoption. They have seen the benefits of Agile around them, but they
need more help in its adoption. In some cases, prospective adopters may be
pushing the boundaries of Agile. A good example is that early adoption of
Scrum focused on small collocated product teams. However, as folks saw the
success of Scrum, the industry has learned to adapt it for larger, more distrib-
uted product teams. In short, companies seek a solid foundation of information
and guidance to help them cross the chasm.
This book lays the foundation for those who want to cross the Agile cultural
chasm, understand the behaviors that need to change, and gauge progress
along the way. It provides an Agile transformation roadmap to the destination
of Agile: business benefits.
CHAPTER
Business Benefits
of Being Agile
Profit in business comes from repeat customers that boast about your
project or service and that bring friends with them.
—W. Edwards Deming
■■Agile Pit Stop Do not introduce senior management to the mechanical aspects of Agile
first. Instead, introduce them to the agile principles, business benefits, and their role in the agile
transformation. This way they realize that Agile helps their business opportunity and that they have
a role to play.
The good news is that applying an adaptive framework like agile methods can
reduce many of these problems. For example, if you reach every scheduled
release date, you bring the project in on budget, and you build it with quality,
but you do not build features that customers want, they will not buy it and
you have failed. This is why I contend that if you align your culture and pro-
cesses around building customer value (e.g., what customers need and when
they need it), then you will be successful and have increased your chances of
making money.
■■Agile Pit Stop If you finish within the schedule, bring the project in on budget, and build it
with great quality, but do not deliver what the customer wants, they will not buy it and your business
may fail.
In addition, I see Agile often focused on the engineering side of the company
because there is a lack of understanding that Agile will help an organiza-
tion’s bottom line. Although Agile will benefit the engineering side, particu-
larly eXtreme programming (XP) practices, Agile should really be driven
by strong business reasons. If you look at Agile as a business tool to make
more money for the organization, you will gain greater buy-in from senior
management, who are often the sponsors of agile programs and are looking
for a business edge.
100 15
50 Money
0
200
0
Figure 3-1. Gauges for your agile dashboard: adjust your levels of customer and employee
engagement to see the changes to your profits
I leave executives to ponder whether they think these sincere actions can
lead to making more money. In my experience, this gets them to actively
listen, versus the passive listening they may exhibit when they think Agile
is an engineering method or something the engineering team and others
must do.
Yes, Agile can increase productivity. Yes, it may reduce your time to market.
Yes, it can improve employee morale. Yes, it can help you manage change. Yes,
it can help you increase project visibility. Yes, it can help you improve quality.
Yes, it helps in many other ways. And yes, Agile can lead to an increase in
customer sales, ergo an increase in profits. This is all true if Agile is imple-
mented correctly.
■■Agile Pit Stop Attention all executives/senior management types: Agile is really there to help
make you more money!
There I said it: if Agile is implemented correctly. This is a big and important if.
The if means that Agile must be implemented sincerely, aligned with agile
values and principles, and with a special focus on the customer and employee.
This is where I contend that an organization really has to “be Agile” to get to
the point of affecting their profits. It does not mean that a company can do
anything to make money, and it particularly implies that you have to think and
act differently to achieve the results you are looking for.
Being Agile 19
■■Agile Pit Stop It is through the customer and employee that you draw your power within an
agile culture and within any thriving company.
When you have a riveting focus on the customer and you believe that an
engaged customer matters, then you have the basis for a relationship where
you can truly understand what the customer wants. When you have a sharp
focus on employees and provide them the space to make decisions and own
their work, then you will begin to understand the value an engaged employee
base can provide.
Upon closer inspection, the values should translate into objectives focusing on
customer engagement and employee engagement.
• Customer engagement focuses on establishing meaning-
ful and honest customer relationships with the goal of
initiating continuous customer feedback to truly identify
what is valuable to the customer. This includes establish-
ing all of the activities involved in attaining this.
• Employee engagement focuses on empowering employ-
ees so they can self-organize into teams and can own and
be a part of the decision-making process at their own
level.
Then we add the “secret ingredient” of applying a continuous and adaptive
approach (a.k.a. agile processes, methods, practices, and techniques). If done
properly with the ability to adapt, this can lead to an increase in customer
sales and an increase in team productivity. This finally leads to your incentive,
which is an increase in company profits (more money).
Approach
Vision Objectives Result Incentive
Agile Values & Principles
Customer Increased
(Continuous and adaptive)
And
Employees
Matter Employee Increased
Engagement Productivity
I know this is both simplistic and difficult, but if implemented and if the vision
is sincere, it may be achieved. The goal of this book is to help you adjust
your mindset to achieve the vision and objectives. How true you are to the
vision and objectives is up to you. Please note that you will have a depen-
dency on your sales and marketing practices, but if you are building customer
value (i.e., what your customer wants), then marketing and selling should be
easier. Because customer value is so important, let’s take a closer look at
understanding this concept.
Being Agile 21
As you may know, a key focus of Agile is to deliver customer value. Value is
the benefit a customer will get from your product or the functionality if you
align with their needs. Customer value should be specified from the perspec-
tive of the end customer or those receiving the value from a specific product.
The authors of Lean Thinking put it this way:
Value can only be defined by the ultimate customer. And it's only meaningful
when expressed in terms of a specific product (a good or a service, and
often both at once), which meets the customer's needs at a specific price
at a specific time.1
■■Agile Pit Stop Customer value = customer needs + right timing + right cost conditions. It is an
elusive target that must be adapted to continually.
Customer value has both temporal and cost conditions. It is an elusive target
that must be adapted to continually. What is considered valuable today may
not be valuable tomorrow.
For example, in the 1980s, cellular phones were large and emulated the shape
of a brick. In the 1990s and into the early 2000s, customers valued smaller
and smaller phones. We saw evidence of this with the Motorola StarTac cell-
phones and the even smaller Pantech C300. But in the late 2000s and early
2010s, customers began valuing larger screen sizes on their phones due the
advancement of smartphone technology (see Figure 3-3). We see evidence
of this with smartphones now having 4.7-inch screens and larger. Build a great
small phone for the wrong time, and few customers find it valuable.
1
James P. Womack and Daniel T. Jones, Lean Thinking: Banish Waste and Create Wealth in
Your Corporation (Productivity Press, 2003).
22 Chapter 3 | Business Benefits of Being Agile
Brick
Figure 3-3. Evolution of the cellular phone—from larger to smaller to larger again
This provides us with more evidence as to why Agile and its continually adapt-
ing nature is so important in the effort to grasp the elusive customer value.
From an agile perspective, this specification of what is customer value for a
product should be a continuous activity to ensure you align and adapt with the
ever changing needs of the customer and sporadic changing conditions within
the marketplace.
■■Agile Pit Stop To grasp the elusive customer value for a product, there should be continuous
customer engagement to ensure we align and adapt with the changing needs of the customer and
changes within the marketplace.
into your business strategy, you can set the levels of customer and employee
engagement to see how they affect customer value and employee empower-
ment and eventually your profits.
With this in mind, let’s take a closer look at what the vision of “customers and
employees matter” really means. Let us start by discussing the importance
of customer engagement (Chapter 4) and then the importance of employee
engagement (Chapter 5).
CHAPTER
Importance
of Customer
Engagement
No plan survives contact with the customer.
—Variation on Helmuth von Moltke
■■Agile Pit Stop The moment you engage with customers, the plan will not survive. But what is
more important: the precious plan or meeting customer needs?
26 Chapter 4 | Importance of Customer Engagement
■■Non-Agile Pit Stop An analogous predicament that many individual consumers experience is with
cable TV service. Cable TV providers offer subscription channels only in big, expensive, one-size-fits-all
bundles without reference to the individual customer’s needs, use patterns, or preferences. A result of
this is that customers are compelled to pay each month for hundreds of channels that they could not be
paid to watch. No wonder millions of cable customers have cut the cord (or are itching to do so).
1
Rob Adams, If You Build It,They Will Come (Wiley, 2010), 1–2.
2
Jim Johnson at Third International Conference on Extreme Programming, May 2002.
3
Theron R. Leishman and David A. Cook, “Requirements Risks Can Drown Software
Projects,” CrossTalk: The Journal of Defense Software Engineering (April 2002).
Being Agile 27
Of the many reasons for new product failures, two stand out. First, many compa-
nies are not as in touch with their customers as they believe they are. Second,
many companies aim to build a global set of features for any new product that
will be imposed on every customer willy-nilly. They ignore the Agile approach:
start out with a minimal set of core features based on customer prioritiza-
tion and feedback, get the new product to market sooner, and build out the
product based on ongoing and specific customer input.
As an exercise, ask yourself:
• What percentage of products have you built that have
failed?
• What percentage of functionality of your released products
is unused or has low usage?
It can be painful to answer these questions, because you may not want to
hear the bad news. However, to avoid repeating the mistakes of the past,
it is good to understand how you arrived at this situation and then, more
important, how you can mitigate or avoid the same mistakes moving for-
ward. Understanding and acting on the twin notions of continuous customer
engagement and feedback and minimum viable product can help you build
products customers want and value.
■■Agile Pit Stop What the customer sees as progress is not project documents, project plans,
and more status reports. Rather, customers see progress as tangible working product functionality.
28 Chapter 4 | Importance of Customer Engagement
We need to think like the customer. What the customer sees as progress
is not the standard project documents, a project plan that indicates the task
completion, or more status reports. Rather, customers see progress as tangible
working product functionality. They purchase working software, not the plans,
status reports, and other intangibles. Customers delight in seeing working
software in action and the inspect-and-adapt approach allows customers to
reconsider and adjust their needs until they are transformed into a valuable
working product. Progress is not advanced until a piece of functionality is
built with quality, meets the customer acceptance criteria, and is available for
review by the customer in the demonstration.
Functionality equates to value for the customer and ultimately means deliver-
ing that business value. Of course, this implies that you have to continuously
engage with the customer to get there. Engaging with customers only during
the requirements-gathering phase and approaching product launch phase is
not enough. We need to continuously engage with customers as we are actively
building the product throughout the project life cycle.
■■Agile Pit Stop Engaging with customers only when gathering requirements and before product
launch is not enough. We need to continuously engage with customers as we are actively building
the product.
2014 Plan
Need Design Build Test Deliver
Waterfall
Wide
Gap
Changing Customer
Needs Customer Need
2014 Changing 2015
Need Market Conditions Narrow
Deliver Gap
Adapt
Need
Adapt
Need
Adapt
Agile Adapt Need
Need
2014
Need
Figure 4-1. Agile adapts to changing customer needs and market conditions. The gap between
what gets delivered and what the customer needs will be much smaller in Agile than in waterfall
For a waterfall-based project, the longer the time from the initial need (a.k.a.
requirements phase) to the release of the product, the greater the risk
(a.k.a. gap) of delivering unwanted functionality. As you will recall from Chapter 3,
part of the definition of customer value is the timing. If you define require-
ments up front in the beginning of the year, inhibit the changes throughout
the year for the release, when you get to the end of the year, the gap between
what you delivered and what the customer needs may be quite wide.
In Agile, we follow a continuous build-inspect-adapt model so that require-
ments are continually validated with the Product Owner and customers dur-
ing each iteration review (a.k.a. Sprint Review). This practice ensures there
are continuous customer engagement and, more important, a continuous
customer feedback loop. At the end of the project, the result should be a
narrow gap between what was delivered and what the customer now needs.
The narrower the gap, the more money a company is likely to make.
30 Chapter 4 | Importance of Customer Engagement
4
Scott Ambler, “Agile Adoption Strategies: November 2011 Survey Results,”
http://www.ambysoft.com/surveys/agileStateOfArt201111.html.
Being Agile 31
Potentially
full product functionality
Figure 4-2. Applying the MVP approach. You can release earlier where the customer can
use the value earlier and you can achieve an earlier ROI. Win-win for all!
■ Agile Pit Stop Agile does not advocate an arbitrary change to requirements. Instead, change
must be strongly related to the priority that customers place on the value of what is being built.
You should be alert to the possibilities of adapting your MVP along the way.
What would you do if a customer were to say during the middle of a project
that if you could get them the functionality they just saw during the demonstra-
tion portion of the Sprint Reviews, they would buy your product? Because of
the continuous engagement, you can deliver this value to them for a revenue
increase on your end and a delivery of customer value on theirs. Even if you
don’t apply the MVP methods, you should at least apply basic customer priority
techniques to ensure you build what the customer currently finds valuable.
Importance
of Employee
Engagement
As a society we know the best way to organize people is freeing them to
organize themselves. Why should it be any different in business?
—Thomas Petzinger Jr.
1
Brian E. Becker, Mark A. Huselid, and Dave Ulrich, The HR Scorecard: Linking People, Strategy,
and Performance (Harvard Business Review Press, 2001).
34 Chapter 5 | Importance of Employee Engagement
One study found that of the forty best companies to work for, thirty-four
included employee empowerment as part of their organizational strategy.2
That study concluded that employee empowerment within the corporate
culture is a “potential source for sustained superior financial performance.”
Employee empowerment can lead to tangible organizational performance and
thus should be taken seriously.
■■Agile Pit Stop Employee empowerment isn’t just a warm-and-fuzzy benefit for the workers, but
can lead to tangible performance and financial gain for an organization.
The goal for your company is to make people matter and introduce real action
that will improve employees’ engagement, ultimately leading to the financial
benefit of the company.
Employee Empowerment
Everybody has heard the term empowerment in organizations—typically to
hype up a new initiative so that employees will feel empowered. But it begs
the question, “Shouldn’t employees already feel empowered?” Empowerment
should be a core value of an organization’s strategy and not a trend that
comes and goes. However, this is not the case for many organizations.
What exactly is employee empowerment? It is a framework that enables
employees to control their own work and destiny. The brainpower and moti-
vation of the talented folks who are hired are tremendous assets to a company.
Jane Smith presents an employee empowerment model that includes three
degrees of empowerment (Figure 5-1).3 The first level encourages employees
to play a more active role in their work. The second level asks employees to
become more involved with improving the way things are done. The third
level enables employees to make bigger and better decisions without having
to engage upper management. The third level is key for an Agile culture.
2
Darrol J. Stanley, “The Impact of Empowered Employees on Corporate Value”: Graziadio
Business Review, 8, no. 1 (2005).
3
Jane Smith, Empowering People (Kogan Page, 2000).
Being Agile 35
Enable
Empowerment
Degree of
Involve
Encourage
Organizational Benefits
Figure 5-1. Employee empowerment model with the goal of increasing empowerment
If management is earnest about applying a model like this, they can benefit in
the following ways. They may see improvements in the quality of their product
delivery, more innovation, increased productivity, and a gain in competitive
edge.
Of course you want to empower your people. Yet somehow we have evolved
into tribes and organizations where only management seems to know what is
best. It is important to remember that management still has a role to play, and
one of those roles is to get the most from their employees. This doesn’t mean
making them work longer hours, but gaining their input and allowing them to
make the decisions they need to control the work at their level.
If you think about it, employees go home and make decisions in their daily
lives and manage thousands of dollars in their own personal budgets. But
when they go to work, many of them have little discretion over even $100 of
decision making and are forced to seek approval for the smallest things.
■■Agile Pit Stop Why do employees who make decisions in their daily lives and manage
thousands of dollars in their own personal budgets have so little discretion over the smallest things
within their company?
Self-Organizing Teams
So what does self-organizing team really mean? Diana Larsen writes:
Sr Mgt Ap
pro
val
Ow or D
ne e
rsh cisio
Middle Mgt ip n
Team
Vertical Horizontal
Hierarchy Empowerment
Figure 5-2. Cultural shift involves pushing down the level of decisions to the lowest possible
level at which the most knowledge exists to make the best decision
Diana Larsen and Industrial Logic, “Team Agility: Exploring Self-Organizing Software
4
Evidence of Self-Organizing
What do self-organizing teams look like? The following are some demonstrable
attributes of a self-organizing team.
• Decision making: Team members make their own deci-
sions about their work. Who better to make decisions
than those who have the details?
• Sizing work: Team members size or estimate their own
work. Who better to size the work than the people who
work on the product and know its complexity?
• Team spirit: Team members have a strong willingness to
cooperate and know that unless all succeed in their part,
none succeed in the whole.
• Common goals: Team members feel they are coming
together to achieve a common purpose through release
goals, sprint goals, and team goals.
38 Chapter 5 | Importance of Employee Engagement
For Scrum to work, the team has to deeply and viscerally understand
collective commitment and self-organization. Scrum’s theory, practices,
and rules are easy to grasp intellectually. But until a group of individuals
has made a collective commitment to deliver something tangible in a fixed
amount of time, those individuals probably don’t get Scrum.5
Ken Schwaber, Agile Project Management with Scrum (Microsoft Press, 2004).
5
Being Agile 39
QA DEV
PO TW SM
Scrum
Team
Notice how this involves moving away from a single point of leadership to a
flat team model in which everyone is a leader when it is appropriate and no
one person tells others what to do.
Stepping Up
Agile entails a radical change not just to the culture of management but also
to the culture of those in engineering. There is a strong expectation that man-
agement will step back and allow the Agile Team to be self-organized. On the
engineering side, there is an expectation that they need to step up, communi-
cate more, and be more assertive. This can be challenging. Whereas there is a
lot of focus on getting management to step back, there isn’t enough focus on
getting Agile Team members to step up.
Engineers tend to be introverts, so the notion of being assertive—let alone
confrontational—can be uncomfortable. Often Scrum Masters end up doing
a lot of the policing to ensure agile practices are being executed well. The
Scrum Master may be seen “nagging” late arrivals to meetings and must push
people to speak up. However, it is not just the Scrum Master’s responsibility
to be assertive; every team member must be willing. Remember, Agile is for
everyone, and every team member should consider himself or herself a leader.
Are you stepping up?
In a hierarchical world, projects are managed by directive. A hierarchy exists
where decisions get made based not necessarily on full knowledge, experi-
ence, or information but on position. Often, decisions are made by a few folks
40 Chapter 5 | Importance of Employee Engagement
and then shared with the team. Ultimately this establishes a culture in which
people on the project team become timid, lack enthusiasm, and do not feel
ownership in the work. If this culture has been embedded, it can take an even
bigger effort to motivate more assertive and extroverted behavior.
■■Agile Pit Stop Though there is focus on getting management to step back, there isn’t enough
focus on getting team members to step up. Engineers tend to be introverts and may be used to
getting instructions. Changing this culture may be more challenging than you think.
Then along comes Agile. When implemented correctly, the Agile mindset
places a strong emphasis on a team’s self-organizing capabilities. There is an
expectation of limited command-and-control from management. The teams
are trusted to make decisions because they are much closer to the details
and have experience in that area. Team members feel invested in the work to
come because they have a say in the direction of the product.
However, transitioning to an Agile culture does not immediately gain the
advantages that you desire. There must be a recognition that managers and
some overly directive people need to step back. However, when they do so,
the team members must step forward to fill the leadership gap. If you want
to feel invested in the work, you must be willing to take the responsibility of
owning the decisions (see Figure 5-4). Otherwise, those people who stepped
back—management—will have an habitual tendency to step forward again to
fill the vacuum.
Ownership
Accountability
Responsibility
of Work
Step Up Step Back
Figure 5-4. Agile Team members must step up to accountability of the work as the
management are stepping back
What does this mean in the Agile context? First, as you become part of an
Agile project, you must truly internalize that employees are now equally part
of the team and their thoughts, experience, and opinions matter. This does
not happen overnight because the dynamics of getting to an Agile culture are
challenging and take time. There will be those working against you, sabotaging
the change to maintain the status quo. Make no mistake: it is up to you to step
up and assertively empower yourself.
So the next time you don’t think you are appropriately involved on the project
or you think you need permission to speak up, stop for a moment. Change
your mindset and be assertive, step up, get involved, become a leader, and start
owning the decisions and work. Agile provides that opportunity. It is your
opportunity to take advantage of it.
■■Agile Pit Stop NVAW (a.k.a. waste or muda) are effort that do not directly add value as
perceived by the customer and may include unneeded functionality or unnecessary steps in a
process of building working software.
6
Mary Poppendieck and Tom Poppendieck, Lean Software Development: An Agile Toolkit
(Addison-Wesley Professional, 2003).
Being Agile 43
Non-Value -
Value-Added -
Added Tasks
build the
45%
Product Tasks
55%
■■Agile Pit Stop It can be hard separating work into value-added and non–value-added because
it can highlight the level of NVAW that is being done.
Another benefit of identifying VAW vs. NVAW is that when you are consider-
ing the velocity or productivity of teams in regard to building new function-
ality, the percentage of NVAW is a direct impediment to a team’s ability to
build new functionality. In other words, it is not uncommon for management
to think that employees are using a majority of their work week building new
functionality when the reality is that only 50 percent may be spent doing so.
What were the perceived benefits obtained from implementing Agile? It is one
thing to have certain reasons for moving to Agile, and quite another to see
if the benefits are realized. Within the 2012 VersionOne survey on Agile, the
results highlighted some benefits we are looking for.7
• 90 percent of those surveyed felt that “ability to manage
changing priorities” “got better” within their company.
• 85 percent of those surveyed felt that “increased produc-
tivity” “got better” within their company.
• 84 percent surveyed felt that “team morale” “got better”
within their company.
These results bode well for Agile. However, this does not accidentally occur.
Companies must include this into their business strategy to highlight that
they take the notions of customers, employees, and Agile seriously. Maybe the
vision where “customers and employees really matter” makes sense after all.
The question is: how important is it to delight your customers by building
customer value and harnessing the brainpower of your employees? While it
is easy to reflexively say “very!,” the reality is that we get distracted by the
day-to-day “administratium” of the company and forget our values. Ultimately
your results will vary depending on the sincerity and commitment you have
to customers, employees, and Agile.
7
VersionOne, “7th Annual State of Agile Development Survey,” November 2012,
http://www.versionone.com/pdf/7th-Annual-State-of-Agile-Development-
Survey.pdf.
CHAPTER
Foundations
of Agile
Agility is more attitude than process, more environment than methodology.
—Jim Highsmith
Process
Values and Principles over Methodology
Practices
Tools
Figure 6-1. Though there is value in the items on the right, we value the items on the left more
I ask you to take a moment to understand this and learn more about the
overarching values and principles of Agile.
46 Chapter 6 | Foundations of Agile
Agile Is a Set of V
alues and Principles . . .
Seriously!
The foundational building blocks of Agile are its values and principles. This is
probably the most important point that is often misunderstood and needs to
be recognized. Agile is not a process, methodology, practice, or tool but a set
of values and principles. The implication is that Agile is more about a state of
being: the Agile mindset. Processes and methodology can help you do Agile in
the mechanical sense, but Agile is a culture shift that requires a willingness to
adapt to the Agile mindset. Agile values and principles are components of the
Agile mindset.
■■Agile Pit Stop Agile is not a process, methodology, practice, or tool but rather a set of values
and principles. The implication is that Agile is essentially a state of being: the Agile mindset.
It is important to not just read the Agile values and principles found in the
Agile Manifesto, but embrace them. Why do you want to embrace these val-
ues and principles? Maybe it is because you believe in the importance of cus-
tomer and employee engagement and that providing value to the customer is
important to the success of your business. Maybe you realize that you need
to be more adaptive because uncertainty exists and customer needs change.
Reading Chapter 3 provides you a better understanding, but ultimately you
own the answer to this question.
The last phrase helps us understand the authors’ intentions. They are not
saying there is no value in the items on the right, but instead that they have
less value than the items on the left. Those who disregard the items on the
right are either Cowboys or Bandwagon Jumpers who do not know better, or
beginners who have not gained an appreciation of striking the right balance.
■■Agile Pit Stop Because it is human nature to evolve over time, we should assume that the
needs of customers will evolve.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and sup-
port they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within
a development team is face-to-face conversation.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes
and adjusts its behavior accordingly.
Take a moment now to reflect on these Principles. What are some of the
attributes of the Principles that stand out? As you reflect on these, can you see
if your product team or organization aligns with any of these Principles?
In Chapter 9, I dissect each of the Principles to better understand what it
means to align it with the mindset that it represents. In Chapter 13, I provide an
adaptable assessment mechanism that can be used to determine where your
team or organization is in relation to being aligned with the Agile Principles
and so having an agile state of mind. Remember, it is not enough to say I am
mechanically “doing” Agile practices. Instead, to gain the business benefits of
Agile, you need to “be Agile” and live these principles.
■■Agile Pit Stop There is nothing called the “agile methodology.” Remember, Agile is a set of
values and principles.
With that in mind, there have been several frameworks, processes, meth-
odologies, and practices established in an attempt to support and promote
the agile values and principles. This section will focus on Scrum, XP, DSDM,
and Kanban because they may be more commonly encountered. It will also
discuss Lean and Value, Flow, Quality (VFQ). While they are not agile processes
or methods, they can help us align with the agile values and principles. The
purpose here is to understand them. Even though I am highlighting these, it
does not imply that they are necessarily better than any of the others not
discussed here. There is no one correct process or methodology to use. The
best one is the one that suits your working environment and your type of
work. Let us examine these in more detail.
Scrum
Scrum is an iterative and incremental framework used to build software. It fol-
lows an inspect-and-adapt process to support product development and con-
sists of Scrum roles, events, artifacts, and rules. The roles inform and surround
the Scrum Team; the events are planned team activities that are time-boxed
within the concept of a sprint, typically 1 to 4 weeks; and the artifacts are the
items used in Scrum that represent work in some manner and illustrate prog-
ress. Rules are applied to the roles, events, and artifacts.
Scrum is not an acronym, so it should not be in all capitals. The word derives
from a team formation in rugby in which the team moves forward as an inter-
locking unit in a manner that each player has a specialty function yet all players
are contributing equally and simultaneously to the team’s forward progress
toward a common goal. Scrum provides agile project and product manage-
ment events or practices. Scrum is often used in tandem with XP, which pro-
vides many of the agile engineering practices.
■■Agile Pit Stop Scrum is a sports term borrowed from rugby. It is not an acronym, so do not
capitalize the letters.
An important aspect of Scrum is that the customers can change their mind
on their needs as necessary to ensure they are getting the product they want
and need at the end. This approach recognizes that customer needs and mar-
ket conditions change and does not try to stifle—and indeed welcomes—the
change activity. Changes can be added to the Product Backlog at any time
and reprioritized according to the customer needs. During the next Sprint
Being Agile 51
Planning session, any new changes can be considered for the new sprint. It is
important to note that once a sprint is started, there should be no attempt
by the customer or team to change the requirements. Instead, allow the team
to focus on the prioritized requirements from the planning session. Although
there are exceptions to this rule, it allows the team to focus in short bursts
and produce working software that the customer can respond to.
The primary overarching role in Scrum is the Scrum Team. The Scrum Team
is meant to be self-organizing so that members feel empowered to make the
decisions and feel ownership of their work. The Scrum Team members are
those committed to building the product and include the subroles of Scrum
Master, Product Owner, and Development Team.
• The Scrum Master acts as a motivator for Scrum. This role
acts as coach to the team to ensure that the Scrum roles,
events, artifacts, and rules are understood and implemented
effectively. He or she is the primary facilitator of the team.
• The Product Owner (PO) represents the customers, is the
customer liaison, and is primarily responsible for under-
standing what is considered valuable from the customers’
perspective. The PO is the primary owner of the product
backlog, where value is expressed.
• The Development Team is a cross-functional group of engi-
neers who build the functionality. They are made up of
personnel with cross-functional skills so that they have
the capabilities to build the product without having to
rely on others outside of the team.
Scrum events are meant to provide an imbricated pattern for the work. Each
event relies on the other and provides input to the next event. When one or
more of the events are missing, this reduces the effectiveness and ability to
inspect and adapt. The Scrum events include:3
• Sprint Planning is held in the beginning of each sprint and
focuses on understanding the user stories that will be
worked on in the sprint. The goal is for all Scrum Team
members to plan this work. The list of work that can fit
into a sprint is known as the sprint backlog.
• The Daily Scrum is a daily event time-boxed to no more
than 15 minutes in which the Development Team com-
municates progress among themselves and introduces
any encountered roadblocks.
3
Ken Schwaber and Jeff Sutherland. The Scrum Guide (2013). www.scrum.org/Portals/0/
Documents/Scrum%20Guides/2013/Scrum-Guide.pdf#zoom=100
52 Chapter 6 | Foundations of Agile
■■Agile Pit Stop The primary roles in XP are the Customer and Developer. Other, less formal
roles are the Tracker and Coach.
Being Agile 53
5
http://www.dsdm.org/
Being Agile 55
This is a bit unusual since most agile methods do not specifically have a step
to verify if the method will be suitable and instead assume it will just work.
However, ensuring that the methodology is aligned with the work and having
management support are critical to the success of the project.
This is one of several DSDM’s success factors. DSDM specifically calls out
the need to ensure management agrees to use the method and looks for a
commitment moving forward. The other success factors are having customer
involvement, an empowered project team, and a strong relationship between
the customer and vendor. DSDM views the full picture of software develop-
ment as areas to focus on because it is understood that any one piece that
goes awry can lead to problems. It should be noted that DSDM may be com-
bined with other methods and techniques like PRINCE2, XP, and Scrum.
Kanban
Kanban is a continuous flow method for managing the development and
delivery of products. Kanban is a Japanese term that translates roughly to
“signboard” or “story card.” This is because Kanban is primarily focused on
making the workflow visible and highlighting the constraints to that flow. The
origins of Kanban can be traced back to Taiichi Onho and the Toyota Production
System. In its more modern form, David Anderson identified five core principles
that support a successful implementation of Kanban.6 They are:
• Visualize your work so that you can see the work and in
context with other work.
• Limit the work in progress (WIP) using a pull system so
there isn’t an overflow of work at any step along the way
and so pace is understood.
• Manage the flow of work, applying measures so the team
knows how much work to commit.
• Make the process policies explicit so that improvements
can be made to acknowledged baselines.
• Improve collaboratively so there is the opportunity to
improve the working process and workflow.
Whereas in Scrum you would use a sprint to develop a batch of work, in
Kanban there is a continuous pull of single pieces of work.
David J. Anderson. Kanban. Successful Evolutionary Change for Your Technology Business. Blue
6
■■Agile Pit Stop I have found that Kanban is effective when the work is more interruption-prone
and when priorities can change from day to day.
7
Mary Poppendieck and Tom Poppendieck. Lean Software Development: An Agile Toolkit.
Addison-Wesley Professional, 2003.
Being Agile 57
■■Agile Pit Stop Often Lean is discussed in terms of eliminating waste. However, the real focus
of Lean is to identify value to the customer: deliver what they want, when they want it, and with the
minimum amount of effort.
8
www.valueflowquality.com
58 Chapter 6 | Foundations of Agile
Ready,
Implement,
Coach, and
Hone (RICH)
Deployment
Model
Before anything else, preparation is the key to success.
—Alexander Graham Bell
Ready
Hone Implement
Coach
When initiating the journey to Agile, I have found that it is important to begin
the process of conditioning the mind toward the Agile mindset. Readiness is
the beginning of the process of conditioning, and it includes making deci-
sions on the elements for your implementation. While it is important to lead
with readiness, this framework may be used iteratively depending on whether
you plan for a more holistic deployment or iterative deployment of certain
elements. With that in mind, I strongly encourage activities focused on readi-
ness to begin your goal of agile transformation.
Being Agile 61
Readiness starts the moment someone asks the question, “Is Agile right for
me?” The goal is to work through this question, understand your context,
and figure out how Agile might be deployed. Readiness can start weeks and
even months before you really get serious about moving down the agile path.
However, it can also be worked through quickly if you are ready to commit.
Readiness shouldn’t be taken lightly. It is important to understand the what
and the why prior to discussing the how and the when.
Once you believe Agile is a direction you would like to take, then aspects
of readiness activities are akin to conditioning the soil prior to growing the
seeds. It is good to take a hard look at the conditions of the fields, equip-
ment, and people. Strengthening the soil helps improve the physical qualities
of the soil, especially in its ability to provide nutrition for plants. You can make
poor soil more usable and rebuild soil that has been damaged by improper
management.
■ Agile Pit Stop Readiness activities are akin to conditioning the ground prior to planting the
seeds. Conditioning the mind with an understanding of Agile principles improves the ability to adopt
Agile in a way leads to being Agile.
This is exactly what readiness activities can do. It is good to examine the
condition of the environment where Agile is being considered. You must begin
the process of conditioning the mind with an understanding of Agile’s values
and principles and the business benefits that can be gained. This can improve
the ability to adopt Agile in a way that the participants begin to understand
the drive of being Agile. By conditioning the organization toward the Agile
principles, we can begin the process of understanding value and empowering
people.
I have found it important to understand the context in which Agile is being
introduced. For example, it is imperative to gauge the buy-in of executives and
stakeholders and willingness and capability of teams. Within an organization,
due to improper management, the employees are often reluctant to speak
up because of the lack of empowerment allowed and command-and-control
behaviors exhibited (explicitly or implicitly). Understanding this context pro-
vides valuable insight on ways to adapt and move forward.
62 Chapter 7 | R
eady, Implement, Coach, and Hone (RICH)
Deployment Model
begins the cycle of the team or organization getting Agile working on the
ground. Here are implementation activities that you may consider. As always,
feel free to adapt this list of activities to benefit your implementation.
• Provide agile education—just-in-time and work-based.
• Provide an Agile Team foundation workshop.
• Provide a Product Owner workshop.
• Provide a Scrum Master workshop.
• Provide agile education for executives and management.
• Initiate periodic Agile Q&A sessions.
• Establish an agile online community (resource website,
social website, etc.).
• Apply the agile framework and practices.
• Apply agile tools.
During the implementation, consider adding these activities to the RICH
backlog as the next sprint of activities. I recommend that once you embark
on these activities you continue periodic stand-ups to gauge progress and
adapt along the way. Also, as you are implementing, expect some roadblocks.
An effective implementation of Agile will affect those across the organization.
Be ready to resolve, mitigate, or improve these challenges. This is where
coaching and honing activities come into play.
Coaching activities come in several forms. Some coach from an agile perspec-
tive, some from a culture change perspective, and others from a sponsorship
perspective. Although an experienced Agile Coach may be responsible for
deploying Agile, coaching is not just limited to that person. Scrum Masters,
Agile Team members, Product Owners, executives, senior management, and
middle management all have coaching roles to play. Everyone should share
responsibility in the success and help each other along to get there.
■■Agile Pit Stop Coaching activities are not just limited to an Agile Coach. Executives,
management, and team members all have roles to play.
■■Agile Pit Stop The goal of a coach is to educate enough people and groom enough leaders that
they coach themselves out of a job.
Motivations for
Moving to an
Agile Culture
Motivation is the fuel necessary to keep the human engine running.
—Zig Ziglar
Communicating Motivations
On an annual basis, companies typically communicate objectives for the
upcoming year. Communicating “why we are moving in this direction” gives
employees a sense that the objectives have been carefully thought out. More
important, discussing the motivations with your employees can help you adapt
the motivations and gain buy-in for the objectives. Although getting employee
input may be risky, it can help you understand how realistic the objectives are.
Also, employees feel valued when you ask for their feedback. It can help get
the most out of people.
If your motivations are compelling and honest and benefit employees, this can
lead to employees being willing to participate in the change. A clear role in
achieving the objective further enhances an employee’s willingness to partici-
pate in the change. The more meaningful the “why” behind the motivation, the
more willing the employee will become to support the objective.
If you find that you haven’t established objectives and accompanying motiva-
tions behind your agile initiative, now is the time to do so. Consider discussing
the objectives and motivations of your agile initiative with key employees to
communicate direction and gain feedback as to what can help motivate them
toward the change. This helps you understand the work you need to do for
readiness as part of the RICH model. Ultimately this helps answer the ques-
tion, “Are you starting in the right direction?”
Adapting Rewards
The objective and motivation should be accompanied by an aligned benefit to
the employee. The benefit or reward could be in many forms and does not
always have to be monetary. For example, the reward can be self-organized
teams.“What’s in it for me?” is a common question about change. For employ-
ees, the benefit can be true empowerment. This is why it is critical to under-
stand what drives your workers and weave these drivers into your objectives
and motivations. When the change involves a shift in the culture, this typically
means that the organizational reward system must be adapted to support the
change.
■■Agile Pit Stop Employees will notice what actions gain reward. Objectives that do not have
aligned rewards for the employee can doom the change effort.
The need to adapt the reward system is particularly relevant when moving to
an agile culture. If the “hero” continues to be better rewarded (instead of the
team) or if management continues to get rewarded for command-and-control
Being Agile 71
attributes (instead of leading their team), this will become quickly evident to
the employees and can effectively doom the change.
The reality is that employees notice the actions that gain rewards (and rightly
so) and will adapt and “follow the money trail.” Any objective that is out of
sync with the actual reward for the employee cannot be sustained and will
ultimately fail. When you add the compelling reward of self-organized teams,
employee empowerment, and some monetary incentives to support the
objective of engaging employees, you will increase the chances for employ-
ees to become self-motivated behind the “what” (objectives) and “why”
(motivations).
Managing Resistance
Resistance is a common reaction to a change initiative. As organizations
attempt to grow, it is difficult to avoid change. Change can occur for many
reasons. When moving to an organization that is embracing Agile, there is
often a need for a significant culture change. Agile brings about a change in
objectives, which affects both employees and customers. Changes can create
new opportunities, but they will also meet with opposition. Many scenarios
engender resistance:
• “Here we go again!” It is comforting when things remain
the same. Employees have seen change efforts come and
go without any true commitment and may attempt to
wait the new ones out. Commitment to change must be
visible with clear motivations and rewards.
• Lack of communication. Employees need to know what is
occurring to them. As information trickles down from
the top, the message can be lost. This is why a plan for
continuous communications at all levels is important.
• Change in employee roles. Some employees like to retain
the status quo and do not want to see their roles changed.
When roles are vague, some don’t know where they fit in
the new culture, making them feel excluded. When they
have no say in their new roles, they can feel alienated.
Discussing with employees the changes in their roles and
adapting as appropriate are key.
• Competing initiatives. Introducing an agile initiative when
there are already multiple initiatives occurring can lead
to employees feeling overwhelmed, causing them to
resist. Hardly an auspicious start to the agile initiative! It
is important for management to prioritize initiatives and
focus on the higher priority initiatives.
72 Chapter 8 | Motivations for Moving to an Agile Culture
Not Working
Competition
Productivity
Morale
Trendy
Belief
Value
Cost
Proactive Reactive
Figure 8-1. Proactive and reactive reasons for moving to Agile
terminology with associates who will be initially working with Agile. You may
adapt terminology to suit the organization if this is beneficial. For example, if
the word sprint is more acceptable then using the term iteration to describe
a time-boxed period, then use the term sprint. Through deploying agile pro-
cesses, training, seminars, and workshops, the terminology can spread.
■■Agile Pit Stop When introducing Agile, avoid referring to any agile methods, tools, or techniques.
Instead, initially discuss only the Agile Values and Principles.
What story does the staff walk away with in this case? The manager had
discussed the importance of respecting people’s time, and then his actions
indicated to the team that the manager didn’t respect their time. This left the
employees resentful and unhappy. Let’s look at another story.
76 Chapter 8 | Motivations for Moving to an Agile Culture
What story do the employees walk away with in this example? Although the
“objective” was to create a company culture of equality, the senior manage-
ment team discussed things that highlighted that they weren’t equal at all,
instead of things the average employee could afford. How many of those in
the company could afford to go yachting? How many could afford to build
a large house at the beach? This is an example of where storytelling can
send the opposite message. The employees felt like they were being put in
their place and stopped believing in the equality objective. Now let’s look at
another case.
A company was trying to introduce Agile into their culture. They
promoted the principles of collaboration, trust, self-organizing
teams, and sustainable pace. It was initially led by an Agile Coach
who built a self-organizing team made up of Agile Champions
(internal employees) from across the company to promote buy-in.
They applied a collaborative approach to build the agile framework.
It became quite successful, and many teams began adopting Agile.
Several senior managers saw the accomplishments and wanted to
make the agile program their own. They disbanded the champions’
team and used their own functional team to lead the agile effort,
even though they were not experienced in Agile and hadn’t received
any training on it. This new management shared the story that they
would provide more structure to Agile. They said they all learned
Agile by reading a book. They also said they would assign a project
manager to the projects to help the teams estimate correctly.
What story are the teams walking away with? The story employees walked
away with was that Agile was no longer being taken seriously. It was clear that
management was now only giving lip service to Agile, really didn’t believe in
the Agile Principles, and didn’t really trust their employees. In addition, the
story about how this management believed that reading a book on Agile made
them knowledgeable became a common joke among the employees.
What type of stories are being told in your organization? Are senior manag-
ers telling stories that align with the objectives of Agile? Are middle managers
sharing stories that align with the needs of their team? Are team members
Being Agile 77
repeating the stories that strengthen the new culture or stories that are
demoralizing? Leaders must keep in mind that when they are speaking to the
people, they are effectively telling a story. Ensure that the messages in the
stories align with the objectives and principles that you would like to see in
your teams and new culture.
Achieving an
Agile Mindset
It is not the strongest of the species that survives, nor the most intelligent
that survives. It is the one that is the most adaptable to change.
—Charles Darwin
We humans like to control our own lives and destinies. This is the natural order
of things. Great pioneers determined their own paths. We learn and adapt as
conditions change. This was true a thousand years ago and is true today. There
are often barriers that prevent us from what we would like to do, but when we
have the ability to control our own destiny, great innovation can occur.
It is ironic that in this new millennium whose watchword is innovation, many
software-related companies have chosen a path of rigidity, with prescribed
processes leaving little room for adaption or a sense of ownership. Companies
are surprised that they are not getting the customer and employee engagement
that fosters innovation and leads to valued products. More control and more
processes are not the solution. Agile, which cultivates a mindset of values and
principles, brings back the vital evolutionary interplay between the constraints
of nature and the flexibility of cultural adaptation.
■■Agile Pit Stop An Agile mindset moves away from the pretense of predicting what the
customer wants a year in advance.
80 Chapter 9 | Achieving an Agile Mindset
Agile principles steer software developers away from the delusion that they
can predict what customers want a year in advance. Instead, it shapes them to
build and adapt according to continuous customer feedback. Agile principles
oppose thinking of employees as cogs to be moved or replaced and instead
views workers as self-organized owners of their work who use their brainpower
to build value.
What words come to mind when you think of Agile? How about value,
principles, working software, transparent, adapt, self-organizing, disciplined,
empirical, collaborative, iterative, incremental? This vocabulary is a first step
in moving toward agile culture.
Agile thinkers bring a different frame of mind to their work. In traditional and
waterfall approaches, the work is well planned with very specific milestones,
and changes are often frowned on or discouraged. You don’t have to think
about why you are doing something or your behavior. Agile, on the other
hand, inculcates the principles and “why” of being Agile and recognizes that
behavior is an important element of the Agile mindset. The agile world is
fluid, and dynamic change is the norm. Agile promotes learning in response to
change in the direction of value.
■■Agile Pit Stop Agile promotes adaptation not in a whimsical and carefree manner but in a
methodical, empirical, and disciplined manner.
4
Being Agile 81
When I ponder the elements of the Agile mindset, I review the Manifesto for
Agile Software Development (Agile Manifesto, for short). Then I refer to the
important Principles behind the Agile Manifesto to realize what the mindset
represents. To better understand the new cognitive patterns needed for the
Agile Principles, I dissect the Principles to better understand the intentions
behind them and what behaviors they entail.
■■Agile Pit Stop The key to understanding an Agile mindset is to read and understand the
Principles behind the Agile Manifesto.
In the next section I expand on each Principle and model how to marshal
supporting evidence that a culture change may be occurring. Other descriptions,
actions, and evidence will occur to you and should be applied freely and
continuously. The key is that you should take a hard look at the Principles,
define what they mean to you, and evaluate the evidence for culture change
in light of whether you are aligning with the Principles. Internalizing an
inspect-and-adapt criterion for evaluating proofs of agile change becomes the
embodiment of achieving the agile culture.
w
Being Agile 83
Frequent/Continuous Delivery
Deliver working software frequently, from a couple of weeks to a couple of months,
with a preference to the shorter timescale. “Continuous delivery” refers to the
capability of frequently releasing software to the customer when they want it.
This ensures that when customers believe there is value from what was built
and they want it, it can be delivered instantly. Because timing is critical, the key
phrase is “when a customer wants it.” Identifying the elusive customer value
means you can release when the customer wants it. If it is delivered too early,
the customer may not be ready for it; if it is too late, the market opportunity
is missed.
Agile thinking includes a world that is fluid, where changes are continuous and
welcome, and teams have the capability of releasing frequently, which applies
to the delivery of software. This ability to frequently release highlights the
importance of infrastructure that can help with continuous integration, building,
and testing. This ability assumes a level of automation that needs to be in place.
Automated testing increases the possibility of testing as much of the func-
tionality as is reasonable, including the capability of performing nonfunctional
testing such as performance testing, load testing, and more.
What actions exhibit continuous delivery?
• A release capability to incrementally and rapidly deploy
software
• Iterative framework with Sprint Reviews
• Continuous integration supported by merging process
and configuration management system
84 Chapter 9 | Achieving an Agile Mindset
preparing a plan, and doing design and development work, an external paying
customer only values the actual working software. You don’t get credit for
in-progress stuff, only the working software.
This is why, at the end of each time-boxed period, working software
is delivered and validated with the customer during the demo. In addition,
working software must meet done criteria to ensure that it is of high quality.
What actions exhibit working software as a measure of progress?
• Progress is measured by working software.
• Sprint Burndown tracks work done and work remaining.
• Done criteria are established that reflect engineering
standards that are applied to user stories.
• Sprint Reviews are conducted to demonstrate the
working software and gain customer feedback.
What is the level of belief?
• Do you believe that working software can be produced
incrementally and is a measure of progress?
Sustainable Pace
Agile processes promote sustainable development. The sponsors, developers, and
users should be able to maintain a constant pace indefinitely. The concept of
sustainable pace has been quantified by Kent Beck, who recommends working
no more than 40 hours a week and never working overtime for more than
one week at a time (not consecutively).1 When you maintain a reasonable
pace, you can sustain a constant pace indefinitely. Studies have shown that
when you consistently work more than 40 hours in a week, the overtime
produces lower-quality software and a reduction in productivity.2
A team establishes velocity based on a 40-hour work week to determine how
much work they can do in a sprint.3 Using velocity allows the team to empirically
determine the amount of work they can build into working software in a given
iteration. More important, does management trust the team’s velocity, or do
they disregard it and force them to do more?
1
Kent Beck. Extreme Programming Explained. Addison-Wesley, 2005.
2
Lonnie Golden. The Effects of Working Time on Productivity and Firm Performance:
A Research Synthesis Paper. International Labour Office, Geneva, 2011.
3
Velocity is the number of units of work (aka story points) that a team can complete in an
iteration or sprint.
88 Chapter 9 | Achieving an Agile Mindset
Technical Excellence
Continuous attention to technical excellence and good design enhances agility.
To strive for technical excellence, you need team members who have
knowledge and experience to produce sound architecture, good design,
and quality software. It is important to have the capability of making the
best technical decisions balancing design, usability, and maintainability. Such
capability requires a seasoned and professional team. In Agile, employees
should want to do the work in the context of career learning and growth.
To strive for technical excellence, effective done criteria should be established
that include engineering standards in design, UX, development, technical
writing, configuration management, building, and testing. To achieve quality, it
may include implementing various XP practices, such as continuous integration
and build, coding standards, pair programming, refactoring, simple design, and
test driven development that are applied to improve the technical excellence
of a product. In addition, the use of retrospectives help the team reflect on
opportunities to build their skills and further achieve technical excellence.
Being Agile 89
Simplicity
Simplicity—the art of maximizing the amount of work not done—is essential.
Striving for eliminating unnecessary work is the goal. This should include
identifying the minimum amount of features for a customer release (MVP)
for it to be successful. It should include reducing non-value-added work
that team members are asked to do. It may involve reducing unnecessary
steps of a process to deploy a release.
To simplify, you need to proactively remove the seven wastes in software
development as defined by Mary and Tom Poppendiek and discussed in
Chapter 6: eliminating partially done work, extra features, the need to relearn,
hand-offs, task switching, delays, and bugs.
Agile thinking focuses on short iterations and small increments. This way you
can fail fast, learn, eliminate waste, and then succeed more quickly. You may
also right-size your documentation with a focus on documenting decisions
and why you made them.
What does this look like in action?
• There is continuous focus on staying lean and removing
waste via retrospectives.
• During demonstrations, customers are asked not only
what they need but what they don’t need.
90 Chapter 9 | Achieving an Agile Mindset
Self-Organizing Teams
The best architectures, requirements, and designs emerge from self-organizing teams.
Self-organizing teams have a combination of greater ownership and respon-
sibility to achieve a common goal of building valuable software and reducing
dependency on management. The team has the authority to be self-organizing
and make decisions regarding architecture, requirements, and design as they
evolve the product. The team needs to be cross-functional so that they have
the skills and talent to make the decisions to develop the product.
A self-organized team moves away from the command-and-control hierarchy
in which one person assigns the work. Instead, a self-organizing structure is
one in which everyone participates in decision making and volunteering for
work from the backlog. This is easier said than done. Therefore, prior to
considering Agile, an assessment of the openness of the culture is helpful for
gauging the starting point.
Having self-organizing teams also means thinking beyond the individual, since
this can constrain collaboration and the team mindset. The focus should be on
instilling team spirit: “You only succeed if the team succeeds.” Rewards should
be team-based to drive the notion home.
The team notion also means hierarchy—such as title, levels, grades, heroes,
and egos—needs to be removed as barriers to team success. Instead, promote
equality among roles. Treating everyone on the team as equals leads to more
engaged members. Nonetheless, team members should respect the fact that
some people have more experience in certain areas and others can gain from
this experience.
What actions exhibit self-organizing teams?
• The team makes the decisions about its work, specifically
regarding architecture, requirements, design, and sizing or
estimating.
Being Agile 91
10
Evaluating
Executive
Support and
Team Willingness
The first and most important step is to get senior management backing.
Without support from the very top, it is generally impossible to make
significant changes.
—Watts Humphrey
Two important criteria for a successful agile implementation are support from
your top executive and willingness to apply Agile by the team. By “executive,”
I mean your most senior manager within the scope of deployment. If you are
looking to initiate an agile enterprise change, then you need top-level execu-
tive sponsorship and management support for the transformation. Because
moving to an agile culture represents a significant change for the teams, it is
important to have team members willing to make the changes for an effective
transition.
As a company approaches Agile, executive support and team willingness should
be evaluated so that you understand your starting point. At the executive and
management levels, a good way to determine support is to understand what
94 Chapter 10 | Evaluating Executive Support and Team Willingness
support is needed, evaluate the level of support, and identify ways to increase
support. At the team level, a good way to determine willingness is to evaluate
the level of willingness and identify ways to improve it.
■■Agile Pit Stop It is important to evaluate executive support and team willingness to understand
your starting point and what you need to do to improve each.
Positive
Innovator
Champion
Bandwagon
Experienced
Workhorse
Inexperienced
Cowboy
Deceiver
Denier
Negative
Figure 10-1. The seven agile personality types based on their agile experience and attitude
toward Agile
Innovator
Innovators make up a small population of folks who are very experienced and
very positive about Agile. The signatories of the Agile Manifesto certainly fall
in this camp, as do seasoned Agile Coaches, writers, presenters, and authors.
They are motivated to help organizations adopt Agile and extend its capabili-
ties into all areas of software product development.
96 Chapter 10 | Evaluating Executive Support and Team Willingness
Champion
A Champion tends to know Agile well and is willing to advocate for it in a very
positive way across an organization. There are even some Champions who
may not be well versed in the practices of Agile but have seen the benefits
of implementing and using agile methods. Key Champions may include your
executives and senior management as well as Agile Coaches, Scrum Masters,
Product Owners, and leaders in engineering. They are motivated by the busi-
ness and organizational benefits of Agile.
Workhorse
The Workhorse has learned about Agile by implementing it within a team con-
text. Workhorses are mostly positive about Agile, have worked or are work-
ing in the trenches as Agile Team members, and will be fairly honest about
what works and what does not. Workhorses commonly use Agile on a daily
basis. They bring a pragmatic approach and are often the first to experience
the agile culture colliding with current company culture. They are motivated
to improve the agile deployment so their lives are better. A lot can be learned
from this group.
Bandwagon Jumper
The Bandwagon Jumper sees benefits in the move to Agile. If Agile is perceived
to be “hot” within their company, they will jump on the bandwagon. This crowd
tends to be inexperienced with Agile but generally positive until it is out of
fashion. They are motivated by improving their own image. Bandwagon Jumpers
may include middle and senior management and engineers who believe they
can get ahead by aligning with the hot new trend. Some Bandwagon Jumpers
will see the value of Agile and may become Workhorses or Champions.
Cowboy
The Cowboy sees Agile as an opportunity to abandon discipline and process
so that they can enjoy the “Wild West” life. Cowboys are not necessarily neg-
ative about Agile. Their motivation is that they know that they get away with
pretending to be Agile because those in the Bandwagon Jumper crowd really
have no idea what it is. Ultimately, these pretenders can give Agile a black eye
in the organization, since others will believe from a Cowboy’s actions that
Agile means no discipline or process.
Being Agile 97
Deceiver
The Deceiver will agree to applying Agile but will either silently attempt to
sabotage the change or continue doing things the waterfall way. A Deceiver
is negative about Agile. Deceivers behave this way either because they resent
having been forced into using Agile or because they feel threatened by the
change but do not want to lose credibility by bad-mouthing the new direction.
They may have had some agile experience that was thrust on them. Deceivers
are the most dangerous because they undermine and obstruct the potential
success that Agile can bring to an organization.
■■Agile Pit Stop It is actually better to have Deniers than Deceivers, because with the former you
know where they stand.
Denier
The Denier will deny outright the benefits of moving to Agile. They are typi-
cally set against Agile from the beginning because they see that it will interfere
with what they perceive to be their currently successful role. They may be
motivated by incentives, expecting that Agile will affect their reward structure
in a negative way. Deniers typically do not have much agile experience. Many
times, it can be beneficial to listen to reasons Deniers give for dismissing Agile.
Their input may help you look for a way to overcome their reasons, therefore
strengthening the perception of Agile within the organization.
■■Agile Pit Stop Gauging the level of executive support is an ongoing activity that includes
understanding what type of support you need, discreetly evaluating support levels you are actually
receiving, and working to increase support levels.
Once you have identified the scope of change you are looking for, then you
should identify the top management and key internal stakeholders who are
important to the success of an agile implementation effort. Internal stake-
holders may include the highest level of management within the level, prod-
uct management involved in the product and requirements direction, middle
management who have resource responsibilities of their team members, and
IT governance, HR, and finance personnel.
Early on, we may not really know the level of agile support from executives,
senior management, and key stakeholders. This is why it is important to peri-
odically gauge the level of support with the goal of increasing the level of sup-
port and creating Agile Champions within your organization.
■■Agile Pit Stop It is very important to assure the executive that you, acting as Agile Champion,
will support their sponsorship activities and keep them informed of the latest progress so they appear
knowledgeable regarding the agile initiative.
Once you have drafted this list of the type of support you want, it is important
to share it with your senior executive within the organizational scope of your
agile implementation. The list begins the discussion that helps you understand
their level of support. You should initially ask if the executive can become the
sponsor of the initiative. Ensure that the executive understands that you will
support them in their sponsorship activities and will keep them informed of
the latest progress regarding the deployment of Agile so they appear both
knowledgeable and confident.
Team Willingness
Willingness may be defined as a disposition to be accommodating and even
enthusiastic. It implies that the willing person is doing something out of choice
rather than under compulsion. When people are willing to do something, it
means they are open-minded and receptive. In the context of being Agile,
willingness means embracing the change toward Agile. It is important when
you begin educating a team toward agile adoption that you gauge their level
of willingness. Gauging their willingness can mean the difference between a
successful or failed adoption.
The goal is to cultivate team members toward becoming Agile Champions
and Workhorses. The good news is that many on an Agile Team are willing to
move to Agile for multiple reasons. One reason is that they look at Agile as
something new and exciting. Others realize that Agile provides business ben-
efits to their personal growth and an increase in employment opportunities.
Having Agile on the résumé is a benefit because many companies include it as
one of the skill sets they are looking for.
■■Agile Pit Stop Agile Team members are willing to move to Agile for both singular and
aggregate reasons. Some realize the benefit to their personal growth and an increase in employment
opportunities.
Some of the Agile Team members may be Deniers and Deceivers. Some will
take a wait-and-see position because they do not have a basis to form an opin-
ion. This is why it is important to begin the education process to build team
knowledge of Agile and then introduce the retrospective. The retrospective
provides a platform for team members to speak honestly about challenges
and seek opportunities for improvement.
Willingness Needed
As you consider willingness in relation to Agile, you need to direct the energy of
the willing toward building knowledge and gaining experience in Agile. Though
you cannot expect all of the team members to become Agile Champions, you
would like them to at least become Workhorses. Some examples of the types
of activities in which the Agile Deployment Lead or Agile Coach may observe
willingness and building agile knowledge include the following:
• Agile educational activities. There is a willingness to take
training and attend sessions to ramp up the teams toward
the processes and practices they will be applying. As time
goes on, education may include agile Q&A sessions and
agile sharing sessions.
102 Chapter 10 | Evaluating Executive Support and Team Willingness
On the positive side, provide those whom you recognize as Agile Champions
the opportunity to gain more experience. They are already on your side, so
make them your strong ally to help you improve willingness among other
team members. Some approach Agile as Bandwagon Jumpers. They know
enough to align with the trend within the company, but may know very little
about Agile. Help them understand the benefits of Agile and provide them
with working experience. The Workhorses already have a bit of agile experi-
ence. Give them more ownership opportunities. See if they would like to be
groomed as Scrum Master or Agile Coach. The ownership opportunities will
give them some leadership responsibilities within an agile context.
On the negative side, ask those whom you recognize as Cowboys if they are
willing to get more serious about Agile. If so, provide them the opportunities
to participate more fully. For Deniers, it can be beneficial to listen to the rea-
sons they dismiss Agile. That input can help you work with them (if they are
willing) to gain experience to at least become a Workhorse. Deceivers may be
hard to identify because they may be initially exhibiting the characteristics of
a Workhorse or Bandwagon Jumper. Continue to keep your eyes open. Over
time, they may expose themselves. Keep in mind that even with your efforts,
you may not be able to influence these latter three types into becoming
willing members of the team.
In some cases, a team member might be willing to apply Agile Principles but
unclear about what they are supposed to do. You may need to proceed with
further education.
Breakfast of Champions
As a company approaches Agile, executive support and team willingness should
be evaluated. The evaluation provides a platform for determining and initiat-
ing actions to increase support and improve willingness. Having support from
executives and willingness from team members can be the difference between
a successful or failed agile deployment. Whether it is an executive or team
member, ultimately the goal is to create Agile Champions who are willing to
support the agile deployment.
CHAPTER
11
Treating
Agile as a
Transformation
Project
If you do not manage culture, it manages you, and you may not even be
aware of the extent to which this is happening.
—Edgar Schein
Moving to Agile is a move to a new culture, and cultural changes are difficult for
a team or organization. To transform your organization to Agile, organizational
values and individual behaviors need to change. Because of this I strongly
recommend that a change toward Agile must be thought of as a transforma-
tion or change initiative, treated as a project, and actively managed. True to
the spirit of Agile, using an inspect-and-adapt model can help you manage the
change and adapt along the way based on the feedback you gain from those
involved.
As a starting point for the transformation, those within the organizational
scope want to know the what and why of the change. Chip and Dan Heath
write: “If you want people to change, you must provide crystal clear direction
106 Chapter 11 | Treating Agile as a Transformation Project
[because what] looks like resistance is often a lack of clarity.”1 Start with
establishing a vision or objectives about why you are implementing Agile. The
objectives may center around customer and employee engagement (Chapter 4
and 5) or around wanting to work by the Agile Principles (Chapters 6 and 9).
Along with objectives, add the organizational motivations for change to Agile
(Chapter 8). The objectives and motivations begin the path toward clarity.
■■Agile Pit Stop As you establish your agile direction, it is important to share objectives and
motivations. Whether you call it a project, program, or initiative, the objectives and motivations help
foster clarity around the effort.
Within the project context, there are other elements that you should apply
that will help you manage the transformation. As illustrated in Figure 11-1,
the rest of this chapter focuses on the element of treating Agile as a trans-
formation project. This treatment includes writing objectives and motivations,
understanding the scope of the effort, establishing a deployment team to
help lead the effort, crafting a communication plan to convey progress,
identifying suitable work, ordering the work in a deployment backlog, and
then applying an inspect-and-adapt process to deploy Agile into the organi-
zational scope.
1
Chip Heath and Dan Heath, Switch: How to Change Things W
hen Things Are Hard, Crown
Business, 2010
Being Agile 107
The less favored scenario is to apply Agile to just one project with the idea
of abandoning it afterward. Although this may be beneficial for exercising
agile processes and getting the release out, you may not receive the business
benefits of Agile because you need behavior change at a much broader level.
It is also a bit of an effort for the employees to adapt to a new approach only
to abandon it. However, if the results are good, it can launch you into a more
consistent use of Agile for the product.
A more favored scenario is applying Agile to a product line or product team.
A product team represents a consistent group of people whose goal is to provide
long-term business, development, and support for a product. This aligns with
the notion that the longer you work as a team, the better your chances of
forming strong working bonds and manifesting the attributes of teamwork.
Also, when a person is aligned with a product for a long period of time, there
is a tendency to have a greater sense of ownership and to be more invested
in the success of the product. Alignment to the Agile Principles is more likely
because it often takes time to align. Implementing at the product level allows
Agile to be applied consistently and gain inspect-and-adapt benefits where
feedback is used to build business value.
■■Agile Pit Stop I have found it useful to deploy Agile within the context of a product team.
A product is represented by a consistent team whose goal is to build and support the product,
and they tend to have a greater sense of ownership and are invested into the long-term success
of the product.
The enterprise level is where you may gain the most business benefits from
Agile. Because Agile requires a culture change, aligning the whole enterprise
to Agile values and principles helps everyone understand the need to adapt
to gain the business benefits. To achieve an enterprise-level transformation to
Agile, it is advantageous to combine the activities identified in the RICH model
for deployment (Chapter 7) and add organizational-level aspects (Chapter 23).
At the enterprise level, you can also leverage economies of scale and mini-
mize similar efforts across multiple teams using a common deployment model,
tools, and training across teams.
If the agile adoption is focused on the whole organization or a large part of it,
then the most senior-level executive within that scope should form a deploy-
ment team of Agile Coaches who have experience in enterprise-level agile
deployments and Agile Champions within whose purview fall the products
that are flagged for agile adoption. Even if the agile deployment is occurring
on just one product team, at the very least, the Product Owner, Scrum Master,
and the most senior manager within the scope of the product should become
the Agile Deployment Team that focuses on the progress of the adoption.
■■Agile Pit Stop Identifying candidate product teams that align with the agile sweet-spot
characteristics is a good place to start your deployment and give you experience.
It is best to target the candidate product teams where Agile has the highest
rate of success. The information that follows highlights the team characteristics
that represent the agile sweet spot. Keep in mind that you can be successful
with Agile even though you do not align with the sweet-spot characteristics.
• Agile team is willing. This makes it easier to advocate for
changes needed to use Agile effectively. It is critical that
your first deployment of Agile occurs on a team that is
very willing to adopt it. Having the Product Owner, Scrum
Master, stakeholders, and Team willing to commit to Agile
will make it easier to deploy. You learned how to gauge
the team willingness to move to Agile in the Chapter 10.
• Product team is small. Most agile processes tend to favor
smaller teams—typically no more than ten members.
This way team members get to know each other and
what they are working on well, which increases commu-
nication and team collaboration.
Being Agile 111
12
Adapting to
Agile Roles and
Responsibilities
Culture does not change because we desire to change it. Culture changes
when the organization is transformed; the culture reflects the realities of
people working together every day.
—Frances Hesselbein
When moving to an Agile world, there is a significant shift in roles and responsi-
bilities. In a more traditional project, decisions are typically made in a hierarchi-
cal manner, and roles are specifically established to support this structure.
If you are serious about moving to Agile and gaining an Agile mindset, then
maintaining traditional roles will get in the way of this change. In the Agile
world, there is a purposeful focus away from hierarchy and a strong focus on
getting people to work together every day.
To get to a fully robust agile organization, it is important for everyone to
play a role. Although managing a successful project from an Agile perspective
requires three core roles, there are many others in the organization who
must play a role to ensure success. Everyone from customers, executives,
and management to sales, marketing, finance, and HR must understand the
Agile mindset. It takes an organization to get to an agile culture.
114 Chapter 12 | Adapting to Agile Roles and Responsibilities
Scrum
Customers Executive/Sponsor
Team
Product
Core Roles
Beyond
Owner
Management
Sales and Marketing
Scrum Master
Figure 12-1. Core roles and beyond—it takes an organization to get to an agile culture
Scrum Team
The Scrum Team is the group of professionals on a project who work together
to build the customer value they have collectively committed to complete
within a sprint. The Scrum Team is a self-organizing group with enough cross-
functional skills and experience to build working software independently.
The Scrum Team includes the roles of Scrum Master, Product Owner, and
Development Team.
Being Agile 115
Scrum Master
The Scrum Master acts as a facilitator and servant leader for the team and an
enabler for Scrum, ensuring that it is understood and followed. This role may
act as Coach to ensure that the Scrum roles, events, artifacts, and rules are
understood and implemented effectively on the Scrum Team. The attributes
of servant leadership include listening, empathy, healing, awareness, persuasion,
and foresight.1 It is important for a soon-to-be Scrum Master to read more on
what is expected of a servant leader.
■■Agile Pit Stop A Scrum Master should have the attributes of a servant leader, which include
listening, empathy, healing, awareness, persuasion, and foresight.
A Scrum Master facilitates the Scrum events. This does not mean that they
direct the activities but that they ensure the events are occurring along with
the behaviors of an Agile mindset. In addition, the Scrum Master removes
roadblocks or finds the right people to remove roadblocks to ensure team
progress. The Scrum Master also does the following:
• Helps the Product Owner enact effective backlog groom-
ing techniques.
• Establishes and produces the Sprint Burndown, velocity,
and other metrics that help the team improve.
1
Larry C. Spears and Michele Lawrence (eds.). Practicing Servant-Leadership: Succeeding
through Trust, Bravery, and Forgiveness. Jossey-Bass, 2004.
o
116 Chapter 12 | Adapting to Agile Roles and Responsibilities
work in a nondirective yet influential manner. Many already have the skills
and the insight into an organization to appropriately remove roadblocks.
On the negative side, some project managers had success using command-
and-control attributes and the more traditional project management prac-
tices, which will not work well in an Agile environment. It can also be hard
for some project managers to eliminate their traditional mindset of detailed
project planning and control.
w
118 Chapter 12 | Adapting to Agile Roles and Responsibilities
Product Owner
The Product Owner (PO) represents the voice of the customer. He or she is the
customer liaison and is responsible for understanding what is considered valu-
able from the multiple customers who may need or are using a product. The
PO must straddle the responsibilities of being continuously available to cus-
tomers to identify value while being continuously available to the Development
Team to communicate customer value to them. Most POs I have worked with
find this both challenging and quite rewarding when implemented well.
The PO is the owner of the Product Backlog, where value is initially expressed
(e.g., as requirements). A PO must digest the various customer needs and
stakeholder demands and establish a meaningful list of user stories into the
backlog for the development team to work from. A key skill that the PO
needs to acquire is the ability to decompose large requirements or epics into
stories that can be built within the time-boxed period of the sprint.
The most challenging role of the PO is to rank the Product Backlog items
according to value. As depicted in Figure 12-2, a PO talks with multiple exist-
ing customers, potential customers, sales, marketing, management, and more,
all of whom are attempting to get their need highest in the ranking. A PO is
beholden to many but is the final arbiter, and everyone must respect the PO
decisions. This can be quite challenging in cultures where a more hierarchical
and command-and-control approach rules. The PO also does the following:
• Parses customer problems and needs into meaningful
requirements that highlight business value.
• Grooms, prioritizes, and ranks the Product Backlog items.
• Removes roadblocks and rules on issues where disagree-
ments arise.
• Coordinates the Sprint Review, invites customers and
stakeholders, solicits customer feedback, and updates the
backlog with feedback provided by the customers.
• Attends Sprint Planning and provides details, answers, and
clarification to the Development Team.
• Adapts requirements when customer needs and market
conditions change, to ensure that what is built and deliv-
ered aligns with customer needs.
• Works with sales and marketing to get their require-
ments into the backlog.
Being Agile 119
Customer D
Customer C
Customer B
Customer E
Potential
Customer A
Product Customers
Owner
Management
Sales
Presales
Other POs
Marketing Development
Team
Development Team
The Development Team is a cross-functional group of engineers who build
the product functionality. The team should be made up of personnel with
different skill sets. This means that the team has the capabilities to build the
product without having to rely on others outside of the team. In Scrum, the
team size is typically seven, plus or minus two members. If you have too few,
you may not have all of the cross-functional skills you need on a team. If the
team becomes too large, it becomes too hard to self-organize.
The skills within the Development Team include but are not limited to analysis,
design, programming, configuration management, testing, and technical writing.
Because this team will be working closely together, the various members
must learn to collaborate and cooperate well. To build this collaboration,
Being Agile 121
Development Team members must respect each other’s values and opin-
ions. They do this by breaking user stories into tasks together during Sprint
Planning, crafting and honing done criteria, and establishing acceptance criteria
together as a team.
■■Agile Pit Stop The development team must learn how to decompose stories into tasks, which
they can build into working software within a sprint. They must respect each other’s values and
opinions to become a collaborative self-organizing team.
Customer
The customer is the primary driver of business value. The customer role
represents buyers and users of the product. This role represents the business
interests who are paying for the product. The customer provides business
knowledge, input, and feedback to the Product Owner to help determine
priority and rank order of the stories and goal setting for a release.
The most important responsibilities the customer enacts are contributing
requirements and attending the Sprint Review to provide the feedback that
helps the PO adapt the product toward the direction of value. The customer
also contributes in establishing acceptance criteria.
There are several customer target groups. There are current customers and
potential customers. Current customers are buyers of your product, must be
treated well, and are your highest priority. Within the potential customer
group, there are the potential buyers and the browsers. As you identify cus-
tomer value, knowing what the current customer wants, you will keep them
satisfied and loyal. Knowing what potential customers want helps you increase
revenue and grow your business. (Learn more about customer target groups
in Chapter 17.)
■■Agile Pit Stop Customers are the drivers defining business value. As you build products, you
must consider value from current customers and potential customers.
Being Agile 123
Executives/Senior Management
Executives and senior management have key roles to play if they want to
transform the organization to Agile. The key role for the most senior-level
executive within the scope is to become the sponsor of the Agile initiative.
They must buy in to the Agile values and principles and understand the behav-
ioral changes that are needed for an effective transition to Agile.
They should know that those within their organization will only take Agile
seriously based on the executive level of visible support. They should peri-
odically provide public support for Agile. Once a communication plan is for-
mulated, portions can be executed over time to keep employees aware of
the progress and accomplishments of the deployment. Further discussion on
communication planning and the sponsor role is found in Chapter 11.
Part of the executive or senior management role as sponsor is to get intro-
duced to the Agile values and principles and educated in the business benefits
Agile can bring, including more revenue for the company. They should under-
stand the language that Agile brings and be conversant in agile values and
principles. Executives should look at their own behavior and align it with the
Agile mindset.
A key responsibility is ensuring their staff, middle management, and leads
understand that the organization is moving away from command-and-control
and toward a self-organizing team model. Executives should act as mentors
to their staff as they help management adapt to Agile. It is strongly recom-
mended for executives to bring in Agile Coaches to help teams not only move
to Agile but also help their staff shift to the behaviors that exemplify an Agile
mindset. Executives may also need to be involved with making adjustments to
staff members who cannot make the switch away from command-and-control.
This can be hard to do, but if they don’t, then those around them will not take
the change seriously.
An executive should learn how to read agile metrics and measures of suc-
cess. Gaining an understanding of Sprint Burndowns, release burnups, value
capture, release frequency, Agile Mindset,Values, and Principles (MVP) Advisor,
and other Agile-related metrics can help ensure the organization is moving
in the right direction. Further discussion of agile metrics can be found in
Chapters 13 and 14.
124 Chapter 12 | Adapting to Agile Roles and Responsibilities
■ Agile Pit Stop Remember, if you don’t align the reward system toward agile behaviors, you will
only get the behavior you reward, not the behavior you want.
The executive should form an Agile Deployment Team of Agile Coaches who
have experience in the scope of the deployment that is needed and Agile
Champions within that scope of the organization that is committed to adopt-
ing Agile. More information on an Agile Deployment Team follows.
Executives should also be invited to attend the Sprint Reviews of their top
products within their organizational scope. They will gain a genuine sense of
progress and see actual working functionality of their products.
Middle Management
Middle management are critical to the success of an effective Agile deploy-
ment because they are the lynchpin between the executive’s vision for Agile
and middle management’s willingness to allow Agile to thrive on a team. If
they are engaged and buy into Agile, then the change may succeed. Even when
executives and senior management buy in, if middle management does not do
likewise, they can block a team’s ability to succeed with Agile.
Middle management is often made up of direct managers of many of those
on Agile teams. Many are functional managers who are used to directing and
assigning the work to their team members. If they don’t understand their
role in the new order or feel threatened by the change, they may become
Deceivers or Deniers. Because of this, it is critical that middle managers are
educated on Agile at the same time their teams are.
Middle management must learn to gently back away from their functional
leadership and act more as servant leaders who trust their teams, help them
remove roadblocks, and support the agile practices. Their direct reports are
now on Agile teams, so they cannot assign them any work. They may attend
the Sprint Review to see the working functionality, which is better than a sta-
tus report in gaining a sense of progress.
Being Agile 125
Often middle management have less to do in an Agile world. The good news is
that they may consider options such as changing their role to resource man-
agement, where they manage more people but do not own an organizational
functional area. They may consider a Product Owner role if they have been
engaged in collecting requirements and interacting with customers. Although
this role should no longer be managerial, a PO helps shape the product by
collecting and grooming the requirements.
A big adjustment and learning opportunity for middle management is to help
Agile teams become self-organizing. This requires a change in behavior. Middle
management must also learn how to establish the concept of bounded author-
ity where teams can make their own decisions, organize, and commit to their
own work. It does not mean that teams can do whatever they want. The
balance is that managers keep limited responsibilities to provide a vision and
support their staff, while allowing teams the ownership of their work.
■■Agile Pit Stop Management have bounded authority whereby they provide their teams a vision
and the ability to be self-organizing, so that communication and trust can thrive.
Management needs to allow the employees to feel that they own the team
decision making and can make their own commitments to the work they do at
the team level. Management must also be willing to be transparent about what
is going on in the organization and be willing to communicate this information
to the team.
Agile Coach
The key attributes of an effective Agile Coach include experience in deploying
Agile, in organizational change, in playing agile roles on a team, and in working
with the business benefits of Agile.
If you don’t know what an agile culture and effectively running agile practices
look like, then how do you learn to recognize it? This is one of the key values
of having an Agile Coach to help you. A Coach possesses deep agile deploy-
ment knowledge to ensure the product teams are implementing Agile effec-
tively. This includes helping teams both mechanically do Agile and behaviorally
be Agile.
Another benefit of an Agile Coach is that they help sustain the adoption of
Agile practices and mindset. Agile training provides initial knowledge for
teams. However, team members can easily revert back to traditional habits.
An Agile Coach reinforces agile values and principles and ensures that the
team continues both the expected practices and behaviors.
An Agile Coach can provide consistency when multiple teams are adopting
Agile at the same time. The Agile Coach also understands both the short-
term and long-term pitfalls that can occur when a hierarchical organization is
moving to Agile. They can help mitigate the challenges ahead of time.
■■Non-Agile Pit Stop A coach can help an organization avoid the following situations: “We
don’t need to document anything because we are Agile”; “We don’t need any management support
because we are self-organized”; and “We can’t tell you what we’re building until the end of the project
because we are using Agile.”
Being Agile 127
Michael Spayd, “Evolving Agile in the Enterprise: Implementing XP on a Grand Scale,” Agile
3
More Roles
Within an enterprise perspective, peripheral roles like sales and marketing,
finance, and human resources should be brought into the agile fold. Although
they do not need to work in an agile manner, they should embrace the same con-
cepts of leadership, self-organizing teams, collaboration, and eliminating waste.
Sales and marketing are actively involved with bringing a product to mar-
ket. They can work with the Product Owner by contributing requirements
and gaining clarification to ensure you are building something the customer
needs. They need to understand that the Product Backlog and prioritization
are owned the Product Owner. Also, they need to learn that requirements
should be funneled to the Product Owner and avoid making commitments
without the Product Owner’s agreement. Those in sales and marketing of
should consider attending the Sprint Review to gain an understanding of what
the new functionality does as well as the progress being made.
Being Agile 129
Within a company going Agile, the finance organization must enable the level
of agility and flexibility that is asked from the people and the agile processes.
Finance should be flexible in understanding that while they can still manage to
cost, the scope is the important variable for delivering customer value.
If performance objectives are part of the organization’s processes, then it is
important for HR to establish a performance review process that supports
team goals. This helps support the principle of self-organizing teams. You will
learn more about adapting performance reviews for Agile teams in Chapter 23.
This broader view and additional information ensures that the product teams
build the right product.
13
Evaluating Agile,
Engineering, and
Team Capability
Sometimes it is good to know the situation you are getting yourself into.
—Mario Moreira
• How do you know you are Agile? This question asks if teams
are “being Agile” (if their behavior and culture align with
Agile values and principles). The answer captures whether
the values and principles of Agile are being applied.
There are two more questions whose answers will help you understand your
starting point:
• What is the current state of your engineering practices?
This question asks how effectively the team is currently
applying engineering practices. If current practices are
poor, it can affect your ability to do Agile. The answer
helps you know if you have hurdles to overcome.
• What is the current level of Agile experience and interest?
This question asks how experienced the team is in
applying Agile. The level of experience helps you adapt
training and other elements of a deployment.
Now let's delve more deeply into these questions and what such a survey
would look like to help you gain answers and establish your baseline.
Figure 13-1. Sprint Planning adoption survey to determine what the team thinks their level
of adoption is in applying elements of Sprint Planning
In this example, “Team commits to work” is the most highly rated, and
“PO prepares acceptance criteria” is the lowest rated. From these results,
the team may initiate actions for improvement. A survey like this can be
periodically conducted to help the team understand if they are moving in
the right direction. From these same data, a trend metric on Sprint Planning
adoption over time may be created. See Figure 13-2 for an example.
Notice how “Team Velocity used for planning” was poorly rated in Q1, Q2,
and Q3. However, in Q4, the rating increased because after the Q3 survey, the
team initiated an improvement action to get educated on the usage of velocity.
The periodic results can also be an input into a Sprint Retrospective.
134 Chapter 13 | Evaluating Agile, Engineering, and Team Capability
■ Agile Pit Stop If you can evaluate yourself on the principles, you can get an idea of whether you
are aligned with the Agile Principles and thus the Agile mindset.
The Agile MVP Advisor survey comes in three parts: principle, evidence of
principle in action, and rating area. As you prepare the survey, there should
be a discussion of what evidence you would expect to see to bring more
objectivity to the process. If you can evaluate your situation highly on the
principles, this can give you an idea of whether you are aligned with the Agile
Principles and thus whether you have the Agile mindset.
Figure 13-3 is an abbreviated example of the Agile MVP Advisor focusing on
just four of the Agile Principles. It is recommended to administer this survey
prior to starting a deployment of Agile and then periodically to gauge if you
are moving toward the behaviors that align with the Agile principles. The
results can help you understand where you align and where you need focus.
It can also be an input into a Sprint Retrospective.
Figure 13-3. Abreviated version of the Agile Mindset Values and Principles (Agile MVP)
Advisor, a survey to gain an understanding of how Agile you are
Being Agile 135
Revisit Chapters 6 and 9 to refresh your insight into all of the values and prin-
ciples to establish a full survey framework to determine whether your team
or organization is being Agile.
Having implemented various Agile survey mechanisms in the past, I am a strong
proponent of sharing only the aggregate results and sharing them only with
those who have taken the survey. No individual results should be shared. If a
product team takes the survey, then the aggregate results go only to the team.
If an organization takes the survey, then the whole organization may review
the aggregate results. To gain the business benefits of Agile, the whole orga-
nization should align with the values and principles. With this in mind, it is
beneficial for the whole organization to take this survey. An Agile-minded
product team that exists in a hierarchical organization will suffer from this
external partnership with the rest of the organization. In other words, if
those outside the product team still operate in a hierarchical and big-upfront
manner, it can affect the team's ability to align with the Agile values and
principles. You may also wish to periodically take this survey to form a trend
metric, which will help you understand if the product team or organization
is moving toward the direction of transforming their behavior toward Agile
values and principles.
Engineering Practices
The engineering practices survey helps you answer the question, “What is the
current state of your engineering practices?” Although applying agile practices
is important, the level of engineering practices applied is equally important.
When you are considering a transition to Agile, you may find that the current
engineering practices are problematic. This is why I recommend that prior to
implementing Agile, you learn what is working well and what can be improved
within the context of engineering practices.
This knowledge has two benefits. The first benefit is that you will better understand
the engineering challenges on the team prior to moving to Agile. This baseline
determination prevents the Agile deployment from being blamed for an existing
engineering problem, and it allows you to more clearly understand these
challenges so that they can be addressed as part of the agile transition. The second
benefit is that if you find that you have poor practices in engineering areas, you
may want to address them before moving to or in parallel with Agile.
To construct a survey, identify engineering practices that you deem important
to technical excellence. Then build a set of statements that are self-rated by
team members to help you verify if the engineering practices are being
followed. Collect the responses and tally for results.
136 Chapter 13 | Evaluating Agile, Engineering, and Team Capability
Averages
Engineering Practices Individual Team Member Ratings (1 -5) Action
Design elements are established and applied
(e.g., call to action, breadcrumbs applied, etc) 3 4 4 4 3 3 4 4 4 3.7
Architecture practices defined and applied
(frameworks, processes, non-functional, etc) 3 4 5 4 4 5 3 4 4 4.0
Version Control used to version code and
checked in nightly 5 5 5 5 5 5 4 5 4 4.8
Effective branching and merging strategy is
applied. 3 4 4 3 4 3 4 4 3 3.6
Effective code review practices are applied 2 3 3 2 2 2 3 2 3 2.4 Implement code review practice
Figure 13-4. Engineering practices survey to determine what is the current state of your
engineering practices
Figure 13-5. Team matrix to identify experience, interest, training, challenges, and benefits
Agile Coach and/or Agile Deployment Team to be aware and help mitigate this
challenge. You may also notice that Scrum Team member D may be problematic.
Although this person has been trained, he or she indicates no interest in
reading about Agile. This could be someone who wanted the Scrum Master
certification but is not really invested in Agile. The information in this matrix
can help you understand knowledge levels, risks to be aware of, and if there
are any particular areas to focus for training.
14
Establishing
Agile Measures
of Success
Customer-based measures are important, but they must be translated into
measures of what the company must do internally to meet its customers’
expectations.
—David P. Norton and Robert S. Kaplan
Getting to “be Agile” is a journey. As part of that journey, how do you know
you are gaining the business benefits of moving toward agility? The answer
depends on the question you ask and the goal it implies. This is why it is
important to ask the right question. The most important question is:
• How do you know if Agile is having a business impact? This
question asks if you are receiving business benefits from
being Agile. If the goal is understanding business results,
then capture measures regarding revenue.
Establishing agile measures of success involves a framework focusing on met-
rics for the organizational level, product team level, and Scrum Team level. This
helps frame the metrics toward those that gain the most benefit.
140 Chapter 14 | Establishing Agile Measures of Success
■■Agile Pit Stop A measure is a numerical value at a point in time. A metric is a mathematical
calculation of measures over time that may represent a trend. “Number of defects collected today”
is an example of a measure. “Defect average per day over a month” is an example of a metric.
■■Agile Pit Stop A revenue measure is the ultimate agile metric because Agile is about improving
the business. However, revenue is a lagging measure, so you need to establish leading measures
that provide timely visibility into what is occurring to help you make decisions that lead to an increase
in revenue.
to ensure you are moving in the direction you want that is represented by a
positive lagging metric (e.g., increase in revenue). I call this the lagging-to-leading
metric path (see Figure 14-1). Examples include:
• Customers attending Sprint Reviews: a leading metric involv-
ing the Sprint Reviews, where you capture how many cus-
tomers are actually attending the review and how much
feedback you are receiving from them.
• Customer satisfaction from Sprint Review: a leading metric
with which you capture customer satisfaction from the
functionality they viewed within the Sprint Review.
• Customer satisfaction of product usage: a lagging metric
involving the satisfaction of the customer in the usage of
the current product, including comments.
• Customer revenue: a lagging metric involving the revenue
coming from customers.
Leading Lagging
Customers Customer Customer
attending Satisfaction from Satisfaction Revenue
Sprint Reviews Sprint Reviews of current usage
Figure 14-1. Lagging-to-leading metric path, using leading metrics to ensure you are moving
in the direction of a positive lagging metric
Value of a Metric
You may observe that although many metrics are created and shared, only a
few of them are actually being used for decision making. You have to continu-
ally ask what measures can help a team or organization move in the right
direction. Before we discuss suggested metrics, it is worth having a discussion
of the relative value of a metric.
142 Chapter 14 | Establishing Agile Measures of Success
The value of a metric is defined as its usefulness divided by the effort it takes
to collect it. The dividend implies that the metric serves a useful purpose,
such as decision making. The divisor implies the metric costs energy in col-
lecting data and generating the metric. If the value of the metric is outweighed
by the energy to generate it, then it may not be worth preparing the metric.
■■Non-Agile Pit Stop The metrics you exhibit will affect behavior. If you collect defects and reward
people on identifying defects, then you may get a behavior focused on identifying and possibly
creating defects to reap a larger reward.
Some metrics may have a short life cycle, being valuable for only a certain
time based on the usefulness it provides. As an example, if a training program
commences, it may be of value to collect number of people trained. This
provides visibility into ensuring the actual number of employees being trained
is increasing as desired. However, once we have trained 90% of the target
audience, it may no longer be useful to collect this data and keep creating this
metric.
Because the relative value of a metric changes over time, it is beneficial to
periodically assess the value being generated. If a current metric no longer
provides value, it may be time to retire it. If a new one is of value, it may be
included if the value outweighs the energy to generate it.
metric can be created to ensure that your adoption levels indicate a positive
movement toward successful adoption of agile practices.
Value Capture
The value capture metric creates visibility for the percentage of value-added
work you are doing compared to the non-value-added work. This measure
captures how much value is being built and delivered within a Sprint and
from Sprint to Sprint compared to the non-value-added work. When adapting
toward Agile, there is often a lack of awareness of the amount of non-value-
added work that is occurring. Value-added work is functionality requested by
customers to produce working software. Non-value-added work does not
directly add value as perceived by the customer. (To gain a deeper understanding
of value-added and non-value-added work, consider reviewing Chapter 5.)
The benefit of this metric is it brings focus on the non-value-added work, so
that you can then reduce it and increase the level of value-added work for
the customer.
To calculate this measure, identify all value-added and non-value added work
within your Sprint (see Figure 14-2). You may decide to categorize the non-
value-added work further (defects, status reports, etc.) and assign a priority
rating to it (defect = NVA-1, status reports = NVA-4). This can give you an
overall understanding of where the most waste is occurring and begin the
process of reducing or eliminating this waste.
Non Value-All
hands Value of Work
5%
Non Value-
in a Sprint
Non-Value- Refactoring (Details)
Defects 5%
10%
Non-Value-
Retro task Value-Added-
5% Work
55%
Non-Value-
Budget
10%
Non-Value-
Administrative
10%
You can track this on a sprint basis, accumulate it over a release basis, or trend
it over time from Sprint to Sprint (as in Figure 14-3) with the goal of seeing an
upward trend of value-added work.
144 Chapter 14 | Establishing Agile Measures of Success
62%
55% 58%
55% 52% 52%
50%
50%
45% 48% 48%
45% 42%
38%
The big advantage of this metric is that it helps you (1) be aware of the value
and non-value-related work that your team is doing, and (2) it allows you
to make adjustments if you want to increase your value-added stream of
work. Your goal is to remove non-valued-added work that is unnecessary and
reduce non-value added work that is necessary for the system to function.
Although this may force you to make tough decisions (i.e., identifying what is
value-added and what is not), it will help you get your team more productive
and focused on building customer value.
Release Burnup
A release burnup is a graphical metric that indicates how much work has been
completed. The benefit is that it is used to enable a team to predict the scope
level they may be able to accomplish for a project.
At the release level, I recommend a burnup. The difference between a burn-
down and burnup is that instead of tracking how much work is left, a burnup
tracks how much work a team has completed, so the line goes up, not down
(see Figure 14-4). The other difference is that in a Sprint, we know the target
velocity so we can burn down from it. However, at the release level, because
we purposefully avoid big up-front scoping of the work so we can adapt to
change, we do not know our release scope or our velocity for the entire
release. Nevertheless, the burnup gives a team the ability to gauge how much
scope they may eventually build over time to help you anticipate when the
minimum viable product (MVP) scope level will be reached and predict a
potential release date.
Being Agile 145
600
500
400
300
200
100
MVP Total Points Trend
0
Start Sprint Sprint Sprint Sprint Sprint Sprint Sprint Sprint Sprint Sprint
1 2 3 4 5 6 7 8 9 10
Figure 14-4 indicates that as of Sprint 6, the team has built 297 points of work-
ing software. Because their MVP is estimated at 490, following the trend line
based on the average velocity, it will take the team until Sprint 10 to build the
remaining functionality.
To construct this metric for each Sprint Review (Figure 14-5), collect such
measurements as number of customers invited, number who attended, num-
ber of internal stakeholders, amount of feedback received, and amount of
feedback used to adapt the product.
16
14
Customer Invited
12
10 Customer Attended
8 Internal Stakeholders
Attended
6
Distinct Customer
Comments
4
Comments used for
product change
2
0
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 Sprint 8
Organizational Metrics
Organizational metrics indicate if the organization and teams therein are
aligning with the Agile values and principles and if a positive business effect
from the adoption of Agile is being seen. To add to the organizational metrics,
consider supplementing them with data from the Agile Mindset, Values, and
Principles (MVP) Advisor survey (Chapter 13). A trend metric can be created
to ensure that behavioral levels indicate a positive movement toward the Agile
mindset at the organizational level. It can also be used at the product level.
Employee Satisfaction
Employee satisfaction is a way to gauge employees' feeling of contentment
within a workplace. Employee feedback allows you to engage in meaningful
improvement opportunities based on their feedback. The benefit of conduct-
ing employee satisfaction surveys is that it lets employees know that you care.
Poor satisfaction can lead to higher than normal attrition rates and low pro-
ductivity. Satisfied employees can lead to loyalty and higher productivity. By
giving your employees a voice, they can express their interests and concerns.
Being Agile 147
Customer Satisfaction
Customer satisfaction is a way to gauge if a company’s products and services
meet or surpass customer expectations. The benefit of customer satisfac-
tion is twofold. First, it is considered a leading indicator of customer revenue,
so it can give you insight into whether you are moving in the right direc-
tion. Second, it can focus employees on the importance of fulfilling customers’
expectations. Although customer satisfaction is measured at the individual
level, it is often reported at a cumulative level. It may be measured along vari-
ous dimensions: the usefulness of a product, the relationship with the com-
pany, and responsiveness to problems.
Customer satisfaction surveys should be conducted periodically—say, on a
quarterly basis—to provide a continual gauge of the customers' view of the
company's products and identify actions for improvement. Postpurchase sur-
veys can reflect the satisfaction of the individual customer at the time of
product or service delivery. Because there are many forms of customer sat-
isfaction metrics, consider researching the various forms and identify what is
right for you.
Customer Revenue
Revenue is a complex term that can be interpreted in many ways. I am refer-
ring to net revenue, which is the amount of money a company receives from
sales of products and services less negative revenue items like returned items,
refunds, and discounts. Although revenue is a lagging indicator, the benefit of
revenue metrics is that they are the ultimate indicator of whether customers
find value in the products you are building.
Revenue metrics can be generated at product, product line, business unit,
or organizational levels. Start at the product level, so you can understand if
there is value coming from a product. When you gain revenue, it is beneficial
to initiate a customer satisfaction survey to understand what specific value
the customer found. Because revenue is a lagging metric, ensure you create
a lagging-to-leading metric path so that you have leading indicators to help you
148 Chapter 14 | Establishing Agile Measures of Success
gauge your path to an increase in revenue. There are many forms of revenue
metrics, so consider researching the various forms and identify what is right
for you.
Release Frequency
A release frequency metric provides visibility into the rate in which you are
delivering customer value into production. The benefit of this metric is that
it can help you fine-tune your release cycle toward the need of the customer
and the revenue you want to gain. Although you do not have to technically
release your product, knowing you have the ability to do so can help you be
ready when a customer says that they would like the functionality now and
you can then gain revenue. The ability of a customer to use the new release is
directly related to the customer value of the release and the customer’s ability
to absorb the release.
If you have an on-premises product that takes two weeks to install into a
customer environment, another two weeks to integrate with other customer
products with verified functionality, and another two weeks to train users in
the new functionality, then reducing release frequency may not be reasonable.
However, if you have customers demanding more functionality on a regular
basis and you can reduce installation times, understanding your release fre-
quency can help you baseline where you are and what you want to achieve.
If you have a SaaS product, the release frequency is dependent on your internal
processes and customer demand.
You can use release frequency as an indicator for revenue. By having both
metrics available, you can have visibility into what happens to a product’s rev-
enue when you increase the frequency of release. Because release frequency
may take many forms, select the metric that is right for you. It may also be
combined with your revenue metric.
Agility Path
The Agility Path is a framework developed by Scrum.org that links current
enterprise activities and their metrics with a process for continuous improve-
ment. The first step is gathering and analyzing the business and process data
needed to assess the current state of a company in each of its critical function
areas. The next step is using these data to identify where improvements to
business practices are most needed to have a positive effect on the company’s
performance.
The Agility Path is broken down into enterprise metrics, which reflect the busi-
ness value a company generates, and foundational metrics, which measure orga-
nizational agility and flexibility in creating this value.
Being Agile 149
g
CHAPTER
15
Constructing
a Scalable Agile
Framework
A total commitment is paramount to reaching the ultimate in performance.
—Tom Flores
It Takes a Village
Although Agile tends to occur on a product team, you will gain the most
business benefits when it occurs at the level of the organization. Some areas
that will help you scale your teams and organizations toward an agile culture
include a focus on team size, roles, Scrum of Scrums, and geographical distri-
bution. Two other areas that will help you scale at the organizational level are
adapting IT governance and performance reviews toward an Agile mindset,
discussed in Chapter 23.
■■Agile Pit Stop Three attributes of Agile teams that align with the Agile mindset are small yet
skilled teams, ownership of a functional piece of the product, and colocation.
Near-shore means that team members are within the same campus or within
the same time zone or two. In the same scenario, if you have a project team
of 35 and find that 15 are in India, 7 are in Europe, and 13 are in the eastern
part of the United States, then it makes sense to have two teams of 7 and 8,
respectively, in India, one team of 7 in Europe, and two teams of 6 and 7 in the
eastern part of the United States. If you find that, within the United States, five
of the team members are colocated in Massachusetts, then it makes sense to
have those five on one team.
Scrum of Scrums
When a product team is comprised of two or more Scrum Teams, a Scrum of
Scrums (SoS) may be established. An SoS is a coordinating body made up of
representatives from each of the Scrum Teams to focus on the many cross-
team issues and dependencies that need to be resolved and to keep large
teams synchronized and operating effectively.
■■Agile Pit Stop The acronym of SoS traditionally means “save our ship.” In Agile, the Scrum of
Scrum acronym SoS also connotes saving through capturing and mitigating cross-team risks that
can affect project success.
Most agile processes such as Scrum are ideally suited for colocated team sizes
of seven plus or minus two people. When you have a large project team of 35,
there needs to be a way to coordinate the work and ensure common issues
across those teams get addressed in an effective manner. The benefits of a
SoS are that it:
• Enhances communications across teams, so each team
knows what the other is doing.
• Avoids duplication of effort across teams.
154 Chapter 15 | Constructing a Scalable Agile Framework
Scrum Scrum
Scrum Team
Team Team
Scrum of Scrums
Figure 15-1. Scrum of Scrums includes a representative from each Scrum Team
The generic SoS focuses on project progress, risks, issues, and dependencies.
This Project Progress Scrum of Scrums is usually comprised of the Scrum Masters,
the Product Owners, and an Agile project manager. The Project Progress SoS
is responsible for the following:
• Monitors release burn-up with velocity to determine
scope to release date and whether adjustments to either
scope or schedule need to occur.
• Identifies and mitigates blocking issues that are beyond
the scope of a Scrum Team, with the goal of removing the
blockage or escalating it to management.
• Discusses story dependencies among Scrum Teams and
ensures that the highest priority stories are optimized to
the project level.
Being Agile 155
Sprint 0
Sprint 0 is a Sprint designed to help teams envision the work ahead. It is pri-
marily used by teams new to Agile to help in their readiness to begin Agile
or by teams beginning a complex project that requires thought for visioning
and getting organized. Sprint 0 is not a replacement for big up-front activities
found within the waterfall and phase-based methods, but instead serves to
establish a basic vision of where the project is headed while acknowledging
that things will adapt as the team moves forward. The length of this Sprint
should be no longer than the standard Sprint length. Here are some tasks that
typically occur during a Sprint 0.
• Define teams, including team size, need for multiple teams,
and team distribution.
• Define Sprint length.
• Educate teams on agile processes and practices.
• Collect and groom stories within the backlog with an
emphasis on prioritization.
• Establish Scrum of Scrums.
• Work on spike solutions per the XP definition.
• Identify project risks, issues, and dependencies.
• Establish the product, technical, QA, and CM visions.
Some may argue that Sprint 0 is not true to Scrum, and they are correct
because no working software is produced. However, in some cases, these
tasks need to occur prior to Sprint 1, irrespective of what you call this time-
boxed period.
■■Agile Pit Stop The key in creating a vision is to envision what is known and enough of a short-
term path to provide high-level guidance to share with the team.
Being Agile 157
For clarity, a vision provides enough detail for team members to understand
the general direction of the topic area. It is not meant to be detailed or fixed,
because in an Agile mindset you cannot possibly know everything up front,
and you expect that it will evolve. Visions should be brief and easily digestible.
They may live in the team document repository, such as the wiki. Also, if the
vision remains mostly the same from one release to the other, then the vision
should primarily include what is changing.
The various visions that can help a team include:
• Product vision: provides business context of the product
to include business performance, market share, and mea-
sures of customer satisfaction, high-level product road-
map, and a prioritized list of business objectives. It may
also include an elevator pitch encapsulating the project in
succinct but compelling terms.
• Technical vision: provides the direction of the architecture,
including known and emerging elements of the technol-
ogy stack, frameworks, common infrastructure and oper-
ating platforms, needs for refactoring, and system-level
nonfunctional requirements such as usability, perfor-
mance, reliability, security, and any governing regulatory
or industry standards that must be followed.
• QA vision: provides an overview of the proposed testing
framework, testing process and how it interacts with the
development process, testing types, test tools, and who
may perform the various types of testing.
• CM vision: provides an overview of the proposed version
control tool, branching and merging processes, and build
management tool and process.
It is best to implement Sprint 0 much like any other Sprint. The team starts
with a form of Sprint Planning, a Sprint 0 backlog is used to manage the work,
and daily stand-ups occur to share progress and roadblocks. Instead of a Sprint
Review and retrospective, I recommend that you conclude the Sprint 0 with
Agile Release Planning. This is a session in which everyone is together (physi-
cally or virtually) sharing the results of Sprint 0 at the same time.
There are two approaches to timing Agile Release Planning. The first is at the
beginning of a project, in a Sprint 0 context or otherwise. The second is that
it occurs every 90 days to periodically visit the visions and direction of the
product.
Automation
One aspect of scaling is reducing manual steps and automating the necessary
steps. Eliminating and automating provides the team an opportunity to scale
and increase their velocity. It is recommended to automate any process that is
repeated by enough people for which the team will see a cost and time benefit
in doing so. Because the team can focus less on the manual steps of a process
and more on the work of building product, they have a real opportunity of
increasing their team velocity.
As an Agile Team gets up and running, given the continuous nature of build-
ing, migrating, and testing code and the increasing size of the code base with
new functionality, a lack or minimal amount of automation may start to affect
velocity fairly quickly in a negative way. Please understand that at a certain
point velocity may remain constant even with automation, but you can be cer-
tain that without automation or with minimal automation the team’s velocity
will plateau.
1
Ken Schwaber. The Enterprise and Scrum. Microsoft Press, 2007.
2
Craig Larman and Bas Vodde. Practices for Scaling Lean & Agile Development, Addison-Wesley
Professional, 2010.
160 Chapter 15 | Constructing a Scalable Agile Framework
Scaling Up
As Agile gains adoption within your product team and outward into your
organization, you may need to consider how to scale your implementation.
This chapter has suggested some ways you can enhance your agile framework
for larger and more complex teams. It is not however meant to be exhaustive.
The key takeaway is that as you scale, you should seek out information and
make sure that you are continuing to promote the spirit of the Agile values
and principles as you do so.
Scott Ambler and Mark Lines. Disciplined Agile Delivery. IBM Press, 2012.
4
CHAPTER
16
Establishing an
Agile Education
Program
Education is the most powerful weapon which you can use to change
the world.
—Nelson Mandela
Does your company education begin and end with training? Will this suffice
for a change to Agile? Agile is a mindset that signifies a change to the culture.
Because of this, we cannot think that reading a book or taking a training class
will suffice and provide enough knowledge to cause a shift in thinking to be
Agile. There is more to ramping up with Agile then just training. It takes a
repertoire of educational elements. Training is just one of those educational
elements.
The goal of this chapter is to make you aware that it takes a variety of educa-
tional elements within an agile context to help your organization come up to
speed with Agile. No one element is sufficient; it is instead the accumulation
of education elements at different points in time that will provide the compre-
hensive focus to help you, your team, and your organization. As you read the
information, the objective is for you to construct an education plan that best
serves your goal of an Agile transformation. Ultimately you want to create a
self-organizing educational culture with many elements and the most mature
level is when employees are willing to give back to their community.
162 Chapter 16 | Establishing an Agile Education Program
Skill Training
Education
Figure 16-1. Path of educational levels that can support a transformation to a new culture
Educational Elements
There are many education elements that can help you get to an Agile culture.
Within the levels of education described in the previous section are various
additive education elements that contribute to the next level of education.
As you move up the education levels, the education moves from formal to
informal elements of education. Here is one perspective on educational
elements within a level:
• Awareness may be considered the first step in the education
process. This element calls attention to the new Agile ini-
tiative, may include the objectives and motivations, and may
provide an overview of the initiative or of the topic such
as a 30-minute Agile overview. Awareness elements may
also be in the form of a brochure, flyer, or short presenta-
tion. This element prepares the mind to become open and
attentive to subsequent educational elements.
• Skills training provides soft or hard skills to the attendee.
This may come in the form of an instructor-led seminar or
a virtual webinar. An example of this type of training is a
course on agile planning tools or how to write user stories.
• Role training provides education on a person’s role in rela-
tion to the process, practices, and methods being taught.
An example is a Scrum Master’s role for Sprint Planning.
• Community sharing includes items within a shared envi-
ronment. This may take form of agile practices within a
website, and recorded seminars and webinars that are
hosted and always available for viewing.
• Process and role coaching involves in-session education by a
coach to a team or an individual. This may include respec-
tive Scrum Master and Product Owner Q&A sessions
where those playing these roles may ask specific questions
regarding the application of the agile process in context
to their role. This element helps reinforce a new skill or
process to ensure they are being applied as expected.
164 Chapter 16 | Establishing an Agile Education Program
■■Agile Pit Stop Forms of education include instructor-led training and seminars, virtual training
and webinars, blog articles, books, video snippets, and practice exercises on websites.
Gamification
Gamification adapts game concepts to nongaming situations to engage
employees and motivate them to improve their performance and behavior.
It rewards employees for completing performance levels with points, badges,
privileges, and sometimes monetary incentives. Gamification can be deployed
to engage employees in agile educational elements.
The key to gamification is that it must be driven by a clear business objective.
With the context of Agile, the goal with gamification is to encourage employ-
ees to become Agile Champions and achieve an Agile culture. Although it
may start with training, you eventually would like employees acting as Agile
Champions to give back to their community.
166 Chapter 16 | Establishing an Agile Education Program
17
Creating
a Customer
Validation Vision
Nothing is as empowering as real-world validation.
—Steven Pressfield
Engaging the customer is one of the most important aspects of building cus-
tomer value. Gaining continuous customer feedback of working software is an
important aspect of the inspect-and-adapt model, which ensures that you are
constructing a valuable solution for the customer. Without customer valida-
tion, you are not really applying Agile; you are just doing a form of iterative
development without aligning your work with customers’ need. Although the
engineering practices applied within an agile project focus on building the
product right, the validation practices focus on building the right product.
Chapter 4 discusses the importance of customer engagement. This chapter
helps you establish the building blocks to achieve continuous customer vali-
dation via an approach I call the Agile Customer Validation Vision. The notion
of thinking through and establishing an authentic validation approach for the
product is missing from agile projects and practices. This vision provides a
framework for identifying the right customers, constructing customer pro-
files, identifying personas, establishing continuous validation sessions, motivat-
ing the customers to attend the validation sessions, and incorporating their
feedback.
168 Chapter 17 | Creating a Customer Validation Vision
■■Agile Pit Stop Your key stakeholders are your customers. If customers don’t perceive value in
your products and buy them, your company will not stay in business.
You may be saying to yourself that your product management, sales, and mar-
keting groups help you with identifying customers. This is good, and in Agile
it is important to foster the team mindset by including their participation and
introducing these groups to the engineering teams.
However, you need a single person, such as the Product Owner, to merge
customer needs and decide on which customers will be the focus for require-
ments gathering and validation events. The ultimate goal is to bring the cus-
tomers to your Sprint Reviews of your working software to prove value or
adapt according to their feedback. Someone needs to be responsible for iden-
tifying the right customers and for all the activities involved with continuous
customer engagement. You need a dedicated business representative on your
team who is focused on building customer value within your products.
Being Agile 169
■■Agile Pit Stop The challenge with identifying the elusive customer value is that different
customer target groups see customer value differently.
It is important to know that your current customers are the real buyers
of your product, must be treated well, and are your highest priority. The
potential customer group represents an opportunity to grow your revenue.
Potential customers represent both potential buyers and browsers. Although
it is hard to differentiate between potential buyers versus browsers, it can
affect their priority within the overall customer pool. If you have past custom-
ers, it is important to keep track of who they are in case you want to revisit
them. You can often glean important information from a past customer from
the perspective of what they did not like about the product and what it might
take to bring them back into the fold again.
Within the current customer group, it is important to identify which custom-
ers are leaders and which ones are followers. A leader is a customer who
embraces your product, is willing to speak positively about it, has the cachet
to attract other customers, and is eager to discuss requirements. A follower
might use the product but not necessarily advocate for it. You want to identify
the leaders. In some cases, with the right grooming, you can convert a follower
into a leader. Grooming may entail engaging them in your requirements dis-
cussions and Sprint Reviews.
170 Chapter 17 | Creating a Customer Validation Vision
Identify Personas
Personas represent specific users of a product and act as examples of the types
of users who would interact with it. Most products have several personas that
use the product in different ways. Examples of three personas for a product
are the regular user, power user, and administrator.
• The regular user uses only the basic user interface
functionality.
• The power user needs more detailed interface functional-
ity to handle more sophisticated work.
• The administrator needs back-end installation and mainte-
nance functionality.
All three use the product differently, and different features are built for their
respective needs. Personas are a powerful way to guide your decisions about
functionality and ensure that you are, in fact, building functionality for each
persona.
Personas should be identified early on in the development of the product.
Often personas are discovered within the user story collection or grooming
activities. Personas are a key ingredient in the way that user stories can be
presented. Including the persona in a story description provides you the point
of view (POV) of a user story and defines who that user story is for. Chapter
18 offers more insights into the importance of including personas in user
story writing. A persona glossary should be shared with the developers so
they understand for whom they are building the user stories and so QA
understands the POV for testing the user story.
■■Agile Pit Stop Personas provide three distinct advantages. The team understands the users
better, which helps guide decisions about functionality. The user stories are written to support and
build functionality for personas. Based on their personas, the Product Owner knows who can give the
best feedback and therefore whom to invite to the Sprint Reviews.
I recommend that you establish a description for each persona. This descrip-
tion is typically illustrated as a fictitious person that represents a real role.
It will include the knowledge, experience, and activities of that role. By writing
a persona as a fictitious person with a name, this makes the persona easier to
imagine and relate to, as in the following examples.
Being Agile 171
Customer Demonstrations
The primary way to be continually in touch with your customers and ensure
you are building customer value is to provide customers with the opportunity
to validate the working software. This engagement is critical to inspect-and-
adapt model to ensure the narrowest possible gap between what is delivered
and what the customer needs at the time of delivery. Studies show that cus-
tomer validation opportunities are fewer than expected.
According to a self-reported survey, only 57 percent of the respondents
affirmed that “at the end of each iteration, we demo our work.1” Worse,
only 38 percent say, “We demo the solution to stakeholders every iteration.”
These results are sobering. They indicate a widespread lack of understand-
ing of Agile values and principles and particularly in the importance of the
inspect-and-adapt model with the customer.
The key to Agile is not just to adapt but to do so in the direction that closes in
on business value. It is challenging to do this when stakeholders—particularly
the customers—are not attending the continuous demonstrations of working
software. The goal should be to get the customers to the demonstrations.
1
Scott Ambler, “How Agile Are You? 2013 Survey Results,” http://www.ambysoft.com/
surveys/howAgileAreYou2013.html.
Being Agile 173
■■Agile Pit Stop Customers who attend your validation events are working full-time at another
company. Their time is precious. Use this time to gain their valuable feedback.
One approach is to start by inviting customers to one demo session and get
their input. Customers who have not experienced something like this before
typically are impressed to see working software so early in a release life cycle.
They especially like to be asked for their feedback. If they like the first valida-
tion session, then invite them to the next demo session. If they agree, entice
them by building in some of their feedback. If they show up for the second ses-
sion, excite them by highlighting the points where you’ve incorporated their
input. At this point, ask the customers if they want to participate periodically
at a per-Sprint cadence.
As you are working on your Agile Customer Validation Vision, you should
include your strategy on how to motivate customers to attend. You will find,
however, that customers are motivated by different things, so you will need an
array of motivational tactics within your strategy.
18
Writing User
Stories and
Grooming the
Backlog
Focus on what can be done rather than be frustrated by what can’t be done.
—Ken Schwaber
The key drivers of work within an agile process are the user stories, which
are collected from the customers, stored in the backlog, and built by the team.
User stories are essentially requirements that are written from the perspec-
tive of the user of the product. The backlog is essentially a requirements list
that is continuously groomed to understand priority and gain clarity. As a
readiness activity within the RICH model, you need to consider the user story
language construct you plan to use to help with consistency and comprehen-
sion, where you plan to store the Product Backlog for easy access and sorting,
and how frequently you plan to groom the backlog.
176 Chapter 18 | Writing User Stories and Grooming the Backlog
Release 1 Release 2
Themes
Epics
User
Stories
Tasks
Themes are top-level objectives that may span multiple releases and products.
Themes should be decomposed into epics that can be applied to a specific
product or release. Themes can be used by a solution or product to drive
strategic alignment and communicate a clear direction. Examples are:
• Reduce the number of clicks to get to our user function-
ality within our products and services.
• Improve traffic to the website.
• Apply single sign-on capability to all company products.
Epics are the parent of multiple user stories and are roughly equivalent to
a feature or very large story that encapsulates a large piece of functionality.
Epics are written by the Product Owner. Epics are helpful when creating a
product vision for a release. They should be decomposed into user stories
before being introduced into a Sprint. Examples of epics are:
• Administrators can manage users.
• Customer can purchase a ticket.
User stories are equivalent to a business or user requirement and are col-
lected and written by the Product Owner. Stories provide user functionality
that represents value to the customer. A user story should be able to be built
Being Agile 177
within a Sprint or, ideally, within half a Sprint. The next section treats user
stories at length.
Tasks are the children of user stories and are equivalent to an incremental
decomposition of the user story that is defined by the Agile Team. The intent
of tasks is to allow the team to incrementally build and test the story so that
not all testing occurs at the end. Avoid decomposing stories into stand-alone
design, develop, and test tasks, which emphasize a mini-waterfall approach.
When a team breaks user stories into tasks, it gains further clarification of the
scope of work that needs to be done. For example, a user story that builds a
search function can be decomposed into:
• Create static web page.
• Build simple search.
• Add advanced search capabilities.
There are other types of work items that should be captured in the backlog.
XP introduces the spike solution, which provides a focus on solving a challenging
technical, architectural, or design problem. Sometimes known as a research
spike, this work may seek the answer to a critical business or technical issue.
Two examples of research spikes are “What database solution will the team
use?” and “What is the product direction in applying forums?” The answers
serve to support subsequent epics and user stories.
User Stories
Within an Agile context, user stories are the primary currency used to deter-
mine what needs to be built by the team that represents customer value.
User stories describe functionality that will be valuable to a user or purchaser
of a system (persona). User stories are the primary topic discussed in Sprint
Planning. The intent of a user story isn’t to specify every detail of the need
but to provide enough detail to start a healthy conversation about the story
to help flesh out the details.
■■Agile Pit Stop The user story is the primary requirement building block for specifying the
functionality that needs to be built within a Sprint.
The Product Owner is responsible for eliciting user stories from customers
and stakeholders. Many others, however, may contribute stories to the
Product Owner, including the Agile Team, sales, and marketing. The Product
Owner collects and adds the user stories into the Product Backlog. Those
178 Chapter 18 | Writing User Stories and Grooming the Backlog
user stories that are rank-ordered highest within the backlog get selected and
built within a Sprint. The attempt is to build user story functionality within a
Sprint time-box.
Canonical Form
There are many ways to write a user story. A canonical form is an example of a
requirements language construct that is geared toward Agile. This brief state-
ment expresses a user story as who wants something, what they want from a
system, and why. The canonical form transcends processes and methodology
and works just as well for waterfall as it does for Agile. There are three key
elements of a user story in canonical form: the persona, the action, and the
business benefit.
• The persona represents a particular user of the system,
as discussed in Chapter 17. Examples of personas include
a buyer who must use the product to purchase items, a
power user who uses the product to create quantitative
reports, or an administrator who uses the system to man-
age users and install the most recent patch upgrades.
• The action represents what the persona would like to do
with the product.
• The business benefit provides the value that is gained for
the persona. It provides context for the action and helps
with testing factors. If I said, “As a user, I can create an
account” and leave the business benefit empty, why do
you think the user wants an account? The answer can
lead you to build very different things if you don’t know.
If the answer is, “to become a member of the site,” you
might build a MyPage. If the answer is, “to purchase con-
cert tickets,” you might build an order entry system.
Description : ______________________________________________________
Tasks: ______________________________________________
_______________________________________________
_______________________________________________
Figure 18-2. User story with attributes to provide a holistic view of the work
Product Backlog
A Product Backlog is a repository for user stories and other Product Backlog
Items (PBIs) such as tasks, epics, and themes. The Product Backlog is the
singular place to store all PBIs related to the product. Most Product Backlogs
are either a form of document or in an agile planning product that offers
automation to manage PBIs.
Being Agile 181
The Product Backlog is owned and managed by the Product Owner. Others
may contribute to the backlog, but the Product Owner controls the prioritiza-
tion and rank order of the work. The Product Backlog should be readily avail-
able to the Scrum Team to view and update, particularly the tasks associated
with the user stories.
■■Agile Pit Stop Anyone associated with the product may contribute stories to the backlog.
However, only the Product Owner can specify priority or rank order.
The key attributes of the Product Backlog are the priority and rank order
(see Figure 18-3). These fields help sort the user stories toward the order of
the work. Within an Agile context, the Product Owner and team gain details
on the highest priority items, seeking to gain clarity, decomposing epics to
user stories and user stories into tasks, and looking for dependencies among
stories.
Sprint
Release
Beyond
Product Backlog
Figure 18-3. Hierarchy of the Product Backlog: highest priority items at the top where
Sprint work is occurring
In a traditional waterfall world, the combination of the project plan and the
requirements list drives the work. In an Agile world, the Product Backlog
drives the work for a team.
Forms of Backlogs
The Product Backlog can be represented in various ways. In its fullest form, it
is the location for the whole list of backlog items. There are other forms of
backlog. They are the Sprint Backlog and Team Backlog.
The Sprint Backlog represents a subset of user stories that are prioritized and
rank ordered. Those stories that are highest priority and fit the team velocity
or amount of work a team can complete within a Sprint period become the
Sprint Backlog. There is a unique Sprint Backlog for each Sprint. The items
182 Chapter 18 | Writing User Stories and Grooming the Backlog
within it come from the Product Backlog and are identified and added during
Sprint Planning. The Sprint Backlog forms the backbone of the work within a
Sprint. All stories and tasks within the Sprint are recorded within the Sprint
Backlog.
The Team Backlog is beneficial when you have multiple Scrum Teams building
a product together. The Team Backlog represents a view of the work that is
geared toward a particular Scrum Team. During grooming and Sprint Planning,
the Scrum Team reviews their prioritized team backlog. From the team backlog,
the team can establish a Sprint Backlog of those high-priority stories that the
team will work on within a Sprint.
Attributes of a Backlog
A healthy backlog includes attributes that can be associated with the PBIs,
such as user stories. It will include the attributes that are associated with a
user story, such as a description, size, acceptance criteria, tasks, owner, and
progress. In addition, because it is a large list, there are additional attributes
that should be included to help you sort the requirements. These attributes
include:
• PBI types: a way to differentiate between work types such
as epic, theme, user stories, tasks, and bugs.
• ID: a way to provide a unique identifier for each PBI.
• Source: the origin of the PBI, such as customer or
stakeholder.
• Priority: a way to differentiate the importance of the PBI,
often written as high/medium/low, or 1/2/3/4, or must/
should/could/would.
• Dependencies: a way to indicate when a PBI is dependent
on other PBIs or external functions.
• Sprint: the Sprint within which the PBI is built.
• Comments: a place to provide additional notes.
Grooming
The primary purpose of grooming is to prioritize the backlog so that when you
initiate Sprint Planning, you have the stories ready for further refinement, siz-
ing, adding to the Sprint, and gaining commitment to the work that is involved.
Grooming may also include ensuring that the user story is in canonical format,
details of the story are understood, dependencies are included, and accep-
tance criteria have been added or clarified. The better you groom the higher
Being Agile 183
priority items within the backlog, the easier and shorter the Sprint Planning
event will be.
■■Agile Pit Stop The key focus in backlog grooming is to prioritize and rank order the user stories,
and then gain more details of those higher priority stories.
The PO is primarily responsible for grooming the backlog. The PO may also
invite the full Scrum Team or a select few, such as the lead developer and lead
QA team member. There is a great benefit for the PO to invite the Scrum
Team. Most important, Scrum Team can ask the PO tough questions regarding
specific information and acceptance criteria to gain relevant detail about the
story.
Grooming should occur at several different times in your release life cycle:
before and during Sprint 0, during Agile Release Planning, during Sprint Planning,
and periodically throughout the release.
Sprint Planning
The grooming that occurs within Sprint Planning focuses on gaining enough
understanding of the user stories to build the functionality within a Sprint.
This grooming will include gaining detail about the story, discussing design
aspects, decomposing the story into tasks, and sizing the story. If the highest
priority user stories are well groomed coming into Sprint Planning, then this
event may be shorter than usual.
The grooming within Sprint Planning is performed by the PO and the team.
The team should leave the Sprint Planning event with confidence in their
knowledge of the user stories that are now part of the sprint backlog.
The Product Backlog provides a single place to store the user stories and
other PBIs. It is important to think through whether you want to manually
manage the backlog items within a document or in an agile planning product
that offers automation to manage PBIs. Finally, ensure there is periodic groom-
ing so you have a prioritized backlog in which the highest priority items have
more details. This helps provide a broad view of the work ahead and easier
Sprint Planning events. Thinking of these areas early and then sharing them
with the team helps provide a framework for collecting, storing, prioritizing,
sorting, and better understanding customer needs.
CHAPTER
19
Working
with Story
Points, Velocity,
and Burndowns
The best we can do is size up the chances, calculate the risks involved,
estimate our ability to deal with them, and then make our plans with
confidence.
—Henry Ford
■■Agile Pit Stop Story points are an abstract scope measure focusing on the work. It is not wise
to apply a schedule measure of hours and days. Instead, use a scope measure like story points to
indicate the amount and complexity of the work.
In Agile, the intent is to determine the unit size of work based on the func-
tionality you are building for that story. In effect, scope is the measure of
progress based on amount of effort and complexity of the work. I realized
that there are those who try to apply a schedule measure because of their
familiarity with traditional estimation whereas story points are in fact meant
to represent the scope of the work. In other words, when you try to apply
a schedule measure for scope, it is like trying to fit a square peg in a round
hole. Ultimately, you need both scope (story points) and schedule (per Sprint
length) to understand your team pace (velocity).
Story Points
Story points are a relative measure that expresses the amount of functional-
ity and the complexity of the work. Every team creates their own story
point sizing framework based on the type of work they do, the skills
and experience of the team, and what they personally perceive to be a small,
medium, or large amount of work. This is why management should not compare
the story point velocity of different teams.
Being Agile 189
This relative sizing framework takes the focus off the actual schedule measure
of hours or days and instead puts it on describing the size and complexity of
a functionality compared with other functionality. If you are familiar with func-
tion points, story points acts as a similar measure that tries to establish a unit
size or scope of the work.
■■Agile Pit Stop Story point sizing framework is specific to each team. This is why no one should
try to compare the story point sizes from one team to the next.
Fibonacci Sequence
Story points are usually expressed in numeric units. The range of units that
is often used within the agile world is the Fibonacci sequence. The sequence
of Fibonacci numbers provides a numeric distribution that can be used to dif-
ferentiate between sizes of work (Figure 19-1).
■■Agile Pit Stop This relative story point sizing framework should be in a readily viewable place
for all of the team to see.
This is the beginning of establishing the relative story point sizing framework
for your team. Because each Scrum Team may work on different types of func-
tionality (for example, front-end UI versus back-end database), it is critical that
each team develop their own sizing framework.
Planning Poker
Planning poker is an instructive and fun consensus-based sizing technique used
to size the stories, primarily during Sprint Planning. It is based on Wideband
Delphi, a consensus-based technique for sizing work. Planning poker starts
with placing the Fibonacci sequence numbers from 1 through 55 on the faces
of playing cards (Figure 19-2).
Figure 19-2. Planning poker playing cards used to size user stories
To play planning poker, each team member gets a deck of cards. For this exam-
ple, Sprint Planning has commenced and the team has discussed the details of
a user story. When it is time to size the story:
• Each team member discreetly selects a card from their
deck relating to the story points they think reflects the
size and complexity of the work for the story and simul-
taneously displays it to the rest of the team.
• If there is consensus in the size, this becomes the recorded
size for the story.
• If there are differences in sizes, then the owners of low-
est and highest cards explain their sizing position, and the
team briefly discusses the story further.
• Each team member again selects a card based on the new
discussion.
• This continues until a consensus on the size is achieved.
Being Agile 191
Planning poker can be played face to face when all team members are colo-
cated or virtually when team members are distributed. If virtual, then sizes
can be instant-messaged to the Scrum Master, who shares the sizes with the
team.
Sprint Burndown
A Sprint Burndown is used by a team to highlight the amount of work that a
team plans to complete, known as the target velocity, compared to what work
was actually completed and what work is left to do. It is a metric meant only
for a particular Scrum Team and is only relevant for a particular Sprint. The
benefit is that it is used to provide a team awareness of whether they are on
track, predict when all of the work will be completed, and identify roadblocks
early.
In Figure 19-3, the ideal burndown line starts with the team’s target velocity,
which is the amount of work a team believes they can do within a Sprint. In
this example, the unit of work is called story points and for this Sprint the
target velocity is 55. The ideal burndown line is established by starting with
the target velocity and then subtracting the average increment each day. You
get the daily average increment by dividing the target velocity by the number
of days in a Sprint (in this example, 55/10 = 5.5).
60
55
52
55 50
50
49
45
43
40
39
37
31
30 31
24 23
20
18
12
10
0 0
Tues Wed Thurs Fri Mon Tues Wed Thurs Fri Mon
Figure 19-3. Sprint Burndown to help a team view their progress throughout a Sprint
192 Chapter 19 | Working with Story Points, Velocity, and Burndowns
The actual burndown line indicates how many story points of work are actu-
ally completed from day to day. It starts with the team’s target velocity (55),
and each day it is subtracted by the amount of work done or completed
stories each day. Because each story is a different size, the amount that gets
subtracted on each day varies by the number of stories and the unit size of
each of those stories. (Don’t be surprised if, early in the Sprint, the actual
burndown stays flat for a couple of days. Team members are just starting the
work and it is not realistic to expect immediate completion of a story.)
Velocity
Velocity is a metric that can help you understand a team’s sustainable pace
by identifying the amount of stories that represent customer value a team
can deliver in a Sprint. Sustainable pace is one of the Agile principles, and the
intent is to understand this pace when team members are working 40 hours
a week and no more. Sustainable pace allows team members to work indefi-
nitely. A team’s Sprint velocity is a representation of how many story points
of functionality a team can deliver within a Sprint. At the beginning of a Sprint,
it is called the target velocity. The actual velocity is calculated at the end of each
Sprint based on the stories that actually get completed that meet the done
criteria (Chapter 20) and the acceptance criteria of each story (Chapter 18).
A team’s velocity is commonly represented in graphical form that is used to
measure the rate of business value a team can consistently deliver from Sprint
to Sprint. Because each team applies its own relative story point sizing frame-
work, this metric is unique and only applicable for a particular team. It must
not be used to compare one team to another. The benefit is that over time, it
becomes a predictor of the amount of work a team can do in the subsequent
Sprint.
In Figure 19-4, the target velocity is the team’s estimate of how many units of
work (or story points) it thinks it can complete within a Sprint. The actual
velocity is the actual units of work completed in that Sprint. The average velocity
is the average of the actual velocities accrued divided by the number of Sprints
completed.
Being Agile 193
80
75
Target Velocity Actual Velocity Average Velocity
70
60 60 58 58 58
60
55 55 55 55
50 54
50 52 53
48
40
40
40
30
20
10
0
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6
Figure 19-4. Team velocity metrics that a team uses to predict their target velocity (number
of story points they can complete in a Sprint)
Notice in the first Sprint that the team estimated a target velocity of 75.
Because they did not have any historical data on which to base their velocity,
it was a guess. They learned at the end of the Sprint that they actually com-
pleted 40 story point units of work. The good news is that at the beginning
of the next Sprint, they have a basis of actual work completed as historical
data, which can help them predict with more accuracy how many story points
of work they can complete. You can see by Sprint 4, the average velocity of
52 story points becomes a fairly accurate predictor of how much work the
team can complete in Sprint 5, during which they actually completed 55 units
of work. The velocity helps set a realistic target of work for each Sprint and
can be used to provide a release burnup for how many story points can be
completed for release (see discussion in Chapter 14).
20
Constructing
Done Criteria to
Promote Quality
Quality is not an act; it is a habit.
—Aristotle
Done criteria are clearly stated conditions that a user story must meet for the
functionality to be deemed complete and shippable for release. Done criteria
supports the Agile principle of technical excellence, by which team members
apply continuous attention to engineering practices and techniques focused
on building a quality product.
Done criteria set the tone and create a habit on what it means to be done.
These criteria should be readily viewable by the team as a reminder as it
makes its transition toward Agile. Done criteria confer the following benefits:
• They help set team’s expectations of what it means
to build the story functionality so that it is potentially
shippable.
• They help identify the engineering activities and expecta-
tions that must occur to build a quality product.
196 Chapter 20 | Constructing Done Criteria to Promote Quality
■ Agile Pit Stop There is a difference between done criteria and acceptance criteria. Acceptance
criteria are unique for each user story and answer the question, “How will I know when I’m done with
the story?” Done criteria are engineering tasks that apply equally to all user stories within the Sprint
and project.
I suggest that done criteria are one of the most critical techniques that must
be discussed and implemented to ensure that what gets built is made with
quality. You can think of done criteria as a form of team-based quality control
applied when a team builds product functionality.
At this point, the team discusses these elements, adapts the criteria to their
current level of discipline, and establishes a common definition of done for the
stories. You may need to further adapt your done criteria for the following
reasons:
• Align with compliance standards that must be met.
• Enhance with technical best practices of an organization.
• Consider the inclusion of establishing automation activi-
ties for streamlining testing and build processes.
Once the team agrees to done criteria, they become a cornerstone for velocity
and so have a direct effect on the sizing of stories. During Sprint Planning
events, the done criteria should be highlighted as a reminder of the level and
detail of work needed to complete the story and as an input to sizing the
work. When done criteria are established, post them in a visible place to
remind the team.
■■Agile Pit Stop You may have variations of done criteria depending on the type of story work
occurring. The done criteria described in this chapter focus on user stories. However, you may define
a specific done criteria for research spike stories and refactoring stories.
You should expect done criteria to evolve over time. You may want to
periodically review them during the Sprint Retrospective events to determine
if they need improvement. Also, some of the effort associated with your done
criteria is dependent on the tools, infrastructure, and automation that cur-
rently exist and on your vision of these areas.
Figure 20-1. How many dones do you need to name your done criteria?
21
Considering
Agile Tools
within an ALM
Framework
Technology is nothing. What’s important is that you have faith in people,
that they’re basically good and smart, and if you give them tools, they’ll do
wonderful things with them.
—Steve Jobs
I typically do not discuss agile tooling when initially helping teams adopt Agile.
I believe the initial focus should be on Agile values and principles and then the
processes and practices. Agile tooling discussions should occur as a readiness
activity within the RICH deployment model so that it is clear to the team
what tools will be used within the project and product context.
From an agile perspective, collocated teams may prefer to work with minimal tool-
ing in the agile space, using spreadsheets, story walls, and whiteboards. As soon as
teams become distributed, however, working with online tools becomes benefi-
cial. A team may gain benefits in productivity and transparency from automation
that they provide. Details on tools that can help you identify, track, and delivery
customer value should be included within the technical vision (Chapter 15).
202 Chapter 21 | Considering Agile Tools within an ALM Framework
■■Agile Pit Stop The tools that you use within an agile context should help you identify, track, and
deliver customer value.
Should you pursue an ALM framework to help with an agile deployment, make
sure that your main objective is to establish mechanisms that improve your
ability to understand and promote customer value throughout the lifecycle.
This helps establish traceability of customer value from the beginning of the
lifecycle to the end.
Being Agile 203
Customer
Value
Agile Methods & Practices
Value Chain
Figure 21-1. Applying application lifecycle management (ALM) tools to support agile
methods and practices to build the value chain and the delivery of customer value
■■Agile Pit Stop Agile Planning is often the first tool thought of for Agile. But business visioning,
collaboration, defect tracking, configuration management, continuous integration and build, test
automation can also be advantageous.
1
Michael Porter. Competitive Advantage: Creating and Sustaining Superior Performance. Free
Press, 1985.
204 Chapter 21 | Considering Agile Tools within an ALM Framework
learns of merge and build issues right away. Frequent code merging reduces
the challenges and pain of large, complex integrations in the future. It also
provides team members with immediate feedback on the success or failure
of changes in a build and in the subsequent smoke test of the product. The
smoke test provides a brief test of the functionality to ensure it operates at a
basic level.
A continuous integration and build system should be integrated with a version
control system that provides effective branching and merging functionality. This
includes the ability to initiate merge and build on check-in to the parent branch
and to provide information on what was merged and built and their results.
In addition, it is beneficial to have an integration with the agile planning tool on
one end to make the team aware of the merge and build results and on the
other end with the test environment to initiate the next step in testing.
One of the advantages of continuous integration is that the team begins to build
the customer value early and often. A very interesting cultural shift occurs
when the concept of continuous is ingrained into a culture. Agile embraces a
mindset of continuous change in which builds move from an event-based inte-
gration process to a continuous integration process. In other words, no one
needs to hold onto large amounts of changes for a major integration effort.
It also promotes more granular user stories and more frequent code changes.
Preparing a technical vision of your tool strategy can help you frame your
discussion around the benefits of tools and how the tools can help you
identify, track, and delivery customer value.
By fostering integration of tools across the lifecycle, an ALM framework can
support both the value chain and Agile in the pursuit of delivering customer
value. ALM establishes a tool framework to help a product team establish
and manage customer value throughout the lifecycle. It ensures traceability of
customer value from one part of the lifecycle area to another. As you
consider Agile, remind yourself of the Agile principle: People and interactions
over process and tools. This doesn’t mean that you ignore tools, but that you
should employ tools to help you deliver customer value.
CHAPTER
22
Implementing,
Coaching, and
Honing Activities
You just want to hone your craft, whatever it may be.
—Christopher Cross
The middle part of this book (Chapters 7–21) focuses on the readiness
activities described by the RICH model to assist the achievement of the Agile
mindset and true agile transformation. Readiness is the beginning of condi-
tioning the mind toward the behavior needed to align with Agile values and
principles and focuses on making decisions regarding the elements for your
implementation. As you incrementally make readiness decisions and continue
to focus on the Agile mindset, the implementation process can begin.
■■Agile Pit Stop The ready, implement, and hone activities of the RICH Deployment Model align
with the agile notion of inspect and adapt. Anything that gets deployed should be subject to an
opportunity for inspection and adaption.
This chapter highlights the key activities within implement, coach, and hone to
achieve an agile state of mind and a transformation to Agile (Figure 22-1).
210 Chapter 22 | Implementing, Coaching, and Honing Activities
Ready
Hone Implement
Coach
Figure 22-1. RICH model with emphasis on implement, coach, and hone activities
Implementing Agile
During readiness activities, there is an ever-growing list of people getting
involved in the Agile adoption effort. While the Agile Deployment Team has
the primary responsibility, they are incrementally involving new people to gain
their input, experience, and awareness. When there is a focus on implementa-
tion, the visibility and impact of the agile effort expands to the whole organi-
zational scope.
Implementation activities focus on the timely application of agile elements
within a team or organization. With proper conditioning during readiness
activities, the participants will understand why they are applying Agile and
begin to internalize the values and principles. Although you have made deci-
sions during readiness activities, you may need to adapt approaches and
decisions as implementation becomes real.
The primary goal of implementing is to roll out Agile to the organizational
scope. There may be emphasis in getting the mechanics in place, but there
should also be a strong focus in changing behaviors.
For everything that is implemented, there should be a follow-up to determine
whether the team understands why they are adopting, at what level they are
mechanically adopting the agile element, and at what level they are making
the cultural shift toward an Agile mindset. This reflective follow-up helps with
honing. During this time, it is important to infuse implementation activities
with appropriate coaching to ensure the agile mechanics and culture begin
to stick.
Being Agile 211
Continuing Education
Education for Agile is a long-term venture. The early steps start with promoting
awareness and getting the organization trained. Awareness should have begun
during readiness to ensure those within the scope are aware of the objective
and motivations for moving to Agile.
■■Agile Pit Stop The agile community venue provides an opportunity to share, discuss, and
collaborate on a variety of topics.
212 Chapter 22 | Implementing, Coaching, and Honing Activities
Early on, the members of the Agile Deployment Team may be the biggest
responders to questions posed, but they should actively seek contributions
from local Agile Champions and other community members. If you have imple-
mented a form of gamification to get people engaged in the community, now
is the time to start. Chapter 16 looks at building an agile community and ways
to implement gamification.
■■Agile Pit Stop Depending on the number of teams needing training, you may consider capturing
metrics on number trained to gain a sense of training progress.
Next, the Scrum Master should be trained by taking a specific Scrum Master
workshop or Certified Scrum Master (CSM) training. This is because the
Scrum Master helps set the project up within an agile context, is the facilitator
of the agile events, and will act as the guardian and promoter of Agile values
and principles.
Being Agile 213
■■Agile Pit Stop When implementing an Agile framework, consider following the Shu Ha Ri
concept of learning (Shu - obey the rule, Ha - adapt the rule, Ri - transcend the rule). First practice
by the book. Then you are in a position to adapt and transcend.
Coaching Agile
Coaching should accompany the readiness, implement, and hone activities.
Agile Coaches can provide significant benefit in these areas if they have expe-
rience in deploying Agile, are veterans of organizational change, have played
Agile roles on a team, and are well versed in working with the business benefits
Being Agile 215
of Agile. Coaching activities focus on helping the team and organization adapt
and align to the new culture.
As Agile Coaches help teams toward their goals, they should support and facil-
itate agile deployment efforts during the readiness, implementation, and hone
activities. As discussed in Chapter 12, Agile Coaches can address issues and
challenges raised by teams that focus on adoption, culture, effect to customer
value, work flow, and quality of the product being built.
Coaching can take many forms. There are executives, managers, and individu-
als who may be Agile Champions in their own right who have organizational
change experience and can help move the organization toward an Agile cul-
ture. They may become Agile Coaches and some may remain Agile Champions.
Both can provide coaching in their own ways.
Regress
Best Agile
Less
Agile Coach
Figure 22-2. An Agile Coach can help you avoid regressing to old practices and taking
wrong turns, and instead help you down the best path for your team or organization
Coaching helps a team adopt an agile process and lays the groundwork for
transforming the culture. When discussing the path to adoption, coaches help
ensure that elements and the Agile culture surrounding the elements stick.
216 Chapter 22 | Implementing, Coaching, and Honing Activities
Honing Agile
One of the Agile principles states that “at regular intervals, the team reflects
on how to become more effective, then tunes and adjusts its behavior accord-
ingly.” Having the opportunity to reflect ensures that the team can continu-
ously hone its agile practice and mindset over time. The event that first comes
to mind is the Sprint Retrospective. That is just one opportunity to reflect
and adjust at the team level. There also needs to be honing at the product and
organizational levels.
Keep in mind that honing can occur the moment any agile element is imple-
mented. Improving the agile mechanics tend to be the early focus of reflecting
and honing. However, over time, there should be a strong focus on whether
the team is aligning with the Agile values and principles and achieving the
transformation an organization or team is looking for.
■ Agile Pit Stop When honing, consider honing the “3 P”s: people, process, and product.
forward. The results of an assessment can provide data points into what areas
are thriving and what areas can be honed for improvement.
The Agile Mindset,Values, and Principles (MVP) Advisor is used to answer the
question, “How do you know you are Agile?” (see Chapter 13). This assess-
ment may occur at the team or organization level. The results of this survey
provide visibility into the behavioral transformation toward the Agile values
and principles. This assessment should be first conducted prior to imple-
mentation to gauge a team’s current alignment to Agile values and principles.
This forms the baseline by which subsequent assessments can be compared.
Progress can be tracked by comparing the previous assessment and the cur-
rent one. The results can be reflected on, and improvement opportunities
can be identified based on the results. This honing activity may occur every
three to six months depending on how regularly you would like to track your
behavioral alignment to Agile.
■■Agile Pit Stop The Agile MVP Advisor focuses on the transformation toward the Agile values
and principles, whereas the Agile Practices Adoption survey focuses on a team’s mechanical
adoption level of an agile process.
The Agile Practices Adoption survey is used to answer the question, “How do
you know you have adopted the agile processes and practices?” (see Chapter 13).
The results of this team-level survey provide visibility into a team’s mechani-
cal adoption level of the agile process and practices that are being applied.
This assessment mechanism should be first conducted after a team has had
training and has been implementing their agile framework for three or four
Sprints or a similar time period. This honing activity may occur every three
to six months or pre-release, depending on how regularly you want to track
adoption levels.
Improving Velocity
As a team tracks its velocity, members should look for opportunities to
improve their pace. Velocity is a measure that can help you understand a
team’s sustainable pace by tracking the amount of story points of customer
value a team can deliver in a Sprint. As new teams get started with Agile, their
velocity trend line is initially inconsistent, but it will eventually become stable
and reliable. When a team sees its velocity trend line plateau, it may be time
to look for improvement opportunities.
Improving velocity is often a long-term exercise. It can start with identifying
and removing impediments and dependencies that slow the team down.
Although this action may initiate in a Retrospective, it may require further
220 Chapter 22 | Implementing, Coaching, and Honing Activities
analysis of challenges that may take several Sprints to fully implement. Some
techniques for increasing team velocity follow:
• Look for software reuse opportunities. Software reuse is
a process whereby product teams may use software
components that represent standard functionality and
incorporate them into their product. Software reuse can
significantly decrease effort spent on building the same
functionality. It entails an amount of integration work to
understand the code, assess its quality, and integrate it
with the product’s current code base.
• Increase test automation. Test automation is a process
that takes manual testing routines and applies coding that
executes those tests based on a trigger. Automation can
result in a significant decrease in effort spent in executing
manual tests. There is effort in getting to a level of auto-
mation before it reduces team effort.
• Apply open-source solutions. Open source provides you the
ability to use peer-reviewed, high-quality code instead of
building it internally. If there is a well-architected code
structure, the ability to insert open-source code can
accelerate pace and lower costs. There needs to be an
investment to understand the open-source code that is
available, assess its quality, and integrate it with the prod-
uct’s current code base.
• Applying a colocation strategy. Colocation is a working
environment where a team is in one location. This can
be challenging for companies that have distributed staff.
Colocation promotes face-to-face communication, which
is one of the Agile principles. This activity involves deter-
mining if a more colocated team is possible. This may
become possible if you are working with several sites
where each has seven or more team members. If initially
QA was in one location, then QA responsibilities can be
distributed. This requires changes for a team, but there
can be a benefit to velocity when colocation and face-to-
face communication occur.
solution. As discussed in Chapter 17, the Sprint Review is the gold standard
for customer validation events at which the customer gets an opportunity to
view the working software.
Other validation activities can also help hone the product toward building
customer value. Aside from the Sprint Review, you can gain customer feed-
back in the review of the product vision and in an alpha-type environment
where the customer can exercise the software in a hands-on manner. When
a customer attends a validation session of working software, what they are
really doing is reflecting on the software and determining if it meets their
needs. This information allows a team to hone the software to better align
with building customer value.
23
Adapting
Governance and
Performance
Reviews
The measure of intelligence is the ability to change.
—Albert Einstein
Within an organization, there are many processes beyond the team that can
get in the way of a successful transformation to Agile. To achieve an Agile
culture, it is recommended that you evaluate these processes to understand
their alignment to the Agile values and principles and adapt as appropriate.
Two of these processes that I have found can negatively affect an Agile culture
are IT governance and performance review processes.
224 Chapter 23 | Adapting Governance and Performance Reviews
—Mark Goyer
Many companies have a form of IT governance that helps them manage the IT
aspects of projects toward a successful outcome. IT governance is applied in
a variety of ways, many of which include a focus on architecture, development,
resource management, and risk management as they relate to the projects
within the organizational scope.
The challenge when moving to Agile is that many folks see Agile as a change
to only the development organization without seeing that Agile requires a
cultural shift throughout the company in order for an Agile transformation
to occur. If your governance process still assumes big upfront planning, this
will need to be adapted if you hope to gain the business benefits of Agile.
Unfortunately, some governance boards are rightly seen as bureaucratic and
rigid. These attributes are not aligned with Agile value and principles. When
encountering these types of boards, there is a bit of work to do.
The first action with any board is to ask your sponsor, preferably an executive, to
share the business benefits of moving to Agile. This readiness activity begins condi-
tioning minds toward Agile. Then it is incumbent to provide awareness of the Agile
values and principles along with the objectives and motivations for moving to Agile.
This begins the journey to align your IT governance toward an Agile mindset.
The natural adaptation is to make the iron triangle flexible, so that if one of
the dimensions changes, the other dimensions change with it.
Another challenge with the iron triangle is that “quality” traditionally gets sub-
sumed within the triangle and is subservient to scope, schedule, and cost. This
is very problematic, inasmuch as quality practices and effort are often the first
to get trimmed when a project is in trouble. To represent properly the pro-
portionate importance of quality within a flexible framework, I recommend
taking the three existing corners of scope, schedule, and cost and adding the
fourth corner of quality (Figure 23-1).
Schedule Scope
Schedule
I call this the flexible trapezium. (A trapezium is a quadrilateral that has no parallel
sides.) The intent is that at any one time on an agile project—and realistically
on any project—the relative position of a corner and thus the length of the
sides may vary depending on the importance of the dimension at that time
(as illustrated by the small arrows in Figure 23-1). Although it is still important
to provide a balance of these dimensions so that one is not inappropriately
dominant over the others, there is flexibility that allows you to address the
customer needs. In too many projects, the schedule becomes the inappropri-
ately dominant dimension to the detriment of quality and scope.
stories. There are many ways this can be achieved. The following elements
indicate if quality really matters:
• Establishing a mindset that quality is owned by the whole
team.
• Constructing done criteria to indicate all engineering
elements needed to build quality functionality.
• Establishing acceptance criteria for each user story to
answer the question, “How will I know I’m done with the
story and meeting customer expectations?”
• Applying testing within an iterative framework so that
testing is continuous.
• Embedding testing within the team in order to break
down the barriers between development and test.
• Encouraging the notion of test-first and the application of
test-driven development.
• Placing a strong focus on unit and regression testing.
• Applying the notion of continuous customer validation of
working software with practices such as Sprint Reviews.
• Implementing code reviews or pair programming.
• Incorporating refactoring into the process of updating
existing code.
Applying the model of the flexible trapezium emphasizes that quality is an
equal member of the dimensions. The question is: What types of changes do
you need to make to your IT governance to support quality?
■ Agile Pit Stop The reason scope is so important is that it asks you whether you think you
are building the right product for the customer.
Collaborative Governance
Collaborative governance unites the brainpower of a governance board and
an Agile Team in a collaborative manner. Governance discussions regarding
the progress of the project should be a balanced and transparent dialogue
between the governance board and the Agile Team. Information, progress,
accomplishments, risks, and issues should be candidly and mutually shared
toward the common goal of a successful product release. Depending on how
rigid or ad hoc your governance is, you may need to adapt it to gain the ben-
efits of Agile.
IT governance boards are often made up of managers who may have thrived
on a hierarchical and directive leadership style. Agile requires all levels to
share leadership and assume the responsibility that goes with it. Collaborative
governance is defined by having the right people making the decisions—not
just on the basis of their job titles but because they have the best insights into
the change, opportunity, or problem under consideration.
Looking across the governance spectrum in Figure 23-2, on one side is rigid
governance where command and control rules and decisions are made at the
top. The other side shows no control, where decisions are ad hoc or erratic.
Collaborative governance is somewhere in the middle and requires everyone
to act like an adult, be responsible and accountable for his or her actions, will-
ing to listen and cooperate, and come to a collaborative decision.
228 Chapter 23 | Adapting Governance and Performance Reviews
■■Agile Pit Stop It is strongly recommended that the IT governance board attend the Sprint
Reviews for the products in their purview.
■■Agile Pit Stop If performance reviews are so critical, why does the average employee have
to adhere to performance reviews and the executive level doesn’t? How can some executives get
large bonuses as their company fails? This inequity is another factor that damages the value of
performance reviews.
24
Three Case
Studies in
Adopting Agile
Strive not to be a success, but rather to be of value.
—Albert Einstein
Once upon a time, there was this desire to become Agile. This is how your
story begins. But giving an account of the achievement of an agile transfor-
mation is more complex and challenging than many realize. It is a story that
requires a change in culture—one of the hardest things to do. It is a tale beset
by many obstacles, including people who either do not try to understand the
value Agile brings or who try to impede the effort.
Fear not! The roadmap in this book can proactively guide you and lay the
groundwork for delivering value, which is what you are in business to do. The
roadmap is for an adaptive path based on your decisions and commitment. So
what does your story look like?
In this concluding chapter, I offer three case studies—stories of a smaller colo-
cated project, a medium distributed project, and a large distributed team—to
help you understand how the readiness activities, deployment approach, and
commitment to Agile lead to different results. What will your Agile case study
look like?
234 Chapter 24 | Three Case Studies in Adopting Agile
■■Agile Pit Stop If the first release is successful, a continuous delivery approach can be
applied with the goal of deploying functionality incrementally every two Sprints.
The Agile Coach provided a two-day training with a focus on Scrum and use
of the physical Sprint Backlog wall for the whole team. Then the coach sat
with the Scrum Master and PO separately for an additional two hours to
focus specifically on their roles and responsibilities.
Because of the team enthusiasm from the training, management felt that they
were ready to apply Scrum. Management continued with the Agile Coach for
about three months, and he did the best he could in such a short time—long
enough to get Scrum off the ground on the team.
The team began implementing Scrum with three-week Sprints with the help
of the Agile Coach. The first three Sprints were fairly successful. Upon reach-
ing the fourth Sprint, the coach’s contract expired. Management thought that
the teams were engaged in Scrum, so the coach was released.
In Sprint 4, the Scrum Master attempted to keep the team focused on Agile
values and principles as well as the Scrum practices. There were several
strong personalities on the development team, two of whom were secret
Agile Deniers. They were worried that they would not be able to continue to
be the senior team leaders and would not be rewarded for problem solving.
During the Sprint Retrospective concluding Sprint 4, the two Deniers teamed
up to do away with the Daily Scrum, saying that maybe twice a week was
good enough. These two did not like the discipline of having to share their
progress. They managed to influence the rest of the team to concur, so the
Daily Scrums turned twice-a-week Scrums. They also managed to influence
the team into using individual velocity instead of team velocity so that they
could show how individually effective they were. The Scrum Master tried to
prevent this, citing the Agile principle of the team approach, but the team, led
by the two Deniers, overruled the Scrum Master.
Several Sprints latter, the Daily Scrum was occurring once a week and the
Retrospective actions were not being completed. The real challenge was that
the team didn’t like decomposing large requirements into user stories that fit
into a Sprint. This was difficult to do. Also, the QA team members weren’t
receiving completed stories until the very end of the Sprint. This became
problematic when a majority of the stories were not getting completed within
a Sprint.
Although the Scrum Master tried to mitigate many of these problems, he
was not experienced enough with Agile to help the team improve. There
was little to no understanding of the Agile values and principles on the team
and no experience to reference. Yet management put much of the blame
236 Chapter 24 | Three Case Studies in Adopting Agile
of the team problems on the shoulders of the Scrum Master, even though
he was escalating the impediments to management for help. Unfortunately,
development had more influence with management than the Scrum Master
had, and management wasn’t experienced enough to support the Scrum
Master or Agile.
■■Agile Pit Stop If management does not align with the Agile mindset, it can be very difficult
for the Scrum Master to keep the team focused on applying Scrum effectively.
One of the senior management became the sponsor for the Agile initiative.
He was excited about Agile and felt that he had a bit of Agile knowledge due
to the Agile books he had read. When he brought the Agile Coach on-board,
he shared a lot of his Agile ideas with the coach. In the spirit of learning more,
the coach recommended that the sponsor take an Agile overview session.
The sponsor felt that he knew enough about Agile already but that other
management should take the overview session.
The overall project team size was 32 people with folks in New York City and
London. The coach advised them to form four Scrum teams of approximately
8 team members each, which was promptly done. Because there were 15
employees in the London, it was decided that 2 teams would be US-based and
2 would be European-based. Each team’s competencies evinced a healthy bal-
ance of development, user experience, and QA.
The coach emphasized the importance of the Agile values and principles and
shared them with the management team. The coach also suggested hiring
experienced Scrum Masters. The sponsor felt that it was best to draw from
the existing talent to play the Scrum Masters. The Agile Coach recommended
that each of the identified Scrum Masters take CSM education. The sponsor
agreed to fund this training.
The existing Product Manager was knowledgeable about the intended product
and made a good PO candidate. Several of the functional managers became
aware that their role would reduce in scope and responsibilities because
the team members would get their work from the backlog. In consequence,
three functional managers insisted that they become POs. Although the Agile
Coach felt there were risks in taking this approach, it was agreed that between
the 1 existing product manager and 3 functional managers that each of the 4
Scrum Teams would have a PO. The coach recommended that each PO take
a formal CSPO education. The POs felt that a short training from the Agile
Coach was enough.
The Agile Coach introduced the team to the readiness activities, and manage-
ment cherry-picked several of them to focus on, including:
• Understand the current state of engineering and Agile
• Determine team willingness and capability
• Identify and establish Agile roles and responsibilities
• Determine education needs
• Establish agile framework and practices
• Identify agile tools and infrastructure needs
The coach felt that certain areas should be addressed: establishing a common
understanding of Agile; focusing on Agile values and principles; understanding
Being Agile 239
■■Agile Pit Stop Story points are the recommended measure for sizing user stories. Story points
are a scope measure that includes effort, complexity, and uncertainty.
The coach, realizing that comparing velocities was also problematic, discussed
the various problems with the Agile sponsor. Unfortunately, the sponsor didn’t
want to make waves because he was friendly with the former functional man-
agers. He said he would talk to the POs, but after another Sprint it was clear
that this wasn’t a priority with the sponsor.
By Sprint 8, the Agile Coach’s contract ended and he was released on account
of budgetary constraints. The sponsor stepped in to provide Agile coaching
and mentoring to the teams. Some of his advice seemed to conflict with the
Agile Coach’s past advice.
The project released within 2 weeks of the schedule. During the last 2 months,
the teams were placed into a death march to complete the project on time.
A few developers and the POs were praised and rewarded for tirelessly mak-
ing the project a success. Once the product was released, however, there were
many customer concerns regarding the alignment of the functionality to their
needs. Few existing customers wanted to upgrade to the new version. This
next-generation product was not providing value to the customers and did
not do well in the market.
The Scrum Masters asked the sponsor to bring in the Agile Coach to conduct
a lessons-learned. The sponsor said that there wasn’t budget for it, but they
were welcome to conduct a lessons-learned on their own. When debriefed,
the team and management learned the following:
• The team liked receiving training, and the Scrum Masters
were grateful for receiving the CSM training.
• The project started well, focusing on readiness activities
and Sprint 0.
• The first two Sprints were very promising.
• By the third Sprint, the team realized that the former
functional managers who were the POs were behaving in
a very command-and-control manner.
• The POs, specifically those who were former functional
managers, overruled many of the decisions the team
made. The result was that the team lost any sense of self-
organization and felt demoralized.
• Although Sprint Reviews were occurring, no actual cus-
tomers were attending. The reviews were for internal
stakeholders.
Being Agile 241
The Agile Coach introduced the team to the readiness activities, and man-
agement agreed to build an Agile Deployment Team to work through these
activities. The readiness activities that were focused on included:
• Establish a common understanding of Agile.
• Provide Agile mindset education on the Agile values and
principles and drivers for why we are changing.
• Add “customers and employees really matter” to the com-
pany vision and “customer engagement” and “employee
engagement” to employee objectives.
• Understand levels of executive and stakeholder buy-in.
• Establish an overall strategy and backlog for the Agile
transformation (including mitigation of risks).
• Understand the current state of engineering and Agile.
• Determine team willingness and capability.
• Determine suitability of product.
• Evaluate and adapt to collaborative IT governance.
• Identify and establish Agile roles and responsibilities.
• Determine education needs.
• Establish agile framework and practices.
• Establish done criteria, user story framework, and sizing
techniques.
• Craft measures of success and general metrics.
• Identify agile tools and infrastructure needs.
The Agile Coach, with the help of the sponsor, identified local Agile Champions
who either had experience with Agile or were enthusiastic about it and who
were willing to form the basis of the small Agile deployment team. The coach
educated the deployment team on the Agile values and principles and the
importance of readiness activities to help condition the product team toward
an Agile mindset.
■■Agile Pit Stop If two or more large product teams are moving to Agile at the same time, it is
highly recommended to use more than one coach.
The Agile deployment team discussed their strategy for deploying Agile and
created a backlog of tasks based on the readiness activities. They asked the
Being Agile 243
sponsor to a send out a message sharing the reasons for moving to Agile. The
sponsor agreed to share the drivers for organizational change and introduced
a common understanding of Agile based on the Agile values and principles.
From then on, the sponsor periodically shared the progress and the impor-
tance of shifting to the Agile mindset.
To support Agile further, the sponsor recommended that management have
performance objectives that focus on employees, customers, and Agile values
and principles. He also recommended that employees have team-based objec-
tives with a focus on the Agile values and principles. This set the tone to sup-
port self-organizing teams and teamwork.
The Agile Coach introduced himself to the overall team in an email and said
he would set up several meetings with the team members from each location:
Boston, Prague, and Bangalore. In the spirit of transparency, he asked the team
in each location about their level of willingness in moving to Agile and fol-
lowed this up with a survey. He listened carefully to the team members during
the meetings to understand their concerns. The survey included questions to
gauge the current level of Agile experience within the teams. Both the level
of willingness and experience levels were used as input on how to adapt the
Agile deployment effort.
The overall team size was 79 people, with most of the team in three locations.
The coach recommended that nine Scrum Teams be formed of approximately
9 team members each. Because there were 35 employees in Boston, 16 in
Prague and 28 in Bangalore, it was decided that 4 teams would be set up
Boston, 2 in Prague and 3 in Bangalore. Initially, there were a high percentage
of QA in Bangalore, so there had to be a rebalancing of development and QA
across the teams. This was handled with management approval. It was also
recommended that each Scrum Team own an end-to-end piece of functional-
ity. This was handled by identifying the functional areas within the architecture
vision and parsing them to the teams.
The coach also suggested hiring at least one experienced Scrum Master at
each location. The others could come from the existing organization. The
Agile Coach recommended that each of the inexperienced Scrum Masters
take CSM education. Management agreed.
It was important to find POs for each team who were knowledgeable in the
IAM space. There were 3 existing Product Managers who made good PO
candidates: 2 in Boston and 1 in Prague. The most senior Product Manager
became the uber-PO who supported 1 Scrum Team and more importantly
provided overall product guidance to the other POs. Two of the other exist-
ing POs agreed to support 2 Scrum Teams each. This meant that the 2 Prague-
based Scrum Teams were set and 3 Boston-based teams were set.
This still left the 1 Scrum Team in Boston and 3 teams in Bangalore. A func-
tional manager who was known to have servant leadership attributes from
244 Chapter 24 | Three Case Studies in Adopting Agile
■■Agile Pit Stop If the new release of this on-premise IAM product goes well, the team will
focus on building a cloud version offering a SaaS solution.
The Scrum Teams individually focused on establishing done criteria. Each team
established their relative sizing framework using story points. Several of the
teams began working on research spikes during Sprint 0 to reduce technology
uncertainty. During Sprint 0, the Scrum Team members received an intensive
Agile training on the Agile framework that was being used—a combination of
Scrum and XP engineering practices. A project SoS was initiated in which the
Scrum Masters got together to discuss project dependencies and progress.
Sprint 0 ended with a cross–Scrum Team Agile Release Planning session. This
session was initiated with a joint video conference session together where
each team was introduced and the uber-PO shared the product vision with
the teams and then gave everyone a chance for Q&A. The teams had to adapt
their working hours to accommodate this session. The QA vision, technical
vision, and CM visions were also shared during this session. The continuation
of Agile Release Planning involved an all-day team backlog grooming session,
which occurred independently within the respective team’s time zone. Then
Being Agile 245
another joint effort occurred in which each team shared their findings. Upon
conclusion, Sprint 1 commenced.
They began implementing Scrum with 3-week sprints. The Agile Coach
brought in a fellow coach, and they shared the load of helping teams come up
to speed with Scrum. The first four Sprints went by with some success, and
there was a lot of focus on the mechanics. Several of the teams were exhibit-
ing self-organizing attributes and some teams were still getting the hang of it.
Each team was honing their relative story point sizing framework and tracking
their velocity. The coaches actively discouraged velocity comparisons, and
these didn’t occur.
In Bangalore, the PO who had been a functional manager had to be further
coached to reduce command-and-control attributes. The main Agile Coach
flew to Bangalore to work with this PO and support the Scrum Masters and
local Scrum Teams. The coach attended many of the teams’ events to gauge
the adoption-level mechanics. He held periodic check-point calls with all of
the Scrum Masters to help them with their challenges.
It was initially challenging to hold joint Sprint Review sessions because there
was often much more work that was completed than could be shared. The
Agile Coach recommended prioritizing the work based on where feedback
was most needed and ensuring each team got a chance to demo at least two
or three stories. The first two Sprint Reviews were held with just internal
stakeholders to exercise this adaptation. This allowed teams time to get used
to demonstrating to people and to figure out the mechanics of the review.
By Sprint 3, the POs began inviting a few existing customers to gain their
feedback. By the fifth Sprint, the Sprint Review began running effectively. A
challenge that was resolved over the next two Sprints was taking the Sprint
Review feedback and incorporating it into the Sprint Planning for adaptation
of built functionality.
After the first several Sprint Retrospectives, the teams began realizing the
importance of carrying out the actions for improvement. Though some teams
were more effective at it than others, they began working these actions and
seeing the benefit. There were two people in two separate Boston-based
Scrum Teams who didn’t like the notion of the daily Scrum and tried to get this
changed within their retrospective, saying it was affecting their work. They tried
to change it to weekly, but the rest of the team members believed it was impor-
tant to share the daily progress and highlight roadblocks. Two Sprints later, one
of the team members who raised this concern said that he didn’t like having to
share his progress all the time and decided to quit. In talking with this team, the
Agile Coach said that, given Agile’s continuous nature, it may not be right for
everyone, and that’s okay. The team promptly replaced this team member with
an Agile-minded engineer and the coach helped her come up to speed.
246 Chapter 24 | Three Case Studies in Adopting Agile
By Sprint 7, the Agile Coach initiated two surveys: the agile practices adop-
tion survey and the Agile Mindset, Values, and Principles Advisor survey (see
Chapter 13). The results were shared during the next Sprint Retrospective
so each team could decide how to improve. Only with the teams’ agreement
a summary was shared with management, together with some recommenda-
tions as to where management could help.
By Sprint 10, the backlog was well fairly well groomed. Affinity sizing was used
to minutely size the remaining stories in the backlog. This allowed the POs
to create a minimum viable product (MVP) value line consisting of the stories
that were targeted for a viable Release 1 product. Having this empirical data
along with the MVP stories provided the basis for an objective discussion with
the organizational IT governance board. The IT governance board suggested
that scope would be the driver and they wanted to continue tracking the MVP
line and the release burnup to see when each team’s velocity met their MVP
lines. Understanding each team’s MVP and velocity provided a means to move
stories to other teams to balance the work.
■■Agile Pit Stop Do not think of your MVP line as fixed scope but as a gauge for what may
make a viable product. It is subject to change based on the continuous customer validation of the
Sprint Reviews and new requirements that come from customers.
As the Scrum Teams’ MVP lines were adjusted based on customer feedback,
each team’s velocity was tracked and it became evident that Sprint 18 would
be the last Sprint on the project. An additional Sprint was added for integra-
tion, performance, and load testing, as well as finishing the user guides, pre-
paring the release notes, and beginning the marketing campaign. When the
product was released, many customers immediately upgraded or purchased
this next-generation product.
Each Scrum Team conducted a final retrospective. The Agile Coach collated
the results. He also conducted another Agile Mindset, Values, and Principles
Advisor survey to compare it to the baseline from the previous survey results.
Upon a roll-up of the retrospective and survey results, a debrief occurred with
the team and management that included the following items:
• It was great having management support and a sponsor
for the move to Agile who really understand the Agile
values and principles.
• Everyone appreciated receiving training. The Scrum
Masters were grateful for receiving CSM training and the
POs for receiving CSPO training.
Being Agile 247
Index
A principles, 48
software development (Manifesto), 46
Acceptance criteria, 197
values and principles, 58
Actual burndown, 192
Agile methodology
Actual velocity, 192 DSDM, 54
Agile chasm, 7 extreme pogramming (XP)
culture change acronym, 52
colazione, 9 customer and developer, 52
culture, 10 planning, designing, coding,
Italian culture, 9 and testing, 53
journey, 8 Kanban, 55
organizational change, 9 scrum, 50
procedural change, 8 VFO, 49
history, 7 VFQ, 57
technology adoption lifecycle Agile mindset
Agile cultural chasm, 11–13 benefits, 92
innovators, 11 human adaptation, 79
life cycle model, 10 innovation, 79
Agile, engineering and team capability. values and principles
See also Team capability business and development team, 84
Agile practices adoption, 132 change to requirements, 83
observe direction, 133 cognitive patterns, 80
sprint planning adoption survey, 132 face-to-face communication, 86
baseline and improve, 138 frequent/continuous delivery, 83
engineering practices, 135 reflection for improvement, 91
important, 131 self-organizing teams, 90
MVP, 134 simplicity, 89
starting point, 132 sustainable pace, 87
Agile foundation(s), 45. See also Agile technical excellence, 88
methodology trust motivated individuals, 85
foundational building blocks, 46 valuable software, 81
Manifesto, 47 working software, 86
250 Index
F L
Fibonacci sequence, 189 Lagging-to-leading metric path, 141
Functional manager as scrum master, 117 Large and complex projects
Index 253
Mario E. Moreira
Being Agile: Your Roadmap to Successful Adoption of Agile
Copyright © 2013 by Mario E. Moreira
This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part
of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations,
recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission
or information storage and retrieval, electronic adaptation, computer software, or by similar or
dissimilar methodology now known or hereafter developed. Exempted from this legal reservation are
brief excerpts in connection with reviews or scholarly analysis or material supplied specifically for the
purpose of being entered and executed on a computer system, for exclusive use by the purchaser of
the work. Duplication of this publication or parts thereof is permitted only under the provisions of the
Copyright Law of the Publisher’s location, in its current version, and permission for use must always
be obtained from Springer. Permissions for use may be obtained through RightsLink at the Copyright
Clearance Center. Violations are liable to prosecution under the respective Copyright Law.
ISBN-13 (pbk): 978-1-4302-5839-1
ISBN-13 (electronic): 978-1-4302-5840-7
Trademarked names, logos, and images may appear in this book. Rather than use a trademark
symbol with every occurrence of a trademarked name, logo, or image we use the names, logos, and
images only in an editorial fashion and to the benefit of the trademark owner, with no intention of
infringement of the trademark.
The use in this publication of trade names, trademarks, service marks, and similar terms, even if they
are not identified as such, is not to be taken as an expression of opinion as to whether or not they
are subject to proprietary rights.
While the advice and information in this book are believed to be true and accurate at the date of
publication, neither the authors nor the editors nor the publisher can accept any legal responsibility
for any errors or omissions that may be made. The publisher makes no warranty, express or implied,
with respect to the material contained herein.
President and Publisher: Paul Manning
Acquisitions Editor:Robert Hutchinson
Editorial Board: Steve Anglin, Mark Beckner, Ewan Buckingham, Gary Cornell, Louise Corrigan,
Jonathan Gennick, Jonathan Hassell, Robert Hutchinson, Michelle Lowman,
James Markham, Matthew Moodie, Jeff Olson, Jeffrey Pepper, Douglas Pundick,
Ben Renow-Clarke, Dominic Shakeshaft, Gwenan Spearing, Matt Wade, Tom Welsh
Coordinating Editor: Rita Fernando
Copy Editor: Laura Poole
Compositor: SPi Global
Indexer: SPi Global
Cover Designer: Anna Ishchenko
Distributed to the book trade worldwide by Springer Science+Business Media New York, 233
Spring Street, 6th Floor, New York, NY 10013. Phone 1-800-SPRINGER, fax (201) 348-4505, e-mail
[email protected], or visit www.springeronline.com. Apress Media, LLC is a California
LLC and the sole member (owner) is Springer Science + Business Media Finance Inc (SSBM Finance
Inc). SSBM Finance Inc is a Delaware corporation.
For information on translations, please e-mail [email protected], or visit www.apress.com.
Apress and friends of ED books may be purchased in bulk for academic, corporate, or promotional
use. eBook versions and licenses are also available for most titles. For more information, reference our
Special Bulk Sales–eBook Licensing web page at www.apress.com/bulk-sales.
Any source code or other supplementary materials referenced by the author in this text is available
to readers at www.apress.com. For detailed information about how to locate your book’s source
code, go to www.apress.com/source-code/.
Apress Business: The Unbiased Source of Business
Information
Apress business books provide essential information and practical advice,
each written for practitioners by recognized experts. Busy managers and
professionals in all areas of the business world—and at all levels of technical
sophistication—look to our books for the actionable ideas and tools they
need to solve problems, update and enhance their professional skills, make
their work lives easier, and capitalize on opportunity.
Whatever the topic on the business spectrum—entrepreneurship, finance,
sales, marketing, management, regulation, information technology, among
others—Apress has been praised for providing the objective information and
unbiased advice you need to excel in your daily work life. Our authors have no
axes to grind; they understand they have one job only—to deliver up-to-date,
accurate information simply, concisely, and with deep insight that addresses
the real needs of our readers.
It is increasingly hard to find information—whether in the news media, on the
Internet, and now all too often in books—that is even-handed and has your
best interests at heart. We therefore hope that you enjoy this book, which
has been carefully crafted to meet our standards of quality and unbiased
coverage.
We are always interested in your feedback or ideas for new titles. Perhaps
you’d even like to write a book yourself. Whatever the case, reach out to us
at [email protected] and an editor will respond swiftly. Incidentally, at
the back of this book, you will find a list of useful related titles. Please visit
us at www.apress.com to sign up for newsletters and discounts on future
purchases.
Available at www.apress.com