16 Agile

“Agile is the ability to create and respond to change. It is a way of dealing with, and ultimately succeeding in, an uncertain and turbulent environment.”¹ It’s really about considering what’s going on in the environment that you’re in today, identifying what uncertainty you’re facing, and figuring out how you can adapt to that as you go along.² The one thing that separates agile from other approaches is that solutions evolve through collaboration between self-organizing cross-functional teams. “Agile is a mind-set based on a set of key values and principles designed to better enable collaborative work and deliver continuous value through a ‘people-first’ orientation.”³ “Agile” is also an umbrella term used to describe many different frameworks and practices that support the values and principles expressed in the Agile Manifesto and the 12 Principles behind the Agile Manifesto.

History of Agile

During the 1990s, software developers realized they needed to change the way they were building software. By mixing old and new ideas, they found a combination that worked.

These methodologies were collectively referred to as agile software development methods, and they emphasized close collaboration between the development team and business stakeholders. During this time, different frameworks started to grow, but there was no consistent way of describing the different approaches for developing software. In 2001, 17 software developers met to discuss these agile software development methods and together they published the “Manifesto for Agile Software Development.” The Agile Alliance was formed shortly after this gathering to encourage practitioners to further explore and share ideas and experiences.⁴

In 2011, the Agile Alliance created the Guide to Agile Practices (renamed the Agile Glossary in 2016), an evolving open-source compendium of the working definitions of agile practices, terms, and elements, along with interpretations and experience guidelines from the worldwide community of agile practitioners. The Agile Manifesto provided a set of value statements that form the foundation for agile software development. In the months afterward, the authors expanded on these ideas with the 12 Principles behind the agile manifesto.

Agile Manifesto and 12 Principles behind the Agile Manifesto

Agile is a mindset informed by the values contained in the Agile Manifesto and the 12 Principles behind the Agile Manifesto.⁵ Those values and principles provide guidance on how to create and respond to change and how to deal with uncertainty.

Project Life Cycles: From Predictive to Adaptive (Waterfall to Agile)

As stated in chapter 5, “Process Overview,” a project life cycle provides the basic framework for managing the project. In chapter 5, we discussed the traditional or waterfall life cycle. The traditional/waterfall life cycle is also known as predictive. On the other hand is the agile life cycle, which is known as adaptive. Other life cycles include iterative, incremental, and hybrid.

This section begins with a discussion on the predictive (water-fall) life cycle and ends with a discussion on the agile life cycle. The hybrid life cycle combines predictive and adaptive, or multiple adaptive frameworks, to create a tailored life cycle to meet the needs of the organization. Figure 16.1 provides a view of the phases contained in the waterfall and agile life cycles.

Predictive

A predictive life cycle (figure 16.2), also known as the waterfall life cycle, is considered a more traditional approach, which takes advantage of things that are known and proven. This reduced uncertainty and complexity allows teams to segment work into a sequence of predictable groupings, such as requirements, analysis, design, build, test, and so on. The bulk of planning occurs upfront; requirements are fixed; project scope, time, and cost are set early in the life cycle and are managed through change control; and activities are executed in a single pass, with a sequential process.

Iterative

An iterative life cycle (figure 16.3) allows feedback to occur on partially completed or unfinished work, so the work can be improved or modified. Requirements are dynamic, project scope is set early in the life cycle, time and cost are modified as more information becomes available, and activities are repeated until correct. During the analysis and design phases the teams may deliver a prototype to the customer for feedback. Customer feedback helps the team to learn what is needed, allowing for refinements to occur during the build and test phases.

Incremental

The incremental life cycle (figure 16.4) provides finished deliverables that the customer may be able to use immediately. The requirements are dynamic, and activities are performed once for a given increment.

Agile

Agile is also known as adaptive. Agile includes both iterative and incremental approaches to refine work items and deliver frequency. Requirements are dynamic and activities are repeated until correct. The agile life cycle is shown in figure 16.5.

When teams use agile approaches, they iterate over the product to create finished deliverables. The team gains early feedback and can release earlier, which provides an earlier return on investment because the team delivers the highest value work first.

Agile and the Project Management Knowledge Areas

Agile ideas apply to many disciplines. When you think of agile as an adjective, it describes the way in which you perform some activity. Therefore, agile in project management explains how we might perform project management in a way that allows us to create and respond to change and deal with uncertainty. Therefore, the Agile Alliance and Project Management Institute (PMI) created the Agile Practice Guide, which explores the use of agile approaches. PMBOK® Guide, sixth edition, integrates agile concepts with the 10 knowledge areas.

