Confused Agile
Could a Scrum Master(or team of Scrum Masters) be successful at an Agile transformation by applying a waterfall-ish CMMi compliant document first approach? The reason I ask this question is because I see that in most of these transformations( at least here in India), the intention is to implement a “scrum process with best practices” than anything else, unfortunately.
There are animated discussions on this in various forums, with some suggesting how Agile is bound to be a failure given the Cultural roots in India (too early to say in my humble opinion, so I’d take the time will tell approach on that part); while others saying essentially most technology firms are large IT services corporations so they have to be sure governance and processes are put in place to control quality than letting things spiral out of control.
I’d like to answer these with a simple story of team that went about in their search for a “best fit Scrum Process” for their origination. The team in focus here is from an organisation which over the years has matured itself on heavyweight processes defined, documented, version controlled over a huge repository, that define a sort of operating manual for every aspect or project delivery, and all possible contingencies. There are process with thousands of forms if not millions. Going by that one could argue a developer had to fill up more ‘lines in form’ than the ‘lines of code’ he/she could write.
They started with a project plan for the Agile transformation of one of the smaller teams, the Agile transformation here had more to do with practicing Scrum than being Agile. Their develpment process had waterfallish specific phases each of which had to go through a thorough and verbose service tickets life cycle, os now it was imperative to have these things in place before a sprint could close, which basically meant everything from Sprint planning to daily standups and retrospecitives themselves had to be documented on wiki, and had their own quality managment parameters.
Imagine a sprint with all of this, yes you guessed it right, 2 weeks wasn’t just enough to get things done! so it was increased to 3 weeks, but then no one wanted to accept what the additional week really is for so teams would end up estimating for 70% of those 3 weeks for their work, rest of documentation and other related stuff, which as you could rightly guess again brought about teams missing committment. Quite natually that “Ideal Scrum Process” still hasn’t seen the light of the day and teams are increasingly fatigued with the notion of Agile now.
I have a lot more examples of how countless man hours were put into the futile exercise of fitting processes as they were into the Scrum Process and yet they all lead to nothing, but this post is not about that rant.
So how did they end up here? To answer in lines of the initial context on where I see most organisations go wrong with Agile, and this has got nothing to do with Cultural Roots or nature of Business as some would like you all to believe, is the failure to realise or acknowledge that the way quality, softwre engineering and testing is looked at also needs transformation not just the daily operational manual being moved to Scrum.This is imperative to get teams into a pragmatic (I’d even say realistic or achievable) sort of Scrum “rythm” not “process”.
I’ve always said Agile is Cultural & Behavioural thing, which means we have to truly understand both the power of small batches and how to work incrementally through iterations to really get into anythig Agile.
The problem here was the inability to unlearn running obtrusive governance. I’d also however agree it is all easier said than done but this is where I’d expect the Scrum Master to step in coach the managers about rethinking how to manage quality in short burst of iterative incremental cycles.
On the engineering front we have practices such as TDD ( Test Driven Development ), we also have thanks to the Mr. Hudson (see here) the abiity to scan all code and pint out potential issues based on a pre-agreed set of rules, and the amazing automation of our end to tests through tools like selenium for that matter, all of which could run in continuous cycles to avoid bloated quality checks.
In other words ask yourself at everystep “Am I enabling finding a needle in a small box or a hay stack?” and move as far away form the needle in haystack as much as possible.
Talking about Scrum itself, most of us have come to realise that at the heart of it scrum is a Continuous Learning and improvement framework, which relies heavily on self organisation to mitigate bloated governance conrols and hence increase throughput of execution while reducing management overheads. What this means is that you have to do small changes one at a time and study their effects to see what works, create a mechanism of repeating things that have worked well until they become a habit and move to next improvement, that’s al that there is to Scrum process if we are hell bent to find one.
Originally published at https://www.anadimisra.com on February 10, 2008.
