The Other Side of Agile: Ceremonial Development
Every so often, I come across developers that are skeptical of Agile Development. I’ve worked in a lot of different teams and generally found that being Agile means different things to different teams. And thats fine.
To a lot of developers, ‘being Agile’ has become synonymous with ceremonial checklist items such as using modern source control, code reviews, writing user stories, doing standup meetings, pair programming, test-driven development, continuous integration, effort meetings and retrospectives.
All these things are good practices, but as time drags on, I wonder if programmers collectively have forgotten what the Agile movement is all about.
Exhibit A: The Agile Manifesto
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
As you can see, ironically, the Agile Manifesto is very simple. Good Agile practices are much more in the spirit of Kaizen and continuous improvement, as opposed to the sterile doctor prescription of do’s and don’ts that most people associate with Agile.
And when I come to realize it, the most successful teams that I’ve worked with have excelled exactly at this — responding and adapting to change. These teams were great at what they did because they had mechanisms in place for the team to continuously improve its own delivery. Truth be told, they weren’t always great because of their code reviews. Or pair-programming. Or Stand-up meetings. Or user stories. These things were sometimes very important in the delivery, but once something becomes routine, it can be hard to take a step back and evaluate if it is still delivering on its value proposition. If you fail to identify and switch out the things that don’t work, then you end up with exactly the type of process-heavy work-flow that the Agile manifesto cautions against.
House Remedies
What all of this has taught me is that it is important to realize that different circumstances warrant different remedies and that nothing is written in stone. As a team grows, improving software delivery can mean adding or removing processes/practices and being Agile is truly nothing more than being nimble and adapting to change, and above all: to never stop questioning if you can do better.
I hope I’m not alone in this, but I believe the first ceremony item on every Agile team’s list should be the retrospective. It’s the one thing that should always happen, no matter what, because it is what makes continuous improvement possible. A successful retrospective meeting will give your team an opportunity to vent and voice any concerns they may have regarding the delivery and is really a topic for a whole article in itself.
You’d be surprised to find out the ‘soft’ nature of the things that come up in retrospective meetings. Maybe the fluorescent lights in the office are straining the eyes when staring at the screen for hours. Or that the team is feeling uncertainty about product release dates. Or that stories arrive to them incomplete. Many of these things can be hard to develop into rigid foolproof processes, but are easy for a team to fix once they are voiced.
Adopting this one practice into the fabric and culture of your team will help you unlock so many tangential benefits and help steer your development process and practices in the right direction. So all in all, to people that have given up, I would say that Agile isn’t so much about where you are today. It is more about having a process in place that can ensure that you keep evolving your team to become a better version of itself, one iteration at a time.
