Trends and Terms in Agile PM

Overview

In the previous chapters, we discussed all the project management concepts and methods by mostly referring to the waterfall (predictive, traditional) project management approach implicitly or explicitly. Although all these concepts and methods are applicable to agile (adaptive) projects, these projects are developed on evolving requirements accompanied by an upfront planning which is not as comprehensive as it is in waterfall approach. Rather, the planning in agile approach is spread throughout the projects over separate iterations, sprints, or timeboxes. Each short iteration allows the project team to refine the requirements in accordance with the uncertainties, risks, technological changes, and stakeholder expectations and concerns. This chapter will first discuss the historical background of agile project frameworks and methods, and their key principles. Then, it will describe the factors to consider when adopting an agile approach, identify the elements of an agile environment, and elaborate on the most common agile methods and scaling frameworks. Finally, this chapter will address the recent trends in agile project management according to the 15th State of Agile Report.

Source: Abdullah Oguz, https://pressbooks.ulib.csuohio.edu/project-management-navigating-the-complexity/chapter/12-0-learning-objectives-and-overview/
This work is licensed under a Creative Commons Attribution 4.0 License.

Introduction to Agile

1980s and 1990s were the years software development teams started to have serious problems with developing and finishing their software projects which were getting more complex with more computer power and digitalization of businesses and organizations. Project managers and developers faced more and more problems when they were using the traditional waterfall approach (Figure 12.2 in the section 12.1.2). The development of software necessitated more collaboration among the project manager, developers, testers and users, and constant feedback from the users. Besides, new requirements were emerging while the software was being developed, and the client and end users were not always happy with the final product when they had the chance to see it after some time passed. Therefore, new methods started to emerge among software developers who lead this type of projects. Lean methodology created by Toyota for their production system, and utilized by many manufacturers was an inspiration for many of these software developers. In addition to the lean manufacturing process, just-in-time process and total quality management movement were other influencers of agile project management. Furthermore, Kanban which is a process improvement method in manufacturing was adapted to the software development life cycle.

As indicated above, new methods began to emerge in the 1980s and mostly in the 1990s as a response to some of the challenges that developers faced when using a waterfall approach.

One of the first to become popular was Rapid Application Development (RAD). James Martin, an IT consultant, developed an approach through which he divided the process into four distinct phases, namely, (1) requirements planning phase, (2) user design phase, (3) construction phase, and (4) cutover phase. It involved creating prototypes and using them to elicit requirements, validate designs and evolve toward usable solutions (Figure 12.1). RAD, itself, led to the development of alternative approaches as well.

Before Agile Alliance had their first meeting in 1999, there had been a diversification of agile methods which were called as lightweight methods as compared to the heavyweight waterfall models. The most popular methods were Crystal methods (1992), Dynamic Systems Development Model (DSDM) (1995), Scrum (1995), Feature Driven Development (FDD) (1997), Extreme Programming (XP) (1999), and Adaptive Software Development (ASD) (2000). Through the 1990s, a number of alternative ways to organize and structure the development of software products emerged as mentioned above, and they eventually evolved into the "agile" in 2001 with "Agile Manifesto".

Agile Manifesto

At their initial meeting in 1999, the pioneers of agile methods discussed the similarity of XP with other methods and decided to meet again, with a broader range of people, to explore common ground. In 2001, a group of 17 people met at Snowbird Ski Resort in Utah to talk, ski, relax and try to find common ground between their thoughts on software development. They represented the leading thinkers from XP, Scrum, DSDM, ASD, Crystal, FDD and Pragmatic Programming, along with others who wanted a viable alternative to traditional heavyweight and documentation-driven development processes. They published the "Agile Manifesto" that embodied the values they all believed in and a set of guiding principles (Figure 12.2). Thus, the Agile Alliance was born.

Twelve Agile Principles behind the Agile Manifesto are listed below:

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

Differences between Waterfall and Agile Methods

As can be seen in Figure 12.3, in the waterfall (predictive, traditional) project management approach, the process is linear and sequential. Project teams should finish one stage to proceed with the following stage. As seen in Figure 12.3, the agile (adaptive) project management approach compresses the sequential phases in small timeboxes. Therefore, agile teams work on a limited number of requirements (i.e., user stories) at a time, and they can receive frequent stakeholder feedback at the end of each timebox when they create a partial working product.