• Project integration management—“Agile approaches promote the engagement of team members. Team members determine how plans and components should integrate.”⁹

“The project manager’s focus is on building a collaborative decision-making environment and ensuring the team has the ability to respond to changes.”¹⁰

For small projects include cross-functional team members in project discussions during iterative planning, stand-up meetings, and project retrospectives. Use visual management tools to enhance collaboration.

• Project scope management—“In projects with evolving requirements, high risk, or significant uncertainty, the scope is often not understood at the beginning of the project or it evolves during the project.”¹¹

“Agile methods deliberately spend less time trying to define and agree on scope in the early stage of the project and spend more time establishing the process for its ongoing discovery and refinement. Many environments with emerging requirements find that there is often a gap between the real business requirements and the business requirements that were originally stated.”¹² Agile methods allow you to build release versions in order to refine requirements.

For small projects, refine and redefine the scope, and define and manage requirements throughout the project. Use a backlog to list everything that is known to be needed for the project.

• Project schedule management—“Adaptive approaches use short cycles, undertake work, review the results, and adapt as necessary.”¹³

Adaptive planning allows for new knowledge to be incorporated, which may drive changing priorities. Short cycles provide rapid feedback on approaches for iterative schedules and incremental deliverables.

The project manager, in an agile environment, will need to include the use of agile tools and techniques for developing and managing the project schedule.

For small projects use a Kanban board to manage the flow of the work.

• Project cost management—“Projects with high degrees of uncertainty or those where the scope is not yet fully defined may not benefit from detailed cost calculations due to frequent changes.”¹⁴

“Lightweight estimation methods can be used to generate a fast, high-level forecast of project labor costs, which can then be easily adjusted as changes arise. Detailed estimates are reserved for short-term planning horizons in a just-in-time fashion.”¹⁵

In small projects, as the scope and schedule are adjusted, the cost forecasts can be easily adjusted to stay in alignment.

• Project quality management—“In order to navigate changes agile methods call for frequent quality and review steps built in throughout the project rather than toward the end of the project.”¹⁶

“Recurring retrospectives regularly check on the effectiveness of the quality processes. They look for the root causes of issues and then suggest trials of new approaches to improve quality.”¹⁷

For small projects, use small batch systems to uncover inconsistences and quality issues, early in the process.

• Project resource management—“Projects with high variability benefit from team structures that maximize focus and collaboration, such as self-organizing teams with generalizing specialists.”¹⁸

The project manager should use collaboration to boost productivity and facilitate innovative problem solving. Use collaboration tools to facilitate team discussions and decision making.

For small projects, use collaborative and supportive management to allow for team-based decision making.

• Project communications management—“Project environments subject to various elements of ambiguity and change have an inherent need to communicate evolving and emerging details more frequently and quickly.”¹⁹

Project managers should post project artifacts in a transparent fashion and communicate regularly with project stakeholders.

• Project risk management—“High-variability environments, by definition, incur more uncertainty and risk. To address this, project management using adaptive approaches makes use of frequent reviews of incremental work products and cross-functional project teams to accelerate knowledge sharing and ensure that risk is understood and managed.”²⁰

“Risk is considered when selecting the content of each iteration, and risks will also be identified, analyzed, and managed during each iteration.”²¹

• Project procurement management—“In agile environments, specific sellers may be used to extend the team. This collaborative working relationship can lead to a shared risk procurement model where both the buyer and the seller share in the risk and rewards associated with a project.”²²

• Project stakeholder management—“Projects experiencing a high degree of change require active engagement and participation with project stakeholders.”²³

“To facilitate timely, productive discussion and decision making, adaptive teams engage with stakeholders directly rather than going through layers of management.”²⁴

In order to accelerate the sharing of information within and across the organization, agile methods promote aggressive transparency. The intent of inviting any stakeholders to project meetings and reviews or posting project artifacts in public spaces is to surface as quickly as possible any misalignment, dependency, or other issue related to the changing project.

Servant Leadership

Servant leadership is a leadership philosophy in which the main goal of the leader is to serve. The phrase “servant leadership” was coined by Robert K. Greenleaf in “The Servant as Leader,” an essay that he first published in 1970. In that essay, Greenleaf said: “The servant-leader is servant first.”²⁵ A servant-leader focuses primarily on the growth and well-being of people and the communities to which they belong. While traditional leadership generally involves the accumulation and exercise of power by one at the top of the pyramid, servant leadership is different. The servant-leader shares power, puts the needs of others first, and helps people develop and perform as highly as possible.

