Every company moving from a primarily waterfall-driven process to an agile mindset has a transitional period. It’s inevitable. This transitional period is usually punctuated by confusion, anger and a lot of mistakes with the self-appointed company agile aficionado screaming “Don’t panic! This is how it’s supposed to work!”.
This period will end in one of two ways.
The first is that the company successfully embraces an agile mindset and everyone is happy and lives the dream that they were promised with post-it notes coming out the wazoo and whiteboards dotting the landscape.
The second is a protracted period of what has been dubbed “Agile Theatre”. This is a ritualistic, cargo-cult-esque implementation of agile thinking with either some waterfall thrown in to fill the gap or just a gap filled with a simmering layer of chaos.
This is not better. This is worse than what you had before.
At best, this is just waterfall with standups and a trello board. This is not particularly damaging but it’s definitely a waste of everyone’s time.
At worst, you’ve removed all the safeguards of waterfall and inherited all of the risk which will eventually end with some serious conversations with men in suits.
Let’s have a quick look at the four principles expressed in the Agile Manifesto:
You can’t remove the “processes and tools” unless you’re serious about the individuals and interactions. How are you forming your teams? Are they cross-functional? Are problems swarmed or are project areas siloed to individuals?
Does the software actually work? Is it fully tested with a comprehensive suite of automated tests? This is not just about discarding the need for documentation. Documentation is good. This is about shipping working and fully tested software without regard for whether or not it is fully documented yet.
Is your customer actually collaborating? Do you meet regularly and discuss changes? Discarding rigorous contractual negotiation without a clear replacement might be the most dangerous thing your business ever does.
Is your costing structure configured in a way that allows the customer to change their mind? Could they end the contract early if their needs are met? Does the customer have a realistic set of expectations of what will be delivered (maybe something radically different to what they originally envisioned?).
If you’re wondering what the god-damn point of these “rituals” that you’re doing everyday, maybe take a step back and wonder if it’s all just for show.
If you liked this article please remember to give it some applause to make sure more people get to read it!
Steven Poulton is a web developer and technical architect living in Manchester, England. In his spare time he likes to make indie music, make indie games and play with his indie cats.