Want Productivity? Focus on Predictability Instead

Richard Lawrence — Thu, 23 Sep 2010 16:07:54 +0000

Focus your team on predictability, and productivity will come. Focus on productivity, and you’ll get neither productivity nor predictability.

Focusing on predictability drives a team to:

Small user stories that can be completed in a day or two
Working on a small number of stories at once
A strong story definition of done with little or no gap between it and the release definition of done
Individuals crossing disciplines to get things done without unpredictable wait times
Making achievable commitments based on past results

On the other hand, focusing on productivity—usually leads to:

Individuals optimizing for their own productivity (i.e. lots of tasks getting done)
Over-committing
Starting stories without necessarily believing they’ll get done (“If we’re going to get all these stories done in this sprint, we’d better start them as soon as possible!”)
Sacrificing quality for speed (i.e. taking on technical debt—”Just get it done; we’ll clean it up later.”)
Communicating and collaborating less (“All that conversation slows me down. I need to focus on my work.”)

The (ostensibly) productivity-focused behaviors may show a velocity increase in the short term. But you’ll pay for it later. More likely, you’ll see an erratic velocity, sometimes high, sometimes zero. And there is likely to be some nebulous chunk of work between the last story and the release.

Over and over again, I’ve seen the predictability-focused behaviors lead to a stable or, more often, a slowly increasing velocity. Small stories are easier to estimate and to get done right. Building quality in keeps the system easy to maintain and extend. And when done really means done, the Product Owner can make meaningful predictions and commitments around delivery. “Working software is the primary measure of progress,” after all.

Note: This assumes energized work. If your team doesn’t care about getting anything done, they could predictably deliver nothing, which isn’t particularly satisfying. With this team, focus on motivation, then predictability. As the Manifesto also says, “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” Motivation comes first.

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.

Richard Lawrence » Definition of Done