The frequent interaction with the client and stakeholders offers an environment where the frustration level of stakeholders is minimized. Nevertheless, agile methods may not be appropriate for all projects. Waterfall project approach may work better when:

• Requirements are very well understood and can be fixed before the implementation begins.
• Client's and customers' expectations from the product is stable and substantial changes can be avoided.
• Technology and the tools utilized are understood very well by the stakeholders, and changes that may affect the project's progress are not expected.
• The duration of the project is relatively short.
• The uncertainty is at a low level.
• Resources are available, and easy to acquire.

Therefore, we can implement a waterfall project when we expect low uncertainty and define the project and product scope, and project constraints easily with clear and unambiguous procedures. The production domain and processes involved are usually well understood and there are typically low levels of execution uncertainty and risk. However, if we cannot define the product scope, and uncertainty level is high, an agile approach would be better to move gradually by clarifying the requirements and uncertainties with the active involvement of clients and stakeholders.

In agile projects, client and stakeholder involvement can be provided constantly since product owners are a part of the team, and the increments are reviewed by the product owner and the client frequently. In waterfall projects, the interaction with the client is deferred to the end of a phase, for instance, when the software coding and testing are complete. However, in real life projects, teams often implement a hybrid approach which is a blend of waterfall approach and some principles of agile such as client involvement and feedback.

An Example: Grocery LLC Decides on the Project Approach for the "Self-Checkout Stations Project"

As discussed in section 1.2.3 titled "Case Study 1.1: Characteristics of a Project Undertaken by Grocery LLC", the grocery chain, Grocery LLC, considers establishing self-checkout station areas in all fifty branches to find a solution to long lines in front of the current checkout stations where the cashiers work. The project selection committee discussed the solution and decided to implement this project. As part of requirements elicitation, business analysis team surveyed managers and employees, and interviewed customers. Besides, the team visited the competitors' markets and made market research to have a better understanding of possible solutions in the market. The team concluded that self-checkout has been increasingly deployed in many grocery store and pharmacy chains (e.g., Walmart, Target, CVS) across the United States, and the manufacturers and service providers are experience. Therefore, the sponsor, project manager, and relevant departments had a meeting to discuss the project management approach. They decided to implement a waterfall approach supported by continuous stakeholder interaction as is done in agile methods.

• Managers, employees, and customers conveyed their requirements. The analysis revealed that requirements are consistent with the current implementations and the research consultancy company's report. Therefore, it was concluded that requirements are very well understood and can be fixed to a large extent before the implementation begins. However, in order to keep up with the technological advancements and to be prepared for the risks such as new waves of pandemic, it was decided to establish a continuous interaction and feedback system with the stakeholders.
• There are experienced companies which provide competitive prices to acquire the systems. They implemented numerous projects across the United States. They have comprehensive knowledge of the current and upcoming technologies.
• The duration of the project is 8 months.

An Example: Grocery LLC Decides on the Project Approach for the "M-Commerce Project".

As discussed in "Case Study 1.2: Characteristics of Another Project Undertaken by Grocery LLC (M-Commerce Project)", the grocery chain, Grocery LLC, considers having a better online presence by creating a mobile app and optimizing the website for mobile devices in particular due to the negative effects of pandemic on the number of in-store customers, hence significantly decreased revenue and profit. In the initiation stage, project manager prepared a report justifying the need for conducting an agile methodology, i.e., Scrum, during this project in order to accelerate the pace and achieve the outcome in a relatively shorter time, receive constant and timely feedback from the employees and customers, keep a healthy interaction with the stakeholders, and adjust the specifications to the fast and unprecedented changing technologies and socioeconomic conditions. Since it was not easy for the project manager and the team to oversee the near future in a turbulent environment (e.g., Covid cases and hospitalizations rocketing to the peak in a very short time), the sponsor and the project steering committee supported the project manager's decision to implement an agile method. The Scrum cycles (sprints) were set as two weeks so that a working app and mobile website can be developed gradually with some of the requirements and functions at the end of each sprint, which can allow frequent end-user feedback and interaction.

Adopting and Creating an Agile Environment

A Case Study of the Penta Transformations

A Six-Month Cultural Transformation: The Penta Story

