—Albert Einstein

Once upon a time, there was this desire to become Agile. This is how your story begins. But giving an account of the achievement of an agile transformation is more complex and challenging than many realize. It is a story that requires a change in culture—one of the hardest things to do. It is a tale beset by many obstacles, including people who either do not try to understand the value Agile brings or who try to impede the effort.

Fear not! The roadmap in this book can proactively guide you and lay the groundwork for delivering value, which is what you are in business to do. The roadmap is for an adaptive path based on your decisions and commitment. So what does your story look like?

In this concluding chapter, I offer three case studies—stories of a smaller colocated project, a medium distributed project, and a large distributed team—to help you understand how the readiness activities, deployment approach, and commitment to Agile lead to different results. What will your Agile case study look like?

Smaller Colocated Project

Once upon a time, there was a small project of 8 people. They were a group working on a new product that was scheduled to take about 6 months to release. Although the PO, along with management, sales, and marketing, established a product vision, they realized that there was quite of bit of uncertainty. Because of this they decided to apply agile processes.

As they were getting started, they were honest with each other and realized that no one on the project team or management really understood Agile or how to deploy it into a team. They felt that training was in order, so they hired an Agile Coach to provide Agile training to the team. The coach recommended an overview for the management team. A couple of the management team members declined the overview invite. The coach asked which of the management will become the sponsor for moving to Agile, and they decided it would be a sponsorship by committee.

The Agile Coach introduced management to the readiness activities to help prepare the team. Management wanted to start the project very soon, so only a few activities were allowed to be focused on. These activities included:

• Identify and establish agile roles and responsibilities
• Determine education needs
• Establish agile frameworks and practices
• Identify agile tooling and infrastructure needs

The good news was that most of the team was colocated. Because there were five developers and only one QA person currently on the team, the coach advised adding two more QA engineers to ensure a healthy balance between building and testing. The team was able to hire only one more QA engineer, but this still provided a better ratio of skills.

Management felt that converting their existing project manager to Scrum Master was a good approach, and this was amenable to the coach. Management identified a PO from the existing pool of product management within the organization. The Agile Coach recommended the Scrum Master and PO be allowed to take the Certified Scrum Master (CSM) and Certified Scrum Product Owner (CSPO) education, respectively. Management declined, citing budgetary concerns.

Scrum seemed to be the right agile process for this project, so the coach recommended this. Everyone agreed. Because the team was colocated, the coach recommended that they initially start with a physical Sprint Backlog wall where the team members could see the stories in their Sprint on a team wall and physically move the stories and tasks forward during the Daily Scrum. The PO opted initially to use a spreadsheet program as the location for the Product Backlog.

The Agile Coach provided a two-day training with a focus on Scrum and use of the physical Sprint Backlog wall for the whole team. Then the coach sat with the Scrum Master and PO separately for an additional two hours to focus specifically on their roles and responsibilities.

Because of the team enthusiasm from the training, management felt that they were ready to apply Scrum. Management continued with the Agile Coach for about three months, and he did the best he could in such a short time—long enough to get Scrum off the ground on the team.

The team began implementing Scrum with three-week Sprints with the help of the Agile Coach. The first three Sprints were fairly successful. Upon reaching the fourth Sprint, the coach’s contract expired. Management thought that the teams were engaged in Scrum, so the coach was released.

In Sprint 4, the Scrum Master attempted to keep the team focused on Agile values and principles as well as the Scrum practices. There were several strong personalities on the development team, two of whom were secret Agile Deniers. They were worried that they would not be able to continue to be the senior team leaders and would not be rewarded for problem solving.

During the Sprint Retrospective concluding Sprint 4, the two Deniers teamed up to do away with the Daily Scrum, saying that maybe twice a week was good enough. These two did not like the discipline of having to share their progress. They managed to influence the rest of the team to concur, so the Daily Scrums turned twice-a-week Scrums. They also managed to influence the team into using individual velocity instead of team velocity so that they could show how individually effective they were. The Scrum Master tried to prevent this, citing the Agile principle of the team approach, but the team, led by the two Deniers, overruled the Scrum Master.

