August 16, 2008

Agile is All About Feedback

Agile methods allow your team to get feedback regarding the software you are building. That’s the point. The feedback works on several levels. Pair programming gives developers instant feedback on their code. Stories represent units of work where testers and analysts can give feedback to developers. Iteration releases facilitate feedback from outside the team. Most agile practices are valuable because they create feedback loops that allow teams to adapt.

A lot of teams adopt Agile with a grab-bag approach without quite realizing the point of the practices. They pair-program without discussion or changing drivers. They send code to QA that the testers can’t test because the story boundaries are arbitrary; they can’t tell whether they found a bug or just the end of the story. Iterations become schedule milestones rather than real opportunities to improve alignment and adjust objectives.

The reason Agile teams can do with less planning is because feedback allows you to make sure that you are on course. If you don’t have meaningful feedback then you’re not agile. You’re just in a new form of chaos.

On my last project, we defined our stories so that they made sense to everyone on the team. Our analysts, testers and developers could all understand and review individual stories. But we found that we had to create a larger grouping, which we called features, to facilitate meaningful review from outside our team. We made sure all the stories in a feature were complete before soliciting feedback from outside the team.

Being able to give and receive meaningful feedback is often a challenge for people. Yet it is crucial to success with Agile.

Agile teams get into terrible binds when executives or clients hand them a list of requirements at the start, tell them to use Agile (because its faster), and then don’t want to participate in the feedback process.

Agile isn’t faster all by itself. Agile is only a benefit in a world that acknowledges the value of adapting. And that adaptability needs to go all the way to whoever is funding the project. It is not enough for the team to be Agile. The sponsors need to be Agile too. Are all of the requirements really required? Do we know exactly what the software needs to look like from the start?

Agile is faster because feedback allows you to find and focus on the most valuable features. If you are certain you know what needs to be built, don’t use Agile. If you don’t have time to gather and act on feedback from customers, then don’t use Agile. If you are sure that everyone understands exactly what needs to be done from the start, then don’t use Agile.

Agile practices build a technical and organizational infrastructure to facilitate getting and acting on feedback. If you aren’t going to adapt to feedback, then this infrastracture is waste that will only slow you down. Previous: Lessons Learned in Agile Development Next: Agile Mostly Means Something Between Scrum and XP

Posted by bret at 05:51 PM | Comments (5)

August 15, 2008

FireWatir 1.2.1 is Released

We have a released a new version of FireWatir. This includes some fixes related to Firefox 3. It also marks the merger of the FireWatir and Watir projects. Unlike Watir, FireWatir works on Windows, Mac and Linux.

To install:

  1. "gem install firewatir"
  2. Install the plugin for Firefox.

Posted by bret at 05:27 PM | Comments (4)