The number one question regarding Agile I get is this:
Can you send me some links, blogs, references on how we should do Agile?
Let’s ignore the fact I make my living doing Agile coaching and software development for a moment. Let’s also ignore the fact that you can’t learn to fly a plane by reading blog posts. Let’s also ignore the fact that there are countless reasons why one book/blog/video might not be the best solution for your situation. Every company is different and requires a custom approach to implementing a new management process. I mean that. Agile is a new management process. It requires focus, dedication, leadership, time, and money. There’s no switch you can flip to become Agile. It’s a process which needs experienced leadership for success. That being said, there is something you can do today which will help you. You can Start doing Agile with retrospectives.
A retrospective is not a post-mortem
A retrospective is not a post-mortem. A post-mortem is what you do after something has died. Maybe, the project failed or you lost a major client. That’s the time for a post-mortem. An exceptional event happened which needs focused analysis.
The Process
I do retrospectives every Friday toward the end of the day. It’s a look back at the past with an eye toward the future. The retrospective gives the team the opportunity to discuss two topics:
- What went well
- What needs improvement
This allows the entire team to discuss areas of success and areas of improvement. Once everyone has had a turn to give input and ask for specifics, everyone votes. Everyone gets one vote on the “what needs improvement” list. The top item, sometimes two, are taken.
I have a simple script I read before every Retrospective. I have it memorized now:
This is the retrospective. We are here to discuss how we work together as a team. The focus is on process and how we work together. It is not a re-cap of the work completed this week. Everyone will be asked to comment on two things. (1) What went well, and (2) What needs work. If you don’t have anything to say, you can say “pass”. Please don’t struggle to comment.
What that reminder out of the way. I call on the first person:
Me: Tom, what went well?
Tom: Ummmm…..
Me: If you don’t have anything you can say “pass”.
Tom: Pass
It’s inevitable.
Once we get through everyone, we get this.
– What went well
Communication
Improved velocity
Agile is working
– What needs improvement
Build server is broken
QA is over taxed b/c we get work to them late
Tommy is bored
Then we vote. Everyone who is part of the delivery team gets a vote. You usually wind up with a clear winner. If not, the scrum master breaks the tie. In this example, let’s pretend “Build server is broken” was the selected.
The outcome
The retrospective now has two final tasks:
- Agree to fix the problem
- Assignment of the resolver
Most of the time, the person responsible for resolving the issue is the scrum master or project manager. So, to fix the “Build server is broken” problem, the cause of the issues must be determined and appropriate action needs to be taken. This could include assigning new duties to a person. Maybe, Tommy? He seems to need something to do.
Final thoughts
The retrospective is the single most valuable Agile practice. It’s the vehicle which enables teams to grow and improve. Having a forum where team members can praise success, discuss issues, and agree to resolve those issues will dramatically increase team productivity and morale. They now become the owner of their process. You can call your management process whatever you want. But having retrospectives is simply a good management practice.
- Everything is a P1 - July 22, 2020
- The Danger of Agenda-less Meetings - April 21, 2020
- Strictly Agile - February 12, 2018