Introducing Agile

In the mid 1990’s, as a reaction to heavyweight waterfall based processes, some other methods emerged. Good examples of these methods are DSDM, RAD, Crystal, XP and Scrum. Not that the people behind them were against process. They just strived to free themselves of Dilbert-like manifestations of process in corporate life, of people hiding behind pointless regulations, managers disrupting the working environment and enforcing unfounded plans and teams producing hundreds of pages of documentation that were impossible to maintain and hardly ever used. They strived for cooperation instead of throwing the result of hard work over a cubicle wall without a proper transfer session and without a clue of what the person on the other side of that wall would be going to do with it.

These methods have in common that they

• Are lightweight 
• Involve the customer
• Have short cycles (2 to 4 weeks, enabling rapid delivery and frequent inspection and adaptation)
• Focus on eliminating waste from the process
• Are keen on the human aspect of software development 

In 2001 a number of representatives from these lightweight methods convened in a ski resort in Utah to establish some common ground. Among them were Kent Beck, the creator of Extreme Programming and Ken Schwaber and Jeff Sutherland, the creators of Scrum. Most participants did not expect any tangible result to come from a gathering of such stubborn, know-it-all methodologists. Nevertheless two important outcomes are to be noted and still influence the world of software development today.

• These lightweight methods were from then on to be known as Agile.
• Agile methods are now guided by the Agile Manifesto , a statement of values that all participants of that gathering agreed on (see The Agile Spirit). 

An overview of events surrounding the introduction of the development methods used in this book, Scrum, XP and RUP is shown in Figure 2.

Figure 2: Timeline Agile and Iterative Software Development Methods

Introducing Scrum
Scrum originates from an article published in 1986 on holistic software development using one cross-functional team across all phases of development. In the article this approach was compared with playing rugby where the whole team takes the ball forward (as opposed to a relay race where a baton is passed on from player to player).

Figure 3: Relay Race versus Rugby

In a relay race a baton is passed along from one player to the next. This is similar to a waterfall approach in IT, where a group of experts carry out one phase in the development of an IT-solution (requirements, analysis and design,  implementation or testing). When they are done they pass the result on to a next group of experts for the next phase. If one player doesn’t make it or drops the baton (often while passing it on), the race is lost. In rugby, time after time the team take possession of the ball and as a team try to get it across the field to score a touchdown (or as a team try to prevent a touchdown when the opposing team has the ball). This is much more like the Agile way of working where a team as a whole delivers working, usable software every two to four weeks.

In the early nineties, Ken Schwaber and Jeff Sutherland each separately developed an Agile management approach. In 1995 they jointly  presented their ideas at the OOPSL ‘95 (an object-oriented programming conference) under the name of Scrum (a rugby term). In 2001 the first book on Scrum “Agile Software Development with Scrum” by Ken Schwaber and Mike Beedle was published. A lot more have followed since then.

Scrum is a framework for self-organization of Agile teams. With only 3 roles, 4 work products and 5 events it sets up an easy to learn process for incremental software delivery, guided by business needs that is further explained in the post about Section 3.2. It helps the team to deliver value to the customer early and gives complete openness to all stakeholders concerning tasks that are being done, work remaining toward the development goal, the teams development velocity and impediments that keep the team from performing at their best. Because of its clear focus on self-organization of teams it is easy to combine with other methods that focus more on the specialist or project management side of IT development. Scrum is often used in combination with XP (eXtreme Programming).

Introducing XP
Around 1996 Kent Beck, a prominent Smalltalk practitioner at Crysler, started refining a set of day to day software development practices that made sense to him. To work out some difficulties his team were having, he asked them to take these practices to their extremes and leave out all others -- and it worked. These practices were first published on the newly evolving internet and since 1999 bundled and further expanded in a series of books, starting with his own book “Extreme Programming Explained”.

XP focuses on improving software quality and responding to change. It’s practices encompass timeboxing, test-first development (writing automated tests before programming), pair programming (working in pairs behind one computer), refactoring (to achieve simplicity and clarity of code), continuous integration (building the code and running outomated tests preferably each time code is checked in), customer involvement and the planning game (for estimating, clarifying requirements and getting commitment from the team). Some of these practices will be discussed in the post about Maintaining Stability.

Other Relevant Posts: 
Introducing RUP
Comparing Methods
The Agile Spirit
Self-organization
Maintaining Stability