Richard Lawrence » Scrum

Growing DONE—How to Make the Definition of Done Work for Your Team

Richard Lawrence — Mon, 21 Dec 2009 23:34:37 +0000

Effective agile teams get things done. They build software day after day that’s not just “code complete” but really shippable. And when their product owner says, “ship it,” they can get their shippable software into production at the drop of a hat.

The Definition of Done can be a powerful tool to make these things happen…If it’s used right.

Most agile teams I see have one of four relationships with a Definition of Done:

They don’t have one
They have one but don’t really use it
They have one but can never satisfy it
They have one, satisfy it for each story, but still have lots to do at the end of a release

I rarely come across teams who use the Definition of Done to good effect day after day, sprint after sprint.

The reason why, I think, is that if a team uses a Definition of Done at all, they try to use a single one before they’re ready. I’ve discovered that most teams really need two definitions of done. For a new agile team, there’s more to do to get software ready for production than can be accomplished a story at a time. Teams that fall into #3 above probably put everything on the Definition of Done. Teams in #4 probably put just those things they could do a story at a time on the Definition of Done and left everything else for later.

The answer is two Definitions of Done. The Story Definition of Done captures what the team can do today to make each story as shippable as possible in each sprint. The Release Definition of Done captures the gap between the Story Definition of Done and what’s actually required to ship. Together these tools provide a way to visualize what done means and to make it happen as early as possible.

Here’s how to build effective Story and Release Definitions of Done…

Building The Two Definitions of Done

1. Brainstorm the List

List all the things required to move a set of features in your product to production. Engage release management, operations, help desk, and other stakeholders at this point—it’s easier to build what they need into the software than to bolt it on at the end. This list typically includes things like:

user documentation
operations documentation
monitoring and logging
performance testing
regression tested in a clean QA environment

Now, list anything required to deliver software at a consistently fast pace from iteration to iteration. For example:

automated unit tests covering 80% of code
automated story tests covering 90% of acceptance criteria
adherence to coding standards
code reviewed by another developer
all production code developed by a pair

Finally, list non-functional requirements such as:

all pages load in under a second
all pages can support 300 simultaneous user sessions

Merge these lists into one, changing the language where necessary so that each bullet reads as a continuation of the sentence beginning: “In order for a set of features to be released to production…”

2. Challenge the List

For each item on the list, ask “why?” Keep asking “why?” until it’s clear that the item is the simplest, cheapest, most repeatable way to achieve some desired goal in the release. If it’s not, change it.

This is where you challenge the existing rules around releases. Maybe your release readiness guidelines today require a complete installation guide. Could you replace that with an automated installation script?

3. Build Release Readiness In

Now you have a list of the minimal set of things a group of features must have to be released—your Release Definition of Done. Bolting those things onto an otherwise complete set of features could impose a fixed cost of weeks to the end of any release. One of our goals in agile is to allow the product owner to be able to say at any point, “This is enough, I want to start making money off of this software now—ship it.” An expensive release gets in the way.

Look at each item on the list and ask, “Could we satisfy this as we build each story instead of all at once at the end of a release?” Yes? Then move it to your Story Definition of Done. No? Could you do part of it or do something that would reduce the time at the end? Yes? Then put that on your Story Definition of Done. No? Then leave it on the Release Definition of Done.

Very few items can’t be satisfied a story at a time. The most common ones I see are performance testing in a production-like environment shared with other products and beta testing with a set of real users. But you can get a head start on even these. Maybe your test environment isn’t exactly like production, but can you make the performance constraints similar enough to at least profile for likely performance issues? Maybe you can’t beta test on a large scale, but could you get a small set of users to volunteer to use stories as they’re built and provide early feedback to make the beta test shorter and more predictable? Think hard about anything you’re tempted to leave on the Release Definition of Done.

4. Use Your Definitions of Done

You now have two definitions of done, one for every story you build and one for a collection of stories you want to release. The Story Definition of Done will inform your acceptance criteria for every story. If page load time matters, a story isn’t done until all the related pages load fast enough. Test for this. Automate these tests and run them on every build if you can.

You won’t satisfy the items on your Release Definition of Done until the end of a release. But this doesn’t mean you can forget about them until then. Keep the Release Definition of Done visible, and look for ways to test early for release readiness.

5. Grow Your Story Definition of Done

The Definitions of Done are a starting place, a statement of what your team can accomplish today. Over time, your Release Definition of Done should get smaller and your Story Definition of Done should grow. If you have 3 weeks of manual regression testing at the end of each release, come up with a plan to grow automated regression tests as you build new stories. Maybe you can reduce those 3 weeks of testing to one. If you have a tech writer spend a month writing documentation at the end of a release today, find ways to integrate her into the team to grow the documentation as you grow the software. Maybe you can reduce that month of writing to 3 days of editing and polishing.

