Want to be more agile? Look back before moving ahead.

An increasing number of companies are pursuing an agile transformation strategy to accelerate innovation, increase customer connection, take advantage of disruptive technologies, and adapt to a rapidly-changing business environment. Agile is serious business—and there are significant financial incentives for those organizations who get it right.

When making the shift to agile, remember the following:

• It takes time. Becoming agile isn’t like flipping a switch. Instead, it’s a long and continuous shift in the way your organization or team collaborates, makes decisions, and executes.
• It’s not one-size-fits-all. If you show me five highly successful agile organizations, they’ll share some significant similarities but also plenty of differences. An agile methodology needs to be customized for your specific business and operating context.
• People issues are inevitable. Any significant business transformation requires a talent transformation. The same is true for agile, as it requires deeply personal changes in the way groups of people get the work done.

Fortunately, the agile management discipline includes an important ceremony known as a retrospective. The techniques used in a retrospective are simple yet powerful.

The retrospective is held at the end of a sprint—the short-term operating cycle in an agile organization. (At PI^®, our product and engineering teams run on two-week sprints.) The purpose of the retrospective is for the agile team to answer three questions:

1. What went well during the last sprint?
2. What didn’t go so well?
3. Which of the things that didn’t go well would we like to improve upon?

By starting with the positives, the team engages in a type of collective affirmation and gets the positive energy flowing. The meaty part of the retrospective comes when the team openly and honestly identifies challenges, frustrations, and problems that cropped up during the sprint. There are often many items on this list—and that’s okay. 

During the final part of the retrospective, the team prioritizes one or more items on the list to improve. At PI, we do this by giving each team member three votes. We then tally up the scores to identify the most popular improvement area.

After successive rounds of retrospectives, the agile organization will evolve the way it executes. This will produce a highly personalized agile methodology in the organization. This addresses how agile takes time and won’t be one-size-fits-all.

But what about the people part?

Using agile to address people issues

I’ve found the same retrospective method works quite well—whether it’s to reflect as an individual, with a direct report or peer, or within a group. Here’s what a retrospective might look like when addressing people issues:

• Self-reflection. As an agile team leader or member, privately ask yourself where you’re comfortable with the agile way of working and where you’re not. Where is your performance high, and where is it not? Then prioritize improvement opportunities and work on them.
• One-on-one relationships. When working with a direct report or a peer, ask one another what’s going well in your agile work together and where are things not going as well. Collectively decide where to concentrate your improvement efforts and hold one another accountable.
• Senior leaders vs. individual contributors. An especially informative exercise is to compare the retrospective results from two groups. Separately capture the “what’s right, what’s not, what’s next” inputs from senior team members and from individual contributors. Compare the two sets of results, looking for both similarities and differences. The differences, in particular, will highlight misperception points and allow the team to identify and remove blockers.

Too often, people issues go unaddressed—and many agile transformations underproduce as a result. Fortunately, the same retrospective method can help agile leaders get the people part right when they use it as a developmental tool with individuals and teams.