Several Sprints latter, the Daily Scrum was occurring once a week and the Retrospective actions were not being completed. The real challenge was that the team didn’t like decomposing large requirements into user stories that fit into a Sprint. This was difficult to do. Also, the QA team members weren’t receiving completed stories until the very end of the Sprint. This became problematic when a majority of the stories were not getting completed within a Sprint.

Although the Scrum Master tried to mitigate many of these problems, he was not experienced enough with Agile to help the team improve. There was little to no understanding of the Agile values and principles on the team and no experience to reference. Yet management put much of the blame of the team problems on the shoulders of the Scrum Master, even though he was escalating the impediments to management for help. Unfortunately, development had more influence with management than the Scrum Master had, and management wasn’t experienced enough to support the Scrum Master or Agile.

Because the performance review process still operated on individual performance, the senior developers on the team made a strong push in the last Sprint to get a large amount of work done. The team members often worked late into the evening and weekends to achieve some level of success. Even with these heroics, however, management decided that testing had to be shortened to keep the release date from getting pushed too far.

The team released their product about two months late. There was difficulty understanding exactly what scope was delivered, and overall product quality was deficient in many areas. The Scrum Master received the blame for much of this, and two development team members received accolades for their “extra effort.”

The company brought the Agile Coach back in to conduct a lessons-learned. When debriefed, the team and management learned the following:

• Insufficient time was spent considering readiness activities and the needs of the team to achieve an effective and sustainable Agile adoption. The team found that they stumbled into many decisions on how to move forward.
• They felt that the Agile Coach should have placed more focus on the Agile values and principles and the cultural aspects of getting to an Agile culture. Most of the team members couldn’t recall more than three Agile principles.
• Because the Scrum Master didn’t have Scrum-specific training and was inexperienced, it was very hard to support and maintain the Scrum practices once the Agile Coach left.
• The Scrum Master felt he was not supported by management to promote and sustain an Agile culture.
• The team realized that they should have engaged the Agile Coach for at least a couple more months to sustain the mechanics, and maybe needed a more experienced coach who could place more emphasis on the values and principles to change the culture.
• The team thought that the retrospective allowed them to decide to change the Scrum process in whatever way they thought best. They didn’t realize that minimizing some of the events affects the whole, because Scrum requires Planning, Daily Scrums, Review, and Retrospective to work in a closed-loop iterative system.
• Whereas an Agile Team applies story points to understand team velocity, this team moved to individual velocities. This quickly took them away from team building and self-organization and instead toward their own individual successes at the expense of the team.
• The performance review system continued to focus on individual goals to gauge success rather than team-based goals. To make matters worse, individual velocities were included into individual performance reviews, and those with higher individual velocities received higher merit increases.
• There were accolades to two of the development team members based on individual heroics, which undermined the goal of team-based achievement.

Unsurprisingly, Agile was not well received by this team. The result was that the team regressed back to more of a hybrid waterfall framework in which heroics were rewarded. The team agreed that if Agile was tried again, there needed to be more of a management commitment to change the culture and a more experienced Agile Coach who better understood Agile and achieving a culture change.

Medium Distributed Project

Once upon a time, there was a group working on significantly improving their portfolio product. Management realized that there was quite a bit of uncertainty in the product direction, which requires new front-ends and much more integration than in the past. As they proposed the 12-month project, management felt that due to the uncertainty, they should apply Agile. Because there was enough disagreement on how to deploy Agile, the management team felt that they would benefit by hiring an Agile Coach.

One of the senior management became the sponsor for the Agile initiative. He was excited about Agile and felt that he had a bit of Agile knowledge due to the Agile books he had read. When he brought the Agile Coach on-board, he shared a lot of his Agile ideas with the coach. In the spirit of learning more, the coach recommended that the sponsor take an Agile overview session. The sponsor felt that he knew enough about Agile already but that other management should take the overview session.

