ANNEX A3

OVERVIEW OF AGILE AND LEAN FRAMEWORKS

This annex describes some of the commonly used agile approaches. These approaches can be used as is or combined to adapt to what works best for a given environment or situation. It is not necessary to use any of these; an agile approach can be developed from scratch as long as it adheres to the mindset, values, and principles of the Agile Manifesto. If the agile principles are followed to deliver value at a sustainable pace, and the developed approach promotes collaboration with the customer, a specific approach is not required. A link to more information regarding each approach can be found in the Bibliography section of this guide.

A3.1 SELECTION CRITERIA FOR THE AGILE PRACTICE GUIDE

There are too many agile approaches and techniques to be explicitly included in this practice guide. Figure A3-1 depicts a sample of agile approaches based on their depth of guidance and breadth of their life cycles. The specific approaches selected for discussion are popular examples that are:

• Designed for holistic use. Some agile approaches are centered on a single project activity, such as estimation or reflecting. The listed examples include only the more holistic agile frameworks. Some are more full-featured than others, but all of the selected approaches are those intended to guide a broad set of project activities.
• Formalized for common use. Some agile frameworks are proprietary in nature and designed for specific use by a single organization or within a single context. The frameworks described in Sections A3.2 through A3.14 focus on those intended for common use in a variety of contexts.
• Popular in modern use. Some agile frameworks are holistically designed and well formalized, but are simply not commonly being used in most projects or organizations. The agile frameworks described in this annex have been adopted by a significant number of industries, as measured by a collection of recent industry surveys.

A3.2 SCRUM

Scrum is a single-team process framework used to manage product development. The framework consists of Scrum roles, events, artifacts, and rules, and uses an iterative approach to deliver working product. Scrum is run on timeboxes of 1 month or less with consistent durations called sprints where a potentially releasable increment of product is produced. Table A3-1 lists Scrum events and artifacts utilized for project execution.

The Scrum team consists of a product owner, development team, and scrum master.

• The product owner is responsible for maximizing the value of the product.
• The development team is a cross-functional, self-organizing team consisting of team members who have everything they need within the team to deliver working product without depending on others outside of the team.
• The scrum master is responsible for ensuring the Scrum process is upheld and works to ensure the Scrum team adheres to the practices and rules as well as coaches the team on removing impediments.

Table A3-1. Scrum Events and Artifacts

Events	Artifacts
Sprint	Product backlog
Sprint planning	Sprint backlog
Daily scrum	Increments
Sprint review
Sprint retrospective

A3.3 EXTREME PROGRAMMING

eXtreme Programming (XP) is a software development method based on frequent cycles. The name is based on the philosophy of distilling a given best practice to its purest, simplest form, and applying that practice continuously throughout the project.

XP is most known for popularizing a holistic set of practices intended to improve the results of software projects. The method was first formalized as a set of twelve primary practices, but then gradually evolved to adopt several other corollary practices. These are listed in Table A3-2.

Table A3-2. The Practices of eXtreme Programming

XP Practice Area	Primary	Secondary
Organizational	• Sit together	• Real customer involvement
	• Whole team	• Team continuity
	• Informative workspace	• Sustainable pace
Technical	• Pair programming	• Shared code/collective ownership
	• Test-first programming	• Documentation from code and tests
	• Incremental design	• Refactoring
Planning	• User stories	• Root cause analysis
	• Weekly cycle	• Shrinking teams
	• Quarterly cycle	• Pay per use
	• Slack	• Negotiated scope contract
		• Daily standups
Integration	• 10-minute build	• Single code base
	• Continuous integration	• Incremental deployment
	• Test-first	• Daily deployment

This evolution was the result of designing and adopting techniques through the filter of core values (communication, simplicity, feedback, courage, respect), and informed by key principles (humanity, economics, mutual benefit, self-similarity, improvement, diversity, reflection, flow, opportunity, redundancy, failure, quality, baby steps, accepted responsibility).

A3.4 KANBAN METHOD

Kanban in lean manufacturing is a system for scheduling inventory control and replenishment. This process of “just-in-time” inventory replenishment was originally seen in grocery stores when shelves were restocked based on the gaps in the shelves and not supplier inventory. Inspired by these just-in-time inventory systems, Taiichi Ohno developed Kanban and it was applied at the main Toyota manufacturing facility in 1953.

The word kanban is literally translated as “visual sign” or “card.” Physical kanban boards with cards enable and promote the visualization and flow of the work through the system for everyone to see. This information radiator (large display) is made up of columns that represent the states the work needs to flow through in order to get to done. The simplest of boards could have three columns (i.e., to do, doing, and done), but it is adaptable to whatever states are deemed needed by the team utilizing it.

The Kanban Method is utilized and applicable in many settings and allows for a continuous flow of work and value to the customer. The Kanban Method is less prescriptive than some agile approaches and thus less disruptive to begin implementing as it is the original “start where you are” method. Organizations can begin applying Kanban Methods with relative ease and progress toward fully implementing the method if that is what they deem necessary or appropriate.

