DevOps. SAFe. Scrum. Kanban. Did you shiver? The experts have you scared you’re doing it wrong (you know, IT – all of IT). The certificate-teachers need you to need them so they can get paid. The coaches and consultants are taxing your #FOMO (Fear Of Missing Out) on ALL THE AGILE.
Get. Real.
It’s an impossible dream: The perfectly lean and agile software process would be just one person – a masterful engineer with great people skills and business acumen who can hang around a group of people to see what troubles them, create an intuitive software tool that relieves the pain, and collect cash from them while obtaining ultra-constructive feedback. In other words “dev” and “ops” as one person.
Ever seen that happen?
That said, every additional person involved in the flow of DevOps information is either a value-addition or a source of systemic waste. More often, everyone involved is a bit of both. As more bodies are thrown at a problem, it is likely any one of them can only spend 10-20% of their time actually adding value. The other 80% – and all overtime – is typically waste due to waiting on information from others, or over-documenting our value-add so others can consume it.
So it isn’t that IT won’t tell you the secret, if they know at all. It’s easy to crack jokes about how little other people accomplish despite working long hours, but less likely that anyone raises their hand and volunteers the truth about how much time is wasted.
– Waiting for clarification
– Waiting for updates to install
– Waiting for SVN code check-in
– Waiting for someone else to check their code, setup a VM, or answer what their code means
– Waiting for the next meeting
– Waiting for the inspiration to work on something meaningless to you
The great big DevOps secret is that no methodology will fix all that waiting. Over-specialization creates a world in which teams throw big piles of shit over the fence, each group speaking it’s own language that no other group understands. New philosophies won’t fix bad relationships, a toxic culture, and shit tools. It takes time, work, and fearless leadership.
Otherwise, Agile, Scrum, Kanban, and DevOps – or any other recipe for “when to meet” and “what to document” – are like 30-day fad diets; it’s a false hope and a gimmick and it doesn’t change the sedentary fast-food lifestyle that keeps you fat in the first place.
Keener Strategy 
Good point of view, thanks, hovewer I must say I don’t agree. I think mature attitude to all the Agile methods is to know their limitations. Like one of my favourite short notes shows, http://kanbantool.com/kanban-library/kanban-results/when-kanban-fails , for example Kanban sometimes fails. Like the whole Agile idea. Life is unpredictable, we’re unable to constrct methods that work in every condition. And, to me, treating the whole Agile idea as totally unuseful is an overuse.
Maya – Actually, I think you and I agree completely. It is dangerous to hop from RUP to Scrum to Kanban to SAFe or anything else if the underlying culture and relationships are maladaptive. This post alludes to lean process improvement as much as it does the various agile methods I’ve coached. The principle is the same: you cannot improve one process in isolation from the overall system that created that process.
Hi,
I have read your blog and I got very useful and knowledgeable information from your blog. It’s really a very nice article. You have done a great job. Thanks for sharing this article.