Agile Project Planning

ExtremePlanner: Agile Project Management for Distributed Software Teams
Click For Your Free Online Trial

Tuesday, February 28, 2006

3 ways to meet your software project deadline

Software development is inherently unpredictable. Many dollars have been spent on training, methodologies, and consultants in the attempt to guarantee software delivery dates. These have been largely in vain. Although there are valid techniques that can improve your estimates, sometimes, sadly, those estimates will be wrong.

As a proponent of Agile methods, I believe that agility is about discovering how wrong you are as quickly as possible. Failing quickly gives you time to adjust, scale back, or just cancel a project before throwing good money after bad. It gives the business information about the true nature of a project, not an artificial sense of well-being just before the explosion.

Agile methods use iterations, or short, time-boxed development cycles. During an iteration, developers work on the highest priority features. They plan to complete whatever they committed to by the end of the iteration.

Due to the unpredictability of software development, you can be sure that sometimes the team will have too much to do (and less frequently, not enough to do) if they are estimating honestly.

When there is too much to do, the best option is to cut scope, since changing the iteration date undermines the primary advantage of time-boxed iterations - quick technical and business feedback.

There are three ways I know of to cut scope, each of which have different tradeoffs. Here's a rundown:

  • Simplify Over-engineered Designs.
    On any software project, there are many technical decisions that can complicate the implementation of a feature. Sometimes these are unavoidable, such as the need to preserve legacy behavior, or support multiple variations. More often, though, a team will decide to use an approach that makes good technical sense, but adds on a good deal more complexity.

    Make sure that you are doing the simplest thing that meets the requirements for today's functionality, testability, and ease of maintenance. Planning too far ahead for the future can hamstring a development effort, and force project delays.

    For example, many teams get caught up in "architecture", which often means building complex application frameworks and middleware, some of which may never be used. This is especially dangerous early on in a project, when details are still fuzzy. Over-building of infrastructure is often a sign that the development team doesn't have enough details about what features to implement, and their priority.

  • Simplify Features.
    Sometimes the communication between business users and developers can be challenging, even with an ideal on-site customer (as proposed by XP). Many times, a specific feature request can be solved by alternative means that still addresses the business problem. This is a great way to reduce scope while still addressing critical business needs.

    So if Joe Customer asks for a automatic notification whenever any order is placed in the system, maybe he actually would be fine with a daily or hourly email with an order summary report. The latter might be a matter of minutes to implement with a simple database report, while the former might mean intrusive, risky changes to the order processing logic in the system.

  • Cut Low Priority Features.
    As a last resort, you may need to eliminate the lowest priority features to make a deadline. This is why Agile methods stress that business priorities should be clearly understood before each iteration. If you run out of time working on something technically difficult, but relatively unimportant, it's hard to explain why the ten simple, higher priority features won't make the release.

    Communicate with your customer about the proposed cuts as soon as possible to allow them to re-negotiate priority if necessary. You build trust and confidence by involving the stakeholders in tough decisions while there's still time to react.

So the next time you run up against a deadline, don't just cut features, first look for ways to cut effort while still delivering value. Your customers will appreciate it.

For more on agile tools and techniques:

(Tags: , , )

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams

Tuesday, February 21, 2006

Agile Prototyping - Part 1

One extremely useful tactic when designing appliction user interfaces is to use paper prototyping. This technique involves drawing mockups of possible designs, and testing them with a facilitator playing the computer, and the user interacting with the paper. Carol Snyder wrote a excellent book on this subject that's worth a read.

So the way this works is that the user interacts with the paper mockups by "clicking" on an area of the paper, and the "computer" facilitator does the appropriate thing that the design supports. This might mean placing a sticky note on top, overlaying another piece of paper, beeping, etc. For multimedia designs, this might stretch the singing and dancing abilities of the facilitator, but the general approach has been shown to be effective.

The key to this technique is that the designers have complete control over the form and function of the prototype, and can get useful feedback without any code being written. If the look of the prototype is a key aspect, then high-fidleity visuals can be created, but typically simple sketches can be equally effective for interaction testing.

