Are you actually changing?
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:
- Have you changed your meeting structure? Are there different things happening in your meetings than last year? Meetings are one of the core tools managers have. If you’re transforming how you’re working, your meetings should be changing too.
- How often do you tell middle management and staff what the goals and targets are? When is the last time you explained the organization’s strategy?
- Did you have to talk to HR to re-align your org to product team’s…or did you just matrix and dotted line the existing structure?
- What are three new features or business ideas that didn’t work as planned?
- How much tech debt do you feel you’re carrying?
- What are the top three impediments to developers releasing software more frequently? (What do the developers say?)
- How has the job of your enterprise architects changed?
- How do you discover what’s valuable to your business?
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:
- When you read about failure, ask yourself: would I have rather they tried nothing? Failure compared to what? What they were doing before?
- Did they get up and try something new? Did they try this thing they failed at in a mindful, disciplined process that allowed them to learn and try again?
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.
When in doubt, remember that “Ramble On” is a summary of The Hobbit. They also sang about vikings.
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.
We’ll be right back after this
June 25 - Kubernetes for Day 2: FedOps
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:
[Get one of my books for free]
- Software Defined Talk #241 - Ask more questions, send more one line emails: ‘Can email ever be fixed, or is GMail good enough? We discuss. Plus, Coté complains about how he should probably start asking more questions instead of answering them at length. Also, we don’t know what a “digestive” is and do not recommend the Mexican bakery pastries.’
- Check out Brandon’s interview with Brian Gracely.
Presentation: Rapidly Deliver the Software That Matters
Check out this recording of a recent talk of mine. It’s the latest rev of my stump speech, with some new material.
Try these things out
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.
From Doing Agile Right: Transformation Without Chaos.
Relevant to your interests
- Micromanagement, the optimistic description.
- Mandatory co-worker house visits - ‘I’ve heard an aggrieved sense of intrusion: Why do I have to let these people see my apartment? If you wouldn’t invite your coworkers over for a dinner party, why should you be expected to let them in virtually? ‘
- Curate your notes - ‘Update your index every day. It only takes me a few minutes, even for days where I’ve taken a lot of notes. For simplicity, I only index the quadrant where a note starts, just in case a single note takes up many quadrants.’
- Kubernetes is for running and upgrading applications - ‘At what level does Kubernetes become a sensible option for deploying an application? “If you assume Kubernetes is there to simplify the act of building and developing applications, that’s where a lot of people get hung up. Kubernetes is a really powerful tool for deploying and keeping applications running and letting you change them later,” said Coleman.... “It’s less about the size of the project than the individual.” The technology is for people “tired of reinventing the wheel,” he said. “It’s not going to be perfect, no software is, but I’m going to let Kubernetes deal with deployments, routes, splitting traffic across applications, put quota on my applications, and so on. That is the Kubernetes sweet spot, has always been.”’‘