On the 15th Anniversary of the Agile Manifesto, Practitioners Debate How Far the Movement Has Come and What's Next
BY KATE ROCKWOOD
Agile is everywhere. Agile is dying. The great debate over the future of agile is as lively as the one over whether it actually delivers all it promises. It still makes some organizations uncomfortable.
“Agile is a dark art,” says Robert Moores, PMI-ACP, PMP, program manager, Google, London, England. “When everyone really buys into true agile, companies move so fast it's incredible. But agile is also a term that's been heavily misused.”
It's been 15 years since a group of software programmers wrote the “Manifesto for Agile Software Development.” It emphasized the value of “individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan.”
There's no denying that agile approaches have since spread beyond software development to other industries, into every corner of project management seminars and training, and to organizations big and small. A decade ago, nearly two-thirds of respondents to the VersionOne annual State of Agile survey said they worked at an organization with fewer than 100 people. In the most recent survey, just one-third of respondents worked at a company with fewer than 100 people. And more than 24 percent of those taking agile approaches work at an enterprise with more than 20,000 people.
“Agile is a dark art. When everyone really buys into true agile, companies move so fast it's incredible. But agile is also a term that's been heavily misused.”
—Robert Moores, PMI-ACP, PMP, Google, London, England
Agile approaches are clearly here to stay. (See “Knowledge Upgrade,” page 58.) But several agile manifesto authors believe the movement hasn't lived up to its early vision and promise. (See “Time to Go Back to Basics,” this page, and “Courage and Curiosity,” page 60.) The word “agile” has become “sloganized” and is “meaningless at best, jingoist at worst,” manifesto co-author Andy Hunt wrote last year. Another co-author noted: “What passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products.”
When the newest edition of A Guide to the Project Management Body of Knowledge (PMBOK® Guide) is published next year, practitioners will notice that agile is more prevalent throughout it.
“We didn't want agile to be a supplement anymore, but an integrated part of the PMBOK® Guide,” says Guy Schleffer, PMI-ACP, PMP, PgMP, PfMP, portfolio manager, Ministry of Defense, Tel Aviv, Israel. Mr. Schleffer is a core volunteer working on the update. “Agile isn't a new thing or something that we need to give more time to experience and let it mature. People are using it and people are looking for it.”
Agile also can be employed as a sort of smoke screen for subpar practitioners who don't want to bother with efforts to define product features and envision a solution, says Jordi Teixido, PMP, COO, Strands, Barcelona, Spain. “Agile is wonderful when you're really iterating and collaborating, but it's also a refuge for mediocre practitioners who are unable to document or express their requirements or forecast what they want to build,” he says. “If you don't follow the rules of the game in waterfall, everyone knows it. But in agile, that's harder to tell from the outside—and because of that, some people use agile on projects that would be far better under waterfall.”
Even when agile is chosen for the best of reasons—a faster product launch, a leaner team, more innovative features—its fast metabolism sometimes can be at odds with the organization's overall level of agility. “If you start with pure agile at a company with any more than, say, 10 people, you'll find that the company is expecting some degree of governance,” says Mr. Moores. “Everything might be hunky-dory on the project team, with stand-ups and burndowns, but then you get to product release and you see that you've just moved the bottleneck from development to somewhere else down the line.” For example, the sales and marketing teams might need more time to prepare for product launch, or the legal team might have issues with features that could have been flagged earlier in the process.
“Agile [can be] a refuge for mediocre practitioners who are unable to document or express their requirements or forecast what they want to build.”
—Jordi Teixido, PMP, Strands, Barcelona, Spain
For agile to realize its full potential, Mr. Moores says, portfolio managers and project management office leaders have a tough target: company-wide buy-in. “The biggest challenge to agile's maturity is getting the company to be truly agile and to embrace agile,” he says. “How do you get legal teams, your sales teams, your account management teams, even your testing and release teams to understand agile? I think it comes from executive buy-in about the risks and buy-in about having detailed planning for perhaps only the next six months and uncertainty around strategy beyond that. Organization-wide adoption is easier said than done.”
Some experts say it's time for a new iteration in thinking about how agile approaches relate to waterfall. The first step is a mindset shift away from thinking that pure agile is somehow more ideal than a hybrid or customized approach, says Mr. Teixido. “When we pit agile against waterfall, it casts waterfall as old, bureaucratic and rigid,” he says. “But sometimes I see more rigidity in agile.”
The best project teams aren't those that adopt, say, Kanban or scrum and then close their minds to all other options, Mr. Teixido says. Rather, standout project leads tailor the approach to the team, project and organization—even if that means reaching beyond agile. “You need to know both worlds. Every project manager should know the traditional methods, like critical path and critical chain,” he says.
“Scaling agile means choosing the right combination of agile approaches for large teams based on the organization's needs.”
—Rahul Sudame, PMI-ACP, PMP, Persistent Systems, Pune, India
When Mr. Teixido was overseeing projects using scrum, the daily stand-ups became burdensome and began to feel like micromanagement. So his team sometimes shifts to weekly review meetings. “And we're still doing sprints, we're still doing agile—it's simply tailored to our needs,” he says.
The upside of that flexibility can't be overstated. “Scaling agile means choosing the right combination of agile approaches for large teams based on the organization's needs and tailored to the team's experience, not just adopting a blanket approach,” says Rahul Sudame, PMI-ACP, PMP, program manager, Persistent Systems, Pune, India.
Mr. Moores, who has spent more than a decade working on agile projects across a handful of global tech organizations, says customized approaches are surprisingly common. “Many companies love the idea of agile but are building their own frameworks with more upfront planning and an upfront approval phase,” he says. The level of governance is largely tied to the organization's risk appetite, but it also tends to be tied to the project scope and team size.
“If you're doing a project like a prototype with, say, four people and it won't affect many teams in the business, then pure agile is fine and often works really well,” he says. “Whereas if you're impacting the bottom line or there are big public relations implications or security issues, it's dangerous to proceed in that off-and-running agile way.”
At one organization he worked at, taking a pure agile approach on a project could only be approved at the portfolio level, and only by meeting certain criteria. (Criteria included a method for tracking spending and a one-page summary of the project's goals.) But there's a payoff. “You save time and money doing that, because you're not applying unnecessary governance to projects that don't need it,” Mr. Moores says.
At organizations where agile approaches are less widespread or tend to meet resistance, however, project leaders should embrace as much upfront planning and governance as the project can reasonably bear. “Doing traditional design documents might not feel like pure agile, but it has an upside: Taking the best bits of agile and traditional project management, from the project through portfolio level, gives you that agility you need,” Mr. Moores says.
From an organizational perspective, of course, the approach taken doesn't matter—delivering results aligned to strategy does. In that sense, the debate over whether and how to effectively scale up agile project management practices connects directly to the larger conversation about how to achieve organizational agility.
“While we're scaling agile, why don't we also work to descale the organizational structure?” Mr. Sudame asks. That would mean less bureaucratic tape, fewer layers of middle management and less redundancy in planning and oversight. “I'm seeing more debate recently over how we can get rid of the fat of extra layers and make sure teams are better aligned with the organization's strategy and used optimally. With less layers, you'd have a better, leaner organization—and stronger project teams.” PM
The Manifesto: A Call for Change
In 2001, 17 software programmers interested in improving then-dominant development processes gathered at the Snowbird ski resort in Utah, USA to relax and find common ground. They ended up writing the “Manifesto for Agile Software Development.” It's reproduced below.
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.
Time to Go Back to Basics
By Andy Hunt, agile manifesto co-author
Many folks today are using agile techniques and delivering great software and value. But too many projects still fail. Many teams behind these failed projects thought they were agile. They weren't even close.
The word “agile” itself has become sloganized. Too many teams are doing a poor, halfhearted attempt at a subset of agile practices. And there's no shortage of vocal agile zealots, as per the definition—a zealot is one who redoubles their effort after they've forgotten their aim.
Remember, the fundamental aim of any agile approach should be to embrace change: to be aware of changes to the product under development, the needs and wishes of the users, the competition, the market and the technology. To “inspect and adapt” by using feedback to change our methods and ourselves.
But our methods themselves haven't been very agile at all. Teams often adopt good practices poorly and have little guidance on how to explore new approaches beyond the oxymoronic “agile canon” that might work better.
We need to go back to basics. We must end our addiction to long-term, plan-based fortune-telling, and be agile so that project teams can turn on a dime. We need to emphasize continuous, real-time feedback under actual conditions. Anything else is just fantasyland. Agile doesn't mean reducing or eliminating uncertainty, or even planning for it. Agile means responding to sudden change quickly and effectively.
While working software is our ultimate deliverable, it can't be at the expense of a functional team and organization. The software, the team, the users and project sponsors all form one system. We need to make sure the whole system works, for all participants. That's the future of agile.
Andy Hunt is a writer and publisher. A former software programmer, he's the author of nine books and the co-founder of the Pragmatic Bookshelf, which publishes award-winning and critically acclaimed books for software developers.
Courage and Curiosity
By Dave Thomas agile manifesto co-author
I returned from Snowbird and watched from the sidelines as software developers got excited by the manifesto. They started trying to apply its values to their daily work. Over time they experienced successes, gained credibility and built momentum.
At some point, maybe three or four years in, things changed. What was a discussion among practitioners and an exploration of possibilities became rules and frameworks delivered by consultants. Companies, unnerved by the pundits who claimed that agile was anarchy, paid big money to experts and brand owners who would give them a playbook—rules and procedures to follow so they could “do agile.” No one seemed to realize that rules and procedures are poisonous to a team exercising agility.
All truths are contextual—no rules are universal. You can't pin something down with rules, constrain it with processes, cripple it with hierarchies and then expect it to exhibit any trace of agility.
Instead, you embrace the fact that the world our systems live in is rapidly changing and ultimately unknowable. Writing systems that work in this world is not a science—it's an exploration. We set off in a direction but rapidly use feedback to guide us. We make mistakes. We backtrack. But if we move closer to our goal each day, eventually we'll get there, even if “there” isn't where we initially thought it was.
Dave Thomas is a programmer. He's also an author (The Pragmatic Programmer, Agile Web Development with Rails, Programming Elixir) and a speaker.
You don't need consultants to become agile. You don't need expensive frameworks.
It's tougher than that.
You need courage and curiosity.
PM NETWORK DECEMBER 2016 WWW.PMI.ORG
DECEMBER 2016 PM NETWORK