Thoughts on the 9th State of Agile Survey
MVB and Continuous Delivery Guide Author Mirco Hering looks at VersionOne's State of Agile Report and how it compares to previous years.
Join the DZone community and get the full member experience.Join For Free
The 9th Annual State of Agile Report had some confirming and some surprising results. If you have not read it, it is worthwhile having a look here. And yes I know that number 10 is soon coming out, but hey there is still value in the 9th one to look at. Besides the usual statistics around how much Agile people are doing (the key number for me was only 5% working for fully traditional organisations), it provided interesting answers to the more common questions that I hear and the answers are often not surprising (but there was the odd surprise). Let’s jump in:
What are the typical benefits of Agile?
The report highlights the following three to be the top answers (which have been stable over the last few years):
Ability to manage changing priorities
This sits well with me as the usual suspects that we have to debunk are not on this list, e.g. faster time to market (only on rank 7) and cheaper delivery (not in the list at all).
How do you measure the success of Agile?
Uhhh, tricky one here. I have heard the question many times and honestly have struggled to give an answer that satisfies senior stakeholders. So what did the report say?
Good answers, and I think this reflects well on what success looks like. Interesting that some of the items mentioned under top benefits are showing up much lower here. Managing priorities obviously speaks to the product quality and customer satisfaction. But team productivity (29% measure it) and visibility (30% measure it) are much lower on the list. An open question for me is how people would measure productivity in the first place (see my other blog on this).
How do you scale Agile?
As much as I come across SAFe it is only used by 19% of the respondents with all the other ones even lower (DAD, LESS). The largest proportion just uses Scrum of Scrums or some custom created method.
Of the top 5 tips for Scaling Agile at least two are in my top lessons learned too: consistent process and practices and implementation of a common tool across teams. I agree with the other 3 tips as well: executive sponsorship, having a coach, and creating an internal support team.
What tools and practices do you use?
Wow. I was surprised — but perhaps I should not have been — that Excel and Project are the most used tools… seriously, are we not better than that? Oh well. On the real Agile tools, Jira and VersionOne take the cake with TFS close behind. IBM is much much lower. This represents my position as well, JIRA is certainly the one most used and few people complain about it, especially when integrated with Confluence.
There is also information on the practices used and I was shocked to see that only 69% use retrospectives and 48% have a dedicated product owner. Overall the adoption rates of these practices feels very low, but perhaps there is some fundamental flaw in the data if it considers people who run Waterfall projects but use a select few Agile practices… hmmm…
What makes Agile fail?
Good information here as well. Lack of experience is the main reason Agile fails, and this means that we should make sure experienced Scrum Masters and coaches support new projects. Lack of management support and a non-aligned company culture are the other two main reasons Agile fails. Those are a bit more difficult to tackle but are important to be aware of as you set off on an Agile project.
Overall I like the results in the report and it certainly helps to see some market data validating points that I keep making with my clients.
Published at DZone with permission of Mirco Hering, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.