Executing Deployment Backlog and Communication Plan

Commencement of implementation means you have made a decision to ­initiate the deployment of Agile within your organizational scope. It is time to incrementally begin deployment activities and initiate communication about those activities. As discussed in Chapter 11, a prioritized backlog is beneficial in helping you understand what should be occurring for a successful ­deployment and to track the progress of the backlog items.

At this point, you should have your objectives and motivations, an ­understanding of the scope of the effort, a deployment team to help lead and support the effort, a communication plan to help convey progress, suitable teams identified within the organizational scope, the work prioritized in a deployment backlog, and a plan for applying and adapting the agile process and mindset for ­deployment into the organizational scope.

The communication plan should include how you will encapsulate various messages into various communication types via various communication ­channels to various audiences with various frequencies. Implementation is a time to communicate progress and expectations frequently. As discussed in Chapter 11, an agile communication plan keeps everyone informed and aware of the ­continued support for Agile.

Continuing Education

Education for Agile is a long-term venture. The early steps start with ­promoting awareness and getting the organization trained. Awareness should have begun during readiness to ensure those within the scope are aware of the objective and motivations for moving to Agile.

Implementing the Agile Framework

Applying the agile framework takes place the moment that Agile is applied on the project. This isn’t a specific activity. Instead, the implementation of the agile framework being used should be initially discussed during training and then applied on the project. For the first three or four Sprints, coaching can be very advantageous for those teams that have not implemented Agile before in ensuring that the processes and team roles are applied properly.

Applying Agile Tools

If can be risky to start using a tool right away. A tool often comes with a dictated process. Instead, it is beneficial first to understand the team’s interaction and natural process. What a team may first consider doing is to use the physical story wall to display the stories, if the team is collocated, or use a basic online spreadsheet to manage the backlog prior to moving to a more sophisticated infrastructure. This gives the team a tangible idea of how they would like to use a tool before it is applied, in alignment with the Agile value of “people and interactions over process and tools.”

A preliminary step to implementing tools is to become aware of the ones that can help you effectively deploy Agile and then identify the appropriate tools for your team’s needs. In addition, the tools you use should help you in the pursuit of delivering customer value. Chapter 21 presents the range of tools that can support Agile and details how they can support the value chain of building products customers want.

Implementing a tool infrastructure can take time. As you are planning the installation and set-up of tools, ensure that you provide reasonable lead time between starting the installation and when you would like the team to actually start using the tools. As part of the implementation, ensure that appropriate training and user guides, physical or online, are provided so that users have educational support.

You should have a backlog of tasks that ensures you have considered the tasks for an effective tool deployment. A general outline of tool deployment tasks at an epic level follows:

• Identification and preparation of the environment: involves a server location for the tool to reside and any accompanying needs for storage.
• Installation of the tool: involves physically installing the tool in the prescribed location and installing client software.
• Preparation of your instance of the tool (as appropriate): involves preparing the tool instance and/or configuring in the product to the team’s needs and for the process the team intends to use.
• Communication of progress: involves sharing with interested parties via the appropriate communication channel the tool deployment strategy, proposed timeline, and progress along the way.
• Training to support the tool usage you expect: includes sharing the process by which you would like the tool to be used.

The key during implementation is ensuring that the tools serve the needs of the team. This is why it is so important to take the opportunity to hone the tool usage and process. Once a team is using a tool, they may find that the initial process needs to be adapted to better align it with the working interactions and shortcuts that get discovered.

Coach as Navigator on the Path to Agile

Think of an Agile Coach as your navigator who can help you move down the best path for your teams and provide course correction when you either regress or move in a less Agile-favorable direction. This is why it is so critical to hire an Agile Coach who has experience in helping at the level of deployment that you are looking for—team, product, or organization. If you do not have a coach, it is very easy to apply a process incorrectly and go down the less favorable path. Without a coach, it is easier to give up and regress back to the old process. The coach provides you with a better opportunity to go down the best path for the team toward Agile (Figure 22-2).

Coaching helps a team adopt an agile process and lays the groundwork for transforming the culture. When discussing the path to adoption, coaches help ensure that elements and the Agile culture surrounding the elements stick.

Providing In-Session Coaching

Training can help teams gain understanding of agile processes and mindset, but at some point the team will implement Agile to gain experience. Because many team members have little agile experience or have a different understanding of what Agile is from past experiences, it can be hard to gauge whether a team is implementing Agile correctly. This is where it is very beneficial to have in-session coaching.

