Improving the way you do software - doing agile, DevOps, or whatever - is about changing. If everything is working fine, you don’t need to change. The teams working on software (“developers”) change how they organize and operate; the people who build and operate the software in production change how they organization and operate; the compliance people change how they organization and update. I’ve written up a lot of this in recent books.
Managers, leadership, executives, they do must change how they organize and operate. There’s some good ideas and tactics in a recent book, Doing Agile Right - a lot about framing up the old, Taylorian way of command and control into delegation and trust.
Are you actually changing how you manage? Here’s an incomplete list of questions to ask yourself:
These are all leading questions, of course. Another question would be: do you know what the “right” answers are, even if you don’t answer as such?
Unless you’re changing, you won’t be transforming and improving. Your business won’t get the benefits of doing modern application development and management if you’re operating the same, just with different words.
Make sure you’re asking questions like this constantly to ensure that not only your organization, but also you are changing. Nothing will change if you don’t change.
In his new book, John Dickerson points out that the phrase “the buck stops here” originally meant that the US President was the one who eventually makes the decision. They’re the lone person setup to finally say yes or no to an idea. They have to make a decision. They have to try things out.
That phrase has come to mean that responsibility always goes to the top (that shit and gold roll up hill, as it were). Originally, that was a side effect of the first. This is mostly used from blame: The Blame Stops here, the sign should now read.
The original phrase also has a bit of shade thrown at the peanut gallery: it’s easy to criticize and point out failures as an observer.
This is an especially hard problem for management that’s trying to improve how their organization does software, “transform” and all that. What us thought lords and ladies are telling them is that they need to take a more product-oriented approach, which means experimenting with what works and doesn’t work. That “doesn’t work” is the hard part.
People focus on the fact that you “failed” instead of how you learned and eventually succeeded at whatever your goal was, e.g., reducing costly call center volume (a very popular business goal), making a commercial kitchen run more efficiently to cut costs and raise profits, creating a better in-store experience, enter new markets to deliver on your revenue growth promises to Wall Street.
Each of those involves trying something new, and if you look through those case studies, you’ll see that there were fits and starts, “failures” along the way.
There are two things here:
You can also do some buck stops here’ing and say “well, what would I have done and how would I have managed hundreds of people doing it?” Most of this is peanut gallery shaming, but, learning from other’s people failure is very cheap and risk-free (you’re just risking that you spent your time poorly).
I don’t think most people in large organizations actually want to risk taking on the risk of innovating. Innovation is dangerous if you can’t absorb “failure.”
Nothing could be further from the truth. Successful innovation is a long journey through failure.
(People often, rightly so, tell me to avoid this framing. That’s fine: I’m framing it like this so that you can prepare yourself. Being a cynic, I find that if I expect negative things they pull me down less and I can learn from them. Call it “learning” if you prefer.)
Building, growing, and nurturing such a system is management’s job. If they fail at that, then there’s some blame to be doled out…perhaps.
Proposing that a rock band make songs like that would have fizzled out in strategic analysis. It was a big risk, and it paid off.
This should make you realize how capricious, convoluted, and delightful everything is, can be. Go out there and try something, and learn from it.
I’m doing a “fireside” webinar with Craig McLuckie on kubernetes and DevOps for US Federal IT people. I don’t think we’ll have slides, just some Q&A. Hopefully it’ll be like a podcast. Nonetheless, it is a webinar. If you can’t make the time (June 25th, Thursday, at noon Eastern/11am Austin time), register for it at the very least and you’ll get notified when the recording is up.
Also, as always:
Check out this recording of a recent talk of mine. It’s the latest rev of my stump speech, with some new material.
> The value of the metrics above is their ability to focus corrective actions on true constraints. There is always at least one constraint to further progress, but there are usually fewer constraints than most people imagine. Focusing on fixing problems that are not constraints will not improve throughput and is often a waste of time, money, and energy.
And, then, some actual things that might be problems:
> Agile itself offers so many ways to advance an agile transition with greater value and lower cost. Focus the fixes on the real bottlenecks. Get the leadership team to behave like an agile team. Clarify a common ambition. Not enough? Stop activities that customers don’t want and teams can’t deliver. Replace ineffective innovation groups with agile teams. Still not enough? Shift planning and budgeting to simpler processes at shorter intervals. Focus support and control functions on changing their business processes to better satisfy their internal customers. If the system is still unbalanced, provide more frequent feedback on performance. If these simpler solutions work, you may be able to pursue continuous improvements while postponing or avoiding some of the most expensive and painful solutions.... Change levers such as these essentially become the backlog of the agile leadership team.