Understanding the learnings from waterfall lessons learned and agile retrospectives.
It’s human nature to compare what we previously have learned in life to new concepts(1). So when something ‘new’ comes around we automatically compare it to areas of acquired knowledge.
The main area that I have come across from both sides of the fence is the agile event ‘retrospective’. This is very commonly compared to a waterfall ‘lessons learned’. I too in my early days of transitioning and gaining newly formed knowledge in agile mindsets used to explain the retrospective event in this way.
So what’s the difference and why? Let’s cover what's first.
Definition: Lessons learned is the knowledge gained from the process of conducting a project. This includes the positives and negatives. The idea is to repeat the positive aspects and not repeat the mistakes(2).
Reality: Lessons learned tends to happen at the end of the project, sometimes if encouraged it happens part way through and only when an issue has occurred and needs reflection on the root cause and how to ‘learn’ from it next time. It is predominantly focusing on the project behaviours rather than team behaviours.
Positives: the project captures the knowledge gained and what worked for future reference.
Negative: the outcome is often fixed, knowledge gained forgotten (lengthy gap), blame reflected on those left and senior stakeholders invited.
Definition: The sprint retrospective is an opportunity for the scrum team to inspect itself and create a plan for improvements to be enacted during the next Sprint(3).
Retrospectives happen as part of the timeboxed period. Timeboxing is a key element of the agile mindset, much to misconceptions of organisations, (which I will cover in the future articles), this involves:
requirements → design → planning → reviews → deployment
Happening over one to four week cycles. Retrospectives however, are often the first meeting to be dropped. Why? Because they are hard. An introspective reflection on both the team and the project is hard. Organisations, teams and individuals don’t always want to recognise failure.
An agile mindset is about failing quickly so not to release products that bring no value to the business; going over budget, reduced value and exceeding the agreed timeline. That of which all account for a failed project and costs the business a ‘healthy’ sum.
Through retrospectives regular feedback loops allow for reflection on areas that are going well, not so well, keep doing or stop, to provide potentially shippable products to the market for maximum return on investment.
Positives: there is no time lag between something happening and there being learnings that can be implemented immediately in the next timebox. The team not only reflects on what went well or not in the timebox as a project but as a team. How did we work together, did we all pull our weight? And what can we try next time? There's flexibility in the action outcome, if it doesn’t work, the team fails quickly and tries something different.
Negative: change is hard, your team may go through turbulence faster than you may want in the early days of a project. But that’s the deal, we form, storm, norm and perform(4). Let’s get there stronger than ever.
Share your experience of learnings however they may surface, for others to learn and implement today. What good is a community and a tribe of ‘projecteers’ when we can’t learn and influence a better tomorrow. Eleanor Roosevelt once said: “Learn from the mistakes of others. You can’t live long enough to make them all yourself.”
You may also be interested in learning modules on agile working from APM Learning, free to APM members.