Past the Summit

Earning the "instigator" lable in my blog masthead, I collaborated with some fellow employees to present the "Agile Summit." Yesterday was the day. It was an internal event, a day of training to give a taste of the concepts—whetting the organization's appetite.

The day was definitely a success, but I am also relieved to be past it. (You need a good waterfall project, with lots of slack, to have the time to plan such a thing.) My product owner and I were also part of the agenda, as a case study of one of the few teams at our company using an agile method. Given only a few minutes to get my message out to 300 people, I chose to focus my talk on collaboration. If people learned only one thing from me yesterday, let it be this:

Talk to each other.

Don't use documents and processes as walls to hide behind. Don't look to Agile to be new wallpaper for those old barriers. Agile is a different mindset, and tenet number one is collaboration. Break down barriers and get rid of gate keepers. Here are some of the compelling benefits we've experienced.

Between the business and developers:

• We're able to react to changes (or new information) in the business process, and we're always working on the highest priority features.
• Prototypes—or, really, quick shells of working code—clarify requirements. It's easier to communicate what you want when you have something to look at.
• Developers can understand the why of what they are building, which lets them build the right thing.
• As the business gives feedback and sees that feedback incorporated into the code, they get more engaged and give more feedback. It's worth their bother.

Between the testers and the business:

• Testers are able to understand the business reasons and user goals.
• Testers will ask questions from a user perspective ("Wouldn't the user want to do this?"), which makes a better product.
• Here's a quote from one of our India-based testers, when asked about the advantage of our project's collaborative model: "Everyone in the team has the freedom to ask questions and concerns to the Business." Freedom. Right on.

Between the testers and the developers:

• This code is more tested, period, than on any of my past projects.
• Developers get feedback the very next day on code they have just written.
• Testers are aware of changes in requirements and logic because they are attending the stand-up calls. No need for change requests and updating specification docs.
• Visibility (in the form of the burndown chart) gives us a real, honest feel for where we are in the project timeline. You can look at it and really know whether we're on time or not.

This collaboration makes us successful, and it makes the work more fun. I mean, which would you rather do: talk to a teammate or fill out a 20-page template?