Constant feedback cycles are the key ingredient to continuous improvement.
This is the third in a series of posts about building great software using agile techniques. The series started here.
Perhaps the biggest mistake software development teams make when adopting an agile approach like Scrum or Kanban is assuming they can lay out the perfect process from the start. They want to implement a set of rules or best practices ( …cringe… ) and get started.
It’s only natural. If your current development process is failing, you get excited about trying a new approach. You want to get it right. You want to succeed. That’s great! Enthusiasm is a wonderful trait.
… but …
Agile approaches to software development are not prescriptive. They don’t come with rule books. There are guidelines and recommendations but few “…you must do this…” or “…you can’t do that…” statements. A major part of being agile is the ability to adapt over time. The approach you choose will be simple in principle and must be adapted to your situation — once you get going.
Start somewhere, anywhere. Do something, anything. Learn and adapt as you go. That’s agility.
Approaches like Scrum and Kanban appear to be inherently simple. They are easy to learn and can be implemented quickly. You’ll need to add complexity as you adapt your chosen approach to your situation. The key is to get started with a simple model, then learn and adapt rapidly and continuously.
Agile teams must define a feedback loop. (Yes, that’s a rule!) They have to record everything. I don’t mean writing formal documentation for every activity. I simply mean informally gathering information that the team can discuss and use to improve their efforts. These feedback discussions need to happen often — usually at the end of each sprint (though I wouldn’t wait more than a month between them even if they occur in mid-sprint).
The best method we have for achieving good feedback and continuous improvement is the retrospective meeting. This may be one of the most under-used aspects of agile development. It’s not easy have an open and frank discussion with your teammates about what happened — why was a defect missed or how did a requirement get dropped — but it’s the best way to prevent adverse events from happening again.
I won’t go into detail on how to conduct retrospectives as much has already been written about the topic. Essentially, you want to ask questions like:
- What is going well?
- What isn’t going so well?
- What should we continue doing?
- What should we do more of?
- What should we do less of?
- What should we start doing?
- What should we stop doing?
- What should we track and measure?
- What can we stop tracking and measuring?
- Who can help us do better?
- What skills are we missing on the team?
You get the idea. Keep it simple and impersonal. Always keep Norm Kerth’s Retrospective Prime Directive in mind.
“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”
Today’s enterprise businesses change faster than ever. Even if it was possible to derive the perfect development approach for your team, in six months — twelve at the most — it will break. Don’t wait for your process to break. Keep learning and adapting.
[The next post in this series is here.]