Like many people, we are excited about the adoption of Agile (adaptive) project management and development in general, and about the adoption of Scrum in particular.

Unlike many people who are so dogmatic about Agile or Scrum, however, we do not believe that the current corporate world has been reorganized completely for Scrum. Maybe some commercial software companies have done that, but the large majority of corporations have not fired all their specialists or given them a new generalist title as some Scrum dogmatists believe they should. Most of these companies still have their current organizations the way they are, with many separate functions in their IT departments. CapitalOne, one of the companies that has adopted Agile often cited by many Scrum trainers, is still hiring business analysts, business systems analysts, and project managers. This is also true of many large companies known for having transitioned into Scrum, such as Sabre, Verizon, NBC Universal, General Dynamics, Texas Instruments, and American Airlines.com, just to mention a few.

We will talk more about Scrum’s origin and fundamentals later in this chapter but for now, let’s say that Scrum, as in the sport of rugby, is a way of restarting the rugby game, either after an incident or after the ball is out of play. The idea is to keep the game (software development) rolling.

Even though Scrum can be used outside of software development, we will focus in this book on Scrum as an Agile process framework for software project management and development alone.

Having managed projects in the traditional command and control style for a long time, we have both witnessed, time and again, that Agile and Scrum seem to help our teams produce software results more effectively than their command and control counterparts.

In 2001, a group of software experts got together in the Snowbird resort of Utah to draft what is known as the Agile Manifesto (www.agilemanifesto.org):

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to 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

That is, while there is value in the items on the right, we value the items on the left more.

Along with these four values, the Agile Manifesto has twelve principles:

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity—the art of maximizing the amount of work not done—is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.