Servant leadership is emphasized in agile approaches as a way to empower teams. It is the practice of leading through service to the team by focusing on understanding and addressing the needs and development of team members in order to enable the highest possible team performance. According to the Agile Practice Guide, “the role of the servant leader is to facilitate the team’s discovery and definition of agile.”²⁶ Servant-leaders approach project work in this order.

• Purpose—Work with the team to define the why or purpose so they can engage and coalesce around the goal for the project. The entire team optimizes at the project level, not the person level.

• People—Once the purpose is established, encourage the team to create an environment where everyone can succeed. Ask each team member to contribute across the project work.

• Process—Do not plan on following the perfect agile process, but instead look for the results.²⁷

Servant-leaders educate stakeholders on agile practices, support the team through mentoring, encouragement, and professional development, help the team with technical project management activities, and celebrate team success. In an agile environment, project managers shift from being the center to serving the team and management. As a servant-leader, project managers change their emphasis to coaching team members, fostering greater collaboration on the team, and aligning stakeholder needs. This shift allows the team, the people with the knowledge, to get the work done.

Agile Teams

Agile teams are cross-functional, self-organizing entities that can define, build, and test a solution. They are optimized for communication and delivery of business value. The work is sized and sequenced so that incremental value can be delivered every two weeks. Ideally, agile teams range from three to nine members, colocated in a team space, and members are 100 percent dedicated to the team.

Roles and Responsibilities

Agile teams are structured for creative collaboration and can include the following roles: project manager, cross-functional team members, product owner, and team facilitator.

Scrum Master

The scrum master serves the team and management. As a servant-leader, the scrum master coaches those who want help, fosters greater collaboration on the team, aligns stakeholder needs, and encourages those people who have the knowledge to get the work done.

The scrum master needs to respond quickly to change. It is about having access to information and having the ability to understand how to use that information to support the project team and respond to project stakeholders. This requires a strong relationship between the scrum master and business owner for efficient and effective information sharing for collaboration and prioritization.

In an agile environment, the scrum master needs to understand how the project aligns with the organization’s strategic objectives and the business requirements for meeting the project objectives. Therefore, as identified by PMI, strategic and business management skills are required along with technical project management and leadership skills.

Cross-Functional Team Members

Cross-functional team members have the skills necessary to produce a working product. They can deliver the finished work in the shortest possible time, with higher quality—especially when there are no external dependencies. These teams are self-organizing, are flexible and creative, are empowered to manage their work, and are accountable for product delivery.

Product Owner

The product owner is responsible for providing vision and guiding the direction of the product. The product owner works with project stake-holders to define boundaries for the project and works with the team daily to provide feedback and set the direction on the next piece of work to be developed/delivered. This is accomplished by reviewing and reprioritizing the team backlog that is used for iteration planning. In addition, the product owner coordinates work dependencies with other product owners as a part of iteration planning. Finally, the product owner is responsible for defining “done” by defining the acceptance criteria for user stories and determining when the user stories are done.

Team Facilitator

The team facilitator operates as a servant-leader to facilitate, coach, and remove impediments. A key responsibility is to protect the team from external forces by removing impediments and barriers. In addition, this person helps the team to learn and follow agile principles and practices. This role may be handled by a project manager, scrum master, project team lead, team coach, or team facilitator.

Team Structure

The agile team structure could consist of self-managing, cross-functional, colocated, and/or dedicated teams.

Self-Managing

Agile teams are self-managing. Within this team, each member is equally important (no hierarchy), but responsibilities are clearly defined. This means that each team member should get equal opportunity to voice his or her opinion. Together, they can then form a solution. Ultimately, the product owner gets the final say about prioritization, but all other discussions are guided by the scrum master to a solution everybody agrees with.

Cross-Functional

The team should possess all knowledge required to deliver a working product. This does not mean that each team member should be the perfect developer and have all of this knowledge, but this knowledge needs to be spread across team members.

Colocated

Agile methods suggest close collaboration. Ideally, the entire team would be sitting in the same room so that there are no barriers (no matter how small) to communication. When team members are spread out over different rooms, locations, or time zones, it is normal for people to postpone their interaction.

For small Projects, teams may not be colocated. Therefore, teams should schedule dedicated working time and use team workspaces. Dedicated working time in a common location would allow team members to work uninterrupted for a period of time. Technology such as video conferencing, document sharing, and other collaboration tools should be used for collaboration. Using video cameras during virtual conferencing sessions will allow team members to be more engaged during the sessions and help build relationships and foster trust.

