A recent report by Harvard Business Review-Analytic Services cites eight hard skills CIOs say will be most important in 2020 and b
Traditional IT postmortems are dead in the agile age
If you wait until the end of a project to review it, you are already too late. Make learning continuous and habitual with these tips for agile retrospectives
Traditional IT postmortems no longer work; it’s time to let them go. They are often undermined by organizational power gradients, confirmation bias, and traditional IT organizations’ discomfort with iteration and agility. If you are waiting until the end of a project to review it, you are already too late.
I do not mean reviewing a completed project has no value, but the all-at-once, at-the-end postmortem needs to be replaced by a more frequent retrospective that embraces incremental learning and change. This will turn your company from an execution-focused organization into a learning-focused organization. Rather than “plan-do” with a postmortem at the end, we need “plan-do-learn-do-learn” – a continuous-improvement model.
[ Is your team really doing agile – or just breaking legacy process into sprints? Read also: Beware the dark side of agile project management. ]
How to encourage continuous learning
In the age of digital disruption, change needs to become part of the company fabric. All businesses must become learning organizations. This means that people, including you, must also be good at changing. Learning must become a fundamental characteristic of people, teams, and departments.
[ Read also: 7 ways to foster a culture of learning in IT. ]
The idea of postmortems is good: time to reflect, learn from what you did, figure out why something went wrong, and ask what you can improve. The traditional approach falls down because it is a one-time process conducted at the end instead of ongoing reflection, change, and learning. What we want are teams that are “habitually” learning, constantly looking at their world and their response to it with a study of how it can be improved.
I advise carving out time every Friday afternoon for teams to discuss what went well that week and what didn’t. From those meetings, identify the big items and have the team address them. As a leader, help the team with resources to address these needs. Repeat this each week and acknowledge improvements made.
Rather quickly, you’ll find teams begin to understand that things can be changed. People will have more confidence about speaking up. And you’ll have an opportunity to fix and change course on items well before the end of a project – and achieve better results as a consequence.
[ What tools help support scrum, kanban, and other agile methods? Read also: Top 7 open source project management tools for agile teams. ]
The trouble with best practices
Many practices in IT, like postmortems, are the result of years of accumulation of IT “best practices.” I encourage everyone to question what they consider their best practices.
The term “best” means something that cannot be improved upon, but it’s dangerous to think of anything as something that cannot change. It’s much better to think of things as “good practices” and encourage people to find ways to make them even more effective and efficient. There is always room for improvement. If you’re not looking for it, chances are somebody else will find it first.
Another problem with best practices is they tend to be copied from someone else and applied without understanding. This limits learning.
The best learning comes from our own “aha” moments. The theory of best practices is tempting; however, avoid directly copying from others and instead embrace adaptive learning to find your own good practices.
Don’t ignore the human element
The typical IT postmortem also tends to ignore the human element. Most project managers want to stay away from discussions about culture and interpersonal dynamics. By comparison, in an agile retrospective, we talk about the human elements because they impact team performance significantly.
Agile teams do this by inviting all team members to speak up in retrospectives. They also invite team members to share any element that is impacting their work, even if this is interpersonal dynamics. We talk constructively and maturely about these items. Improving team performance requires candor. This can be difficult in organizations because typically what’s shared is limited by the perceived power gradient within that organization. People generally only share with powerful people the information they believe those people want to hear.
Many companies want to avoid discussing culture, so I talk about mindset instead. Do you have a fixed or growth mindset? A growth mindset in your employees will naturally create a culture of continual learning. That is what will enable success in today’s world.
Achieving this requires that people feel comfortable speaking up. Leaders must provide psychological safety so people can share information without fear of repercussions. You do this by being aware of this phenomenon, by acknowledging your own mistakes, and by being open to ideas that differ from your own. In my experience, this takes time to build, so you need to be patient. For some of my projects, it has taken six or seven retrospectives before the team learns it is safe to be candid.
If you are waiting to do retrospectives until the end of your project, don’t bother. Instead, establish a routine and safe forum to get regular inputs from your team members. Regular retrospectives will generate real learning from IT projects.
[ Culture change is the hardest part of transformation. Get the eBook: Teaching an elephant to dance. ]