—Edgar Schein

Moving to Agile is a move to a new culture, and cultural changes are difficult for a team or organization. To transform your organization to Agile, organizational values and individual behaviors need to change. Because of this I strongly recommend that a change toward Agile must be thought of as a transformation or change initiative, treated as a project, and actively managed. True to the spirit of Agile, using an inspect-and-adapt model can help you manage the change and adapt along the way based on the feedback you gain from those involved.

As a starting point for the transformation, those within the organizational scope want to know the what and why of the change. Chip and Dan Heath write: “If you want people to change, you must provide crystal clear direction [because what] looks like resistance is often a lack of clarity.” ¹ Start with establishing a vision or objectives about why you are implementing Agile. The objectives may center around customer and employee engagement (Chapter 4 and 5) or around wanting to work by the Agile Principles (Chapters 6 and 9). Along with objectives, add the organizational motivations for change to Agile (Chapter 8). The objectives and motivations begin the path toward clarity.

Within the project context, there are other elements that you should apply that will help you manage the transformation. As illustrated in Figure 11-1, the rest of this chapter focuses on the element of treating Agile as a transformation project. This treatment includes writing objectives and motivations, understanding the scope of the effort, establishing a deployment team to help lead the effort, crafting a communication plan to convey progress, identifying suitable work, ordering the work in a deployment backlog, and then applying an inspect-and-adapt process to deploy Agile into the organizational scope.

Scope of Agile Deployment

In planning an agile deployment, you need to define the organizational scope. Are you targeting the enterprise, part of the enterprise, a solution area made up of several products, or a single product team? Your target scope becomes the cornerstone for the project. The scope helps you understand the breadth of the effort and those with whom you will be working.

The less favored scenario is to apply Agile to just one project with the idea of abandoning it afterward. Although this may be beneficial for exercising agile processes and getting the release out, you may not receive the business benefits of Agile because you need behavior change at a much broader level. It is also a bit of an effort for the employees to adapt to a new approach only to abandon it. However, if the results are good, it can launch you into a more consistent use of Agile for the product.

A more favored scenario is applying Agile to a product line or product team. A product team represents a consistent group of people whose goal is to provide long-term business, development, and support for a product. This aligns with the notion that the longer you work as a team, the better your chances of forming strong working bonds and manifesting the attributes of teamwork. Also, when a person is aligned with a product for a long period of time, there is a tendency to have a greater sense of ownership and to be more invested in the success of the product. Alignment to the Agile Principles is more likely because it often takes time to align. Implementing at the product level allows Agile to be applied consistently and gain inspect-and-adapt benefits where feedback is used to build business value.

The enterprise level is where you may gain the most business benefits from Agile. Because Agile requires a culture change, aligning the whole enterprise to Agile values and principles helps everyone understand the need to adapt to gain the business benefits. To achieve an enterprise-level transformation to Agile, it is advantageous to combine the activities identified in the RICH model for deployment (Chapter 7) and add organizational-level aspects (Chapter 23). At the enterprise level, you can also leverage economies of scale and minimize similar efforts across multiple teams using a common deployment model, tools, and training across teams.

Agile Deployment Team

If Agile is to be taken seriously, it is good to form a team made up of the agile sponsor and Agile Champions within the organizational scope where you are looking to deploy Agile. The objective is to include a combination of agile experienced and committed personnel to help guide the organization and product teams. More important, it will help those adopting Agile to remove roadblocks.

If the agile adoption is focused on the whole organization or a large part of it, then the most senior-level executive within that scope should form a deployment team of Agile Coaches who have experience in enterprise-level agile deployments and Agile Champions within whose purview fall the products that are flagged for agile adoption. Even if the agile deployment is occurring on just one product team, at the very least, the Product Owner, Scrum Master, and the most senior manager within the scope of the product should become the Agile Deployment Team that focuses on the progress of the adoption.

Agile Deployment Backlog

As part of the project in which Agile will be deployed, it is important to establish a list of tasks that help the organization and product team deploy Agile. Creating a backlog helps the team understand the work involved and ensures key activities are performed to effect an Agile transformation. The activities for the backlog are found in Chapter 7, where the RICH deployment model is discussed and divided into Readiness tasks, Implement tasks, Coach tasks, and Hone tasks. These tasks can form the basis for your backlog. However, you do need to brainstorm and add other tasks that will help you adapt to Agile within your organizational scope. If there are multiple product teams adopting Agile, consider the backlog as a reusable element for each product team’s needs.

Agile Process for Agile Deployment

In the spirit of Agile, I recommend that you apply an inspect-and-adapt approach in deploying Agile within your organization. Establish a deployment backlog with tasks discussed in Chapter 7. Consider a Scrum approach in your deployment. Starting with Sprint Planning, prioritize the tasks and extract a Sprint Backlog derived from the overall backlog. You then hold Daily Scrums (or at least twice a week) to gauge progress and learn and mitigate the risks. At the end of each sprint, you can review what tasks were completed and those not finished and why, as well as review any measures focused on moving to Agile. This is followed by a retrospective of what was learned and can be improved on. Applying a Scrum approach will help you deploy Agile, adapt to organizational needs, and learn one of Agile's processes along the way. It is also important to identify measures that can help you determine if you are being Agile and moving in the right direction. More details on measures can be found in Chapter 14.