Penta Technologies, a family-owned construction software company in Wisconsin, developed and provided customized accounting and finance ERP systems, labor productivity suites, and payroll tools for construction back-office services. However, the convenience of customization led to more complicated workload for the project teams and employees while it was a relief for the clients. Rather than focusing on the effectiveness of projects and their outcomes, the company dealt mostly with the contract negotiation and customer emergencies. The main issues were the implementation of a traditional project management approach that made the frequency of delivery slow and inconsistent. However, the solution was not that easy just by switching to an agile structure. The president and the COO figured out that there are organizational and cultural barriers that need to be overcome first. First of all, they reduced the number of executives to three, which simplified the decision making and allowed space for the team to identify the most urgent issue, optimizing the product development teams. But this was only the initial step to transition to a more agile structure. The COO announced that they were going to partner with everyone in the organization to figure out the best structure for the business. As a result, employees' feedback was aggregated in five areas that need attention: (1) Remove functional silos, (2) more ownership in the work, (3) remove unnecessary and complex processes, (4) stop micromanagement and improve trust, and (5) more focus on value. Based on this valuable employee feedback, a team conducted research on different organizational structures. The team suggested a transition to the Scrum framework which a team-based and servant-leadership organizational structure. This was just the beginning for Penta. However, this case showed that organizations need to evaluate the current organizational structure and culture, and develop a novel background and mindset over which they can build the new agile structure. A new house cannot be constructed over an old and torn foundation. We need to ensure that the foundation is so strong that it can bear.

Creating a Novel Mindset: Agile

As can be seen in the case study of Penta Technologies above, organizations don't start creating, adopting and implementing an agile project approach in one day as is the case for all the actions organizations should take. A long and well-thought-out process is inevitable to generate ideas effectively, which can benefit the organization in the long term. As for the agile environment, the challenging process requires adoption of an agile mindset that spans throughout the organization including the executive team, managers, supervisors, and all other employees. At the very beginning, organizations and their project teams and leaders should answer many questions, some of which are provided below, to develop an implementation strategy:

• How can organizations, their employees, and project teams and in particular, their members, act in an agile manner?
  • Are there organizational impediments that we need take care of (e.g., issues in formal structure such governance and policies, and informal structure such as organizational culture)?
  • What are the levels of acceptance and resistance that we may expect from the executives, managers, employees, project managers, and team members?
  • How can we measure these levels (e.g. survey, interviews, focus group meetings) so that we can create an action plan?
  • What kind of activities (e.g., seminars, webinars, training, social events) do we need to organize?
• What can our teams deliver quickly and obtain early feedback to benefit the next delivery cycle?
  • Are our products appropriate for quick incremental deliverables?
• How can the teams act in a transparent manner?
• What works can be avoided in order to focus on high-priority items?
• How can a servant-leadership approach benefit the achievement of the team's goals and project objectives?

Benefits and Challenges of Agile Project Management

When organizations start utilizing agile project management approach and principles, they can expect to see the benefits below:

• They can find opportunities to deliver business benefits at an early stage through addressing straightforward problems.
• They can shorten the time to introduce new products and services to the markets and customers.
• They can increase and maintain the adaptability to changing needs of customers.
• They can achieve an improved quality of products and services through short cycles and constant client and stakeholder interaction and feedback.
• Ultimately, they can maximize the return on investment.

Gustavsson examined the literature to list the common benefits of implementing agile project management in a non-software development context. Top ten benefits indicated by Gustavsson are listed below:

• Better collaboration in the team
• Increased customer interaction
• Increased productivity and speed
• Increased flexibility in coping with the change
• Better understanding of goals/tasks/requirements
• Increased transparency and visibility
• Increased quality
• Customer-centered value adding priority process
• Increased knowledge sharing
• Increased cross-organizational collaboration

However, Gustavsson also examined the problems and challenges while adopting and implementing agile approach, and outlined eleven challenges as below:

• Changing mindset to allow flexibility
• Lack of process visibility
• Buy-in from managers
• Difficult to see benefits early in the project
• Inadequate knowledge sharing
• Individual work, lack of communication
• Long-term planning
• Lack of stakeholder engagement
• Scope creep (uncontrolled expansion of the scope with product requirements and project activities)
• Insufficient resource allocation
• Redundant work

