New to Agile and Scrum

When looking at an agile process it is important to understand that agile is an umbrella term used to describe a general approach to software development. Though there are many agile incarnations, all agile processes, including Scrum, emphasize teamwork, frequent deliveries of working software, close customer collaboration, and the ability to respond quickly to change.

Scrum is one of many agile processes. You can think of agile as an umbrella term that encompasses other processes, such as Extreme Programming, Adaptive System Development, DSDM, Feature Driven Development, Kanban, Crystal, and more. Another way to think about the relationship between agile and Scrum is this: If my refrigerator were to break, I would go to an appliance store and be shown various refrigerators. I might see refrigerators from Maytag, General Electric, Viking, Whirlpool, Frigidaire, SubZero, Bosch and so on. I would leave the store let's say with a Maytag because its unique features best fit my needs. In the same way that Maytag is a brand of refrigerator, Scrum is a brand of agile.

Unlike refrigerators, however, you can customize an agile process to better fit your team. You can choose to primarily use Scrum, for instance, but also incorporate some of the desirable features of the other agile processes. For example, many teams that use Scrum also employ test driven development and pair programming, both of which are components of Extreme Programming. The flexibility of the agile processes is a large part of their appeal.

Transitioning to a new process is hard. The benefits of doing so must outweigh the cost. Organizations that have made the switch to an agile process like Scrum report the following benefits, all of which are related and build on each other:

 

  • Higher productivity
  • Higher quality
  • Reduced time-to-market
  • Improved stakeholder satisfaction
  • Increased job satisfaction
  • More engaged employees

 

Having more engaged employees leads to more productivity gains, initiating a virtuous cycle of continuous improvement. The data behind these claims are available in chapter 1 of Succeeding with Agile.

If whatever process you're using today is working, by all means stick with it. Keep in mind, though, that the rate of change in the world has accelerated dramatically over the past 30 years and especially over the past 10. Product development cycles that were acceptable 10 years ago would be laughable now.

There is no reason not to expect this quickening trend to continue. Today's “fast enough” will likely not be fast enough tomorrow. In order to remain competitive, companies developing software need a process that can help them keep up with the accelerating rate of change. An agile process like Scrum help teams develop software more quickly and at lower costs, giving them a competitive advantage in a fast-paced market.

Scrum has been around a lot longer than you may think. The first paper on Scrum appeared in the Harvard Business Review in January 1986. Software teams started using Scrum in 1993. Other agile processes started popping up shortly after this but the term “agile” was first applied to Scrum and similar processes in early 2001. With this long history, agile processes like Scrum have clearly passed the fad stage. In fact, a 2009 survey by SearchSoftwareQuality found that 56% of organizations were using an agile process on at least some of their projects.

Of course they don't have to write all code in pairs, but that might be worthwhile on some projects and for some programmers. Pair programming is one of the Extreme Programming (XP) practices. But because it can often be a great idea, it has expanded beyond XP and into teams using other agile approaches, such as Scrum. Every agile team should experiment with pair programming and figure out when it's appropriate for them and their project. It's quite possible that it's not 100% of the time, but it's even more likely that it's not 0%.

Change begins when an awareness that the status quo could be improved turns into a desire to do something different. All of the awareness and desire in the world, however, won't get you anywhere if you do not also acquire the ability to be agile. You will need not only to learn new skills but also to unlearn old ones, including the following:

  • New technical skills, such as test automation and design evolution
  • How to think and work as a team
  • How to create working software within short timeboxes

Because Scrum is sufficiently different from traditional software development, training along with on-site coaching or mentoring is usually required. What seems to work best for most companies is some initial training, oriented at creating a willingness to try Scrum and to understanding its core principles. This general training is usually then followed up with practice-specific training or coaching, such as bringing a test-driven development expert on-site to work hands-on with teams in their code. Mountain Goat Software offers training and onsite coaching to help you and your team get started and get better at agile. To reinforce training, companies should provide opportunities (wikis, informal lunch-and-learns, cross-team exchanges) for teams to share information with each other.

Above all, don't stall, waiting to know all the answers before you start. The best way to develop the ability to do something is to start doing it.


Additional Resources

Recommended Courses