Scrum at the Agile 2006 Conference
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 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.
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.