Five Practical Tips for Any Team to Reduce Risks, Increase Agility, and Deliver Value

A colleague recently asked me how a team can deliver something useful in the next four to five weeks.

“That's all? Just four to five weeks?” I asked.

Yes, that was all the time they had remaining. They'd worked on this product for a while, but that was the time they had left.

This problem can occur in any kind of project, but it most often occurs when someone thinks they can plan for a long time and not deliver incrementally. (See the How to Predict A Little About the Future Work Without Long Intricate Plans for a management perspective on how to reduce the feedback loop duration.) Every time a team goes longer than a few days or a week without demonstrating something, they are at risk of running out of time on their project.

If your team has that problem, don't try to say which lifecycle or approach you will use now. (See Project Lifecycles: How to Reduce Risks, Release Successful Products, and Increase Agility for all the names.)

What you did before is sunk cost. Instead, consider how to help the team focus on limited WIP, high collaboration, and frequent delivery.

Here are my tips.

Tip #1: Rank the Work

It's possible the team's backlog and/or roadmap is a wishlist, especially if the roadmap is full of very large problems the team will need to break apart to make progress on.

That's why I like to rank the work first. Not prioritize it. Rank it. (See How to Tell the Difference Between Rank Order and Prioritization.) Ranking will make people say which feature is #1, which is #2, etc. Even better, they might be able to see how little they can do to solve this particular problem.

This reduces the risk of not getting the “right” work done fast enough.

I like to discriminate among the various minimums to decide how little the team needs to do to solve a particular problem.

Tip #2: Clarify Which Pieces Are Minimums

We often discuss MVPs, but I have found MVPs are not always the minimum this product needs right now. See Consider Product Options With Minimum Outcomes for more ideas about what a minimum could be—or must be.

If this team is supposed to replace a given product, they often need almost all of what already exists. However, your team might be able to release smaller increments of value. All the product minimums help decide which increment is most valuable right now.

This reduces the risk of not releasing the most valuable work.

Sometimes, that means the team needs to right-size the work so they can finish it.

Tip #3: Right-Size the Work

Right-sizing is a simple-to-explain, sometimes challenging-to-do idea. In general, how often does this team finish valuable work? Yes, this is a measure of cycle time. However, some teams that've been together for a while already ask themselves, “Is this roughly the same size as the stories we normally finish in a couple of days?” (See How to Right-Size Your Stories for Better Predictability.) This manages the risk that the team does not finish the most important work.

What if you already sized the work “down” and your team still needs a week or two to complete something useful? The team needs to collaborate on everything. And often, before they can do that, the team needs to limit all its WIP (Work in Progress).

Tip #4: Limit All the WIP

Some teams multitask between several projects. If your team has limited time, limit the WIP. Make sure the team works on one, and only one, project at a time.

If the team has already done that, as in the case above, make sure the team also limits the number of items each person works on. For example, every time someone has to interrupt themselves to do a code review, chances are excellent that requestor has started on a new piece of work. And the reviewer has a new piece of work. See See and Resolve Team Dependencies, Part 1: Inside the Team.

(See the value stream maps in Measure Cycle Time, Not Velocity, to see how long everything might take when people work on multiple pieces of work.)

Tip #5: Collaborate on Everything

I'm a huge fan of pairing, swarming, and mobbing. The more the team swarms or mobs to limit the team's WIP to one item, the fewer meetings the team needs. The simpler the board can be.

Sometimes, managers do not understand how collaboration—not cooperation—can reduce a team's cycle time. That's where the value stream maps in Measure Cycle Time, Not Velocity can help everyone understand. Or, ask people to read How Flow Metrics and Why They Matter to Teams and Managers.

Not Sure How to Start?

I'm describing agile principles, but no specific framework's practices. If you think you can use these principles and you're not sure how to start, read How to Conduct an “Agile” Hudson Bay Start to Test How Your Team Works. That post (and/or the books below) will help you start and see how you can use these five tips.

You will increase agility, deliver value faster, and maybe, just maybe, meet your new deadline.