In-session coaching is beneficial as teams begin to implement agile processes and for three to four Sprints. In this context, an experienced Agile Coach sits in on the events and helps a team adapt to their new roles and practices. The coach should have the experience of providing teachable moments without unnecessarily interrupting the flow of an event. By the time the team is in Sprint 3 or 4, the coach should disengage and only periodically check in to see how the team is doing.

For example, in the first Sprint, the coach should attend the Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective events. In the early stages, the coach helps the team with event mechanics. By the third or fourth Sprint, the focus should be more on team dynamics and helping the team achieve a self-organizing state. Because of the principle of self-organizing teams, you do not want a coach participating in agile events beyond several Sprints. You do not want the team to become reliant on the coaches and unable to ­self-organize.

Grooming In-House Talent

As a team is starting to learn their agile process, it is beneficial for a coach to have one-on-one sessions with the Scrum Masters and POs, allowing these two roles charged with championing the agile process to ask specific questions to gain further familiarity with their roles, the mechanics, and the culture that is expected. For the first several Sprints, these sessions can be held weekly, then they should be reduced to once a month or as otherwise appropriate.

If a company is large enough and has several Scrum Masters and POs, another way to groom in-house talent is to hold periodic Q&A sessions for all the exponents of a given role. This is a good way to leverage a coach’s time by fielding questions of general application. At the same time, those Scrum Masters or POs who attend can hear each other’s challenges and realize that they are not alone. This is also an opportunity for bringing the Scrum Master or PO groups together to form the beginning of an agile community by role.

Building an In-House Coaching Circle

If an organization is large enough, there may be a benefit to grooming ­internal staff who have an affinity for Agile to become internal Agile Coaches. An experienced Agile Coach is needed to groom internal coaches, because it requires someone with deep knowledge and experience in Agile and the ­ability to groom enthusiasts to become coaches. This collection of internal Agile Coaches forms the basis for the coaching circle.

An Agile coaching circle is a support network of like-minded Agile enthusiasts who are interested in gaining knowledge and hearing others’ experiences in readying, implementing, and honing teams in Agile. As an organization implements Agile, some folks will more naturally adapt to it. The pool of potential internal coaches may belong to Agile Team members, Scrum Masters, POs, and local Agile Champions. An organization needs to make a commitment to the internal Agile Coaches to allow them to help teams beyond their current role.

Using the Retrospective for Continuous Improvement

The Sprint Retrospective is the first and foremost way to continuously reflect and hone. The goal is to identify what went well in the Sprint and what can be improved. It is an opportunity for the Scrum Team to reflect on the past Sprint’s activities, including team dynamics, processes, tools, and culture. It is equally important to discuss what went well and what can be improved.

Once improvement opportunities are identified, they are prioritized by the team. The highest priority improvement opportunities are discussed by the team, and a root-cause analysis should be applied to get to the core of the problem. This ensures the team is providing the right solution to the ­problem. Then the team commits to those solutions as actions and they become improvement tasks for the next Sprint. This type of reflection and honing occurs on a Sprint-by-Sprint basis.

Using Empirical Data for Improvement Input

As part of honing, it is very useful to use empirical data from meaningful metrics to help a team identify opportunities for improvement. Trend metrics based on empirical data can help you reflect and hone. There are times where team members have a “gut feeling” about something and empirical data can help them take it from instinct to objective fact.

For example, a team is sensing that they are not getting enough time to build their stories during a Sprint. How can they prove this in an empirical manner? To gain empirical data, each team member can review their calendar during the length of a Sprint and see how much of their time is spent in meetings. This empirical data can help someone objectively validate the gut feeling and determine whether a course of action is warranted.

Say, for example, that it is empirically discovered that over 30 percent of the team’s total time is spent in non–Agile-related meetings. Now that the team has baseline data to work with, it is possible to determine over successive Sprints if the action of reducing meetings has a positive effect on the amount of time a team has to build stories.

Conducting Periodic Agile Assessments

Agile assessments can provide insight into the level of implementation of the mechanical elements or the cultural and behavioral elements of Agile. The key is to create a baseline with the current level and periodically reassess to determine whether improvement has occurred. Baselining provides visibility into your starting point and information to help you adapt when moving ­forward. The results of an assessment can provide data points into what areas are thriving and what areas can be honed for improvement.

The Agile Mindset, Values, and Principles (MVP) Advisor is used to answer the question, “How do you know you are Agile?” (see Chapter 13). This assessment may occur at the team or organization level. The results of this survey provide visibility into the behavioral transformation toward the Agile values and principles. This assessment should be first conducted prior to implementation to gauge a team’s current alignment to Agile values and principles. This forms the baseline by which subsequent assessments can be compared. Progress can be tracked by comparing the previous assessment and the current one. The results can be reflected on, and improvement opportunities can be identified based on the results. This honing activity may occur every three to six months depending on how regularly you would like to track your behavioral alignment to Agile.

