Succeeding with Agile » Chapters

22. You’re Not Done Yet

Mike Cohn — Sat, 03 Oct 2009 20:58:49 +0000

We’ve come a long way together. My hope is that you have been implementing
many of the recommended practices and “things to try” throughout the book. If
so, you’ve hopefully made a lot of progress. You’ve established an Enterprise Tran-
sition Community (ETC) to introduce Scrum into your organization. The ETC,
in turn, has created an environment that encourages improvement communities
to form and flourish. Some of these improvement communities have disbanded
already, after accomplishing what they sought to improve; other improvement
communities have expanded their focus or are still hard at work at more persistent
improvement opportunities.

21. Seeing How Far You’ve Come

Mike Cohn — Sat, 03 Oct 2009 20:54:32 +0000

Soon after beginning your effort to adopt Scrum, someone will ask, “How are
we doing?” This is not a question with a simple answer like, “We’re doing great.”
Similarly and fortunately, you cannot distill your answer down to, “We’re Scrum
level three.” Adopting Scrum is a complex process, and answering how you’re
doing at it will require a complex answer. Fortunately, many early-adopter com-
panies have experimented with ways of doing this, and a handful of suitable ap-
proaches have been documented and are available.

Chapter Contents

The Purpose of Measuring
General-Purpose Agility Assessments

Shodan Adherence Survey
Agile: EF
Comparative Agility Assessment

Creating Your Own Assessment
A Balanced Scorecard for Scrum Teams

Constructing the Balanced Scorecard
Favor Simple Metrics

Should We Really Bother with This?
Additional Reading

Chapter 20. Human Resources, Facilities and the PMO

Mike Cohn — Mon, 31 Aug 2009 00:34:58 +0000

To achieve long-term success with Scrum, the implications of becoming agile
must be transferred into other parts of the organization. When this is not done,
organizational gravity—those influences that formed the organization into whatever
shape it existed in before the start of the transition—will kick in. I have seen
Scrum transitions stalled or completely stopped because they ignored the impact
of becoming agile on groups outside development.

Chapter Contents

Human Resources
- Reporting Structures
- Periodic Performance Reviews
- Removing Team Members
- Career Paths
- With People Involved, There Will Always Be People Issues
Facilities
- The Space
- The Furniture
- Items That Should Be Visible in Your Workspace
The Project Management Office
- People
- Projects
- Process
- Renaming the PMO
The Bottom Line
Additional Reading

Sample task boards:

Magnetic cards stick to the board.	A roll of corkboard, wrapping ribbon and push pins.	A cabinet. Open the doors to find food.
Sheet metal with magnets.	Simple but effective.	Low-tech always works.
Another cork and push pin board.	Using a corner because they couldn't get a whole wall.

Chapter 19. Coexisting with Other Approaches

Mike Cohn — Mon, 31 Aug 2009 00:33:02 +0000

It’s one thing to look at agile software development in a test tube; it’s another to
experience it in the real world. In the test tube, agile methodologies like Scrum
are easily adopted by all members, and the nasty realities of corporate politics, economics,
and such cannot intrude. In the real world, though, all of these unpleasant
issues do exist. It is rarely as simple as deciding to use Scrum and then being able
to do so with no other constraints. One project might be allowed to try Scrum
as long as it doesn’t interfere with the organization’s CMMI Level 3 certification.
Another project might be allowed to try it as long as they pass the preliminary
architecture review and then have a successful meeting at the design complete
checkpoint.

Chapter Contents

Mixing Scrum and Sequential Development

Three Scenarios of Interaction
Three Areas of Conflict
Can Scrum and Sequential Coexist Forever?

Governance

Running Scrum Projects with Non-Agile Governance

Compliance

ISO 9001
Capability Maturity Model Integration (CMMI)
Achieving Compliance

Onward

Additional Reading

Chapter 18. Distributed Teams

Mike Cohn — Mon, 31 Aug 2009 00:31:17 +0000

A few years ago, collocated teams were the norm and it was unusual for a team
to be geographically distributed. By now, the reverse must be true. Personally, I’m
now surprised when someone tells me that everyone on the team works in the
same building. With the prevalence of teams that are spread across the globe, or
at least across a couple of time zones, it is important to consider how well Scrum
works when a team is geographically distributed.

Chapter Contents

Decide How to Distribute Multiple Teams

Create Coherence

Acknowledge Significant Cultural Differences
Acknowledge the Small Cultural Differences
Strengthen Functional and Team Subcultures
Build Trust by Emphasizing Early Progress

Get Together in Person

Seeding Visits
Contact Visits
Traveling Ambassadors

Change How You Communicate

Adding Back Some Documentation
Adding Detail to the Product Backlog
Encourage Lateral Communication

Meetings

General Advice
Sprint Planning Meeting
Daily Scrum
Scrum of Scrums
Sprint Reviews and Retrospectives

Proceed with Caution

Additional Reading

Chapter 17. Scaling Scrum

Mike Cohn — Mon, 31 Aug 2009 00:29:29 +0000