The overall project team size was 32 people with folks in New York City and London. The coach advised them to form four Scrum teams of approximately 8 team members each, which was promptly done. Because there were 15 employees in the London, it was decided that 2 teams would be US-based and 2 would be European-based. Each team’s competencies evinced a healthy balance of development, user experience, and QA.

The coach emphasized the importance of the Agile values and principles and shared them with the management team. The coach also suggested hiring experienced Scrum Masters. The sponsor felt that it was best to draw from the existing talent to play the Scrum Masters. The Agile Coach recommended that each of the identified Scrum Masters take CSM education. The sponsor agreed to fund this training.

The existing Product Manager was knowledgeable about the intended product and made a good PO candidate. Several of the functional managers became aware that their role would reduce in scope and responsibilities because the team members would get their work from the backlog. In consequence, three functional managers insisted that they become POs. Although the Agile Coach felt there were risks in taking this approach, it was agreed that between the 1 existing product manager and 3 functional managers that each of the 4 Scrum Teams would have a PO. The coach recommended that each PO take a formal CSPO education. The POs felt that a short training from the Agile Coach was enough.

The Agile Coach introduced the team to the readiness activities, and management cherry-picked several of them to focus on, including:

• Understand the current state of engineering and Agile
• Determine team willingness and capability
• Identify and establish Agile roles and responsibilities
• Determine education needs
• Establish agile framework and practices
• Identify agile tools and infrastructure needs

The coach felt that certain areas should be addressed: establishing a common understanding of Agile; focusing on Agile values and principles; understanding levels of executive and stakeholder buy-in; establishing a strategy and backlog for the Agile transformation; and establishing done criteria and measures of success. But the coach made progress with the agreed-to readiness activities. Against the Agile Coach’s advice, the POs felt using hours instead of story points was best for story point sizing.

The team started with a 4-week Sprint 0 to get organized. A Product Owner Scrum of Scrums (SoS) was established so that the POs could collaboratively build and prioritize the Product Backlog and sort user stories to the various team backlogs. The POs became a bit overzealous and attempted to prescribe user stories to Sprints through the end of the proposed schedule.

They began implementing Scrum with 4-week sprints with the help of the Agile Coach. The first two Sprints were focused on the mechanics. A project SoS was initiated in which the Scrum Masters got together to discuss project dependencies and progress.

Starting in Sprint 3, command and control was being exhibited by the POs. The three who had been functional managers were reverting back to their old habits of directing the teams. The teams began having problems with self-organization because they were getting overruled in their decision making by the POs.

In the first three Sprints, the teams mechanically exercised the Sprint Reviews with internal stakeholders focusing on the goal of bringing in existing customers of the old product and potential new customers. By the fourth Sprint, the POs recommended that because they felt that they knew what the customers wanted, that there wasn’t a need to bring them in to the Sprint Reviews. The Agile Coach strongly encouraged bringing in customers, and the POs said that they would think about it.

During the Sprint Retrospective concluding Sprint 5, several teams expressed concerns about the command-and-control behavior that was being exhibited by the POs. The team members didn’t push it because they were also concerned that their performance reviews would be negatively impacted by the former functional managers who were acting as POs.

The Agile Coach attempted to mitigate this command-and-control problem. The POs were quite certain that they were doing the right thing because they felt that the team wasn’t making good decisions. Since the project was challenging, the POs felt they needed to take the reins of the project.

Another problem that occurred was that the POs started to compare the velocity across teams. The message that they were sending was, “Look how many hours of work this team is putting in. How come you aren’t putting in those kinds of hours?” This started to have a demoralizing effect on several teams.

The coach, realizing that comparing velocities was also problematic, discussed the various problems with the Agile sponsor. Unfortunately, the sponsor didn’t want to make waves because he was friendly with the former functional managers. He said he would talk to the POs, but after another Sprint it was clear that this wasn’t a priority with the sponsor.

