The list of companies touting agile is long. Some of the software companies might be familiar. Spotify, Salesforce, Google, Apple, Amazon, Yahoo, Red Hat, Adobe, and Facebook are all agile. Smaller, lesser-known software-development companies such as Atlassian, Paycor, Pivotal Labs, BNA Software, Hotels.com, and DevSpark are agile.
Companies we don’t typically think of as agile are working to be agile. Microsoft claims to be agile. General Electric, Hewlett-Packard, and Bank of America are agile. The United States Department of Defense is agile.
Game developers are agile. Financial companies and media companies are agile. Banks and universities are agile.
InThe Agile Mind-Set, Gil Broza asks an intriguing question: What noun typically follows agile?
Broza writes:
“People talk about agile development, agile project management, agile processes, agile methods, and agile best practices. Some speak about the agile methodology or the agile framework. Others refer to pairings like Scrum/agile and lean/agile.”
The language of agile is everywhere.
Consultants talk about becoming agile to avoid disruption. Terms like extreme programming, Scrum, and kanban are tossed around as ways to become agile whether people know what they mean or not. “Sprint”, “iteration”, “backlog”, and “burn down” are all entering the lexicon.
Forbes describes what agile leaders look like:
“Agile leaders are not only fast and effective problem solvers when dealing with situations they’ve never dealt with before, but they are also laser-focused on results and excellent at reshaping plans and priorities when faced with unexpected changes in the environment. They are resourceful and competitive. And, they get it done fast.”
Crossing the chasm
As agile has spread, the backlash has been fierce.
A number of people have written about the ubiquity of agile and its subsequent loss of meaning. Dave Thomas, one of the original developers of the “Manifesto for Agile Software Development” or Agile Manifesto, has declared, “Agile is dead.” Thomas suggests that agile “has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products.” He suggests the word has been co-opted to boost sales in the same way that “green“ has been used.
A great rant from Tom Elders on Hacker News starts with “I can’t take this agile crap any longer. It’s lunacy. It has all the hallmarks of a religion.”
What is happening with agile?
According to the most recent “state of agile” survey from InfoQ, agile has gone mainstream and the majority of organizations use agile techniques for at least some software development projects.
We can use Geoffrey Moore’s chasm model for technology adoption to get a sense of what’s happened in the marketplace with agile. Moore’s model for disruptive technologies is useful because it looks at innovations that require people to do things differently — innovations that require behavior changes.
Looking at Moore’s model, innovators and early adopters are visionaries with a high willingness for change, high risk tolerance, and strong support from management. Early adopters understand the benefits and are willing to experiment in order to gain a competitive edge.
There is a large gap or chasm between these innovators and early adopters and the largest segments of the market: the early and late majorities.
Pragmatists and conservatives on the other side of the chasm are far more likely to approach agile from a completely different perspective. They are risk averse. They have heard of agile but likely think it is a process change that they can easily roll out to their IT organizations. Their risk tolerance is low, they want quick results, and they’re expecting relatively easy-to-implement process changes.
In other words, they are driven by practicality and want an out-of-the-box solution. The early majority wants technologies that are simple to implement.
As a result, many vendors and consultants have figured out that they can take advantage of the industry buzz and the early majority’s desire for practicality to sell agile tools and processes to convince these customers they are becoming more agile. As William Pietri wrote on the Agile Focus blog, “An idea that provides strong benefits to early adopters gets watered down to near uselessness by mainstream consumers and too-accommodating vendors.”
Much of this has happened in the agile marketplace as early adopters sought out-of-the-box tools and processes.
Coaches and consultants with experience in making the transition are spread thin and many new consulting organizations look to take advantage of the situation and sell their services.
The early majority also sees agile as a process to enhance productivity rather than a potentially disruptive culture change. Agile can (depending on existing culture) be a significant cultural change. Crossing the chasm is more difficult with agile than with other innovative technologies because organizations might not have a culture that is ready for agile and either don’t understand or underestimate the cultural change inherent in agile.
The Agile Manifesto
The Agile Manifesto reads:
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
The Agile Manifesto describes a change in beliefs, a cultural change.
Tobias Mayer described it this way in The People’s Scrum:
“Scrum is a framework for organizational change and personal freedom. It is not a methodology, it is not a process, and it is much more than a tool.”
Agile is a set of beliefs, a set of ideas. Are executives and leaders willing to adopt and champion these ideas? Or are they merely looking to “optimize” employees because employees are seen as the constraining element of the system?
Moore’s ideas about crossing the chasm help us understand that what is happening is normal for innovations that impact behavior.
We don’t believe agile is dying or jumping the shark, but rather is experiencing growing pains as it reaches new markets. In many cases, however, what this means to organizations on the other side of the chasm is that what they’re doing or attempting to do is not really agile.
Adoption vs. transformation
One of the more common mistakes made when implementing agile is not seeing it as a framework for organizational change. This typically looks like adopting sprints and the artifacts associated with sprints and ignoring other components of the change framework, most often agile values.
When asked why agile projects fail, the number two reason cited in VersionOne’s 2014 “State of Agile Survey” after “None of our projects failed” was “Company philosophy or culture at odds with core agile values.”
Henrik Kniberg tells the story of one of his most successful projects — a system built for the Swedish police that allowed them to use laptops in the field — and what happened afterwards [Kni13]. Because the project was extremely urgent, the group was allowed to use an agile approach and break out of the traditional organizational culture. Everything went well, the police organization viewed it as a success, and the project even won a “project of the year” award.
What came next, however, was even more interesting. A high-level decision was made to rebuild from scratch that same system police had used in the field, using Siebel. This was part of a standardization effort to reduce the complexity and number of systems. Not only was the decision made to use a technology that the development team didn’t agree with, but it was decided to use a more traditional, sequential project-management approach to development. Development took a couple years and when it finally rolled out, it was a disaster because the police found it to be slow and clumsy and basically unusable. Making the change even more difficult was that the police preferred their existing system, which worked. Kniberg estimates that this cost the Swedish police more than £1 billion.
Adopting agile practices is likely to lead to marginal improvements at best if current values and culture are out of alignment with agile beliefs and the organization doesn’t change.
As Mike Cottmeyer wrote in “Untangling Adoption and Transformation”: :
• Transformation is about changing the “agile being” side of the equation.
• Adoption is about changing the “agile doing” side of the equation.
Some symptoms that might indicate that transformation has not yet fully happened and agile culture and values have not yet been adopted are:
• Agile teams have defined dates and scopes.
• A manager assigns tasks to team members.
• Impediments to development are not addressed.
• Team members don’t point out problems when they see them.
• Testing is not allowed because it highlights shortcomings.
• Burn-down charts are altered to present a rosy picture.
• Management plans rather than teams.
• All features are seen as high priority.
• Communication is one way, from leaders to employees through broadcasts.
• Agile is seen as something “the technology people do”.
• Teams are not developing working software.
• Teams are reporting rather than discussing progress.
• Superstars are valued over team.
• No changes affect how things are done.
• There is a reluctance to hire qualified outside experts.
• Leadership demands results without providing direction.
• Knowledge is hoarded.
To realize the full benefits of agile requires the values or the “being” part of agile. Michael Sahota and others have discussed how agile processes and methods can be adapted to different cultures. We would like to take a different approach. We believe that if organizations adopt agile as a set of beliefs, they will develop an agile culture and that this agile culture is what leads to continuous adaptation and innovation. The focus of the change effort must be on the heart, not the head or the hands.
Processes and methods can become stale and rote, and can stifle innovation — even processes that were initially developed to be agile. An agile culture, however, will continuously improve and adapt without the need for periodic change initiatives.
Numerous books and best practices exist to help organizations with implementing agile practices, or the “doing” side of the equation. Our reason for writing this series is to examine the values and culture that make organizations agile.
Coming Up In This Series
This post is based on our book, Why Agile Works: The Values Behind the Results and is the first of a series of blog posts coming soon, all taken from the book . To be notified when the next blog post appears, subscribe to our newsletter & blog updates.