6point6's study published on April 2017, based on a survey on 300 CIOs (average company size: 1,300 people) shows that the perception of Agile is changing. CIOs are often disillusioned, finding (usually the hard way) that many(12%-21%) agile projects fail completely, that Agile is not easy to scale, and that distributed agile teams are often underperforming.
This is good news. Agile never was, and never will be a silver bullet. Struggles with Agile adoption and a decent share of failures, show us that Agile will work only when carefully customized for the specific organization, by the specific organization. This should shift our focus from advocating Agile to making it work – without expecting/demanding that the organization changes its culture overnight to become ‘Agile’. Established Agile scaling frameworks such as SAFe can help with that.
The age of agile innocence is ending. Finally
For the massive effect it has had on the software industry, there are surprisingly few industry reports analyzing the extend of Agile adoption*, compared to Waterfall, the older standard. Moreover, we have little data on the perceived success of the adoption efforts. Is Agile considered successful by the companies adopting it, after all?
Most reference reports (such as the ‘State of Agile’ or the ‘State of Scrum’) base their data on surveys conducted on people already interested in or practicing Agile, a fact which obviously limits the sample and creates a strong positive bias towards Agile.
This report published recently by 6point6 (a UK consultancy), tried to measure the perception of Agile success and the most common adoption roadblocks, by conducting a study on 300 CIOs, half in the US, half in the UK.
* I am on purpose using the term ‘Agile Adoption’ instead of the more commonly used ‘Agile Transformation’. Whatever they may be called, true Agile Transformation initiatives, radically transforming the way of work, are rare. Much more frequent are ‘Agile Adoption’ initiatives, which are less ambitious and limit Agile to an (alternative) delivery mechanism. These initiatives impact mainly IT, so it would be expected to ask a CIO about their results.
The results are really interesting. 12% of Agile projects in the UK, and 21% in the US fail completely. Most failures are attributed to lack of adequate documentation (44%) and lack of adequate road-mapping (34%).
Adoption struggles are so cruel that half (50%) of the CIOs surveyed now consider Agile to be a passing ‘IT fad’, fueled by Agile consultancies who have been ‘an industry in its own right’ (73%).
The results show that Agile has passed the peak of the hype cycle. Organizations are now more skeptical towards over-enthusiastic consultants, taking success for granted. They now realize it takes serious work to make it work. To go Agile, you need experienced practitioners, lessons from previous failures and successes, and, if your IT department is large, a scaling framework.
Findings & Lessons
1. Agile is mainstream
More than half of CIOs (52%) are using Agile for all their projects. Only 7% report that they will not run any Agile projects during the next year. It seems that Agile has overtaken Waterfall as the primary delivery method. Nice to be on the highway.
Now, has also Agile culture (focus on people vs processes, frequent feedback vs long term planning, self-organization vs. hierarchical decisions, cross functional teams vs. silos, etc.) overtaken traditional corporate culture? Sadly, the report does not answer this question -but my guess is no – we are still on the dirt track.
Agile delivery is not ‘new’ anymore, while Waterfall is getting older every day.
2. Scaling Agile is not trivial. It is also necessary
On the question “Have you had any experience with Agile at scale?” only 5% respond negatively. If you are serious about Agile, you must scale it. The ‘scaling’ model starts to reveal the complexities involved. “Multiple products to multiple teams”, is more frequent (62%), than “multiple teams to one product” (50%), whereas “multiple products, one team” gets 30%.
Now “Multiple products to multiple teams” is considerably more complex in terms of operating model than “multiple teams to one project”. That means that the organization will need a well-established, clear and comprehensive Agile operating model (or invest considerably to create its own). That is one of the reason for SAFe’s growing popularity. Simpler frameworks, assuming one product per team (e.g. Nexus) might not be enough.
Use a scaling framework to scale Agile. Or invest to find your own way.
3. Institutionalizing Agile - The devil lies in the details
According to the respondents, 34% of Agile projects fail due to ‘lack of planning’ in the form of a rolling lookahead roadmap. Is sprint-based short-sightedness killing vision? Is the lack of mid-term goal-setting killing motivation?
Apart from planning, lack of adequate documentation and architecture are also a pain point. 68% of the respondents think that ‘Agile teams need more Architects’, while 44% of failed Agile projects, did so because of ‘a failure to produce enough (or any) documentation’.
Establishing Agile as the primary work model of an organization, means that just enough planning, documentation and architecture is included in the mix. If the teams fail to see or implement this, the organization must help them (by imposing minimum-documentation practices, planting architects in the team and requesting medium term road-mapping)..
Failing to get seriously involved in the details of delivery during an Agile adoption, will risk your teams’ success.
Agile has overtaken Waterfall as the de-facto standard for software project delivery. This large-scale adoption surfaces complexities leading in many cases to disillusionment about Agile’s success potential.
This forces both organizations and Agile practitioners, to return to realism. The ‘hype’ period is over. The big battle has been won. We now need to focus on all the little things ensuring successful delivery. Winning the little battles will win us the war.