These results demonstrate that no one system, approach, or methodology is alone perfect. Project managers and team members always need to take into account the coexistence of pros and cons of anything used in a project by incorporating the cost-benefit analysis. While increased knowledge sharing was indicated as a benefit, challenges presented a challenge of inadequate knowledge sharing. Thus, decision-makers and project managers should consider the factors that may cause inadequate knowledge sharing in an agile environment. This is also valid for other elements such as flexibility, communication, early delivery, and resources as well as triple constraints (i.e., scope, schedule, and budget).

Regarding the project success, Serrador and Pinto's  quantitative analysis of 1.002 projects across multiple industries and countries concluded that agile methods have a positive impact on two dimensions of project success which are efficiency and overall stakeholder satisfaction against organizational goals.

The Elements of an Agile Environment

Although the roles and the practices of each agile method and framework vary from one to another, there are common roles and practices across them. In this section, we will elaborate on these.

Common Agile Roles and How Agile Team Works

There are three main roles in agile teams.

1. Cross-functional and self-organizing teams and their members
2. Product owner
3. Team facilitator

Considering the self-organizing structure of agile teams and the role of project manager as a team facilitator and servant leader, we can first focus on the team members who form the agile teams. Cross-functional teams consist of members with various skills from different areas. If it is a software development team, it can be composed of designers, systems analysts, developers, testers, and business unit representatives. Team members discuss the tasks and pick the ones they think would fit the best. Team facilitator (or the project manager) doesn't tell who should do what, but acts as an obstacle remover and a coordinator. Agile teams generally work during short cycles (i.e., iterations) to release a working product, an incomplete but a testable partial product, which is named as increments. Rather than creating the whole website with its all backend features in three months, these teams create a number of web pages with some of the properties and functions in a short time (e.g., a two-week iteration). In the end of each iteration, the team presents the increment in the form of a partial product (e.g., three web pages). The product owner representing the client and the end-users provide the feedback about what they think of these three web pages. They may say "We want the navigation bar at the top with that size and those colors" or "The pictures should not cover more than one third of the row while not zoomed in". These increments help the team receive feedback constantly. Therefore, they can work on each increment based on the feedback, and they can improve the product. This provides the team with the opportunity to make timely and effective interventions which otherwise would cause serious problems at the end of the project. So, when the team receives the feedback as regards the navigation bar's position and color, they apply the request to the current and future web page layouts. However, another feedback may still want the team to change the position and color. This is an ongoing process with constant interaction with the client, end users, and stakeholders. In a waterfall project management approach, the team finishes the development of the whole website, and submit it to the client for the inspection of the client and its end users. However, in the meantime, a three-month duration passes, and the possibility of receiving feedback from the client that can lead to a serious rework could be high.

As is discussed above, these teams are self-organizing teams, which means that team members decide on the tasks that each will work during an iteration, rather than a team facilitator tell them what they need to do. Agile teams are generally small teams smaller than 10 members. These teams use techniques to collaborate more effectively such as pairing, swarming, and mobbing. Pairing is generally utilized by XP (Extreme Programming) teams when software developers write codes. While one member works on coding, the second member checks the quality of the coding made by the first member. Another collaboration technique is swarming through which multiple team members focus collectively on resolving a specific impediment.

A second agile role is the product owner who is responsible for guiding the direction of the product. Product owners can be a representative of the internal or external client, or a person who represents the client and the stakeholders. Product owners keep a constant daily communication with the agile team. They provide the product backlog which includes the user stories (requirements), and prioritize the user stories. Product owners are the bridge between the clients (and their end-users, customer and stakeholders) and the agile team. The feedback conveyed by the product owner is used to develop the increments at each cycle. Product owners communicate with subject matter experts to produce good-quality user stories (requirements) and offer effective feedback. Recently, IIBA (International Institute of Business Analysis) have offered a new certificate, "Certificate in Product Ownership Analysis", which integrates product ownership and business analysis.

