Tag Archives: Kaizen

Is Scrum serving your Software Development, or the other way round ?

There was a question on the group Scrum Practitioners on LinkedIn if “…implementing Scrum as a whole should be our goal or would you use aspects of the Scrum methodology to realise an agile culture change ?”

Looking at the disproportionately large number (with an increasing trend) of posts on popular mailing lists on Scrum and Agile software development, I am alarmed that most energy and thought is being spent on figuring out “how Agile you are”, how should the user stories be worded, and whether one uses planning poker or not ? I mean…does it really matter whether you use ‘deal hours’ or ‘story points’ whatever that means ? If your team members are not speaking out ‘impediments’ in daily scrum…come on…that was the case in good old days also…expecting that Scrumifying the process will make everyone speak up honestly, do their job on-time and love thy neighbors is little too much of wishful thinking in my honest, brutal and uncharitable view. 

Scrum exists to serve its master, which is Software Development and not the other way round. So, implementing Scrum can never be the goal by itself (isn’t that where we went wrong with the CMMs and the ISO9000s of the world ?). Timely delivery of on-specs and high-quality software is almost always the goal. Anything that helps in that direction is a only a means towards that goal.

I would take whatever is applicable and makes sense to MY business situation – which is a unique combination of:

  • my organizational maturity +
  • organizational culture +
  • type of problem being solved +
  • management style +
  • … +
  • another one hundred and one reasons that must be analyzed before prescribing a one-size-fit-all solution.

To that end, I will not stop at Scrum but explore other Agile methods, Six Sigma practices, Lean principles, Kaizen philosophy, TOC / Critical Chain..even borrow from CMM / CMMI and ISO…and…why not…the good old Waterfall (sometimes, the old wisdom is not so bad after all !)….just about anything under the sun that makes my business look better. In fact, for more complex problems, I might look up to other industries like construction, shipping, logistics, etc. to see how they solve such problems and learn from there. After all, my business is far more important than an academic satisfaction of having implemented a one hundred percent bookish definition of Scrum without knowing whether it is working for me or not, and completely depriving myself an opportunity to know if there are better ways to solve my problems.

Scrum doesn’t have the monopoly over good software development practices. If we all started blindly following Scrum in toto, there won’t be any better solutions to newer problems. There must be a healthy effort to question Scrum practices and make continuous improvements in it instead of treating it like holy scriptures which can’t be challenged.

My prescription for myScrum test would not to measure it by inputs (i.e., do you do 2 week or 4 week sprints, are your specification complete before the next iteration, etc.) but as follows:

  1. Are your new practices improving employee motivation ?
  2. Are your new practices improving team productivity ?
  3. Is frequent software delivery improving customer satisfaction ?
  4. Are you able to accommodate late requirements with increasing ease ?

I think if you can answer all of these questions in affirmative, you have a winner in your lap – doesn’t matter if it doesn’t measure up to the ‘stringent’ criteria of Nokia Test or some other activity-based assessment of your software development religion. You don’t even need to call it Agile or Scrum…just call it Photosynthesis, Metamorphism, Evolution, Oxidation…whatever you feel like…after all, your Scrum should serve your software development needs, rather than you serving Scrum.

Is Scrum serving your Software Development needs, or the other way round ?