Are we Agilists in danger of making the perfect the enemy of the good?

Leave a reply

perfectOver the last year or so I have had lots of good robust discussions with other Agile coaches and one thing started to worry me. I heard “But that is not Agile” or “But that is not REAL DevOps” more and more frequently. While I agree that we should always strive for better and better performance, the absolutes seem to me counterproductive. Two topics close to my heart seem to cause this kind of reaction more often than others.

 

SAFe – The Scaled Agile Framework
There is lots of discussion on the internet about SAFe and why it is or why it is not really that Agile. Most organisations that I talk to are nowhere close to the maturity that you assume when you see the SAFe framework. I am sure that there are companies who are further down their Agile path and think that SAFe is very restrictive and old-school. I have to say that most people I talk to would be extremely happy if they could achieve the Agility that SAFe can provide. And it is a framework after all, a bit like a scaffold that you can use to move forward from the old waterfall ways into a more Agile enterprise without throwing everything out. And yes once you think that SAFe is not challenging your organisations and you see opportunities to become even more effective go ahead – push yourself further. For now I quite happy to use the SAFe framework within large organisations to help me speak a language my clients understand and to push them a bit further on their journey. I will have to admit that probably have not spent enough time with the other scaled agile ideas to judge them all – and perhaps writing this blog can be a motivation to do that. For now SAFe is my go-to framework of choice and even those who argue it’s not really Agile, I think even those would agree that many organisations would be more Agile if they had implemented SAFe than they are now – and that’s good enough: For now!

DevOps
So many organisations and projects I encounter do not have the right technical practices in place that allows them to deliver solutions effectively. Practices like Configuration Management, Automation of Build, Deployment and Test, and Environment Management I think belong under the big headline of DevOps. So when I then talk about DevOps practices with peers at conferences and describe that in large organisations I often recommend a DevOps team to start with, I hear “But that is not what DevOps is about”. The so often quoted cultural barriers between Operations and Development in large organisations makes it simply impossible in my view to embedd an operations guys in each development team. And to be honest there are often many more development teams than operations folks who could be embedded. So why wouldn’t I then create a team with representation from both sides to begin with and to get the best guys into that team to solve the difficult technical problems. After all that what Google has done with their Engineering Tools team. I think that is a valid step and yes perhaps afterwards we push this further, but for now most organisations that I have been working with can gain a lot from good practices being implemented through a DevOps team. Having a DevOps team does not mean we don’t want to change the culture, it just means we want to do this one step at a time.

Picture: Perfect by Bruce Berrien
taken from https://www.flickr.com/photos/bruceberrien/with/384207390/
under Creative Commons license

If software delivery is not a factory – what is it?

3 Replies

After posting my first blog I had a discussion with a friend of mine who is an Agile coach. He asked the obvious question: “Mirco, if you think it is not a factory anymore, what is it then?”.

Studio_AaltoNow that caused me to pause, but after a moment I remembered a discussion panel at a conference I attended. The topic was “Software Delivery Metrics” and the whole room was looking for answers on how to measure the effectiveness of software delivery teams or the even more elusive productivity. The discussion went around and around in circles and while I was hoping to get some good answers there was none to be had. People were talking about business outcomes and customer and employee satisfaction – which I agree with but are difficult to measure and to determine cause and effect. Before giving up I threw the following analogy in the room: “So what you are saying is that software delivery is like marketing? When you run a campaign and everyone is happy with the campaign and the product sells more than you consider yourself successful with your marketing campaign. But you don’t know whether your campaign was successful or whether your competitor did something stupid, and you don’t know whether there would have been a more productive way to deliver the campaign” – so perhaps software delivery is not a factory anymore, it is a studio (like a marketing or design studio).

Now this analogy might not be perfect either and I am sure some marketing buffs out there will tell me that marketing is very measurable. Especially if you consider the abilities that came with A/B testing in online marketing, but hey its closer to the truth than the factory model is.

I will close with a quote from John Wanamaker:

“Half the money I spend on advertising is wasted; the trouble is I don’t know which half”

– I leave it to you to see what this means for software delivery.

Picture for this post:
Studio Aalto, by Pepechibiryu, available from: http://en.wikipedia.org/wiki/Alvar_Aalto#mediaviewer/File:Studio_Aalto.jpg
License: CC BY-SA 3.0 

Welcome to Not A Factory Anymore

1 Reply

Hi everyone,

this is my first blog post. Yes I have finally made the leap into the blogosphere. Over time I will blog here about software delivery, agile, DevOps, Continuous Delivery and anything else that grabs my attention.

But first things first: Why ‘Not a factory anymore’?

I think many of us have heard over time the analogy of Software Delivery with a factory. In my mind that analogy is not accurate anymore and sends the wrong image. Software is not being produced, it is being created, it’s a creative process.

On my blog I will share with you my thoughts on everything that I think shows why the factory model is not appropriate and giving this blog that name leaves no doubt in the reader’s mind, where my allegiance lies in regards to how software based solutions should be delivered.

Looking forward to engage with the community via this blog and to see you around at conferences and meetups