Unlike most agile approaches, the Kanban Method does not prescribe the use of timeboxed iterations. Iterations can be used within the Kanban Method, but the principle of pulling single items through the process continuously and limiting work in progress to optimize flow should always remain intact. The Kanban Method may be best used when a team or organization is in need of the following conditions:

• Flexibility. Teams are typically not bound by timeboxes and will work on the highest priority item in the backlog of work.
• Focus on continuous delivery. Teams are focused on flowing work through the system to completion and not beginning new work until work in progress is completed.
• Increased productivity and quality. Productivity and quality are increased by limiting work in progress.
• Increased efficiency. Checking each task for value adding or non-value-added activities and removing the non-value adding activities.
• Team member focus. Limited work in progress allows the team to focus on the current work.
• Variability in the workload. When there is unpredictability in the way that work arrives, and it becomes impossible for teams to make predictable commitments; even for short periods of time.
• Reduction of waste. Transparency makes waste visible so it can be removed.

The Kanban Method is derived from lean thinking principles. The defining principles and the core properties of the Kanban Method are listed in Table A3-3.

The Kanban Method is a holistic framework for incremental, evolutionary process and systems change for organizations. The method uses a “pull system” to move the work through the process. When the team completes an item, the team can pull an item into that step.

Table A3-3. Defining Principles and Properties of the Kanban Method

Defining Principles	Core Properties
Start with current state Agree to pursue incremental, evolutionary change Respect the current process, roles, responsibilities, and titles Encourage acts of leadership at all levels	Visualize the workflow Limit work in progress Manage flow Make process policies explicit Implement feedback loops Improve collaboratively

Kanban boards, such as the one shown in Figure A3-2, are a low-tech, high-touch technology that may seem overly simplistic at first, but those using them soon realize their power. Utilizing policies for entry and exit to columns, as well as constraints such as limiting work in process, kanban boards provide clear insight to workflow, bottlenecks, blockers, and overall status. Additionally the board acts as an information radiator to anyone who sees it, providing up-to-date information on the status of the work of the team.

In the Kanban Method, it is more important to complete work than it is to start new work. There is no value derived from work that is not completed so the team works together to implement and adhere to the work in progress (WIP) limits and get each piece of work through the system to “done.”

A3.5 CRYSTAL METHODS

Crystal is a family of methodologies. Crystal methodologies are designed to scale, and provide a selection of methodology rigor based on project size (number of people involved in the project) and the criticality of the project.

Crystal Methodology realizes that each project may require a slightly tailored set of policies, practices, and processes in order to meet the project's unique characteristics. The family of methodologies use different colors based on “weight” to determine which methodology to use. The use of the word crystal comes from the gemstone where the various “faces” represent underlying core principles and values. The faces are a representation of techniques, tools, standards, and roles listed in Table A3-4.

Table A3-4. The Core Values and Common Properties of Crystal

Core Values	Common PropertiesA
People	Frequent delivery
Interaction	Reflective improvement
Community	Close or osmotic communication
Skills	Personal safety
Talents	Focus
Communications	Easy access to expert users
	Technical environment with automated tests, configuration management, and frequent integration

^A The more these properties are in a project, the more likely it is to succeed.

A3.6 SCRUMBAN

Scrumban is an agile approach originally designed as a way to transition from Scrum to Kanban. As additional agile frameworks and methodologies emerged, it became an evolving hybrid framework in and of itself where teams use Scrum as a framework and Kanban for process improvement.

In Scrumban, the work is organized into small “sprints” and leverages the use of kanban boards to visualize and monitor the work. The stories are placed on the kanban board and the team manages its work by using work-in-progress limits. Daily meetings are held to maintain the collaboration between the team and to remove impediments. A planning trigger is set in place for the team to know when to plan next, typically when the work-in-progress level is lower than a predetermined limit. There are no predefined roles in Scrumban—the team retains their current roles.

A3.7 FEATURE-DRIVEN DEVELOPMENT

Feature-Driven Development (FDD) was developed to meet the specific needs of a large software development project. Features relate to a small business value capability.

There are six primary roles on a Feature-Driven Development project where individuals can take on one or more of the following roles:

• Project manager,
• Chief architect,
• Development manager,
• Chief programmer,
• Class owner, and/or
• Domain expert.

A Feature-Driven Development project is organized around five processes or activities, which are performed iteratively:

• Develop an overall model,
• Build a features list,
• Plan by feature,
• Design by feature, and
• Build by features.

The life cycle flow and interaction of these five processes is illustrated in Figure A3-4.

Feature-Driven Development activities are supported by a core set of software engineering best practices:

• Domain object modeling,
• Developing by feature,
• Individual class ownership,
• Feature teams,
• Inspections,
• Configuration management,
• Regular builds, and
• Visibility of progress and results.

A3.8 DYNAMIC SYSTEMS DEVELOPMENT METHOD

Dynamic Systems Development Method (DSDM) is an agile project delivery framework initially designed to add more rigor to existing iterative methods popular in the 1990s. It was developed as a noncommercial collaboration among industry leaders.

