Lessons Learned

It goes without saying that mistakes will be made when operating in an uncertain environment. The trick, of course, is to learn as much as possible from each misstep, adding to the knowledge base of the organization and, hopefully, not making the same mistake again. There are three parts to the basic lessons learned process. First, develop an environment that supports continual learning. Second, capture key lessons learned. And third, archive, organize, and make these learnings accessible to current and future project teams.

Many organizations believe that they are too busy to spend time looking back. They think it's a waste of time, or worse, they are embarrassed to bring attention to poor behavior, decisions, or performance. Breaking this type of culture will go a long way toward improving both short-term and long-term success in the agile environment. The agile project operates in an atmosphere of high interactivity, boundary crossing, and multiple simultaneous pathways. Team members need to have conviction in their opinions, be able to consider alternative viewpoints, and come to agreeable conclusions among themselves. In a nutshell, they need to be able to work effectively together. While this is the case in almost all of business, it is emphasized here because of the higher levels of interaction among team members who, perhaps, are not used to working together. By inserting lessons learned sessions (either periodically or at major milestones) into your overall project plan, you will be putting the team on notice that their actions will be reviewed and captured. When organizations first start this process, it tends to gravitate toward team dynamics, both positive and negative, as the team learns how to work together in the agile paradigm. Once the interpersonal dynamics are worked out, the lessons learned tend to shift toward technical and business decision making, but by this time your team will be well on its way to becoming truly effective in the agile environment.

Agile Strategy

Support and allocate time for a consistent "lessons learned" process. By creating an environment of intrateam- and self-accountability, you will accelerate the development of effective working relationships among your team members.

Effectively and efficiently capturing the lessons learned from your projects is the key enabler to making this process successful. There are numerous ways to perform this process, but key elements are that it must be easy to use, take minimal time, have full involvement, and provide fast feedback to the participants. Without at least touching on these areas, the process can become too drawn out and analytic for the agile project, thus stalling its progression, rather than accelerating it. The goals should be to quickly capture what went well and what could be improved. There should be a brief discussion on the results, and then the team should move on. Some action items may be assigned as an output from the process, but they should not hinder forward progress of the overall project or the next project. If you already have a lessons learned process, take a look at it from the agile perspective and consider the aforementioned points. As a target, try to limit team involvement in the process to one to two hours total. If you go over two hours, the process will get too heavy for the agile environment, and you'll need to make some modifications. If you don't currently have a formal process, an example is included at the end of this chapter that can be used as a starting point for you to customize to your project environment.

Finally, archiving, organizing, and communicating your lessons learned will be a foundation of your long-term success. Certainly, results should be immediately communicated to the participants via e-mail or other project communication. However, teams should be able to learn from the lessons of other teams as well as their own. Creating some type of online and organized archive system is the best way to do this. Knowledge management is a relatively sophisticated topic unto itself and is not discussed here, however, I discuss the basics of a manual project management infrastructure that would cover the long-term archiving and accessibility of lessons learned in Chapter 10.