The Agile 2006 Conference

I spent last week at the Agile 2006 conference in Minneapolis. I’m going to try to dig through my notes and produce a few rambling paragraphs to at least begin commemorating my experience.

The conference was punctuated by many animated discussions, impassioned talks, and heated debates. No single point of view carried the day. This was entirely appropriate, since Agile programming is still very much a work in progress.

One of the themes common in the conference was the need for communication, and the need to constantly reassess the progress one was making and any assumptions held by a team. Many Agile technologies focus on getting developers together in one room and encouraging them to debate and evolve their ideas

As a result, heated controversy and open discussion were not so much by products of the conference, as the very subject matter of the conference itself. This was no place for wall flowers who wanted to sit in corners. Here developers could gather together and pursue ideas with passion and conviction.

My Impressions

When I was sent to the conference, I was told to listen for ideas that I could share with the other C# Program Managers here at Microsoft. Since I am new to the company, I was therefore scrambling to compare my circumscribed knowledge of Microsoft methodologies with what I was hearing at the conference.  

I personally like Agile development, but I have limits to my enthusiasm. A lot of good ideas have emerged from this fecund source, but it seems at times that a filter is needed to sort out the good from the bad.

There are certain common Agile programming techniques, such as Test Driven Development and Refactoring, which I believe to be of great value to many developers. I quickly decided, however, that the Microsoft C# team should think long and hard before adopting Agile programming wholesale. The development of a tool as complex as Orcas seems to necessitate a good deal of careful planning and documentation which is not typical of an Agile project.

This is not to say that Agile programming is not being practiced at Microsoft. There are many advocates of Agile here in Redmond, and some projects are said to be run on strict Agile programming methodologies. Indeed, there were some 20 other Microsoft employees who attended the Agile 2006 conference. Many of them were strong Agile advocates, and nearly all had at least an active interest in the subject.

Though I’m still the new guy here, I have seen enough of the C# development process to know that there are a few Agile-like aspects to the C# team’s methodology. However, the C# team is definitely not using a pure Agile methodology.

There were a number of speakers at the conference who had a few choice words for teams who use the term Agile, but who do not adopt the main tenants of the platform. I will therefore say that the Microsoft C# team is just dabbling in Agile, rather than plunging in without restraint. Other teams on the Microsoft campus, however, are rumored to use strict Agile methodologies.

I should also add that one of the best talks I saw at the conference was made by Mike Cohn, who had a great session on planning. As he showed in his talk, and as he shows in his book, Agile has some great ideas about how to plan even large software projects. Hopefully I’ll get around to summarizing his talk in a future blog, and I would certainly recommend his book to anyone that thinks Agile programmers lack discipline or a clear vision.

Agile Development

I will close up this blog by trying to make a few generalizations about Agile programming. These comments are meant not so much to be definitive, as to give me a chance to try to summarize for myself some of what I saw and learned at the conference.

Agile is broad term encompassing a set of related methodologies. These methodologies usually emphasize short, iterative processes that can easily change course.

Agile methodologies tend to emphasize working code over detailed documentation. Like a good author, an Agile programmer aims to show, rather than tell. Instead of talking or documenting a project, Agile programmers like to sit down and write code, and then let the code speak for itself. The customer can then run the code to see if it does what he wants. If it does not fit the bill, the Agile technologies such as Test Driven Development are designed to be flexible and to allow easy adoption of the customer’s wishes.

Agile methodologies stand in contrast with plan-based methodologies that emphasize a set schedule and a detailed, well documented, step by step outline. Agile technologies such as Scrum or XP are considered to be adaptive, while methodologies based on schedules and plans, such as RUP or any waterfall method, are called predictive. Agile methodologies are designed to easily adaptthemselves to changing circumstances. Predictive methodologies tend toward the creation of a single, monolithic document that outlines a precise series of steps and a set timeline. This document predicts, or dictates, the course of action to be followed.

Most methodologies fit on a continuum between pure Agile methodologies and pure plan-based methodologies. Thus some RUP systems, such as OpenUP/Basic, have an Agile flavor to them. Statements made about any one methodology will therefore tend to be a generalization. In practice no one shop is likely to be a pure example of one methodology. Instead, they will mix elements of both technologies in a way they view as optimal.

Agile technologies are iterative. Predictive technologies tend to be linear. The waterfall method, for instance, sees each project progressing through a series of steps, from the early planning process that outline requirements, through the development process, and ending up with a testing, deployment and maintenance process. This linear progression should be seen in contrast to the looping, iterative nature of the Agile process.

Each iteration in most Agile processes will be relatively short, lasting not more than two to four weeks.  At the end of each iteration the team should be able to produce a working project. The project may not contain all the features the team hopes to produce in the long term, but what is included in the build should be stable.

The ability to deliver software to the customer at regular intervals makes it possible for both the customer and the team to regularly assess progress. If the assessment reveals problems or misunderstandings, then the lightweight nature of the process should make it possible to quickly and easily change course. The emphasis on iterative change is why this technology is called adaptive or agile.  

Though it is not common, some Agile teams do generate documents and plans. However, they do not generate detailed, long term plans.

Many of the principles of Agile development are summed up in the Agile Manifesto, which states, in part, that Agile practitioners value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Summary

In this blog I’ve jotted down a few impressions and thoughts on the Agile 2006 Conference. In particular, I’ve talked a little about what the conference meant to me, and I’ve given an overview of Agile development.

Hopefully I will eventually find time to focus on a single methodology, such as Scrum. Certainly Scrum proved to be one of the most frequently discussed topics at the conference.

As I said at the beginning of this blog, I heard all kinds of comments during the course of the conference. Almost everyone at the conference like some aspects of Agile programming, but few people bought into the whole package.

Most of the Microsoft employees I talked to enjoyed the conference, but some of the old hands who’d been to other Agile conferences felt that this one was not up to snuff. It was great fun and often quite enlightening to listen to them wax cynical over a fancy dinner in the Minneapolis heat. These were grizzled veterans who had seen it all, and for them the conference lacked the sparkle and excitement that a relative new comer such as myself might have experienced.

So please feel free to comment if you would like to add your opinion regarding any of the topics I discussed in this blog. I’m not here to dictate anything, but just to share some ideas and listen to what you might have to say.