Agile Communication Plan

When embarking on an agile journey, it is essential to strategize how to communicate about the deployment to those within the organizational scope you are targeting. It is equally important for senior management and executives to periodically provide public support for Agile. Once a communication plan is formulated, portions of this can be executed over time to keep employees aware of the progress and accomplishments of the deployment.

When preparing your communication plan, you will find that it is not a one-size-fits-all approach. It is important to identify the various elements of communication and then craft a communication plan for the organization’s needs. The primary elements of a communication plan (with examples) include:

• Message types (objectives, motivations, milestones, opportunity, successes, reinforcement, tips)
• Audiences that will receive the communication (everyone, senior management, product teams)
• Types of communications (newsletters, briefings, presenta-tions, focus groups)
• Types of communication channels (email, social media, face-to-face, internal TV, webinar, blog)
• Frequency of communications (daily, weekly, monthly, ad hoc)

Ultimately, the communication plan should include your strategy for communicating the various messages being encapsulated into certain communication types, in what communication channels, shared with what audience, and with what frequency. This keeps everyone informed and aware of the continued support for Agile.

Considering Work Suitable for Agile

I am often asked, “What type of work is best suited for Agile?” The short answer is: “Any work where you have uncertainty. The more uncertainty, the greater the need for Agile.” This adage typically applies to new and unique products. Agile’s inspect-and-adapt model helps identify the complexities of the idea while providing the team with an iterative opportunity to learn more quickly and adapt both their processes and the product direction.

Agile may also be applied to legacy products for which management has decided to reenergize the functionality. A good example is an older on-premise product to which management wants to have a cloud version or wishes to add mobile-enabled functionality. The challenge in applying Agile to legacy product teams is that there is inertia to continue as is. It will be challenging to change the attitudes of the team members who are Cowboys, Deceivers, or Deniers posing barriers to change. However, these challenges can be overcome if the benefits of Agile are compelling.

For teams that are focused on sustaining engineering and support work on an existing product, Kanban may be appropriate. If the work is interruption-driven and focused on defects, then applying a planned approach such as Scrum may not be possible. I have also seen Agile applied to products that are in great trouble and others that have great urgency.

Deciding Which Teams Go First

As you are working through the readiness tasks, there should be discussions around which teams will move to Agile and in what order. When embarking on the deployment of Agile, it is best to set up early successes. Early success can have a positive effect on the transformation to Agile. The positive messaging and local Agile Champions that are created will help influence others who want to move to Agile.

It is best to target the candidate product teams where Agile has the highest rate of success. The information that follows highlights the team characteristics that represent the agile sweet spot. Keep in mind that you can be successful with Agile even though you do not align with the sweet-spot characteristics.

• Agile team is willing. This makes it easier to advocate for changes needed to use Agile effectively. It is critical that your first deployment of Agile occurs on a team that is very willing to adopt it. Having the Product Owner, Scrum Master, stakeholders, and Team willing to commit to Agile will make it easier to deploy. You learned how to gauge the team willingness to move to Agile in the Chapter 10.
• Product team is small. Most agile processes tend to favor smaller teams—typically no more than ten members. This way team members get to know each other and what they are working on well, which increases communication and team collaboration.
• Team is colocated. Project work benefits from face-to-face communication. Agile is no different. This allows for continuous and synchronous communication between team members and reduces the time of communication hand-offs.
• Customer is readily available. Customer availability and access ensures that the team has direct access to the customer, who continuously provides feedback on the functionality, leading to a product with strong business value to the customer.
• Product Owner/Customer Representative is committed, readily available, and colocated with the team. A committed and accessible PO ensures that the team can readily and interactively ask questions throughout the project regarding the requirements of the work at hand.
• Application is interactive. New products that are interactive and customer-facing can gain more advantages from Agile’s inspect-and-adapt approach.

Aligning the Agile Deployment around Product Release Schedules

Although the Readiness activities can occur outside of a product release cycle, I have found that it is best to align Implementation activities with the beginning of a project or release life cycle for those product teams that are first applying Agile. This allows a just-in-time learning and implementation approach as teams begin adopting and adapting to the new processes, methods, practices, tools, and mindset.

You definitely want to avoid an agile implementation in the middle of a project’s life cycle if you can help it because of the disruption that the change will bring. If the project is in crisis with some months to go prior to release, however, there may be a strong benefit in moving to Agile.

Project Framework to Transform

With Agile, you have the ability to educate, inspire, motivate, and transform. But this does not happen by accident. It should be a managed change with a starting point and a direction. It is beneficial to employees to treat a deployment of Agile as a project. It provides visibility and highlights the importance of Agile within the organization. Adding objectives and motivations behind them adds clarity to the deployment of Agile. Having an Agile Deployment Team of Agile Champions provides guidance as you work through the deployment backlog. A communication plan that is effectively executed keeps employees aware of the progress and accomplishments of the deployment. Applying an iterative approach to deployment activities shows a commitment to Agile.

The question is: How much focus and clarity do you need to provide your employees to transform your organization to Agile? If you do not manage the deployment of Agile, it will manage you, and you may not gain the business results you are looking for. Treating your Agile deployment as a transformation project can help you get there.

¹ Chip Heath and Dan Heath, Switch: How to Change Things  When Things Are Hard, Crown Business, 2010