Chapter 1
Agile

This book is geared toward Agile, but there are other software process models. Each has a different way of proceeding through the software development life cycle (SDLC). This chapter starts by describing Scrum, the SDLC, Agile, and a contrasting software process model called Waterfall. That is followed by a discussion of Scrum (an Agile framework) and notable Agile methods.

This chapter will give you the flavor of Agile and Scrum rather than being a comprehensive guide. For more detailed information about topics introduced here, see the References section at the end of the chapter.

1.1 The Software Development Life Cycle

The software development lifecycle (SDLC) is the progression of a software project through five SDLC stages:

1. Requirements: Figuring out and writing down what the software must do, how well, and under what limitations or constraints.
2. Design: Determining how the software’s code will be structured and how users will interact with the software.
3. Implementation: Using the requirements and design to code the software.
4. Testing: Checking that the code was written without fault (verification) and that the software is what the users or client wants (validation).
5. Maintenance: Improving software’s existing functionality and code.

There are different ways to travel through the SDLC stages. Patterns of traveling through the stages are called software process models. Commonly, people compare the Agile software process model with the Waterfall model.

Agile, guided by the Agile Manifesto (Beck et al., 2001), moves through the SDLC approximately like in Figure 1.1.

Note. The vertical lines represent development cycle boundaries. Planning (R,D) for the next development cycle starts during the previous cycle. R, requirements; D, design; I, implementation; T, testing; M, maintenance.

Agile development cycles are relatively short and numerous. Releases are frequent and incremental. Each cycle, there’s a little more working functionality. There are multiple ways to go about developing and managing software in an Agile way, such as by using the Scrum framework (Schwaber & Sutherland, 2020) or Extreme Programming (XP) (Beck & Andres, 2004; Wells, 2013).

Waterfall moves through the SDLC approximately like in Figure 1.2.

Movement is fairly linear and sequential. Each stage depends on the previous stage having been completed. Lots of documentation is produced.

Ironically, people often associate Waterfall with an article that describes Waterfall’s major flaws. The second figure in Royce’s (1970) article depicts the Waterfall model with seven stages and downward movement from one stage to the next, suggesting that movement to the previous stage is not allowed—you can’t swim up a waterfall. Later in the article, Royce suggests modifications to the Waterfall model, such as making and implementing a preliminary program design (then going back to the requirements stage as needed).

Waterfall might not make sense for many software projects, but how about for building a bridge?

1.1.1 Why Care about Agile, Other Software Process Models, and Software Engineering Methods?

• So you can detect and/or understand what a software development team is doing. When you’re new to a team, having a general understanding of different software process models can help you ask good questions, identify what you see the team doing, and look competent in front of your team and managers.
• So you have ideas to choose from when you need to select a software process model or method for a new project. You might need to choose or recommend how your team proceeds.
• So you have ideas to choose from when a project is in trouble. According to CHAOS Report from the Standish Group International, Inc. (2015), during fiscal years 2011 to 2015, 17% to 22% of software projects failed of the 25,000+ software projects in their database, with the likelihood of project failure increasing drastically with project size. Sometimes, you can save a project if you have the right methods.

Since this book is focused on Agile, the remainder of the chapter summarizes the Agile software process model, one Agile framework (Scrum), and a few Agile methods.

1.2 Agile, Scrum, and Agile Methods

1.2.1 Agile

The Agile philosophy is summed up by the Agile Manifesto for Software Development (Beck et al., 2001):

Why does this book have a whole chapter about Agile and not one about Waterfall or any other software process model? Because most organizations use Agile for software or IT projects.

For example, an HP survey of 601 respondents (Hewlett Packard Enterprise, 2017) found the following distribution of what organizations use as their primary software process model:

• 51%: Leaning toward Agile
• 46%: Hybrid
• 16%: Pure Agile
• 7%: Leaning toward Waterfall
• 2%: Pure Waterfall

Why do organizations choose Agile? According to HP, out of 403 organizations that have primarily adopted Agile, the following percentage of respondents agreed with the following statements about Agile development:

• 54%: Enhances collaboration between teams that don’t usually work together.
• 52%: Increases the level of software quality in organizations.
• 49%: Results in increased customer satisfaction.
• 43%: Shortens time to market.
• 42%: Reduces cost of development.

1.2.2 Scrum