By Sprint 8, the Agile Coach’s contract ended and he was released on account of budgetary constraints. The sponsor stepped in to provide Agile coaching and mentoring to the teams. Some of his advice seemed to conflict with the Agile Coach’s past advice.

The project released within 2 weeks of the schedule. During the last 2 months, the teams were placed into a death march to complete the project on time. A few developers and the POs were praised and rewarded for tirelessly making the project a success. Once the product was released, however, there were many customer concerns regarding the alignment of the functionality to their needs. Few existing customers wanted to upgrade to the new version. This next-generation product was not providing value to the customers and did not do well in the market.

The Scrum Masters asked the sponsor to bring in the Agile Coach to conduct a lessons-learned. The sponsor said that there wasn’t budget for it, but they were welcome to conduct a lessons-learned on their own. When debriefed, the team and management learned the following:

• The team liked receiving training, and the Scrum Masters were grateful for receiving the CSM training.
• The project started well, focusing on readiness activities and Sprint 0.
• The first two Sprints were very promising.
• By the third Sprint, the team realized that the former functional managers who were the POs were behaving in a very command-and-control manner.
• The POs, specifically those who were former functional managers, overruled many of the decisions the team made. The result was that the team lost any sense of self-organization and felt demoralized.
• Although Sprint Reviews were occurring, no actual customers were attending. The reviews were for internal stakeholders.
• The POs believed they knew what the customers wanted, but they were incorrect. The product release was not aligned with customer needs.
• There was little mitigation of the PO command and control due to their relationship with the sponsor. This negatively affected any chance of achieving a culture change.
• Product quality was deficient in many areas. There was inadequate testing within each Sprint. Testing was minimized toward the end of the project.
• Once the Agile Coach was released, the Scrum Masters and team didn’t feel they had anywhere to escalate their concerns when the issues were beyond their control.
• There was strong sponsor support at the beginning, but the sponsor didn’t support the culture change needed for Agile.

Some of the members from the Scrum Teams felt negative about Agile after this experience. Other members understood that the POs were not really working in an agile manner and were not aligned with the Agile values and principle. It was recognized that the project regressed to a more hierarchical command-and-control manner and wasn’t really Agile.

Large Distributed Team

Once upon a time, there was a group working on a next-generation identity and access management (IAM) product. Management realized that there was quite of bit of uncertainty in the new direction and significant re-engineering of their past product line. One of the senior management, having experienced Agile in another company, knew that because of the uncertainty, that this product should apply Agile. Management knew that it was going to take a while and initially targeted about 12 months to build functionality. They were open to adjusting scope or schedule as the project ramped up.

This same senior manager agreed to be the sponsor for the agile initiative. The sponsor felt that it was important to hire an Agile Coach to help deploy Agile. But because not all coaches are created equal, he wanted to ensure he hired a coach who was an Agile subject matter expert and experienced as a change agent, coach, and trainer. As the first action toward Agile, the sponsor asked the Agile Coach to educate his peers and direct reports on the Agile values and principles. The sponsor knew that some of the involved senior management were in other offices, so he sent the Agile Coach to those sites to educate the management.

The Agile Coach introduced the team to the readiness activities, and management agreed to build an Agile Deployment Team to work through these activities. The readiness activities that were focused on included:

• Establish a common understanding of Agile.
• Provide Agile mindset education on the Agile values and principles and drivers for why we are changing.
• Add “customers and employees really matter” to the company vision and “customer engagement” and “employee engagement” to employee objectives.
• Understand levels of executive and stakeholder buy-in.
• Establish an overall strategy and backlog for the Agile transformation (including mitigation of risks).
• Understand the current state of engineering and Agile.
• Determine team willingness and capability.
• Determine suitability of product.
• Evaluate and adapt to collaborative IT governance.
• Identify and establish Agile roles and responsibilities.
• Determine education needs.
• Establish agile framework and practices.
• Establish done criteria, user story framework, and sizing techniques.
• Craft measures of success and general metrics.
• Identify agile tools and infrastructure needs.