The Bottom Line

Use two definitions of done. In every retrospective, look for ways to grow your Story Definition of Done so you can consistently build and release software quickly. If you get to a point where you can throw away the Release Definition of Done, congratulations! But don’t start there.

How to Give a Great Sprint Demo

Richard Lawrence — Sat, 25 Apr 2009 02:03:10 +0000

Exciting. Entertaining. Do these words describe your sprint demo meetings? Or are boring and unfocused more accurate?

I can’t believe how many times I’ve come in to coach a team and they’ve been surprised when I actually expected to see a software demo in the sprint demo meeting. As the agile principle says, “Working software is the primary measure of progress.” Let’s see some software!

Why are so many agile teams so hesitant to do demos? Why are demos so lifeless? Sometimes, the team’s not actually done. That makes a demo awkward. Other times, they can’t communicate what they did to the Product Owner; they don’t speak “business.” But most often, they simply don’t know how to give a good demo.

So, how do you give a good demo?

Here are a few tips:

Focus on acceptance criteria. You’ve defined what done means for the story (right?), so focus your demo around proving that you’re actually done.
Start with the demo in mind. Don’t wait to think about the demo until you’re done with the story. You might be able to write tests that double as demo scripts. And it’s best to plan your demo for a story while it’s fresh in your mind, before you move to the next story.
Prepare. Don’t ad lib. Think through an interesting scenario to prove that you’ve satisfied the core acceptance criteria. Create any necessary test data. Use tools like Watir if necessary to get your app into a state where you can start an interesting demo.
Practice. Run through the demo at least once. When you’re getting started, you might want to grab a trial version of Camtasia and record yourself giving the practice demo. Painful, huh? That just means you need to work on it.
Tell a story. Center your demo around a realistic user solving a real problem. The point is not just to show that the software works, but to show that it’s valuable.
Keep it short. If you work on your stories one at a time and get them accepted when they’re ready, you don’t need to exhaustively cover all your acceptance criteria in your demo. Instead, focus your demo on what’s interesting and what’s valuable about each feature.

The sprint demo should be the most exciting part of Scrum. It’s when the team gets to show everyone all the value they’re delivering. That’s worth investing a little time to do well. You may find that previously disinterested stakeholders start coming just for the show.

What has worked well for you in sprint demos? What hasn’t worked? Share in the comments.

Continuous Deployment

Richard Lawrence — Fri, 13 Feb 2009 15:05:23 +0000

I’ve written before about the amazing financial impact of releasing more often. And I know from personal experience the positive impact that frequent releases have on learning and on product quality and value. So, I enjoyed this post on one company’s experience with continuous releases. Yes, you read that right; they release, on average, 50 times per day.

We call this process continuous deployment because it seemed to us like a natural extension of the continuous integration we were already doing. Our eventual conclusion was that there was no reason to have code that had passed the integration step but was not yet deployed.

Read the whole thing and consider what it would take in your organization to get to continuous deployment. How fast could you go? And what impediments would have to be resolved to make it happen?

7 Tips for a More Effective Daily Scrum

Richard Lawrence — Sat, 07 Feb 2009 17:40:26 +0000

The main purpose of the Daily Scrum is for team members to make and follow-up on commitments to one another that work towards the team’s shared sprint commitment. If your Daily Scrum has become unfocused, too long, or otherwise ineffective, here are seven ways to get it back on track.

1. Do it around the task board. Have team members point at stories and tasks on the task board as they talk about their work. This keeps the focus on work for the sprint and makes it obvious when the talk becomes unrelated to the sprint.

2. Change the questions. In “One Word Can Change Your Daily Scrum” I described a way I like to change the three Daily Scrum questions to focus the team on getting things done.

3. Don’t show up. If your Daily Scrum has turned into a status report to the ScrumMaster, try taking a few days off. Let the team report to each other instead of you. Aaron Sanders has more here. Less dramatic ways to have the same effect are avoiding eye contact or stepping outside the circle. But sometimes dramatic is necessary to shake things up.

4. Don’t talk. If you’re not taking sprint tasks, you don’t need to answer the three questions. Emphasize that by not talking at all during the Daily Scrum. Use non-verbal communication when necessary, but keep your mouth shut.