The third and the final role is a team facilitator which can be also named as project manager, scrum master, project team lead, or team coach based on the method or framework utilized, and/or the organization's guidelines. In agile teams, project managers' role is different from the traditional role they play in waterfall (predictive) project management. Generally, in traditional approach, project managers are the ultimate authority in a team who decides which tasks are carried by which member. Their authority with respect to the control is high. However, in agile teams, project managers should be the facilitators and coaches, and they need to adopt a servant leadership approach. Team members organize the tasks that needs to be carried out during a cycle. Project managers help them in removing the impediments, overcoming the conflicts inside the team or with stakeholders, and coaching the members to allow them to improve their skills. For example, if team members find themselves in a conflict with a stakeholder and cannot solve the issue themselves, the project manager gets involved to resolve the conflict. Or developers in the team may ask the project manager to buy a license for a software which can help them produce a better quality IT solution or complete the activities earlier. Servant leaders empower their teams and facilitate their teams' success by promoting self-awareness, listening, helping people grow, coaching, promoting safety, respect and trust, and promoting the energy and intelligence of others. They practice their leading through service to the team focusing on understanding and addressing the needs and development of team members. Hence, interpersonal skills such as team building, motivating, communicating, influencing, decision making, political and cultural awareness, negotiating, facilitating, managing conflict, and coaching are more important than the technical skills.

Common Agile Practices

Agile teams utilize various artifacts and events to conduct their tasks and achieve project objectives. Although they are used in different agile methods with same or different names, the Scrum framework which is the most common agile method make use of all of these artifacts and events. They are:

1. Team charter
2. User stories and backlog
3. Planning of each iteration or cycle (Not a comprehensive upfront planning)
4. Daily standups
5. Demonstration or reviews
6. Retrospectives
7. Backlog refinement

A team charter is necessary for all types of projects. It consists of team values, working agreements, ground rules, and group norms. It is a social contract which indicates how the team members interact with each other. The primary objective of a team charter is to create an agile environment where project managers, team members, and product owner can work to the best of their ability. In agile projects, the team charter has to define what "ready" and "done" mean. In particular, when teams use a Kanban board (see Figure 12.5), tasks are organized on a timebox (i.e., cycle, iteration, Scrum sprint) to display and monitor their status such as to-do, doing (in progress), and done. Teams can assess the completeness of user stories and tasks according to the definition of "done". Therefore, they can evaluate the completed tasks consistently.

User stories are requirements presented in a story form for the team to understand the needs of the client and stakeholders. They, together, establish the product backlog, the basis of the plan and each iteration. The structure of a user story is given below. These stories don't only convey what a stakeholder expects from a product or service, but also includes the reason why that stakeholder needs. The project team can better understand why the stakeholder asks for a requirement. It can give a clue to the team if the requirement is a must or not, or if it is possible to incorporate into the product.

• As a "user/stakeholder", I want to "perform a function / an action / an app feature" so that I can "acquire a benefit / an expected outcome".

Let's consider that our grocery chain's m-commerce project is conducted as an agile project. Therefore, we have created some of the user stories. It is of high importance to keep in mind that product owner doesn't need to list all the user stories since one of the advantages of agile projects is that a product evolves throughout the project based on the feedback of the end-users. Three user stories are provided below as examples that can be used in this m-commerce project:

• As a customer, I want to browse all the items under relevant categories (e.g., bakery, beverages, laundry and cleaning, electronics) so that I can find the items I am looking for and view all the related items on a single window or page, or more than one page with the page numbers displayed at the bottom of each page.
• As an administrator, I want to disable accounts which are not valid anymore so that we can manage the active accounts and archive the disabled accounts.
• As a shopper (or a store employee who is picking up the ordered items from the shelves), I want to view all the online orders assigned to me on my mobile device so that I can start shopping two hours before the delivery begins.

Table 12.1 exhibits four user stories selected from our m-commerce project. In order to keep the user story column shorter, we removed the "so that" part which provides the reasoning of why the stakeholder needs this requirement.

Product owners prioritize the user stories. Before each cycle starts, sufficient numbers of user stories with the highest priority are pulled from the backlog so that the team can work on these user stories. Let's assume that the user stories in Table 12.1 were selected for the first cycle / timebox since the team decided to pull the highest priority user stories for the first cycle. Priority is only one factor to consider while selecting the user stories. Teams also estimate the story size taking into account the estimated time to finish and other criteria such as the effort and resources required to complete these tasks. Analogous estimating technique that takes into account the information from other projects, experience of project managers and team members from previous projects, and lessons learned helps the teams to create these estimates. Estimations are very important to make a better planning if the team can complete them in one cycle or iteration. While scrum teams set a specific time to finish each iteration (e.g., 1 week, 2 weeks, 30 days), Kanban teams focus on the user stories by means WIP (Work in Progress) limits. Therefore, Kanban teams don't necessarily set a timebox, but they commit to completing an increment of work by focusing on a limited number of manageable tasks.

