Great leaders need to understand what their teams are building, how far along the work has progressed, and whether that work is on, ahead of, or behind schedule.
✓ Critical ❑ Helpful ❑ Experimental
Depends on: Vision
Steps to first adopt this practice:
See Warning Signs, below.
You measure the number of features that work—work for users, for real, in production—not the number of hours that bottoms have been in seats; you measure results, not effort. Track the work intended to be in this release and the amount of work completed thus far.
Adjustments to the content or time frame of a release are made based on how much of the software is working, not how many hours are invested into it.
You don’t need any large or complicated tool to track feature completion; a simple spreadsheet is often all that is needed to track this information.
Ensure everyone knows what features are going into a release. This information is usually decided in a release planning meeting (or similar practice), but can change over time. Excessive change here is dangerous, so be careful.
Your spreadsheet has a section for each release and a line for each team. Each team’s feature commitment is listed, along with an estimated (or actual) number of the stories for each feature:
A representative from each team will report weekly on how many features have been completed.
When the rate of completed work is trending towards a date far beyond the desired ship date, reduce the scope of the release instead of trying to force more work from the teams. Team capacity is addressed in CapacityPlanning, but treat capacity as a constant for the current release.
Learn what your team’s capacity is by watching these numbers for several months. As you learn what they’re capable of delivering, you’ll learn how to plan realistic releases and how to more effectively direct your teams to get the product you want.
Understanding the problem is not under-performing delivery teams but unrealistic expectations is the first step to growth.
Create a challenging but sustainable work pace and you’ll discover predictable ship events, higher quality, and loyal team members.
Graph the data in different ways to understand which forms are best absorbed by yourself or others, as well as which format shines a light on your areas of concern. There are many ways to graph this information and different formats resonate differently with different people. Find the ones that work best in your organization. But again, focus on results, not efforts. We can only ship working software, not hours.
Try to anticipate what your teams will accomplish in a given iteration. Attend their demonstrations and see what’s working and what’s not. Get involved with your teams iteration ceremonies. Challenge your teams to hit 100% of their iteration commitments.
Plan a release you believe your teams can hit comfortably instead of one that will tax (or overwhelm) them. Help the teams hit a few comfortable targets. It’ll give them confidence, as well as the space they need to get better in this new way of working, while also helping you improve your understanding of how they work.
Try to anticipate when a release will ship. Use the progress of the teams and their completion rates to anticipate completion. Remember that the past usually looks like the future, so use traditional story per feature ratios and stories per iteration to do your calculations. Never assume a faster rate than you’ve seen in the past. That way lies madness. And ulcers.
Doing the math is often all that’s needed, but it must be visual. Many executives are data driven individuals. They’ll want the spreadsheet. Others need a graph. So provide both.
The numbers that matter are:
Sometimes people get upset when they first see these numbers, but they’re almost always upset with themselves or their lack of awareness. We haven’t (yet) seen anyone upset at the person presenting the numbers.
Anti-patterns from the Hall of Shame:
Far too often an executive or manager will try to solve their problems tracking progress with a new tool or a major change to their existing tooling. This new tool is always costly, or the tooling update is driven by an expensive consultant. It’s important to realize that these changes will interrupt a team’s workflow. With the best of intentions, the change will slow everyone down. Resist the urge to chase the elusive silver bullet and instead embrace the simplicity of a spreadsheet.
First, understand what your teams are trying to do and how much is done. Then, when time permits, feel free to upgrade the tooling. But never embrace a tooling upgrade in the midst of a stressful project. These upgrades only benefit the tooling vendors, never the organization.