Dedicated

Every member of the team should be assigned to the project full time, as any distraction will just delay work. Focused work is far more effective than switching between assignments or dividing attention between two projects. Being dedicated to a single project is also the best way to take up ownership and responsibility (allowing for better self-management).

A concern is that when the team is not 100 percent dedicated, team members lose productivity by multitasking. Multitasking reduces the throughput on the team’s work and impacts the team’s ability to predict delivery consistently.

For small projects, team members are not always fully dedicated to a single project. They often work on multiple small projects or a small project and operational activities. It is important to note that people experience productivity losses, somewhere between 20 percent to 40 percent, when task switching. And people are more likely to make mistakes when they multitask. Therefore, careful planning and the use of collaboration tools will help with the use of an agile methodology.

Tools and Techniques

Tools and techniques consist of Scrum, Kanban method, and Scrumban.

Scrum

Scrum is a single-term process framework used to manage product development. The framework consists of Scrum roles, artifacts, and rules, and uses an iterative approach to deliver working product. Scrum is run on timeboxes of one month or less with consistent durations called sprints where a potentially releasable increment of product is produced.

The scrum board (figure 16.6) shows the sprint backlog, the work that is in process, and the work that has been completed.

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 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.

Scrum

Kanban Method

Kanban is a visual process management system. The word Kanban is literally translated as “visual sign,” “card,” or “sign board.” Kanban boards enable and promote the visualization and flow of the work through the system for everyone to see. This display is made up of columns that represent the states the work needs to flow through. A simple board could have three columns to represent to-do, doing, and done. The Kanban board could also be arranged by the activities in the project life cycle; for example, to-do, analysis, development, test, delivery. The Kanban method is utilized and applicable in many settings and allows for a continuous flow of work and value to the customer.

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.

• Focus on continuous delivery—Teams are focused on work flowing 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 nonvalue-added activities and removing the nonvalue-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.³¹

Kanban boards provide clear insight to workflow, bottlenecks, blockers, and overall status. They allow you to limit work-in-progress by setting limits on the maximum amount of work that can exist in each status of the workflow and by defining preconditions that must be fulfilled before work will begin. The Kanban board in figure 16.7 allows the team to identify the backlog items as well as what is in process and done for each of the analysis, build, and test activities.

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 limits and get each piece of work through the system to done.

Scrum and Kanban

Scrumban

As stated in the Agile Practice Guide, 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 it 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.

The Scrumban approach is suitable for small projects because it provides the flexibility of the agile methodology and can be easily adapted to the needs of the project.

Common Practices

Common practices include user stories, retrospectives, backlog preparation and refinement, and daily standups.

User Stories

A user story is a short, simple description of a feature as told from the perspective of the person who desires the new capability, written by the team that will be doing the work. Each user story is expected to provide a contribution to the value of the overall product. The goal of the user story is to provide clarity on what will be developed in enough detail so the team will know how to implement.

Retrospectives

Retrospectives are an important practice because they allow the team to learn from previous work on the product and its process. A retrospective usually occurs after an iteration, about every two weeks. They can also occur after a release or after the team reaches a project milestone.

The purpose of a retrospective is to learn from the previous work and to make small improvements. During the retrospective, the team looks at qualitative (people’s feelings) and quantitative (measurements) data to find root causes, design countermeasures, and develop action plans.

Backlog Preparation and Refinement

The backlog is an ordered list of all the work for the team. This work is presented in story form that is sufficient enough to understand the current iteration and broad enough to understand the next iteration.

Daily Standups

Daily standups should take no longer than 15 minutes. This allows the team to engage in discussion to allow them to uncover problems and ensure the work flows smoothly. During the daily stand-ups, everyone answers the following questions:

• What did I complete since the last standup?

• What am I planning to complete between now and the next standup?

• What are my impediments (or risks or problems)?

PROJECT EXAMPLE

Dallas Lee is the project manager for a software development project. He planned the project using the waterfall method and has included phases for requirements, analysis, build, test, and release activities. The organization has decided to transition from the waterfall methodology to agile, and Dallas is filling the role of scrum master. A portion of the waterfall version of the project schedule is shown in figure 16.8. Dallas planned the first three sprints as shown in the sprint planning sheet and sprint planning board, figures 16.9 and 16.10, respectively.

Now that Dallas is using the agile methodology, he created user stories for each sprint. An example of one of Dallas’s user stories is shown in figure 16.11.