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.

process retrospective

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 “Accountable” since I’ve had many, many discussions that got derailed over the delineation between Responsible and Accountable. 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.

Category:
planning

Join the conversation! 2 Comments

  1. Excellent advice, I recently commented something similar in a discussion on LinkedIn. What’s often surprising is how little colleagues know about how each other work. When you start with a defined process you begin to deviate from it over time. This happens for a variety of reasons; it could be because you return to old habits or, more likely, you figure out better ways to deal with things and improve the way you work. The problem with it is that as a team you all start to follow slightly different processes, what might seem like an obvious improvement to one could have been missed by another. Running a ‘process workshop’ as part of the retrospective helps everyone get back on the same page. This is where I disagree slightly with the article as I would absolutely recommend this done in a meeting with the team and not one-to-one. That said I don’t believe there would be value doing this every time, quarterly or six monthly would be sufficient.

    Reply
    • Let me amend that: in addition to a team meeting, do a one-on-one. There are many who don’t contribute in group meetings who have insights they’ll share in a private session.

      Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 4,449 other followers