10 rules for keeping Agile development... well, agile

How to avoid becoming an 'Agile Zombie,' and 9 other Agile adoption pitfalls.
Written by Joe McKendrick, Contributing Writer

One of the most important things to know about Agile methodologies is that if it is limited to one team of developers churning out code, it won't be Agile.

In their new ebook, Agile for Dummies, Scott Ambler and Matthew Holitza walk through the steps required to be truly an Agile shop, observing that it takes a whole organization to truly be Agile.
For definition purposes, the authors describe "Agile" as an "incremental, iterative approach to delivering high-quality software with frequent deliveries to ensure value throughout the process. It places a high value on individuals, collaboration, and the ability to respond to change.” Their work reflects many of the core values and principles outlined in the Agile Manifesto, now 10 years old.
Ambler and Holitza explore the key success strategies for organizations make when adopting Agile strategies:
1. Look beyond the application “construction” stage: Consider the effort in a lifecycle context – not just building the application, Ambler and Holitza caution. “If organizations only change the way they construct software, they can’t necessarily call themselves 'Agile.'” Why? Because development teams may end up churning out new releases faster than the help deck or operations teams can handle them. As a result, the “waterfall” lives on, inundating all the people further downstream.
2. Don't be “Agile zombies:” There's often an assumption that attending a class or seminar and implementing some of the points learned leads to “Agile.” (The same assumption dogs SOA projects as well, by the way.) Every organization is different, and is constantly evolving. Continuous learning and improvement is at the core of Agile. “Agile isn’t a prescribed process or set of practices; it’s a philosophy that can be supported by a practice and no two agile approaches are the same,” Ambler and Holitza state. “One methodology that fulfills all needs doesn’t exist.”
3. Plan, plan, plan: First, don’t adopt Agile just because it's Agile. Organizations should answer questions such as: 'Why do we want to be agile, and what benefits will agile provide? How will we achieve and measure agility? What cultural, technological or governance barriers exist, and how do we overcome them?' Without a plan that clearly shapes the initiative and includes addressing and resolving constraints to agility (for example, removing waterfall process checkpoints or getting support from other required entities), it is more difficult to shape the initiative, staff it, fund it, manage blockers and maintain continued executive sponsorship.”
4. Include the entire organization: Yes, that includes the marketing folks and the bean counters as well. This is something more SOA proponents need to as well with their projects. It's faster and less painless, of course, just to launch an Agile initiative within a single team. But in the end, this isn't Agile. “A single team can gain some benefit from agile, but to be truly successful, you need to look at the whole process around solution delivery. And many people are involved in that process. Agile should be a change in culture for the entire organization.”
5. Get a C-suiter involved: It's important to find supporters not only IT, but across all the business lines, Ambler and Holitza state. Most importantly, try to get support from the C-suite. “An effective agile adoption requires executive sponsorship at the highest level.” Why? Because these are the people who control the purse strings, and can move the resources needed to make it all happen.
6. Stay at a deliberate pace – no need to rush: “Moving to Agile is very exciting, and it can be tempting to jump right in, pick a process, get some tools, and hit the ground running,” Ambler and Holitza say. What could happen, they caution, is Agile proponents will run into brick walls, such as testing snafus, scalability issues, and difficulties getting multiple teams to work together.
7. Bring in the coaches: Agile means a shift in the way business views technology. And, as with any cultural shift, “coaching is imperative,” Ambler and Holitza say, noting that “developers don’t like change and many people like working in their own world.” With Agile, developers may need to work in unison with five, six, or ten other people. Plus, business users will need to learn to work with development teams as well. That's why a coach – either a professional or an anointed employee with great communication and motivation skills – is advised, to help everyone to learn to work together, and not against each other.
8. Adjust, revamp or introduce governance: Moving to Agile methodologies means revisiting processes and procedures that may have been in place since time immemorial. Remember, Agility relies a lot more on business support than previous, more closed IT initiatives. “Existing traditional governance processes can be very difficult to change due to internal politics, company history, or fear that compliance mandates may be negatively impacted,” the authors observe. “Some common governance areas that are overlooked but can have dramatic impacts to agility are project funding, change control, and phase gates.”
9. Train, train, train: Organizations tend to be notoriously skimpy on training, but Agile is one area where investment is warranted. Skinflint managers may only send a few key people to training, “in hopes that they can train the rest of the organization while trying to implement the new approach.” This wont work – Agile is a game-changing initiative across the organization, and everyone needs to be brought up to speed and enlightened. As the authors put it: “Agile involves a change in behavior and process.”  Just as Agile means continuous improvement, so should peoples' skills be continuously improved.
10. Get the right tooling, and get the tooling right: The goal of good Agile tooling is to automate as much of the process as possible, while delivering measures of progress. “If tools are used inconsistently, metrics may not correctly reflect the correct status, builds could be run incorrectly, and overall flow and quality issues result,” Ambler and Holitza say.

Editorial standards