Agile/Scrum-Lessons Learned

Lessons Learned
Ok so I know that one of the agile/scrum manifesto items is “create just enough paperwork” and I have in earlier posts said that this sometimes is easier said than done. There are a few documents that I have found to be useful no matter what framework your project has adopted. One such document is the lessons learned document where you analyzed results of failures and successes of a project. Try to capture good and bad practices (lessons learned) earlier in the project, if you can do this you will be far ahead when it is time to close the project and deliver the application. When you make discussions as a team try to keep track of decisions that turn out well and ones that don’t. Document what you believe was the reason the decision turned out well or what made it turn out bad. Always include all the team members (agile/scrum) the members of the team are usually very straight forward and insightful on what was a positive or negative decision. Also this is not a “gotcha” document it is not created to point fingers, it is a positive team-building and decision-making tool. Here is an example that I created that we handed out at the end of the project, I had the entire team document there inputs directly in it. It truly believe that this document helps build team cohesion and unity, your career as a scrummaster will benefit if you carry out this process. Here are a few lessons learned ideas I have used in the past.

Lessons Learned Ideas
1. Involve the entire team including the product owner; this is how you get the full team input.
2. Ask what you did right and what you did wrong in each iteration, and then ask the team what the “team” could have done to turn negatives into positives.
3. Ask the team “what decisions should we have considered, but did not make.
4. If there were selective areas of the application that had more issues than others, select team members who were involved with the work that took place and involve them in the lessons learned for that portion of the application.
5. Remember this is agile/scrum don’t make this a time-consuming process; conduct one meeting at the end of the project.
6. Document the information and include it in a lessons learned document, use this document for all projects so you have uniformity across the enterprise, you don’t have to spend needless time on redoing documentation.
7. Give yourself a copy, team, product owner, store it in a wiki, on shared server, this will be a tool for future projects.

Popular posts from this blog

Burn Down vs. Gantt Chart

Agile/Scrum- Communication Plans

Cost Control Agile/Traditional