Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News 12th State of Agile Report Published

12th State of Agile Report Published

This item in japanese

The 2018 State of Agile Report has been published by CollabNet VersionOne. Some of the conclusions from the report are that the need for customer and user satisfaction is increasing, more and more organizations are scaling agile, distributed teams are becoming the norm in agile software development, and many organization have started or plan to start a DevOps initiative in the next 12 months.

InfoQ interviewed Lee Cunningham from CollabNet VersionOne about the 12th State of Agile report.

InfoQ: What are the major changes in the 2018 State of Agile report compared to previous reports?

Lee Cunningham: Most of the trends we track in the survey change only incrementally from year-to-year, and many of them reinforce that the same fundamentals still need to be addressed. Organizational culture is one example of that.

One significant change did emerge this year, though, and that is the importance of customer/user satisfaction as a measure of success, both for agile initiatives (transformation effort itself) and for agile projects. In the past we’ve seen things like "on-time delivery", "quality" and "business value" ranking ahead of customer satisfaction.

InfoQ: Why has the need for customer and user satisfaction increased?

Cunningham: I believe (and I certainly hope) it is that there is broader recognition that the customer is the most important entity in the value stream. If we aren’t listening to our customers, and we aren’t delivering what they really want, they’ll just go somewhere else. In that case, it doesn’t matter whether or not what we’re delivering is on-time, seems valuable, and is generating few bugs.

InfoQ: How can organizations apply agile to support this need?

Cunningham: The first principle behind the Agile Manifesto states that customer satisfaction is the highest priority. I think the principles that follow support that. So as simple as it might sound, I’d suggest an organization revisit those principles to see where what they’re doing may be at odds with those principles. As an example, they might ask, "Are we harnessing change for the customer’s competitive advantage, or are we optimizing around schedule and resource management, and actually discouraging change?"

InfoQ: What are the main expectations that organizations have from adopting agile?

Cunningham: This year’s survey tells us that the top five reasons for adopting agile are to "accelerate software delivery", "enhance ability to manage changing priorities", "increase productivity", "improve business/IT alignment", and tied for fifth place, "enhance software quality" and "enhance delivery predictability". Most of those have been in the top five for a few years now.

InfoQ: Do they manage to realize these expectations? Are they getting benefits from adopting agile?

Cunningham: It’s encouraging to see that those five (really, six) expectations are among the top eight reported benefits realized. Also among those top eight are "project visibility" and "team morale". Of course, visibility and morale have a lot to do with achieving the others. So yes, it appears that the most sought-after expectations are being realized among the majority of the respondents. However, I have concerns about the sustainability of agile transformation in organizations that aren’t seeing improvement in areas like predictability, risk reduction, and quality, In my experience, where problems persist in those areas, support for agile transformation can erode.

InfoQ: The report states that the top three factors most helpful in scaling agile are internal agile coaches, consistent practices and processes across teams, and the implementation of a common tool across teams. How does this relate to the agile manifesto that values individuals and interactions over processes and tools?

Cunningham: A common scenario is a large organization in which multiple, separate grassroots agile efforts form over time, each with different norms and using a diverse set of tools. Fast forward to when the enterprise wants to harness the power of agile in a coordinated way across large numbers of these islands of agility. At that point, some decisions have to be made as to what makes sense for that organization. Questions become "How do we get the real-time visibility we need across these teams of teams?" and "How do we foster enough commonality across the organization so that we’re all moving in the same direction, but we aren’t squashing team identity." Just enough consistency of practices, and the right tooling can help.

A simple example is where there’s a mix of Scrum teams working alongside Kanban teams. All of the teams may be asked to measure cycle time, in order to surface opportunities for improvement to common, systemic factors. To do this well, organizational leadership needs to enable -- not drive -- this, and they need to be able to explain why something is being asked. That is why I believe it’s important to understand the principles behind the practices. And we need to be willing to stop doing something that isn’t working. Otherwise, we could find ourselves trying to process and tool ourselves to success -- exactly what the manifesto is trying to steer us away from.

InfoQ: Distributed agile teams are becoming the norm as 79% of the respondents had at least some teams practicing agile. How does this impact the way that agile is adopted and applied?

Cunningham: I think it reflects the reality that so many people today work not only in geographically-distributed corporate locations, but that many people work from home or work while traveling. In other words, it’s just a fact that everybody’s not in the same room at the same time. So if agile’s important to us, we’ve got to figure out how make that work. Collaboration technology has gotten better -- at least better than it was 10 years ago -- making distributed agile more technically feasible.

We see organizations succeed with distributed agile with individual team members that are geographically separated. So maybe four of the team members are in Florida, one is in Texas, and another is in Alaska. This arrangement can be more difficult when the team members are separated by too many time zones, though. We also see success when individually colocated teams are working together in a program or release train, but those teams are geographically dispersed.

The fundamental factor to the success of a given organization in applying agile across distributed teams, in my view, is whether they’re really agile teams. If the "Dev" team in location X is handing off to the "QA" team in location Y, there’s a problem.

The survey investigated what agile techniques are employed:

InfoQ: Retrospectives are among the five top agile techniques employed by teams. Do you know what causes the high rate of adoption?

Cunningham: I think this indicates the recognition that reflection for adjustment (or inspection for adaptation) are integral to agility. The fact that it is in the top five is encouraging.

InfoQ: At the lower end of adoption, the report mentions common work area, Story mapping, and Agile/Lean UX. Why are these techniques less adopted?

Cunningham: I don’t know for certain, but I’ll offer my opinions. Even in agile "shops", I think UX is still a very specialized skill set, and often with just one or two UX designers to work across multiple teams.

The relative lack of common work areas may simply be an indication that organizational culture is not aligned with agile values. Corporate facilities departments are known for not allowing deviations from the sanctioned seating arrangement. And that’s sad. A more optimistic view of this is that it correlates to a more distributed workforce, where team members aren’t even on the same continent.

Although Story Mapping has been around for a while, I really don’t know if it’s well-understood. For better or worse, I think that people are still more comfortable with hierarchical feature breakdowns.

InfoQ: What are the biggest changes reported when it comes to tools for managing agile projects?

Cunningham: The one that stands out is Kanban board rising to the top slot, displacing Taskboard. Taskboard still comes in third place, but I read this as a slight shift from thinking about work to thinking about delivering.

InfoQ: 71% of the organizations have a DevOps initiative or expect to start one in the next 12 months. What are their expectations from DevOps?

Cunningham: Based on how the respondents say they measure the success of DevOps initiatives, the top three expectations are "Accelerated delivery speed", "Improved quality", and "Increased flow of business value to users". "Increase customer satisfaction" is only the fifth highest response. I find that an interesting difference from the reported success measures for agile initiatives. This may be an indicator that when the survey respondents think of "DevOps success", they’re thinking primarily of delivery pipeline efficiency, whereas when they think of "agile success", they’re thinking of the larger value stream (of which the delivery pipeline is a part).

InfoQ: What are the benefits that organizations are realizing with DevOps?

Cunningham: We didn’t come out and ask that in this year’s survey. That’ll be a good one for next year. Aside from the survey, I can say that DevOps adoption, when approached as part of the complete "concept to customer" value stream, seems to have a greater impact on business value throughput than when thought of in terms of just the "IT value stream".

Rate this Article