When I wrote Manage It!, I included an idea called a Hudson Bay Start. I wrote an article about that later, in How to Use Iteration Zero—Or Not. Hudson Bay Starts are not a new idea.
However, you might not know what they are. Here's the idea: the team chooses one item from their backlog. They collaborate (however they want) to complete it. Then, they demo and learn from what they did. That allows the team to decide how they want to work in the future. The team can see any of their traps and choose to avoid them.
While very few teams still try to do an Iteration Zero, many teams still have too much WIP. Then, they feel they must roll over any unfinished work to the next iteration. Because they have so much WIP, everything takes a long time to finish. Too often, these “agile” teams don't work as even a cooperative team, never mind a collaborative team. (For more details, see the series that starts with See and Resolve Team Dependencies, Part 1: Inside the Team to see the differences in value streams between individual, cooperative, and collaborative teams.)
Instead, I've been recommending teams use an “agile” Hudson Bay Start. I'm using the “agile” word in front of this because then the various managers and coaches will pay attention. (When we put “agile” in front of terms, many managers say, “Okay, just go do it.”)
This works best in a new team, or a team recommitting to agility. Or a team that's not working “fast” enough. This “agile” Hudson Bay Start works because of the flow metrics.
How to do an “Agile” Hudson Bay Start
- Gather the team. (If you have a distributed team, address your hours of overlap. You might not have a real team—you might have a collection of individuals. In that case, your value stream map will tell you a whole lot about the collaboration you might expect.)
- As a team, choose one item to work on. Just one item that offers value to a customer. Not two items or more. One item.
- Start a value stream map. (See the examples in Measure Cycle Time, Not Velocity.)
- I recommend the team swarm on this item. (See Pairing, Swarming, and Mobbing for more details.) As the team works, update the value stream map. And, when people finish “their” work, they can support other people however the other people want that support. Some examples: code review, test review, experiment design.
- Once the team completes that item, do a demo and a retrospective.
Here's how I like to demo and retro.
How to Demo the Hudson Bay Start
If the team has access to a customer, use the customer to demo the finished feature. If not, ask the Product Leader to demo.
I ask everyone on the team to take notes during the demo.
- Is the demo-er confused at any time during the demo?
- Does the demo expose any defects?
With any luck, the team only spent a day or so on this feature. No one has invested weeks or months of their time, which means they are more able to see and admit they have problems when other people demo their work.
As soon as they finish the demo, it's time for the team to retrospect on their work.
How to Retrospect on the Hudson Bay Start
I always recommend Agile Retrospectives: A Practical Guide for Catalyzing Team Learning and Improvement as my go-to book for retrospectives. If no one on your team has read that book, buy a copy for everyone and read it. Then, practice.
Remember, the retro is the only “mandatory” practice in the Agile Manifesto. That's because the retro supports double-loop learning. No other practice is in the principles—only the retro.
If a team has never retrospected before, it might well be worth the expense of having an outside facilitator support the team for their first retro. I like this order for examining what they did:
- Start with their demo (what worked, what didn't, etc.) Yes, the demo is the outcome of how they worked. But I want to know if the customer was delighted or not. And, the team knows something about their process worked. Even if they all hate each other.
- Next, examine how they worked. Use all the various data: the value stream map, the flow metrics, and how everyone felt along a timeline.
Choose one thing to change.
Then, do another Hudson Bay Start. That will allow you to answer the inevitable “efficiency” questions.
How Efficient Are We?
Every time I do this with a team, someone (or many someones!) asks, “But these three people were not busy all the time. That's so inefficient!”
If you measure work by a single person, it does look that way. However, individuals cannot—by themselves—finish features. The team needs everyone on the team to participate. (See Want Both Efficiency and Effectiveness? Lower WIP and Right-Size Work and Think Agile to Work Efficiently and Effectively.)
The only “efficiency” measure is cycle time and throughput: how fast a team can finish work that has value to a customer. All other measures of “efficiency” or “productivity” are useless.
If a team wants more efficiency, they can increase collaboration. That will reduce all the wait states. (Review Flow Metrics and Why They Matter to Teams and Managers.)
Your team might have different questions or problems. Here are several problems I see:
- Someone is assigned to several teams. Sorry, they are not part of any team. Instead of a single collaborative cross-functional team, your organization has bits and pieces of teams.
- Someone is too far away in terms of hours of overlap. Sorry, they are not part of this team.
- This team does not have all the people they need, often because of “shared services.” Sorry, you don't have an agile team.
Many supposedly agile teams are not teams, never mind exhibit agility in any way, shape, or form.
And way too few teams have ever tried to create working agreements.
A Hudson Bay Start will illuminate why your team is not able to work together. A retro will help your team choose how to work next.
An “Agile” Hudson Bay Start Tests How Your Team Works
Use a Hudson Bay Start (“agile” or not) when you want to clarify what's going on with your team. Set your team up for success. (See Create Your Successful Agile Project for many more ideas, including working agreements.)
But too few teams are “agile” on Day 1. Use a Hudson Bay Start to see what your team can do and what they might consider as a change. (And read Create Your Successful Agile Project and Project Lifecycles to see what you can do.)