I can still remember the pit in my stomach when Steve Jobs tried to quiet the complaints of the newly launched iPhone 4 (the first I ever owned). The smartphone giant came out with a brand new design of the device, which included a new radio antenna. Instead of doing a mea culpa (which came later, of course), Jobs responded with a line that would launch a thousand memes:
“You’re not holding it right.”
We laughed at it then. It’s still funny today.
Regardless of the industry, though, we all have our own version of the phrase. With conference season in full swing, I can guarantee a similar phrase will be repeated in conversations:
“That’s not Agile. You aren’t doing it right.”
Was reminded of this while reading a recent white paper released by UK consultancy 6point6. Included in the paper are the results of a survey of 300 US and UK CIOs. The numbers do not paint a pretty picture of Agile IT delivery, at least from the executive perspective.
- Over half of CIOs regard Agile development as “discredited” (53%).
- Three-quarters (75%) are no longer prepared to defend it.
- Almost three-quarters (73%) of CIOs think Agile IT has now become an industry in its own right.
- Half (50%) say they now think of Agile as “an IT fad”.
At first glance, those numbers shouldn’t surprise many of us. Many of today’s IT executives don’t have the day-to-day interaction with their teams. Agile transformation and coaching are just the latest in a long line of consultants at their door knocking for business.
They also don’t care how they get work delivered. Just that it does and often that’s the only success metric. If you combine that with the recent State of Agile survey, productivity is the only metric that probably matters. The line that did stick out to me was this:
“In many ways, Agile was a reaction against the very forces that are now testing its limits.”
What are these forces? Can we look at these currents stated in the survey and explore the concept of improving how we work with executives?
CIOs Expect Quick Wins. Really Quick.
The average length of tenure for today’s CIO is 14 months, according to the survey. Granted, the paper does not list how many are fired and how many voluntarily leave. It does not give the exec much time to make an impact, though.
If the HBR articles and countless books promising quick wins of Agile are to be believed, this points to why companies are “buying Agile” for organizations.
Many of my friends might point to poor expectations of early evidence of transforming IT departments. Others could point to consultants selling Agile as a product (supported by the stats above). Either way, leadership can’t afford to give us time to rebuild their teams from scratch.
The call on change agents is to hit the ground with both feet running and start delivering value early.
Should we count “quick wins” as something to prioritize when kicking off a new effort? I wish the answer was “no” with all my heart. That’s just not the case most of the time. This supports the notion of developing proper success metrics early on with leadership to provide transparency. Curious what ways you have done this with your clients and companies.
Old School Methods Are Not Going Away.
One could argue that the accelerated need for early success on Agile teams might diminish the need for heavy-weight legacy methods. That’s just not the case, according to the survey. CIOs see Agile projects fail because of a lack of documentation (44%) and upfront planning (34%).
Turns out Waterfall is fighting its death harder than many of us thought.
These projects are not cheap. The paper stated the average cost of an IT Project is £8M (almost $10.3M). For that amount of money, leadership wants to know what exactly it’s buying. Combine that with the estimate that 12% of all projects completely fail, there is extreme nervousness over delivery methods.
Most of our Agile colleagues can speak to the success working with teams on the ground level delivering working software. We take a backlog and we work it one story at a time.
Would executives see that as successful delivery? One could argue these stats say “no”.
Agile consultants are increasingly getting into boardrooms, which might help align the expectations around how much planning is “just enough”. The call on us appears to need to double down on this conversation.
Agile Execution is Just Jazz Hands Without Proper Technical Leadership.
The survey states 68% of CIOs agree that Agile teams require more Architects. This comes from a few areas where teams struggle to deliver true needs of the organization. Most backlogs tend to focus on new features first (35% of respondents said so) and leave the non-functional work for later in the project.
Also, 46% stated they felt Agile projects don’t function with any kind of strategic vision. Business and product leadership tend to focus on the big shiny items of value to show their bosses how well things are going on their teams.
This ignores the principle of business and teams talking every day and mutually agreeing on the highest priority items to tackle next.
Failing to prioritize items like security and performance earlier in the product lifecycle creates a ton more work later on. This is where concepts like thin-slicing of features can be a benefit.
Now, one might ask if allocating more archtects to these efforts will solve the problems. I’ve encountered many architects that can absolutely draw a new system and carve out methods of implementation. And yet, teams still struggle with delivery. This again could point to expectations of what benefit this actually provides.
Roadmaps need to speak to technical and business outcomes. Only then can Agile teams build proper backlogs of value.
“From a leadership point of view, Agile is currently not in a good state.”
This line should send chills up and down the spines of our community. These are the folks signing checks for our efforts. If we can’t engage in leadership and encourage better ways of running Agile projects, we are truly doomed to becoming a fad.
Are we indeed “not doing Agile right”? You tell me.
About the Author
This is an Agile Alliance community blog post. Opinions represented are personal and belong solely to the author. They do not represent opinion or policy of Agile Alliance.