DSDM is known best for its emphasis on constraint-driven delivery. The framework will set cost, quality, and time at the outset, and then use formalized prioritization of scope to meet those constraints as shown in Figure A3-5.

Eight principles guide the use of the DSDM framework:

• Focus on the business need.
• Deliver on time.
• Collaborate.
• Never compromise quality.
• Build incrementally from firm foundations.
• Develop iteratively.
• Communicate continuously and clearly.
• Demonstrate control (use appropriate techniques).

A3.9 AGILE UNIFIED PROCESS

The Agile Unified Process (AgileUP) is an offshoot of the Unified Process (UP) for software projects. It features more accelerated cycles and less heavyweight processes than its Unified Process predecessor. The intent is to perform more iterative cycles across seven key disciplines, and incorporate the associated feedback before formal delivery. The disciplines along with guiding principles are listed in Table A3-5.

Table A3-5. The Key Elements of the Agile Unified Process

Disciplines within a Release	Principles Guiding the Disciplines
Model	The team knows what it's doing
Implementation	Simplicity
Test	Agility
Deployment	Focus on high-value activities
Configuration management	Tool independence
Project management	Tailoring to fit
Environment	Situationally specific

A3.10 SCALING FRAMEWORKS

A3.10.1 SCRUM OF SCRUMS

Scrum of Scrums (SoS), also known as “meta Scrum,” is a technique used when two or more Scrum teams consisting of three to nine members each need to coordinate their work instead of one large Scrum team. A representative from each team attends a meeting with the other team representative(s), potentially daily but typically two to three times a week. The daily meeting is conducted similar to the daily standup in Scrum where the representative reports completed work, next set of work, any current impediments, and potential upcoming impediments that might block the other team(s). The goal is to ensure the teams are coordinating work and removing impediments to optimize the efficiency of all the teams.

Large projects with several teams may result in conducting a Scrum of Scrum of Scrums, which follows the same pattern as SoS with a representative from each SoS reporting into a larger group of representatives as shown in Figure A3-6.

A3.11 SCALED AGILE FRAMEWORK

The Scaled Agile Framework (SAFe®) focuses on providing a knowledge base of patterns for scaling development work across all levels of the enterprise.

SAFe® is focused on the following principles:

• Take an economic view.
• Apply systems thinking.
• Assume variability; preserve options.
• Build incrementally with fast, integrated learning cycles.
• Base milestones on objective evaluation of working systems.
• Visualize and limit work in progress, reduce batch sizes, and manage queue lengths.
• Apply cadence; synchronize with cross-domain planning.
• Unlock the intrinsic motivation of knowledge workers.
• Decentralize decision making.

SAFe® focuses on detailing practices, roles, and activities at the portfolio, program, and team levels with an emphasis on organizing the enterprise around value streams that focus on providing continuous value to the customer.

A3.12 LARGE SCALE SCRUM (LeSS)

Large Scale Scrum (LeSS) is a framework for organizing several development teams toward a common goal extending the Scrum method shown in Figure A3-6. The core organizing principle is to retain as much as possible of the elements of the conventional single-team Scrum model. This helps minimize any extensions to the model that might create unnecessary confusion or complexity. Table A3-6 shows a comparison of LeSS and Scrum.

Table A3-6. Comparison of LeSS and Scrum

Similarities of LeSS and Scrum	LeSS Techniques Added to Scrum
One single product backlog One definition of done for all teams One potentially shippable product increment at the end of each sprint One product owner Complete, cross-functional teams One sprint	Sprint planning is more formally divided into two parts of what and how Organic cross-team coordination Overall cross-team refinement Overall retrospective focused on cross-team improvements

In order to extend Scrum without losing its essence, LeSS promotes the use of certain discerning principles, such as systems thinking, whole product focus, transparency, and others.

A3.13 ENTERPRISE SCRUM

Enterprise Scrum is a framework designed to apply the Scrum method on a more holistic organizational level rather than a single product development effort. Specifically, the framework advises organization leaders to:

• Extend the use of Scrum across all aspects of the organization;
• Generalize the Scrum techniques to apply easily at those various aspects; and
• Scale the Scrum method with supplemental techniques as necessary.

The intent is to use agile approaches beyond project execution by enabling disruptive innovation.

A3.14 DISCIPLINED AGILE (DA)

Disciplined Agile (DA) is a process decision framework that integrates several agile best practices into a comprehensive model. DA was designed to offer a balance between those popular methods deemed to be either too narrow in focus (e.g., Scrum) or too prescriptive in detail (e.g., AgileUP). To achieve that balance, it blends various agile techniques according to the following principles:

• People-first. Enumerating roles and organization elements at various levels.
• Learning-oriented. Encouraging collaborative improvement.
• Full delivery life cycle. Promoting several fit-for-purpose life cycles.
• Goal-driven. Tailoring processes to achieve specific outcomes.
• Enterprise awareness. Offering guidance on cross-departmental governance.
• Scalable. Covering multiple dimensions of program complexity.