The Agile Coach, with the help of the sponsor, identified local Agile Champions who either had experience with Agile or were enthusiastic about it and who were willing to form the basis of the small Agile deployment team. The coach educated the deployment team on the Agile values and principles and the importance of readiness activities to help condition the product team toward an Agile mindset.

The Agile deployment team discussed their strategy for deploying Agile and created a backlog of tasks based on the readiness activities. They asked the sponsor to a send out a message sharing the reasons for moving to Agile. The sponsor agreed to share the drivers for organizational change and introduced a common understanding of Agile based on the Agile values and principles. From then on, the sponsor periodically shared the progress and the importance of shifting to the Agile mindset.

To support Agile further, the sponsor recommended that management have performance objectives that focus on employees, customers, and Agile values and principles. He also recommended that employees have team-based objectives with a focus on the Agile values and principles. This set the tone to support self-organizing teams and teamwork.

The Agile Coach introduced himself to the overall team in an email and said he would set up several meetings with the team members from each location: Boston, Prague, and Bangalore. In the spirit of transparency, he asked the team in each location about their level of willingness in moving to Agile and followed this up with a survey. He listened carefully to the team members during the meetings to understand their concerns. The survey included questions to gauge the current level of Agile experience within the teams. Both the level of willingness and experience levels were used as input on how to adapt the Agile deployment effort.

The overall team size was 79 people, with most of the team in three locations. The coach recommended that nine Scrum Teams be formed of approximately 9 team members each. Because there were 35 employees in Boston, 16 in Prague and 28 in Bangalore, it was decided that 4 teams would be set up Boston, 2 in Prague and 3 in Bangalore. Initially, there were a high percentage of QA in Bangalore, so there had to be a rebalancing of development and QA across the teams. This was handled with management approval. It was also recommended that each Scrum Team own an end-to-end piece of functionality. This was handled by identifying the functional areas within the architecture vision and parsing them to the teams.

The coach also suggested hiring at least one experienced Scrum Master at each location. The others could come from the existing organization. The Agile Coach recommended that each of the inexperienced Scrum Masters take CSM education. Management agreed.

It was important to find POs for each team who were knowledgeable in the IAM space. There were 3 existing Product Managers who made good PO candidates: 2 in Boston and 1 in Prague. The most senior Product Manager became the uber-PO who supported 1 Scrum Team and more importantly provided overall product guidance to the other POs. Two of the other existing POs agreed to support 2 Scrum Teams each. This meant that the 2 Prague-based Scrum Teams were set and 3 Boston-based teams were set.

This still left the 1 Scrum Team in Boston and 3 teams in Bangalore. A functional manager who was known to have servant leadership attributes from Boston agreed to become the final PO to support the remaining Boston Scrum Team. For Bangalore, it was decided to hire a PO who had IAM product experience. This person supported 2 Scrum Teams. An existing functional manager who had product knowledge became the PO to support the remaining Bangalore Scrum Team. The Agile Coach strongly recommended CSPO education for these POs. Management agreed to fund this training.

The Agile Coach recommended starting with a 3-week Sprint 0 to get organized. The first two activities were discussing the use of Agile and managing project risks. The POs got together to build the product vision. Because this project was distributed, the coach suggested collaborative online tools for dialogue across teams. There was also a focus on using an online agile planning tool so that the Product Backlog could be easily instantiated into each individual team and Sprint Backlogs. In addition, a configuration management (CM) vision and QA vision were established to support the code changes and quality of the product.

The POs formed an SoS so they could collaboratively build and prioritize the backlog and sort the user stories to the various team backlogs. The uber-PO provided overall guidance. They decided to use the canonical form for writing user stories and spent a lot of time grooming the backlog together. The POs also agreed that each location would hold joint Sprint Reviews so that current and potential customers and other stakeholders were not being asked to attend multiple Sprint Review sessions.