Instead of carrying out an overall project planning and trying to predict all the aspects of a project (e.g., scope, requirements, schedule, cost) as is done in waterfall project before the implementation phase starts, agile projects work on a limited number of requirements. Thus, planning can be done at the beginning of each cycle, which allows the team to adjust itself according to the feedback from end-users, and changing requirements and conditions. As the project progresses, agile teams generally spend less time in the initial phases (e.g., requirements, planning, design as exhibited in Figure 12.4). Hence, they can focus more on implementation.

Another practice in agile projects is the daily standup meetings which occur mostly in the early morning before starting the daily tasks. They are called standup meetings since members generally stand up instead of sitting so that they can accelerate the meetings by avoiding the comfort of sitting. Although team members don't meet in person at the collocated offices as it used to be due to the wider utilization of virtual teams recently and because of the Covid-19 pandemic measures that mandated to stay at home, agile teams continue holding these standup meetings, being the mostly utilized agile practice, in online platforms such as Microsoft Teams and Zoom. The project leader or a team member can take the lead in standup meetings. In general, team members discuss the three questions below:

1. What have I completed since the last standup meeting?
2. What am I planning to complete until the next standup meeting?
3. What are the impediments, risks and problems that I may encounter?

When teams create an increment (e.g., a website with three web pages, an EPR module for accounting with limited functions, a prototype of a machine that is intended to manufacture spare auto parts) at the end of a cycle, they can demonstrate how this increment works. The product owner assesses the demonstration and collects the feedback from end-users. Therefore, the team can continue building upon the increment according to the feedback. Although negative feedback from the product owner may lead to a frustration for the team, frequent feedback in earlier stages prevents the team from heading in a wrong direction. The team leader's servant leadership role as a coach can help the team enable frequent delivery.

At the end of each cycle, agile teams discuss what worked and what could have been better in that cycle. These retrospectives help the teams learn from their previous work. The lesson learned process becomes more frequent in line with the review and feedback from the product owner and end-users. As one of the agile principles indicate, "at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." Teams may also decide to retrospect at different times, not only limited to the end of the cycles. For example, the project manager may call for a retrospective meeting when the team is stuck and cannot complete the work. Therefore, this meeting can help the team determine the underlying reason of the bottleneck and find a solution with a facilitated brainstorming session.

The last common agile practice to mention is the backlog refinement process which occurs generally in the middle of iterations. In this refinement meetings, product owners present story ideas to the team and the team learns about the potential challenges or problems in the stories.

Common Agile Framework and Methods

Although there are many agile approaches, only several of them are utilized commonly by organizations. The Agile Practice Guide by PMI (Project Management Institute) lists the single-team agile methods as below:

1. Scrum
2. Extreme Programming (XP)
3. Kanban
4. Crystal methods
5. Scrumban
6. Feature-Driven Development (FDD)
7. Dynamic Systems Development Method (DSDM)
8. Agile Unified Process (AgileUP)

Besides single-team agile approaches, higher-than-single-team level (e.g., enterprise-level) scaling frameworks are provided below:

1. Scrum of Scrums
2. Scaled Agile Framework (SAFe®)
3. Large Scale Scrum (LeSS)
4. Enterprise Scrum
5. Disciplined Agile (DA)

Scrum

Scrum is the most utilized single-team agile method. It consists of roles, events, artifacts, and rules. Scrum events are sprints, sprint planning, daily scrum, sprint review, and spring retrospective. Scrum artifacts are product backlog, sprint backlog, and increments. It uses an iterative approach to deliver a working product (i.e., an increment) at the end of each timebox. These timeboxes are called sprints which last generally for one month, or four weeks, or shorter with consistent durations. When a two-week sprint duration is determined, all the sprints are set at two weeks. At the end each sprint, a potentially releasable increment of product is produced. A scrum team is composed of product owner, development team, and scrum master. 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.

Kanban

The Japanese word "kanban" means "visual board" or a "sign". It was first developed and applied by Toyota as a scheduling system for just-in-time manufacturing. The workflow is visualized on a Kanban (Figure 12.5). The Kanban board is also used by Scrum teams.

