Could a Scrum Master(or team of Scrum Masters) be successful at an Agile transformation by applying a waterfall-ish CMMI, document first approach? The reason I ask this question is because I see that in most of these transformations, the intention is to implement a “scrum process with best practices” than anything else, unfortunately.
There are animated discussions about 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 argument); while others saying 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 address all such arguments with story of team that went about in their search for a “best fit Scrum Process” for their organization. The team in focus here is from an organization which over the years has matured itself on heavyweight processes defined, documented, version controlled in a vast repository, that define an operating manual for every aspect of project delivery, and all possible contingencies. There are hundreds of forms if not thousands for managing any change or service request in course of development, testing, release management and production operations. 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.
Thee team 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 development process had waterfall-ish specific phases each of which had to go through a thorough and verbose service tickets life cycle, so now it was imperative to have these things in place before a sprint could close, which also meant everything from Sprint planning to daily stand-ups and retrospecitives themselves had to be documented on wiki, and had their own quality management parameters.
Imagine a sprint with all of this; yes you guessed it right, 2 weeks wasn’t just enough to get things done! so sprint duration was increased to 3 weeks. Sadly enough, no one wanted to accept what the additional week really is for so teams would end up estimating for most of those 3 weeks for their work, not factoring documentation and other related stuff as it was never estimated in the pre-Scrum days (and things worked for us earlier without having to estimate this effort argument was enough to convince all). Which, as you must have rightly guessed again, led to teams missing commitment. Quite naturally 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 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.
How did they end up here? To answer in lines of the initial context of this blog, where I see most organizations 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 realize or acknowledge that the way quality, software 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 “rhythm” 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 anything Agile.
The problem therefore in most organization making the transition is the inability to unlearn their existing conventions, norms and processes 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 (now Jenkins) the ability to scan all code and pint out potential issues based on a set of rules, and the amazing automation of end to end tests from UI 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 every step “Am I 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 realize that at the heart of it scrum is a Continuous learning and improvement framework, which relies heavily on self organization to mitigate bloated governance controls 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 all that there is to Scrum process if we are hell bent to find one.
I hope we see more conviction in scrum masters in near future and a bit of appetite to unlearn in the management if the Agile wave is to make any sense.