There’s more to being Agile than just blindly following the rules and processes of any specific methodology. One of the core components of effective Agile practice is internalizing the concept of continuous improvement. As I’ve touched on in other articles, Agile is a direct descendant of the concepts originating in the lean manufacturing movements of the late 1940s and early 1950s. And the single most important part of this ancestry is the focus on empowering and entrusting the people who do the work with setting their own destiny and with challenging each other to improve their practices on a regular basis.
Retrospection is For Improvement
One of the biggest mistakes that I see teams make in their Agile transformation is their unwillingness to actively and actually engage in proper retrospection. They have the meeting, they take the notes, they all nod their heads when reviewing the items brought up in the discussion…but that’s it. There’s no follow-up, there’s no follow-through, there’s no action planned for the next sprint. It’s a ceremony without true purpose, the truest form of a cargo cult mentality — checking the box that the ceremony is there, but only as a hollow shell of what it can and should be. The entire point of doing retrospection is so that the team can plan out ways to improve what they do — together, as a team. But when process is “determined” by management and handed down to the team, or when plans are made and delivered to the team as a fait accompli, or when teams have no effective means of feedback that actually results in change, then you’re not really being Agile. You need to trust your teams to understand their own strengths and weaknesses, and to work together to create plans to shore up those weaknesses in whatever way they think is best.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Self-Directed Teams Decide Their Own Future
When we don’t trust our teams to decide their own fates, we are engaging in one of the most pernicious anti-patterns that exist in Agile development, and in doing so we’re hamstringing everything that we do from that point forward. We might as well just be doing waterfall development, because when teams aren’t empowered to help themselves, to improve themselves, to experiment and try new things, they’re not being Agile. More often than not, this boils down to a simple lack of trust — lack of trust in the team, lack of trust in the individuals, and lack of trust in the Agile philosophy itself. Management needs to understand and accept that embracing Agile as a culture means letting go of the kinds of command-and-control authority that they’ve relied on for far too long. The role of management in Agile is one of facilitation and removing blockages — it’s not one of telling people what to do or how to do it. Self-motivated, self-driven, and self-directed teams are more dedicated, more energized, and best capable of determining when, how, and what needs to change for them to do more, better, and faster.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Scrum is a Starting Point
I know I’ve said this before, but it bears repeating — Scrum is a great pattern to begin your Agile journey by embracing in its totality. Not just in the what, but also in the why — otherwise you’re just another cargo cult Agile shop. It is not, however, the be-all, end-all, silver bullet solution to any of your development problems. And you should be very leery of anyone who tries to sell you on it being that — there’s a gigantic market out there of Agile “consultants” who do nothing more than swear on the Scrum Bible and tell you that any other idea is heretical and anti-Agile (the irony being, by simply making such a statement they are themselves what they claim to be helping you avoid). There is absolutely value in having a set structure with prescribed and proscribed practices to implement when you’re uncertain of what you’re doing, or sometimes even what your end goal truly is. But, once you’ve got those practices established, once you’re holding your ceremonies on a regular basis, once your teams have actually started to internalize the values of Agile development, it’s time to consider taking off those training wheels. It’s time to seriously engage with your teams and help them to determine what will work best for them — maybe they want to have standups twice a week instead of every day, maybe they want to do standups over Slack or email, maybe they want to try 3-week sprints or 1-week sprints. Whatever they want to do, as long as it’s with the intent of improving, should be permissible. Experimentation is how we improve — and if it doesn’t work, we’ve learned a valuable lesson and can try something else. Don’t think that just because you’ve started with Scrum, that’s what you have to continue to do until the end of time. Agility is about adjustment, improvement, and tossing out whatever causes waste and trying something new to make things better.
Individuals and interactions over processes and tools.
