During preparation for a presentation on agile and agile implementation, I started to think about what to do when you cannot implement a full agile system up front. I decided I would go for retrospectives, simply because they represent the core idea of agile: to improve the way we work. Therefore, retrospectives will drive the process in the right direction, even without Scrum, kanban, Extreme Programming, or any other fancy agile process.

Improvement requires that you know what to change, and retrospectives can help you identify just that. When you know what to change and why you want to change it, you can look into Scrum, kanban, or lean and get inspired by the practices in order to find something you can experiment with for a while.

In order to get retrospectives to work, you must do them properly and regularly. You and the group you work with should identify one or two problems with the way you work. You all have to agree about why these problems are important to solve. The next step is to choose one of the problems and define a hypothetical solution. The solution is hypothetical because you do not know if it is the right solution. You have to define how to identify that it actually solves the problem, i.e., how you will measure that the change you introduced works and removes or at least relieves the problem.

Retrospectives should be performed at regular time intervals of at least every four weeks. There are two reasons for this. Firstly, it means you must keep the changes small. If the change seems big, break it down. A consequence may be that you are not able to fully solve the problem, but it is far better to make a small change and solve some part of the problem than to try to make a big change and fail. Secondly, it allows for agility in how you change your processes. When you change in one direction, new problems may arise, and you can take them up in due time. If the time span between retrospectives becomes too long it, is my experience that the effectiveness of the retrospectives decreases. I believe the main reason is the lack of focus on the improvements, which causes team members to return to previous bad practices and habits.

The single largest risk in performing retrospectives is that you could identify the problem and describe the hypothetical solution and related measurements, then just go back to your daily work without any of the changes being implemented, and the solution slowly disappears in the mist of daily tasks. To avoid this, you need two things: a solution champion and a visual representation of the measurements.

The solution champion is someone who takes ownership of implementing the hypothetical solution and following up on it. Consequently, the solution champion cannot do as much "normal" work because he or she now has this important improvement task. This may sound obvious, but in my experience, this is the main reason for not following through on improvements—no one actually was assigned the responsibility or time allocation to do it. A visual representation of the measurements is needed to provide clear feedback to all involved on the progress of the hypothetical solution. This enables people to act or comment on the progress.

The benefit of starting an agile or lean transformation simply with retrospectives is that the transformation will focus on the right problems, and you can avoid introducing new ones. If you implement a whole agile process framework (e.g., Scrum), the retrospectives often end up focusing solely on the newly introduced process and not the underlying problems. By starting with retrospectives, the practices you introduce are chosen because they solve a problem you all have agreed upon, not just because they are part of a process framework. This makes the practices more relevant, and the mere fact that you are trying the practices as a solution to a specific problem may make it easier to introduce the process and get working.

Getting Started with Retrospectives

If you have never run a retrospective, I suggest you get help from an experienced coach. I have found this to be the fastest way to learn facilitation techniques. Pair up with the coach and prepare, execute, and follow up on the retrospective together.

If getting this kind of professional help is out of scope, I suggest using the framework described by Esther Derby and Diana Larsen. This framework provides a good starting ground for your initial retrospectives and enables you to focus on the content. As you learn and become more experienced, you can deviate and experiment with the style of the retrospectives. At that point, I recommend the website TastyCupcakes.org and the pocket book Getting Value out of Agile Retrospectives by Luis Gonçalves and Ben Linders as good sources of inspiration. They provide activities to keep your retrospectives fresh and varied, which is important if you want to keep the continuous improvement engine running.

Another practice I have found valuable is using kanban to visualize work. The transparency supports continuous improvement, and almost all people can adhere to it. People focused on lean often say, "You should start with defining the value for the customers." This can be difficult, especially if you have many of them. However, when you visualize the work, you can enable value-based prioritization and learn what it actually is the customers want. The entire process becomes easier once you can actually see what it is you are doing.

Conclusion

Agile and lean methods often promise you will achieve better, faster, and cheaper solutions. However, introducing a full agile framework can be daunting and cumbersome. Instead, I suggest beginning with the core focus of these methods: continuous improvement. Retrospectives are the starting point of your agile journey and can help you solve the most immediate problems in your process, leading you down the road of process improvement.