Information Technology Dark Side

Tate Stuntz is a contributing editor to TechDarkSide.com and manages projects, services and methodologies for fun and profit. He can be reached at tate.stuntz@nimbleconsulting.com.

What is it exactly that separates an Agile project from a ‘non-Agile’ project?

When I tell people I’m a fan of Agile, they ask me what the big deal is, and then they wait for me to give what they assume is a brief answer. As if there is some trick that I can explain in 60 seconds which will make any project an Agile project.

The people who do this to me are the ones who consider themselves experts in project management and software development. These types already have a rich mental framework to draw upon. So, they think of everything new they might learn as an exception or a corollary to something they already know. “Oh, so that car is just like my car except it’s red and it’s a 5-speed…”

For people who already know how to succeed with traditional methods, telling them to collaborate, continuously focus on quality, value people, cut down on non-value added activities, etc., etc. is not very illuminating. It contributes to their opinion that Agile is just the next buzzword for the same best practices they’re already familiar with. Keep the team together? Make sure your users are available to discuss the requirements? . . . DUH!

Let’s give the traditionalists some credit. Most successful software people, regardless of their role, already know how to be agile (lowercase ‘a’) - even on a sequential project. What they want to know is how to be Agile (uppercase ‘A’).

I’ve been noodling on this notion for quite a while now and, while I can’t get it down to just one ‘trick,’ I think I have a few core practices that you just have to do in order to be successfully Agile.

Now each of these actually corresponds to one of the original Agile Principles, so I’m not inventing anything new here but I’d like to offer this shorter list because many of the original principles are important to traditionalists too and the descriptions are so brief that the differentiation from traditional best practices can be overlooked. The ‘newness’ is not immediately apparent to the casual reader.

So, here you have it, the Short List of the Magnificent 7 Litmus Test Practices you must understand and embrace to be successfully Agile:

• Agile Requirements Management
• Self Organization
• Agile Modeling
• Refactoring
• Regression Testing
• Timeboxed Iterations
• Velocity Metrics

In this post, I’ll discuss the first practice, Agile Requirements Management, in some detail. I’ll describe the others in later posts. Also, note that I’m calling these practices instead of principles. In the manifesto, they are really principles. In order for people to really be able to apply a practice to different contexts, they have to understand the principle first, but frankly that has been done by several others and I’m too lazy to do it again here. I’ll stick to describing the practice in brief, concrete terms in hopes of keeping your attention.

Agile Requirements Management

Agile Requirements Management is really a combination of requirements management and change management and it most closely resembles the approach that sequential teams use for defect management.

Think of a large, well-run, sequential project in all-out testing mode. There might be system testing and user acceptance testing going on at the same time. New builds of the code are released frequently - maybe every day - so people can retest the code and close existing bugs or log new ones. Several people are logging defects of various types (including some defects that are really enhancements) into a single bug-tracking tool. The bugs are described clearly, concisely and briefly. Usually a one line title and a couple paragraphs of description are all the narrative required. The list of defects is frequently re-prioritized to account for new bugs or new information on old bugs. Some bugs are assigned to specific developers, but usually the developers simply grab the next bug off the list based on priority and their understanding of the bug.

In the projects I have seen, almost anybody is allowed to log a bug and almost nobody creates detailed specifications for each bug. The bug is fixed and released in a matter of days if not hours. The bug usually documents not only what is happening, but what is supposed to happen and the steps to reproduce the error. That is, a very brief requirement with a very brief built-in test script. Somebody re-executes the steps and, if the bug has been fixed, it gets closed.

Now, imagine a slightly more disciplined and less stressful version of that same process being used from the very beginning of an Agile project. The most important requirements are logged clearly and briefly in a tool like a spreadsheet or a bug-tracker. Some built-in tests of some sort to accompany each requirement would be very helpful. This is frequently started during a Start Up or Inception phase.

Then, for each iteration, the project team prioritizes the list and bites off a small subset to turn into software. The users see the result of that development effort and provide feedback. This feedback can be logged defects or enhancement requests or it can be changes to requirements already logged (but not built yet) or even brand new requirements. The team re-prioritizes the list and grabs the next set of items to work on. The work items can be any combination of defects, enhancements, and new features. This continues on with the ‘requirements list’ being changed continuously throughout the project, just like an ever-changing bug list in a sequential project’s testing phase.

As for change-management, part of the management of change comes from the fact that ‘the business’ prioritizes the list and agrees to continue on with each iteration. This means that they control how much time and money are spent just like they do when they approve the original budget and the subsequent (inevitable) change requests on traditional projects. An Agile project just provides a different means for tracking and pricing the change. You’ll have to read the post on Velocity Metrics (once I get to it) in order to understand that part of the change management.

Scott Ambler has a really good essay on Agile Requirements Management too. Check it out.

Next time, Self Organization.

If you enjoyed this post, make sure you subscribe to my RSS feed!

Stumble it!