Take a process retrospective

July 21, 2013 / Steve Johnson

A key element of many agile methods is the retrospective. After each iteration, the team comes together to discuss what worked and what didn’t, and to brainstorm ways to improve the process. After all, the people who participate in a process are the ones most likely to see ways to improve it.

But let’s take it further. Don’t limit your thinking to just the product creation process. After each product release, let’s examine every process: the development methods, the product launch, the sales enablement, the roll-out to professional services and support.

This is when your colleagues’ opinions really do matter. Have a few sit-downs with your counterparts in marketing, sales, support, service, and operations to see what you did right and wrong, and get suggestions on how you can do things better.

It’s probably better if you do these retrospectives in one-on-one discussions instead of big meetings. You’ve learned how to gather requirements from your customers; now use those techniques to gather requirements from your colleagues. What worked; what didn’t; what recommendations do they have to make it better? What problems occurred in the roll-out that could be prevented in the future.

Some questions you want to ask are: 

• Was the process well defined or was it missing key deliverables?

• Did you have goals for this process and did you achieve them?

• Did you have the right team members involved? Were any team members overwhelmed? Were any team members unnecessary?

RACI

A RACI assessment is a powerful tool for defining the roles of team members. After all, not everyone has the same level of participation. RACI stands for Responsible, Approves, Consulted, Informed. Learn more at http://en.wikipedia.org/wiki/RACI_matrix

(If you’ve used a RACI matrix before, the big challenge for most people is the “A.” I use “Approves” instead of “Playbookable” since I’ve had many, many discussions that got derailed over the delineation between Responsible and Playbookable. Use Approves instead.)

A challenge for many teams is the idea that everyone needs to be responsible. In your process retrospective, revisit the roles involved in each process and determine where they belong in the RACI matrix. Maybe some team members need to be consulted rather than responsible; maybe some need only be informed.

A business retrospective

While we’re at it, let’s look at the financials too. Did the product achieve its first year goals? Compare the costs that were planned to the actual expenses. Examine the revenue forecast to reality. In most cases, you’ll see that it takes much longer to ramp up revenues than anyone expected. We’re optimists, many of us.

It’s amazing how often a number gets pulled out of the air instead of from a spreadsheet. One product manager estimated $18 million in revenue for his product. His boss thought about that number for a second and decided that the product should really do $40 million instead. The next year, the product did $18.3 million and nobody got their bonuses.

Work with your finance team to do a retrospective on the business planning and financial modeling processes. And let those lessons drive your next forecast.

Ultimately, the measure of success is profitable customers.