On agile software projects, this kind of lightweight prototyping can happen up front, often saving quite a bit of development effort. Some people mistakenly believe that agile development means "no up front design", when in fact, it favors rapid feedback.

Rapid feedback means getting something in front of the user as quickly (and responsibly) as possible. This means that prototypes that can be quickly put together have great value in terms of soliciting earlier user feedback.

The great thing about doing this with paper is that anyone on the team can create and test designs, not just the developers.

For more on agile tools and techniques:

(Tags: , , )

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams

Sunday, February 12, 2006

Web-based Acceptance Testing Done Right

The Selenium project (sponsored by ThoughtWorks) has been quietly making an in-browser automated testing facility. It just went from interesting to compelling with the introduction of Selenium IDE, a free Firefox extension that lets you record, script, save and execute in-browser acceptance tests.

Now, I've always been skeptical of record and playback testing tools, since they usually require an obscure syntax, or are difficult to maintain. Not so with Selenium, which can use either an HTML table style syntax, or Ruby syntax (simple command-argument combinations).

The IDE makes creating scripts manually a breeze, and when combined with the record function, it's almost effortless. The only downside is that now there's no excuse for anyone creating a web-based application to avoid automated testing.

I haven't been this excited about a testing tool since, well, ever. Congratulations to the Selenium IDE team for a job very well done.

Get more information at:

For more on agile tools and techniques:

(Tags: , , )

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams

Wednesday, February 08, 2006

Agile Darwinism

With the recent controversy over "intelligent design", I've been thinking about the theory of natural selection.

Adapt or die.

This is basically what agility is all about - figuring out what's working by doing a little bit, getting feedback, and adapting as necessary. Or to put it more simply:


It's really that simple. Agile practitioners need to remember that the practices are helpful, but without inspecting what's working in a particular context, no practice should be followed blindly.

Two factors are going to force this issue in the near future. The acceptance of Scrum and XP by mainstream companies continues to rise, and there is an increasing trend towards globalization of the workforce. This will make distributed teams even more common, and will stretch the commonly held Agile "best practices" to their limits. Adaptation is the best strategy for keeping Agile methods relevant and effective for the needs of business.

Don't get me wrong, there are lots of very useful Agile practices that have been discovered, documented and validated over the last five to ten years and I follow many of them. But when the next technological ice age happens, I, for one, don't want to become extinct.

For more agile management tools and tips:

(Tags: , , )

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams

Wednesday, February 01, 2006

Is QA Redundant for Agile Software Projects?

A recent topic on The Server Side forum discusses the role of QA on agile software projects. Apparently a talk by Scott Ambler ruffled a few feathers in the testing community.

The basic argument given in the discussion is that QA is irrelevant on agile projects, since each iteration is a smaller increment of functionality and therefore easier to test. Developers do testing in the form of automated unit and acceptance tests, which guarantees quality moving forward.

Complete and utter nonsense.

The primary role of QA is to provide information to the business on the state of software. This means having an objective view first and foremost, and being able to back up that view with repeatable tests that exercise the software in it's intended context.

I've developed software for many years, and led software teams for nearly as long. We were rarely objective about the state of the software, try as we might. Now, sometimes that meant we thought the software was in bad shape, and sometimes the opposite, but it's very difficult to be independent reviewer and a creator at the same time.

Agile methods do help by making the increments smaller, so that there is less to obsess about and less to test, but the objectivity problem remains. This role is given to the customer in agile projects.

Inevitably, though, customers (who frequently have real jobs other than handholding the development team), have difficulty writing exhaustive acceptance tests and doing complete reviews of the software until it's in production. And of course, for commercial software, the role of the customer is played by a product manager or a marketing group. While they can provide guidance, again, they aren't trained to consider every possible exceptional scenario.

QA teams, then, are the last resort for most projects (whether we consider them to be part of the customer role or not). Certainly there are bad QA teams (or possibly just badly managed), but calling all QA activities irrelevant is just short-sighted.

There are several good resources on how to better integrate QA into the development team on agile projects, including Brian Marick's website, and Lisa Crispin's book. Do today's testers need to step up a bit to work with agile methods? Certainly. But let's not throw the baby out with the bathwater.

For more on agile tools and techniques:

(Tags: , , )

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams