12.2 Adopting and Creating an Agile Environment

12.2.1    A Case Study of the Penta Transformations

A Six-Month Cultural Transformation: The Penta Story^[1]

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

12.2.2    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^[2]:

• 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?

12.2.3    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 (2016)^[3] 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 (2016) 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 (2016) 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 (2015) 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.

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. In this section, we will elaborate on these.

12.2.4.1      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^[4].

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^[5]. 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^[6].

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

Table 12.1: A Backlog composed of Four User Stories

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^[7], 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.^[8]” 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^[9].