5. Use a parking lot. There are legitimate things for a team to talk about in the morning that don’t fit the tightly-defined purpose of the Daily Scrum. Use a parking lot (i.e. a flip chart or section of a whiteboard) to capture those topics. Address them right after the Daily Scrum is over. You can even let team members add items to the parking lot outside of the meeting to be addressed in the next “parking lot time.” That way, they’re not trying to remember their parking lot topic when they should be paying attention to the Daily Scrum.

6. Actually stand. It shouldn’t be necessary for us to stand to have a short, high-energy meeting, but it really seems to help. If your team has started sitting for the Daily Scrum and it’s running longer than 15 minutes, it might be time to try standing again. Set an example by standing for the whole meeting, and maybe ask one or two influential team members to do the same. Combining this with #1 makes it feel less awkward.

7. Pass a token. Jason Yip describes how introducing randomness and play into the Daily Scrum by tossing a ball to the next person to speak can add energy to the meeting.

What else have you done to keep your Daily Scrum effective? Share in the comments.

Agile Product Management Boot Camp

Richard Lawrence — Thu, 22 Jan 2009 03:52:29 +0000

Bob Hartman and I are offering an Agile Product Management Boot Camp course March 9-10 in Denver. If you’re a product manager, product owner, business analyst or in any other product facing role in an agile (or soon-to-be agile) environment, this intense, hands-on course is a great opportunity for you to ensure that you’re helping your team maximize the value it delivers.

Topics include…

Understanding Agile: Process and Driving Principles
Ensuring the Right Things Gets Built: Testing and Acceptance
Specifying What to Build: User Stories
Deciding What to Build First: Prioritization
Defining Customer Value: Minimum Marketable/Releasable Features
Project Acceptance: Building a Product Vision and Business Case
Product Management 101: Useful Tips, Tricks and Techniques
Pulling it All Together: Project Simulation

You will leave the course knowing how to:

Deal with the team outside of just planning meetings, demonstrations and retrospectives.
Break down requirements into usable stories – even when the team is unable to help.
Deliver value in stages rather than all at once.
Write acceptance criteria to ensure the right features are being developed.
Create a project business case and vision.
Perform basic product management functions in an agile way.
Effectively interact with customers, community, stakeholders, managers, and the team.
Make a convincing business case for using agile for more projects.
Continuously improve.

The course registration fee is $1,200, but readers of this blog can take advantage of a special 2-for-1 offer. Simply register with discount code RLB2FOR1, and we’ll send you another code you can give to a colleague to register for free. Seats are limited, so get your registration in today.

Short Answers #2: What to Focus on in 2009

Richard Lawrence — Sat, 03 Jan 2009 23:48:33 +0000

It’s officially a series now. In this Short Answers video, I answer the question, “If my Scrum team could work on one thing in 2009, what should it be?”

Of course, adopting agile engineering practices and getting better at product management are often easier said than done. If you’d like help getting started with some of the practices I mentioned in the video, I’m running a New Year’s training and coaching special with 7 ways to get 2009 started right for less than $2,000.

Books I mentioned in the video:
The Goal by Eli Goldratt
It’s Not Luck by Eli Goldratt

New Benjamin Zander Video – “How Fascinating!”

Richard Lawrence — Fri, 12 Dec 2008 18:10:40 +0000

There’s a new Benjamin Zander video over at the Pop!Tech conference website. There’s some overlap with the video from TED I posted back in June—most of the content in each video expands on the ideas in The Art of Possibility. Nonetheless, this video is well worth watching even if you’ve seen the few other videos of him on the internet.

In this video, Zander works with a 15-year-old cellist—who, as far as the boy knows, has come simply to perform for the crowd—and over the course of 20 minutes turns a technically sound performance into music, music that touches everyone there.

One moment that connects with me as an agile coach is when he teaches the young cellist how to respond to mistakes in a performance.

The natural response is to grimace, lose energy, become discouraged. (I was terrible about this as a young performing musician.) This launches a downward spiral that affects the rest of your performance and influences your audience’s perception of it. Instead of respond in that way, Zander suggests that the boy throw up his hands, smile, and say, “How fascinating!” That mistake is information. It’s an opportunity to learn and improve. He says in the book, “…it is only when we make mistakes in performance that we can really begin to notice what needs attention.” (p. 31)

The awareness of mistakes is not sufficient to improve. Improvement comes from a willingness to take risks and then to accept the inevitable mistakes as useful feedback. I tell managers that software teams that aren’t allowed to struggle and even fail in their early sprints will still struggle and still may fail…you just won’t know it in time to do anything about it. Your retrospectives may show that your team is a mess, that you struggle just to deliver working software, that there are a million places you could do better. “How fascinating!”

Short Answers #1: When Stories Are Larger Than Planned

