Updated: Updated: Transformation
This the last part of my mini-series on Agile delivery in enterprises:
- Part 1 - Agile and Architecture: Friend, not Foe
- Part 2 - Agile Is the Steering Wheel, Not the Gas Pedal
- Part 3 - Conversation stopper: IT Should Become Agile
As before, I am not looking to get into the middle of the heated debates about the different interpretations and factions but of the Agile movement. Rather, I am looking to remind folks to not lose sight of the basic ideas and mechanisms behind the Agile movement, which all too often go under in the heat of the daily enterprise struggle.
Enterprise Discipline
Readers frequently comment on the little gems or pointed statements hidden in my book The Software Architect Elevator. One such statement that was picked up by am astute reader who shared it on Twitter, was:
Corporate environments often lack the discipline to implement Agile processes.
The chapter containing this little zinger is aptly named “Slow Chaos Is Not Order.” The title plays off the fact that established organizations believe that their processes provide them with structure and decision discipline. The reality is, things are in utter chaos, it’s just so slow moving that hardly anyone notices.
The simple and pointed slogan leads us to two important insights:
Moving Fast Needs Discipline
Fast-moving things can always look a little chaotic but are in fact often the most disciplined processes. My favorite example is an F1 pit stop. At first sight, you can’t even quite figure exactly what happened, but within 3 seconds, a car received four new tires, has its aerodynamic trimmed, and in the old days was even fueled up. Once you look more closely, you realize that this is made possible only by relentless practice and discipline. Every single move has been practiced umpteen times and each person in the team (I counted 18 active team members and a few more taking time or standing by) has an exact role to play. I once got to try my luck at changing a tire at the BMW center in Munich and would surely not be hired for this job.
The same is true for Agile methods. Even though Agile isn’t just about speed, the agility stems from the ability to work in short iterations and quickly course correct as needed. This is possible because teams follow a relatively rigid process of stand-up meetings and sprint planning sessions. They also use modern software delivery techniques like high levels of automation and test-driven development. That’s equally sensible to wearing a fire-retardant suit and a helmet during the pit stop. No one would want to freelance that one.
Most Enterprise = Low Discipline
Most enterprises consider themselves highly disciplined - think of all the processes, standards, and steering committees! Unfortunately, that discipline largely lives on paper - in reality most enterprises run a vibrant black market (see The Software Architect Elevator), which is often the only way to get anything done. Also, decisions ranging into the millions of dollars are often evaluated more on compliance with presentation templates than on a deep analysis of the available options and their implications. These realities gave the chapter its name—it is indeed chaos, just very slow moving.
Lack of discipline is often the result of (past) success. If money comes by easily and the market lead is substantial, lack of spend and decision discipline isn’t going to hurt the organization all that much. It’s when disruption comes knocking on the door that the lack of discipline becomes a major problem.
Undisciplined Non-Agile
And that’s why we talk about many large organizations lacking the discipline to be agile. When these organizations do embark on an agile journey, they likely end up in one of two scenarios:
- They continue to move slowly and aren’t actually agile
- They try to work in sprints but lack the discipline to make the method work
It’s needless to say that both scenarios are unlikely to deliver the anticipated results. As sad as the prevalence of “Agile by label only” is, it might actually keep enterprises on the safe side as it doesn’t require any discipline. So, undisciplined non-Agile might be better than undisciplined Agile.
Increasing Enterprise Discipline
The real question, of course, should be how we increase the discipline in large organizations. Sadly, traditional IT shops might resort to more of the illusions they have applied in the past: “let’s set up more steering committees and tighter standards!” Yeah, right…
Instead, let me share a few ideas that are more likely to bring discipline:
1. Increase Transparency
My favorite topic in large IT organizations is the lack of transparency. Another pointed line in my book highlights that traditional enterprises only trust what’s on a slide whereas digital companies trust anything but. Looking at real data such as velocity, burn rate, provisioning times, time to feature delivery etc. will bring better decision discipline as handwaving and watermelon status reports take a back seat.
2. Think in the First Derivative
Absolute values often tell only half the story. “The servers are running at 60% CPU utilization” - is that a problem? That’s hard to tell without knowing the trend. If that’s a steady state it may be alright and actually very good hardware utilization. If it was 50% 5 minutes ago and 40% 5 minutes before then, you might want to have another look. The same is true for projects: the best metrics are the ones that give you value and consumption over time such as burn rate and feature velocity.
Side note: As an architect I have become so used to this thinking that I run the risk of annoying people. When I was looking to make an international shipment of course I want to know the price elasticity, i.e. how much more will it cost per cubic meter or kg more? That’ll determine how carefully I pack or select. However, most places need me to provide a fixed parameters so they can give me a single magic number. For folks working with cloud this can be frustrating and difficult to explain to others.
3. Ban the Hourglass
As discussed in my book Cloud Strategy, too many IT presentations suffer from the hourglass effect: they start with a lot of buzzwords and promises, then get rather vague, and end with a major budget and headcount request. It goes without saying that the middle part is the most interesting one, so instead of reviewing for formatting, any IT decision presentations should be tested for this antipattern. Better yet, use written documents instead of slides, akin to Amazon’s battle-proven approach of writing narratives.
4. Use Models
Decision models are a great way to improve decision discipline. Good models are simple and evocative—they bring clarity, not confusion. Most IT selections fall back on a model that’s rather the opposite, the product fitness scoring matrix. You’ll be looking at an endless list of difficult to decipher line items, which is summarized by “84.6”. We presume 84.6 is better than 50, but is it really better than 80? And, especially, what stands behind the differences between the scores? Am I ranking a car without radio against one without air conditioning?
At Singapore GovTech, using a handful of simple models during decision meetings had a significant positive impact on elevating our discussions while at the same time deepening our thinking—see my LinkedIn Post.
5. If It’s Too Complicated, It’s a “No”
Lastly, I am a firm follower of the Feynman rule “if you can’t explain something in simple terms, you don’t understand it.” IT is plenty complex and the decisions we need to make often involve tens of millions of dollars and bear substantial risks. So, it’s our job to reduce the complexity without losing the essence of the situation we are facing. Good architects do this well (see my earlier blog post, Architects Zoom In and Out, See Different Things).
Going Agile? Bring Some Discipline!
Organizations can increase decision and execution discipline in several ways. So, next time someone touts the Agile panacea, remind them to bring some discipline first. Speed, agility, and sloppiness don’t mix.
Make More Impact as an Architect
The Software Architect Elevator helps architects and IT professionals to take their role to the next level. By sharing the real-life journey of a chief architect, it shows how to influence organizations at the intersection of business and technology. Buy it on Amazon US, Amazon UK, Amazon Europe