The work is split into pieces, and each item is written on a card. Then, they are put on the wall, or it can be visualized in a software program or a website such as Jira. Explicit limits are assigned in Kanban projects so that each workflow state can have limited number of in-progress items (Work in Progress – WIP). The team tries to finish these tasks in the shortest possible time. This lead time is measured so that the team can optimize the process to make the lead time as small and predictable as possible.

Scrumban

Scrumban is an agile approach originally designed as a way to transition from Scrum to Kanban. Scrumban teams use Scrum as a framework and Kanban for process improvement. It uses the prescriptive nature of Scrum to be agile, and uses the process improvement of Kanban to allow the team to continually improve its process. In Scrumban, the work is organized into small "sprints" and leverages the use of Kanban boards to visualize and monitor the work. There are no predefined roles in Scrumban as is the case in Kanban. However, the Scrumban teams generally retain the Scrum roles.

eXtreme Programming (XP)

As the name implies, XP is utilized by software teams. It is an agile software development framework that aims to produce higher quality software, and higher quality of life for the development team. XP is the most specific of the agile frameworks regarding appropriate engineering practices for software development. This method does not only focus on project management like other methods and frameworks do, but also focuses on how teams actually build code. Like Scrum, it has practices and values that help teams get into an effective mindset. One of the primary practices of XP is pair programming through which coding process is conducted by two developers working together at a single computer. While one member works on coding, the second member checks the quality of the coding made by the first member. Another unique XP practice is the coding the unit test first. Before writing the code, a unit test is created so that new codes are automatically tested.

SAFe® (Scaled Agile Framework)

The SAFe is the most common scaling framework according to the 15th State of Agile Report published in 2021. Thirty-seven percent of respondents indicated that their organization applies SAFe while 9% uses scrum of scrums and 6% uses enterprise scrum. The SAFe focuses on providing a knowledge base of patterns for scaling development work across all levels of the enterprise (Figure 12.6). It also focuses on detailing practices, roles, and activities at the portfolio, program, and team levels. SAFe organizes the enterprise around value streams that focus on providing continuous value to the customer.

Recent Trends in Agile Project Management

Organizations, whether they are multinational corporations, non-profits, government agencies, or international organizations, often make use of agile project methods and frameworks. Although agile started with the software development projects (see Section 12.1), its utilization has become common in other IT projects, and eventually non-IT projects such as new product development projects have practiced agile methods increasingly. A survey conducted by PMI (Project Management Institute) found that 23% of the organizations worldwide utilized agile techniques whereas 47% used predictive approach. However, another 23% also used hybrid approaches (e.g., using waterfall's sequential and linear project life cycle stages while establishing a more frequent communication and feedback system with the client and stakeholders).

A recent study is the 15th State of Agile Report conducted in 2021 by digital.ai. Their data is up-to-date and reflect the impact of COVID-19 pandemic. Their sample is dominantly composed of people who work in agile teams or in organizations which implement agile approach. This report highlights salient insights from the practice as detailed below:

• The most popular agile approach is Scrum. 66% of the respondents identified Scrum as the methodology they follow most closely. Besides, 9% indicated that they use ScrumBan and 6% blends the Scrum with XP. Therefore, Scrum's share is 81% in total.
• The most popular scaling approach is SAFe with 37%. SAFe was followed by Scrum@Scale / Scrum of Scrums (9%) and Enterprise Scrum (6%).
• The top five agile techniques and practices used by the organizations are daily standups (87%), retrospectives (83%), sprint/iteration planning (83%), sprint/iteration reviews (81%), and short iterations (63%).
• The top five agile planning and delivery tools are Kanban boards (77%), taskboards (67%) spreadsheets (66%), agile project management tools (64%), and bug trackers (62%).
• The top five reasons to adopt agile are "enhance ability to manage changing priorities", "accelerate software delivery", "increase team productivity", "improve business and IT alignment", and "enhance software quality".
• The top five challenges in organizations regarding agile practices are "inconsistent processes and practices across teams", "organizational culture at odds with agile values", "general organization resistance to change", "lack of skills/experience with agile methods", and "not enough leadership participation".
• Eighty-one percent of the respondents recommended Jira as a software tool in agile planning and management. Jira was followed by Digital.ai agility (formerly VersionOne) and Azure DevOps. Thirty-five percent recommended Microsoft Project.

Key Takeaways