Scrum is a well-known framework for software project management. It aligns with the Agile philosophy. For example, the Scrum Guide (the ever-evolving manual for Scrum; Schwaber & Sutherland, 2020) says that to reflect the “responding to change” value, a software project should be broken into development Sprints that are usually two to four weeks long. Each Sprint has a Sprint Plan. Sprint Plans can be defined shortly before the Sprint; Teams (and their customers) might only know what is happening with the project’s development for a couple weeks at a time.

Scrum Teams fit their own methods into the Scrum framework, which the current version of the Scrum Guide divides into three categories: the team, the events, and the artifacts. To give you a quick, convenient introduction to Scrum, each element of the framework is listed below, by category.

The Team. The Scrum Team “consists of one Scrum Master, one Product Owner, and Developers.”

• Scrum Master: “accountable for establishing Scrum as defined in the Scrum Guide.”
• Product Owner: “accountable for maximizing the value of the product resulting from the work of the Scrum Team.”
• Developers: “people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.”

The Scrum Master’s focus is process, the Product Owner’s focus is the product (software), and the Developers’ focus is creating a product while following Scrum processes.

The Events. There are five Scrum events:

• The Sprint: fixed-length development periods of “one month or less . . . A new Sprint starts immediately after the conclusion of the previous Sprint.”
• Sprint Planning: “initiates the Sprint by laying out the work to be performed.”
• Daily Scrum: “a 15-minute event for the Developers of the Scrum Team . . . focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work.”
• Sprint Review: “to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders . . .”
• Sprint Retrospective: “to plan ways to increase quality and effectiveness . . . Scrum Team inspects how the last Sprint went . . .”

A Sprint is a development period that occurs in a series of Sprints, which are each laid out during Sprint Planning. Each day, the Developers have a 15-minute meeting about planning the next workday. Sprints end with a Sprint Review (team and stakeholders) and a Sprint Retrospective (team only).

The Artifacts. There are three Scrum artifacts:

• Product Backlog: “an emergent, ordered list of what is needed to improve the product.”
• Sprint Backlog: “composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).”
• Increment: “a concrete stepping stone toward the Product Goal.”

The Product Backlog contains a rough list of tasks the Scrum Team is planning to do some time, but the tasks haven’t yet been scheduled and may not be defined in detail. The Sprint Backlog contains tasks the team has decided to work on and has added details about completing the tasks. An Increment is an achievement toward creating the product (e.g., finishing a feature implementation).

The Scrum Guide (Schwaber & Sutherland, 2020) describes the Scrum framework elements in more detail and defines some of the terms that were unexplained here (e.g., Sprint Goal).

1.2.3 Agile Methods

There are several notable Agile methods that can be used within Scrum (or other frameworks, or other software process models). A few of them:

• Scrum board: A way to organize and visualize tasks or work as cards on a board. The board has columns for different categories, and each card is placed within a column. A Scrum board could be a physical bulletin board with sticky notes or index cards. It is also a common feature of task management software.
• Spike: A quick and to-the-point investigation for gathering information to help the team answer a question or choose a development path.
• User story: A short description of a software feature from the perspective of fulfilling a user need (e.g., using this format: As a <role> I can <capability>, so that <receive benefit>). Tasks, priorities, time/cost estimates, and acceptance criteria may be associated with a user story.

1.3 Summary

“Agile” has associated values but no concrete meaning: it’s a philosophy, and there’s not just one way to follow it. Agile frameworks such as Scrum give more concrete guidance on software development and project management. Scrum is defined by the current version of the Scrum Guide (Schwaber & Sutherland, 2020), which changes frequently.

References

Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R. C., Mellor, S., Schwaber, K., Sutherland, J., & Thomas, D. (2001). Manifesto for Agile software development. https://agilemanifesto.org/

Beck, K., & Andres, C. (2004). Extreme programming explained: Embrace change (2nd ed.). Addison-Wesley.

Hewlett Packard Enterprise (2017). Agile is the new normal: Adopting Agile project management. https://softwaretestinggenius.com/docs/4aa5-7619.pdf

Royce, W. W. (1970). Managing the development of large software systems. Proceedings of IEEE WESCON, 26, 1-9.

Schwaber, K., & Sutherland, J. (2020, November). The 2020 scrum guide. https://scrumguides.org/scrum-guide.html

Standish Group International, Inc. (2015). CHAOS report 2015. https://standishgroup.com/sample_research_files/CHAOSReport2015-Final.pdf

Wells, D. (2013, October 13). Extreme programming: A gentle introduction. http://www.extremeprogramming.org/