The Agile Practices Adoption survey is used to answer the question, “How do you know you have adopted the agile processes and practices?” (see Chapter 13). The results of this team-level survey provide visibility into a team’s mechanical adoption level of the agile process and practices that are being applied. This assessment mechanism should be first conducted after a team has had training and has been implementing their agile framework for three or four Sprints or a similar time period. This honing activity may occur every three to six months or pre-release, depending on how regularly you want to track adoption levels.

Improving Velocity

As a team tracks its velocity, members should look for opportunities to improve their pace. Velocity is a measure that can help you understand a team’s sustainable pace by tracking the amount of story points of customer value a team can deliver in a Sprint. As new teams get started with Agile, their velocity trend line is initially inconsistent, but it will eventually become stable and reliable. When a team sees its velocity trend line plateau, it may be time to look for improvement opportunities.

Improving velocity is often a long-term exercise. It can start with identifying and removing impediments and dependencies that slow the team down. Although this action may initiate in a Retrospective, it may require further analysis of challenges that may take several Sprints to fully implement. Some techniques for increasing team velocity follow:

• Look for software reuse opportunities. Software reuse is a process whereby product teams may use software components that represent standard functionality and incorporate them into their product. Software reuse can significantly decrease effort spent on building the same functionality. It entails an amount of integration work to understand the code, assess its quality, and integrate it with the product’s current code base.
• Increase test automation. Test automation is a process that takes manual testing routines and applies coding that executes those tests based on a trigger. Automation can result in a significant decrease in effort spent in executing manual tests. There is effort in getting to a level of automation before it reduces team effort.
• Apply open-source solutions. Open source provides you the ability to use peer-reviewed, high-quality code instead of building it internally. If there is a well-architected code structure, the ability to insert open-source code can accelerate pace and lower costs. There needs to be an investment to understand the open-source code that is available, assess its quality, and integrate it with the product’s current code base.
• Applying a colocation strategy. Colocation is a working environment where a team is in one location. This can be challenging for companies that have distributed staff. Colocation promotes face-to-face communication, which is one of the Agile principles. This activity involves determining if a more colocated team is possible. This may become possible if you are working with several sites where each has seven or more team members. If initially QA was in one location, then QA responsibilities can be distributed. This requires changes for a team, but there can be a benefit to velocity when colocation and face-to-face communication occur.

Promoting Customer Validation

Often forgotten as a honing activity is customer validation. Engaging the customer is one of the most effective ways to hone the product toward building customer value. Gaining continuous customer feedback of working software and incorporating that feedback ensures that you are constructing a valuable solution. As discussed in Chapter 17, the Sprint Review is the gold standard for customer validation events at which the customer gets an opportunity to view the working software.

Other validation activities can also help hone the product toward building customer value. Aside from the Sprint Review, you can gain customer feedback in the review of the product vision and in an alpha-type environment where the customer can exercise the software in a hands-on manner. When a customer attends a validation session of working software, what they are really doing is reflecting on the software and determining if it meets their needs. This information allows a team to hone the software to better align with building customer value.

Promoting Giving Back

As you saw in Chapter 16, the notion of giving back applies to employees who have gained enough skills, experience, and confidence that they are capable of giving back to their community. When employees have reached this level of experience and are willing to give back, they start helping others. In relation to Agile, this is a form of self-organization in which a group of local Agile Champions feels ownership of the mission to enhance culture and is willing to support the transformation to Agile.

Equally important, giving back is a form of individual honing for further understanding of agile concepts. To give back to the community, this person must reflect on their own experience to hone his or her thoughts to determine what they contribute back to the community. Honing your thoughts to give back can occur in several ways:

• Contributing your experiences and providing answers within the local agile social collaboration venues. Providing answers to a Q&A venue require a reflection and fine-tuning of one’s thoughts prior to responding.
• Writing a blog article on an agile topic or experiences you have had on an Agile Team. Authoring an article requires reflection and articulation of one’s thoughts, knowing that readers will take your writings seriously.
• Participating as co-lead in agile training. Preparing for training and being in front of a crowd can motivate a strong need to reflect and hone your understanding of a topic and the delivery approach.
• Drafting and delivering seminars and webinars. Creating and delivering information likewise requires reflection and honing.