12.2 Adopting and Creating an Agile Environment

12.2.1 Creating a Novel Mindset: Agile

As 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 adopting an agile mindset throughout the organization, including the executive team, managers, supervisors, and all other employees. Initially, organizations and their project teams and leaders should answer many questions, some of which are provided below, to develop an implementation strategy^[2]:

• How can organizations, their employees, project teams, and, in particular, their members act in an agile manner?
  • Are there organizational impediments we must address (e.g., issues in formal structures such as governance and policies and informal structures such as organizational culture)?
  • What levels of acceptance and resistance may we expect from the executives, managers, employees, project managers, and team members?
  • How can we measure these levels (e.g., surveys, interviews, focus group meetings) to create an action plan?
  • What activities (e.g., seminars, webinars, training, social events) must we 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 transparently?
• What works can be avoided to focus on high-priority items?
• How can a servant-leadership approach benefit the achievement of the team’s goals and project objectives?

12.2.2 Benefits and Challenges of Agile Project Management

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

• They can find opportunities to deliver business benefits early by 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 the changing needs of customers.
• They can improve the quality of their products and services through short cycles and constant client and stakeholder interaction and feedback.
• Ultimately, they can maximize the return on investment.

Based on a literature review^[3], a study listed the top ten benefits of implementing agile project management in a non-software development context as below:

1. Better collaboration in the team
2. Increased customer interaction
3. Increased productivity and speed
4. Increased flexibility in coping with the change
5. Better understanding of goals/tasks/requirements
6. Increased transparency and visibility
7. Increased quality
8. Customer-centered value-adding priority process
9. Increased knowledge sharing
10. Increased cross-organizational collaboration

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

1. Changing the mindset to allow flexibility
2. Lack of process visibility
3. Buy-in from managers
4. Difficult to see benefits early in the project
5. Inadequate knowledge sharing
6. Individual work, lack of communication
7. Long-term planning
8. Lack of stakeholder engagement
9. Scope creep (uncontrolled expansion of the scope with product requirements and project activities)
10. Insufficient resource allocation
11. Redundant work

These results demonstrate that no system, approach, or methodology is perfect alone. Project managers and team members always need to weigh the pros and cons of each approach, incorporating a cost-benefit analysis. While organizations benefit from increased knowledge sharing across some areas, there may still be gaps where knowledge is not effectively shared, leading to critical issues. Thus, decision-makers and project managers should consider the factors hindering effective knowledge sharing in an agile environment. This is also valid for other elements such as flexibility, communication, early delivery, resources, and the triple constraints (i.e., scope, schedule, and budget).

12.2.3 Some Agile Frameworks and Methods

Although there are many agile approaches, only several are utilized commonly by organizations. The Agile Practice Guide by PMI (Project Management Institute)^[4] 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)

12.2.3.1 Scrum

Scrum is the most utilized single-team agile framework. Section 12.3 in this Chapter comprehensively explains the Scrum framework.

12.2.3.2 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^[5]. The workflow is visualized on a Kanban (Figure 12.2.1). Scrum teams also use the Kanban board to track the progress of activities in a Sprint.

^[6]

The work is split into pieces, and each item is written on a card. Then, they are put on the wall or can be visualized in a software program or a website such as Atlassian’s Jira^[7]. Explicit limits are assigned in Kanban projects so that each workflow state can have a 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 the team can optimize the process to make the lead time as small and predictable as possible.

12.2.3.3 Scrumban

Scrumban is an agile approach originally designed to transition from Scrum to Kanban^[8]. 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 improve its process continually. In Scrumban, the work is organized into small “sprints” and leverages Kanban boards to visualize and monitor the work. There are no predefined roles in Scrumban, as in Kanban. However, the Scrumban teams generally retain the Scrum roles.

12.2.3.4 eXtreme Programming (XP)

As the name implies, software teams utilize XP. It is an agile software development framework that aims to produce higher-quality software and a higher quality of life for the development team. XP is the most specific of the agile frameworks regarding appropriate engineering practices for software development^[9]. 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 develop an effective mindset. One of the primary practices of XP is pair programming, through which the coding process is conducted by two developers working together on a single computer^[10]. 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 coding the unit test first. Before writing the code, a unit test is created so that new codes are automatically tested^[11].

12.2.3.5 SAFe® (Scaled Agile Framework)

The SAFe is the most common scaling framework according to the 15th State of Agile Report published in 2021^[12]. 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.2.2). It also focuses on detailing practices, roles, and activities at the portfolio, program, and team levels^[13]. SAFe organizes the enterprise around value streams that focus on providing continuous value to the customer.

^[14]

12.2.4 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. It is important to note that Kanban does not have formal roles like there are in Scrum. Instead, Kanban focuses more on the workflow and visualization of tasks without predefined roles.

12.2.4.1 Common Agile Roles

There are three main roles in agile teams.

1. Cross-functional and self-organizing teams

Considering the self-organizing structure of agile teams and the role of the project manager as a team facilitator and servant leader, we can first focus on the team members who form agile teams. Cross-functional teams consist of members with various skills from different areas to produce a working product. A software development team might include UX/UI (User Experience/User Interface) designers, systems analysts, developers, testers, and business unit representatives. Members of a marketing campaign team might include content creators, graphic designers, SEO specialists, social media managers, data analysts, and product managers. Team members discuss the tasks and pick the ones they think best fit their skills and strengths. This is why these teams are called self-organizing teams.