My wife, Laura, cooks dinner nearly every night. Some nights she makes something
a bit fancier; other nights, if she’s more rushed, she cooks something simple.
But it’s always tasty, healthful, and prepared without a great deal of stress. Except
for Christmas dinner. Cooking Christmas dinner is stressful. The house is full of
guests—her parents, my parents, maybe an aunt and uncle, and a brother or sister
or two. And yet she seems to prepare more dishes than we have guests. Christmas
dinner is done at a scale unseen the rest of the year. And anything done at a larger
scale than we are accustomed to—including a software development project—is
more difficult.

Chapter Contents

Scaling the Product Owner

Sharing Responsibility, Dividing Functionality

Working With a Large Product Backlog

One Product, One Product Backlog
Keep the Product Backlog to a Reasonable Size

Proactively Manage Dependencies

Do Rolling Lookahead Planning
Hold a Release Kickoff Meeting
Share Team Members
Use an Integration Team

Coordinate Work Among Teams

The Scrum of Scrums Meeting
Synchronize Sprints

Scaling the Sprint Planning Meeting

Stagger by a Day
The Big Room

Cultivate Communities of Practice

Formal or Informal
Creating an Environment for Communities to Form and Flourish
Participation

Scrum Does Scale

Additional Reading

Chapter 16. Quality

Mike Cohn — Mon, 31 Aug 2009 00:27:08 +0000

Early into my career as a programmer, I left my large, stable employer for an
eight-person start-up. I went from a well-funded environment where we had a
separate testing and quality assurance organization to a company where I was only
the second programmer; there was not a tester in sight. Sometime during my first
week at my new job, it hit me: I would be responsible for my own quality. There
were no testers who would check my work or who would be a safety net for my
meager attempts at unit testing. And then the bigger realizations hit: Without a
tester, I would look like a fool to our customers (although none would know me
personally) and I would also look like a fool to my boss, which could cost me my
job

Chapter Contents

Integrate Testing Into the Process

Why Testing at the End Doesn’t Work
What Building Quality In Looks Like

Automate At Different Levels

The Remaining Role of User Interface Tests
The Role of Manual Testing
Automate within the Sprint
Sampling the Benefits

Do Acceptance-Test-Driven Development

The Right Level of Detail

Pay Off Technical Debt

Paying Down Testing Debt in Three Steps

Quality Is a Team Effort

Additional Reading

Chapter 15. Planning

Mike Cohn — Mon, 31 Aug 2009 00:25:02 +0000

“We’re agile, we don’t plan” and “We’ll be done when we’re done” were common
statements in the early years following the publication of the Agile Manifesto.
I suspect that many people on some of the early agile teams that took this stance
knew that they were giving up something valuable when they threw planning out
the window. But, theirs was a natural reaction to the prior cultures in which they’d
worked. Too many developers hated planning because the plan had never been of
any personal benefit to them. Instead, plans were often weapons used against the
developers: “You said you’d be done by June; it’s June. Make it happen.”

Chapter Contents

Progressively Refine Plans

Don’t Plan on Overtime to Salvage a Plan

Learning the Hard Way
Getting There
If Not Overtime, What?

Favor Scope Changes When Possible

Considering the Alternatives
Project Context Is Key

Separate Estimating from Committing

The Right Data to Do This
Going from Estimate to Commitment
Historical Velocity Forms the Basis for Committing

Summary

Additional Reading

Chapter 14. Sprints

Mike Cohn — Mon, 31 Aug 2009 00:22:29 +0000

Like all of the agile processes, Scrum is an iterative and incremental approach
to software development. Although the terms iterative and incremental each have a
unique meaning, they are often used together. Let’s briefly tease them apart so we
can better understand their meanings.

Chapter Contents

Deliver Working Software Each Sprint

Defining Potentially Shippable
Identifying Potentially Shippable Guidelines

Deliver Something Valuable Each Sprint

Prepare in this Sprint for the Next

Billiard Ball Sprints
Only Pull into a Sprint What Can Be Completed

Work Together Throughout the Sprint

Avoid Activity-Specific Sprints
Replace Finish-to-Start Relationships with Finish-to-Finish Ones
Overlapping User Experience Design
Think Holistically, Work Incrementally
Architecture and Database Design

Keep Timeboxes Regular and Strict

Never Extend a Sprint

Don’t Change the Goal

Break the Habit of Redirecting a Team

Get Feedback, Learn, and Adapt

Additional Reading

Chapter 13. The Product Backlog

Mike Cohn — Mon, 31 Aug 2009 00:20:07 +0000

The biggest question looming at the start of a project is, what exactly are we
building? We know the general shape of the system to be built. We may know, for
example, that we are building a word processor. But there are always dark corners
yet to be explored or issues yet to be settled about how specific features will work.
Will our word processor include an interactive table design feature, or will tables
be designed by entering values into a series of screens?

Chapter Contents

Shift from Documents to Discussions

Don’t Throw the Baby Out with the Documentation
Use User Stories for the Product Backlog

Progressively Refine Requirements

Emergent Requirements
The Product Backlog Iceberg
Why Progressively Refine Requirements?
Progressive Refinement of User Stories

Learn to Start Without a Specification

Specify by Example
Cross-Functional Teams Reduce Documentation Needs

Make the Product Backlog DEEP

Don’t Forget to Talk

Additional Reading