Richard Lawrence — Wed, 10 Dec 2008 23:20:57 +0000

I’m experimenting with video for what is likely become a new series here. In these “Short Answers” posts, I’ll answer an agile question in about a minute. Use the comments to suggest questions you’d like to see in future Short Answers.

In this post, I answer the question, “What should I do when I discover in the middle of a sprint that a story is larger than we planned?” Several people have asked me this, and the answer is not, “Suck it up and work 80 hours to get everything done.”

Are the Product Owner and ScrumMaster’s Interests Opposed?

Richard Lawrence — Wed, 26 Nov 2008 17:53:31 +0000

The Chief Engineer role in the Toyota Product Development System combines parts of the Product Owner, ScrumMaster, and senior technical team member roles from Scrum. In addition to leading the technical design of a new product and facilitating the work of the other engineers, the CE must deeply understand and care about what the customer values—he has ultimate responsibility for delivering value to the customer and for the resulting commercial success or failure of the product.

CEs have gone to amazing lengths to gain that deep understanding of the customer’s needs.

For example:

While developing Toyota’s successful 2003 Sienna, the Sienna CE drove his team in Toyota’s previous minivan model more than 50,000 miles across North America through every part of Canada, the United States, and Mexico. The CE experienced a visceral lesson in what is important to the North American minivan driver and discovered in every locale new opportunities for improving the current product. As a result, the Sienna was made big enough to hold full sheets of plywood while the turning radius was tightened, more cupholders were added, and cross-wind stability was enhanced, among many other improvements that resulted from this experience.

(From The Toyota Product Development System by James M. Morgan and Jeffrey K. Liker, p. 30)

If you’ve followed recent discussions on the scrumdevelopment group, you’ve seen multiple threads over the last couple months that discussed how the interests of the team, SM, and PO are intrinsically in conflict and that acting as both PO and SM requires a kind of useful schizophrenia.

I have to wonder: Toyota is one of the best product development organizations in the world. Are Toyota’s CEs a special breed, immune to the conflicts of software teams? Do the rest of us need distinct roles to balance our selfish interests?

At the very least, if we find that the interests of our POs, SMs, and teams seem to be fundamentally in conflict, we should ask why. Shouldn’t we all have the same goal: Producing valuable software now and in the future? Perhaps we should consider how to align around that goal rather than how to balance the interests of roles centered on lesser goals in the hope that we achieve the true goal as a kind of dialectical byproduct.

It’s one thing to say that the PO and SM roles ought not be combined because each is so demanding that it requires a person’s full time attention. But it’s quite another to say that the roles are fundamentally locked in a conflict too intense to be handled by a single person, and that better software results from that conflict.

Motivated Individuals

Richard Lawrence — Fri, 14 Nov 2008 20:31:35 +0000

As agile approaches the mainstream, it’s easy to lose sight of some of the core principles, especially this one:

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

If agile is to apply broadly, we can’t reserve it just for those projects that start with motivated individuals. We need to learn how to cultivate them.

What makes for motivated individuals on a software team?

The belief that the product is worth building. (I consider really interesting technology a special case of this.)
The belief that the expectations placed on the team are achievable.

(The book Influencer divides these into Motivation and Ability, but I find that ability so often drives motivation that the two can’t easily be separated. Nonetheless, the book and the authors’ blog are well worth reading.)

Scrum’s sharp distinction between “what to build,” which belongs to the Product Owner, and “how to build it,” which belongs to the team, can create a situation where the team passively builds whatever the Product Owner asks for whether they believe in the value or not. If better software is built by motivated individuals, this is not the way to get it.

This week, I facilitated a project retrospective for a team that struggled with the value of the product they’ve been working on since May. On several occasions, the team was visibly demotivated by the low value they saw in the product. They worked hard and did a good job, but I could tell that they weren’t motivated by the product itself. In the retrospective, one of the answers that emerged to “What should we do differently next time?” was, “Engage the Product Owner in conversations about the value of the product.” Had they done this, the team might have been able to help the Product Owner identify more valuable stories. Or the Product Owner might have been forced to articulate the value of the current stories more compellingly. Either way, the team would have been more motivated to deliver.

The principle I quoted above can be read as, “Find individuals who are already (or inherently) motivated and use them on your projects. Avoid the unmotivated individuals.” That’s fine as far as it goes, but I don’t think it usually works that way. It’s better interpreted something like this: “Find individuals who are open to caring about their work (i.e. potentially motivated). Engage them to become motivated about building something valuable. Let them make delivery commitments they believe they can achieve. Support them and get out of their way.” That’s how you build projects around motivated individuals.