Contrary to waterfall (predictive) teams, the project manager’s role shifts from a command-and-control position to a facilitator and coach in agile teams. Instead of assigning tasks, the project manager—often referred to as a Team Facilitator, Scrum Master in Scrum, or Agile Coach in Kanban—focuses on removing obstacles that hinder the team’s progress and fostering a collaborative environment. This shift also transforms the project manager into a “servant leader,” empowering team members to take ownership of their work and responsibilities.

Agile teams emphasize rapid iterations and flexibility. In agile teams, work is often structured in short cycles known as iterations or sprints, during which the team develops a working product increment. They deliver increments that are continuously refined based on feedback from stakeholders and end users. These increments represent incomplete but testable versions of the product. For example, in a mobile app development project, rather than developing the entire app with all its features over several months, the team might create a basic version with core functionalities in a shorter time frame, such as a two-week sprint. By the end of the first iteration, the team could deliver an increment where the app includes a simple login system and a home screen with basic navigation.

Agile teams require ongoing communication and collaboration, both within the team and with stakeholders. The project manager is crucial in maintaining the information flow, ensuring progress transparency, and helping the team align with the project’s objectives. Team size typically ranges from 5 to 9 members in frameworks like Scrum and XP, which ensures that the team remains small enough to be nimble yet large enough to be cross-functional. However, Kanban and Scrumban do not prescribe a fixed team size, allowing for flexibility based on workflow and project needs. Agile frameworks encourage regular check-ins, such as daily standups or team syncs, where members discuss progress, share challenges, and adjust plans as necessary.

2. Team facilitator

A product owner is responsible for guiding the direction of the product. Product owners represent the client and the stakeholders. They keep constant daily communication with the agile team. They provide the product backlog, including the user stories (requirements), and prioritize the user stories. Product owners are the bridge between the clients (and their end users, customers, 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 and offer effective feedback.

The product owner represents the client and the end users and provides feedback about what they think of the increment at the end of each cycle. Let’s assume that in a website development project, the product owner provides feedback about the three web pages created at the end of the first cycle. 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.” Thus, producing these increments helps the team receive feedback constantly. The team can work on each increment based on the feedback, and it can improve the product. This allows the team to make timely and effective interventions that otherwise would cause serious problems at the end of the project. So, when the team receives 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 from the product owner at the end of the third cycle may require the team to change the position and color. This is an ongoing process with constant interaction with the client, end users, and stakeholders.

On the contrary, in a waterfall project management approach, the team finishes the development of the whole website and submits it to the client for inspection by the client and its end users. Let’s say three months passed in that waterfall project, and the team got the feedback for the whole website. This late feedback requires serious rework since the client did not like many features and the look and feel of the website. However, it is worth mentioning that many projects using the waterfall (predictive) approach incorporate some agile components to benefit from the advantages of agile methods, making these projects “hybrid.”

12.2.4.2 Common Agile Practices

Agile teams utilize various artifacts and events to perform tasks and achieve project objectives.

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

1. Team Charter

2. User Stories and Backlog

User stories capture the functional needs of stakeholders, presented in a simple format that conveys what the user wants to achieve and why. The collection of these stories forms the product backlog, which serves as the team’s evolving plan for the project. Regardless of the framework (e.g., Scrum, Kanban, XP), agile teams prioritize the backlog based on business value and other factors such as complexity or effort required. In Kanban, there is no fixed timebox like in Scrum, and instead, teams pull items into the work process as capacity allows, focusing on limiting WIP (work in progress).

3. Iteration or Cycle Planning

Agile frameworks such as Scrum and XP divide the work into timeboxed iterations or sprints. Teams plan their work at the beginning of each iteration, allowing flexibility to adjust to changing requirements or stakeholder feedback. On the other hand, Kanban teams do not adhere to fixed cycles but continuously plan and prioritize tasks as they are completed. The goal across all frameworks is to release a working product incrementally.

4. Daily Standups

Daily standup meetings (daily syncs) are a key practice in most agile methodologies. These short meetings, held daily, help the team inspect progress and adapt their approach as needed. While standups are integral to Scrum and XP, they are also widely used in Kanban to track work in progress and identify blockers. Standups typically involve discussing what was completed yesterday, what is planned for today, and any impediments the team faces.

5. Demonstration or Reviews

Teams present their work for feedback at the end of an iteration or after completing a set of tasks. In Scrum, this is called a Sprint Review, while in Kanban or Scrumban, teams may schedule a demo after completing significant work items. The objective is to gather feedback early and often so that adjustments can be made before moving forward with further development.

6. Retrospectives

Retrospectives are a practice where the team reflects on their processes, collaboration, and outcomes, discussing what went well and what could be improved. In Scrum, this happens at the end of each sprint, while in Kanban and Scrumban, retrospectives can be scheduled regularly or triggered by specific events. The goal is continuous improvement, a core principle in agile methodologies.

7. Backlog Refinement

Backlog refinement (previously known as backlog grooming) involves reviewing and updating the product backlog to ensure it is properly prioritized and detailed for future work. While Scrum has formal refinement meetings, Kanban teams continuously refine their backlog as part of their flow. In both approaches, refinement helps the team identify potential challenges in upcoming work and improve estimates or understanding of tasks.