Continuous Improvement – Gravy train of excuses?

I wrote this in 2012, originally published on my old site before GoDaddy killed it by mistake, and reviewing my drafts I thought I’d add a small update about the debacle that is SaFE and then publish it again. I’ve even left in parts that have now evolved, but it is a good reference point to my own thoughts chronologically.

Why was I attracted to Agile back in the day? Scrum / XP simple, lightweight, seamless process frameworks that were transparent and gave everyone what they wanted. That was 7-8 years ago for me.

Move in 2012 and I can’t help but feel that Agile is on a collision course that I’m no longer 100% happy about.
Roll on 2013/14 and then there’s SaFE, which is unbelievably one of the worst things to happen to Agile, I’ve just finished working for one of the largest SaFE transformations on the planet and I can certain with 100% certainity that SaFE is not Agile, it is butchered Agile utilising lots of practices and processes of the very world we have been trying to get away from (i.e. heavy documentation, heavy over bloated processes, lots of demarcation with less emphasis on promoting collaborative working, etc…). I will be writting an extensive blog on my experiences on SaFE, and why I turned down the chance to become SaFE certified.
Instead of being lightweight we’ve ‘bolted-on’ loads of additional ‘improvements’, instead of being simple, we have over complicated it. And we’ve even given it a badge; Continuous Improvement (you’ll often hear people follow up with lines like; ‘The pace of change’, ‘maintaining a healthy rate of change’, etc…). If you want to impress at an interview go on about CI, in truth its pretty hollow. Change for the sake of change is absolutely pointless, and often is used to cover up failings of either the individuals or team.
Don’t get me wrong, I’m very, very vocal about evolving your Agile model so that it fits your team like a glove, never stop evolving, just STOP making pointless, unjustifiable changes for the sake of change!!!! It may a good sound bite, but be real.

My next statement may not make me the most popular, but we’ve handed Agile back to the very people who we complained about prior to Agile; Project Managers with charts, metrics, creators of complex processes to justify their existence and to the analysts who over analysis the model and seek to help the Project Managers over complicate the model.

So what can be done, I thought I’d never say this, hand it back to IT. I am a 110% believer that everything should be business orientated, that the customer is king, BUT now I believe that the process that started out from IT should be returned to IT, instead of the business taking control and bastardising Agile to fit within their pre-existing broken models.  I could imagine a number senior managers having the following conversation over the last few years;

Senior person A
‘The development team seem to be doing OK these days, the other departments seem happier with them’

Senior person B
‘Yes, they do. Its this Rugby thing thing their doing, whats it called again…? Tackle, pack…?’

Senior person A
‘I’ve heard them mention Scrum.’

Senior person B
‘They’ve done well so far, but I think they need us to take over now, its started well, we don’t want them to ruin it now do we.’

Senior person A
‘Your right, we could improve it, IT don’t really understand the needs of the business. They need governance, tighter management, this empowered, collaborative approach may work for them, but what about the most important views, our views above all others. I from the golf course am the voice of our customer’.

Senior person B
‘We’ll add in the metrics, firm up the fringe processes and make it better, strong governance is what they need!’

Its ultimately a break down in the collaboration between the business and IT that has caused this. Obviously I make the assumption that your IT department led the original Agile implementation and that your genuine Agile coaches reside there instead of inside of your business, but if you do have coaches working within the business space and the business is still not behaving accordingly, question the caliber of your coach or more than likely the environment and constraints you’ve put on your coach which reduces their effectiveness.

I applaud all of my fellow Agile minded people, don’t over complicate your Agile model, make it simple and seamless, let your teams feel the benefits of not having to spend hours / days on pointless ‘value-less’ tasks or generating graphs for the sake of it, if your management isn’t confident before a gnant chart won’t improve that confidence, only delivering can and how can you achieve this when your busy generating tasks? Or making pointless changes to your model? Don’t hide behind Continuous Improvement as an excuse for failing.

Back to Top
Have a chat with us
We use cookies in order to give you the best possible experience on our website. By continuing to use this site, you agree to our use of cookies.