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

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

Summary: How to avoid becoming an 'Agile Zombie,' and 9 other Agile adoption pitfalls.

TOPICS: IT Priorities

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.

Topic: IT Priorities

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • RIP, Spiral?

    Gee, we used to call stuff like this "a plan." But I guess you can't charge mega consulting fees with something that simple, can you? Although I kind of like "Agile Spiral" -- it sounds like a black DARPA project. Consider it trademarked.
  • Agile = HACK

    It is just an excuse for developing crappy products.
    • re: Agile = HACK

      Hey Wackoe, I'd like to understand more of your reasons for blanket tarring agile as an approach for generating software. In all honesty I have seen great products produced by agile and non agile teams ( in the same way I have seen plenty of crap produced by non agile teams). In my experience though, agile teams have fewer single points of failure and can often produce higher quality (in terms of lower defects, greater code simplicity and elegance AND fit for actual business need) with higher team morale and cohesion than is often the case in a more v-model approach. BUT it does take discipline and it does rely on the understanding that to get great quality software you need great quality people. (and you need to trust them)

      BUT if you're not disciplined in your approach, or if you're looking at it from the outside in, then , yes, it could be easy to view Agile as a safe haven for cowboys who produce shonky work.

      But like it or not, Agile is mainstream now, and there are some really good reasons that so many organisations are heading down that path. Change is one of the few constants in life (yes, that is a deliberate use of those two words) and as software professionals we need to relish and embrace those changes. They allow us to grow and develop as individuals. If we don't accept the need for change and evolution in our working life then we would all still be using punchcards and tape. (And yes, for a brief period in my working life... I had the 'pleasure' of using those!)
      Pamela Stone
      • Dear Pamela,

        ... come work with us.

        Sincerely yours, Games Cafe Inc.