Charlie Calvert's Community Blog : Agile

Scrum at the Agile 2006 Conference

Charlie Calvert — Thu, 10 Aug 2006 02:43:00 GMT

It’s time to add some more information about my trip to the Agile 2006 Conference. One of the big themes that kept coming up at the conference was Scrum, a popular technique for implementing Agile technologies.

The Scrum methodology was perhaps the most popular single Agile technique discussed at the conference. Many of the Scrum talks were well attended, but I heard a number of fierce discussions about the quality of the material delivered to the conference goers. There was an uneasy sense among some of the veteran conference attendees that Scrum needed to make some advances in order to prove itself truly effective, and that there were some serious questions about how well it could be adapted for use in very large projects.

Scrum

Scrum was created in the early nineties by Ken Schwaber and Jeff Sutherland. Their work was based on management techniques developed in Japan during the 1980’s. These Japanese innovators were not software developers, but auto and consumer manufacturers.

As a software methodology, Scrum assumes that most challenges encountered in the business world are too complicated to be clearly defined. Instead, one works to achieve an “agile” process that can easily adapt to changing requirements and unexpected developments.

The scrum process starts with a backlog of tasks. Teams of 6 or 7 individuals are formed. They agree to work in short iterations and to produce frequent deliveries. In very large projects, Schwaber talked about creating a Scrum of Scrums, so that teams of 6 or 7 individuals were grouped together into larger teams. No one team would have more than 6 or 7 members, but multiple teams could work together to form a larger unit.

Each iteration might last two weeks, with a delivery to the customer of working software after each iteration, or at least once a month. Each delivery should include the completion of one or more backlog items. However, if the software is not running properly, then there should be no delivery.

A scrum process includes short daily meetings with all team members and the key stakeholders, including the customer. A deep, honest and impassioned involvement with and by the customer is absolutely necessary.

The meetings have to be honest. If there are problems, they should be surfaced immediately. Since the team is having daily meetings, no problem should stay hidden for longer than 24 hours.

There is no leader of the team. Instead, there is a scrum master whose primary job is to eliminate impediments such as outside interference. In particular, the scrum master should make sure that management doesn’t bother developers with demands that break their concentration or ruin their morale.

Successful Scrum teams become adept at verbal communication. There is a huge emphasis on meeting face to face. In fact, Scrum teams work in a single open space, called a bull pen, where face to face communication is not only encouraged, but inevitable. Getting developers to give up their offices and move into a bull pen is one of the more difficult steps encountered by adopters of this methodology.

Because of the active, verbal communication found on agile teams, silence is generally frowned upon and regarded as a sign that the system is broken. Agile teams sit together, and communicate frequently. At one of the talks I saw, Ken Schwaber said that he knew a process was broken when he came for a visit, and saw all the developers hunched over their machines, not saying a word.

It would be a mistake, however, to regard a good Scrum team as undisciplined or unfocused. They follow a rigorous discipline based on active communication and short iterative cycles. They tend to rely on working code rather than on detailed plans. Nevertheless, they aim to create high quality code, and to work together closely to achieve clearly defined short-term goals.

Summary

During his talk Schwaber said that the word Scrum was chosen because it has an ugly, informal sound, and is derived from a particularly chaotic part of a rugby game. The word is meant to invoke the informal, noisy, hardworking atmosphere that prevails in a happy Scrum team.

Introducing Scrum into a company is often difficult, as it challenges many of the preconceptions found in most corporate environments. Developers need to change their habits, the customer needs to get heavily involved in the development process, and VP’s have to accept change on a large scale. Schwaber says, however, that when these steps are followed, Scrum has proved to be successful in both small and large development projects.

The Agile 2006 Conference

Charlie Calvert — Wed, 02 Aug 2006 02:13:00 GMT

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 adapt themselves 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.