The Scrum Teams individually focused on establishing done criteria. Each team established their relative sizing framework using story points. Several of the teams began working on research spikes during Sprint 0 to reduce technology uncertainty. During Sprint 0, the Scrum Team members received an intensive Agile training on the Agile framework that was being used—a combination of Scrum and XP engineering practices. A project SoS was initiated in which the Scrum Masters got together to discuss project dependencies and progress.

Sprint 0 ended with a cross–Scrum Team Agile Release Planning session. This session was initiated with a joint video conference session together where each team was introduced and the uber-PO shared the product vision with the teams and then gave everyone a chance for Q&A. The teams had to adapt their working hours to accommodate this session. The QA vision, technical vision, and CM visions were also shared during this session. The continuation of Agile Release Planning involved an all-day team backlog grooming session, which occurred independently within the respective team’s time zone. Then another joint effort occurred in which each team shared their findings. Upon conclusion, Sprint 1 commenced.

They began implementing Scrum with 3-week sprints. The Agile Coach brought in a fellow coach, and they shared the load of helping teams come up to speed with Scrum. The first four Sprints went by with some success, and there was a lot of focus on the mechanics. Several of the teams were exhibiting self-organizing attributes and some teams were still getting the hang of it. Each team was honing their relative story point sizing framework and tracking their velocity. The coaches actively discouraged velocity comparisons, and these didn’t occur.

In Bangalore, the PO who had been a functional manager had to be further coached to reduce command-and-control attributes. The main Agile Coach flew to Bangalore to work with this PO and support the Scrum Masters and local Scrum Teams. The coach attended many of the teams’ events to gauge the adoption-level mechanics. He held periodic check-point calls with all of the Scrum Masters to help them with their challenges.

It was initially challenging to hold joint Sprint Review sessions because there was often much more work that was completed than could be shared. The Agile Coach recommended prioritizing the work based on where feedback was most needed and ensuring each team got a chance to demo at least two or three stories. The first two Sprint Reviews were held with just internal stakeholders to exercise this adaptation. This allowed teams time to get used to demonstrating to people and to figure out the mechanics of the review. By Sprint 3, the POs began inviting a few existing customers to gain their feedback. By the fifth Sprint, the Sprint Review began running effectively. A challenge that was resolved over the next two Sprints was taking the Sprint Review feedback and incorporating it into the Sprint Planning for adaptation of built functionality.

After the first several Sprint Retrospectives, the teams began realizing the importance of carrying out the actions for improvement. Though some teams were more effective at it than others, they began working these actions and seeing the benefit. There were two people in two separate Boston-based Scrum Teams who didn’t like the notion of the daily Scrum and tried to get this changed within their retrospective, saying it was affecting their work. They tried to change it to weekly, but the rest of the team members believed it was important to share the daily progress and highlight roadblocks. Two Sprints later, one of the team members who raised this concern said that he didn’t like having to share his progress all the time and decided to quit. In talking with this team, the Agile Coach said that, given Agile’s continuous nature, it may not be right for everyone, and that’s okay. The team promptly replaced this team member with an Agile-minded engineer and the coach helped her come up to speed.

By Sprint 7, the Agile Coach initiated two surveys: the agile practices adoption survey and the Agile Mindset, Values, and Principles Advisor survey (see Chapter 13). The results were shared during the next Sprint Retrospective so each team could decide how to improve. Only with the teams’ agreement a summary was shared with management, together with some recommendations as to where management could help.

By Sprint 10, the backlog was well fairly well groomed. Affinity sizing was used to minutely size the remaining stories in the backlog. This allowed the POs to create a minimum viable product (MVP) value line consisting of the stories that were targeted for a viable Release 1 product. Having this empirical data along with the MVP stories provided the basis for an objective discussion with the organizational IT governance board. The IT governance board suggested that scope would be the driver and they wanted to continue tracking the MVP line and the release burnup to see when each team’s velocity met their MVP lines. Understanding each team’s MVP and velocity provided a means to move stories to other teams to balance the work.

