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.
Note that leaders can’t manage or change “progress” itself, team speed is a fixed velocity in the short to medium term. It’s important to know the state of the product development and consciously avoid reflexive actions that make bad matters worse. At Level 2, you can use Manage Priorities to effectively manage the data from this practice.
First, do no harm.
✓ Critical ❑ Helpful ❑ Experimental
Depends on: Vision
Steps to first adopt this practice:
See Warning Signs, below.
You measure the number of user capabilities 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 timebox 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 and a chart on the wall are often all that is needed to track this information.
Ensure everyone knows what tasks need to be worked on. Deciding that should be a very quick and informal process, not a big high-ceremony affair.
Your spreadsheet has a section for each release and a line for each team. Each team’s feature allotment 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 CapabilityPlanning, 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 only ship working, tested features, not hours.
Try to anticipate what your teams will accomplish in a given timebox. Attend their demonstrations and see what’s working and what’s not. Get involved with your teams meetings.
Plan a release your teams believe they 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, base your calculations on what the teams have been able to recently complete. 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.
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 and consultants, never the organization.