As the Scrum Teams’ MVP lines were adjusted based on customer feedback, each team’s velocity was tracked and it became evident that Sprint 18 would be the last Sprint on the project. An additional Sprint was added for integration, performance, and load testing, as well as finishing the user guides, preparing the release notes, and beginning the marketing campaign. When the product was released, many customers immediately upgraded or purchased this next-generation product.

Each Scrum Team conducted a final retrospective. The Agile Coach collated the results. He also conducted another Agile Mindset, Values, and Principles Advisor survey to compare it to the baseline from the previous survey results. Upon a roll-up of the retrospective and survey results, a debrief occurred with the team and management that included the following items:

• It was great having management support and a sponsor for the move to Agile who really understand the Agile values and principles.
• Everyone appreciated receiving training. The Scrum Masters were grateful for receiving CSM training and the POs for receiving CSPO training.
• The project started well. Focusing on readiness activities and Sprint 0 helped the team get their heads around the move to Agile.
• The teams liked hearing the various visions (product, QA, CM, and so on). These helped them understand the go-forward focus and gave them a sense of security that these areas had proper attention.
• Though initially skeptical, the POs and Scrum Masters found the SoS of great value in collaborating across teams and discussing dependencies and ways to optimize at the overall project level.
• Teams liked having the Agile Coach during the first several Sprints but were relieved to see the coach back off after Sprint 4 so that the team could self-organize.
• The teams were pleased that they could push back on the command-and-control and micromanagement and enlist the support of the coach and especially management to remove these regressive behaviors.
• Everyone really liked getting a chance to demonstrate to customers. The POs like it because this helped them validate their product direction.
• As the team adopted the agile practices, they realized the need of having management and IT governance move toward the Agile mindset in order to transform the culture and adapt to customer needs.

As a side effect of the successful project, two of the Scrum Masters wanted to begin their education in becoming Agile Coaches. The Agile Coach emphasized that being a true coach requires more experience but that their attitudes would help them. Building an internal agile coaching circle helped the organization leverage its local agile talent. Because of this positive experience, several other teams in the company wanted to go Agile.

What Will Your Case Study Look Like?

As you approach your agile adventure, the question is, “What will your case study reveal?” Can others learn from your journey? Have your teams mechanically adopted Agile but not reached a transformation toward Agile values and principles? Have you regressed from Agile to a hybrid waterfall framework? Have some teams adopted Agile while management continues to operate in a traditional manner? Are only the engineering teams doing Agile, while management and IT governance continue to demand a fixed scope, quality, schedule, and cost up front?

It is important to remember that moving to Agile is meant to be a move to a new culture, and this is difficult. Do you see a culture shift occurring? Chapter 2 argues that a skill change is easier than a procedural change, and a procedural change is easier than a culture change. A culture change implies a behavioral change in people, focused on a change in the values within their organization that is expressive of a new way of thinking. It does take time, and this is why it is important to think of a move to Agile as a journey. This is also why the readiness activities of the RICH deployment model (Chapter 7) are meant to ensure that you ask the right questions, help you plan your agile adoption with the goal of a cultural transformation, and condition the mindset toward the Agile values and principles.

Agile is not a silver bullet that will give instant results. If you truly align your culture and all of the people’s behaviors to Agile values and principles, then maybe you can gain the benefits sooner rather than later. This is why I provide you with the Agile Mindset, Values and Principles Advisor in Chapter 13. It can help you gauge your alignment to the Agile values and principles along the way.

As you discuss Agile with management, ensure the conversation is driven by the business benefits Agile can provide. Going Agile is not just a cool thing for teams to do—it can help you improve a company’s financial strength. Gaining the adaptability of scope that Agile brings can help you achieve an increase in revenue. To make money, however, you need to delight your customers by building customer value and harnessing the brainpower of your employees. What happens when you step up the level of customer engagement? What happens when you step up the level of employee engagement?

The roadmap in this book can help you achieve an agile transformation to the betterment of revenue and customer success. Ultimately, what will be the story that represents your agile journey? Will it be a case study that can be held up as an example of successfully implementing Agile, or will it be a parable of perils and pitfalls to avoid? The answer is up to you.