Who's on first?

The bigger the program, the more customers and stakeholders exist. More customer involvement is expected for agile programs than for other programs. There are more customers than those in specific agile program roles. Finding them all and working with them to enable the benefits of the program to be accomplished are essential to avoid debilitating chaos. Communications management and training are two areas of change management that are particularly important for large-scale agile program success.

Introduction

Let's first paint the picture of large-scale agile programs using a Scrum or incremental approach to deliver a software solution and their potential for customer chaos.¹ An agile program involves customers as product owners throughout the program to prioritize and reprioritize business needs, as well as to review and provide feedback rapidly for incremental solutions built in short cycles. When there are multiple agile Scrum or delivery teams working with multiple product owners, often at multiple locations, possibly on multiple planned releases of a solution, the program has scaled up to be “large-scale.” The multiplier effect is significant on all aspects of orchestrating the program, but particularly when it comes to managing customer expectations and involvement.

What can go wrong from a customer perspective? A product owner may be in sync with his or her agile team, but not with other product owners. This can result in conflicting solution direction discovered with cross-team validation and release-level demos. A product owner may bring a perspective of business priorities that is not aligned with solution users, either those participating in some large, release-level user acceptance test activity, or the ultimate end users. A product owner may be unable to make the cyclical story acceptance decision in a binding way, either delaying or changing decisions. A product owner may feel he or she does not have the big picture in terms of the total solution, or may not understand the impacts of his or her behaviors on other parts of the program. A product owner may get reorganized during the program with new responsibilities that do not involve the program, or he or she may take an extended vacation or leave the organization. This can be disruptive, because the glue of the ongoing agile interactions has lost its stickiness. Imagine as many as 10 active product owners, each representing a different business function with different line management, different agendas, and different immediate stakeholders. The potential for customer chaos is real and represents a significant risk to the large-scale agile program.

If your own program management and agile experiences do not convince you, consider communication theory. Basic communication theory, starting with Shannon (1948), tells us that communication complexity increases with the number of participants. Relative to project management, Badiru (2008) identified a Triple C Model, involving communication, cooperation, and coordination. In Badiru's model, cooperation complexity increases even faster than communication complexity with the number of participants. We cannot take cooperation for granted: It demands structured communication up front and is a prerequisite for effective project and program coordination.

As a program manager faced with the need to deliver a large-scale agile program, managing customers and stakeholders is an essential part of your activities, starting during planning. The best agile program managers are also effective organizational change management leaders.²

Identifying Stakeholders

First, the identification of customers and stakeholders starts early. We need to get beyond the product owners and the agile Scrum team participants, mapping out all the internal, customer, and third-party direct and indirect participants, impacted stakeholders, and influencers. Though best agile practices demand that the executive sponsor of the program should be from the business organization, this does not always happen. Particularly when agile programs are driven by IT organizations, understanding the entire spectrum of customers and stakeholders can be difficult. One vehicle we have used successfully is the business execution model diagram. It is a network diagram for the agile program that shows all the participants at an organizational level. The connections in the diagram indicate who is the immediate customer for an organization (internal or vendor) on the program. This is essential to know, because it often motivates behaviors that are otherwise difficult to understand. Exhibit 1 shows a skeletal business execution model diagram.

Exhibit 1: Sample business execution model diagram showing stakeholder organizations.

In the narrowest sense, only the yellow boxes across the top of the diagram are customer stakeholders for this program. The customer LOBs, or Lines of Business, box will be expanded with possibly one product owner per LOB, or per department within an LOB. This will also lead to corresponding additional detail in the customer user groups for the solution.

Note the number of other participating organizations in the program. Each of them needs to know what is going on and what is planned in order to be able to cooperate and coordinate for collective delivery of the program benefits. The challenge is that when you start a program, you may not even know of their existence, let alone their relationships with other organizations involved in the program.

Complete stakeholder identification requires going into detail about the individuals participating and impacted directly or indirectly by the agile program. Stakeholder analysis starts with gathering information about all the stakeholders, beginning with their home organization from the business execution model diagram, typically during program planning and initiation, including Epic 0. This information is structured into a stakeholder map document. The following information is typically helpful for large-scale agile programs:

• Stakeholder name,
• Home organization,
• Title in organization,
• Role relative to program,
• Impact of program,
• Influence on program success, and
• Attitude toward program.

This can add up to a large table, which can also be visualized for further analysis according to the various dimensions. For example, the program roles can be categorized and viewed as core agile team participants, extended agile support team participants, and others beyond the program team. This is shown in Exhibit 2. Each has a different communication need. Notably, the program sponsor and other executives are obviously a special case of stakeholders, for which governance structures are planned and used to provide oversight for the delivery of the agile program and its benefits.

Exhibit 2: Stakeholder visualization summary by role category.

Planning Agile Program Communication

Stakeholder analysis examines the stakeholder map in many ways, and ultimately drives our change management and communications strategies and plans. We tackle communication using a systematic, multilevel approach. For Scrum teams and agile program delivery needs, sprint-level and release-level communication ceremonies are central, but with scale, additional communication vehicles are needed.

Many organizations, while striving toward a quarterly or more frequent fixed cadence of production releases, still plan large initial solution releases. This introduces traditional software development life cycle concepts and milestones into the agile program. One fundamental aspect of participating in agile programs that customers struggle with is the amount of participation required. Though they may welcome the opportunity to have influence throughout the program, customer organizations are often unprepared for the impact of the time commitment or the need for empowered decision making demanded of agile product owners. We have introduced planning communication vehicles successfully to address these concerns and support customers as they plan their participation in large-scale agile programs. First we use a program milestone map that shows when various agile teams ramp up, are active, and how their activities relate to release-level activities.

The sample shown in Exhibit 3 has been formatted to avoid a long timeline stretching horizontally across the page. Each column is a week. Sprints and months are also shown. The rows are for the various agile delivery and support teams. We have collapsed some groups of teams for the sake of simplicity. Also, when we use the Cognizant Daikibo™³ approach (Cognizant, 2015), we show first concept teams starting, followed by delivery teams, and then validation teams for each of the agile team rows. Sometimes a concept team, which works with the customer product owner and subject-matter experts, as well as with leads from delivery and validation teams, feeds multiple delivery and validation teams. The easiest example to help understand this is for reports or interfaces. Customers rarely can provide an individual who can be a product owner for all reports or all interfaces across multiple business functions of a complex solution. Instead, those reports and interfaces arise as technical stories in the context of the given business user story created by a concept team.

In any case, the milestone map allows an “at a glance” view of the program, showing when release-level activities, shown here as the initial pale blue⁴ Sprint 0 event; the yellow hardening, integration, and performance (HIP) sprints⁵ that occur during Sprints 6, 11, and 16; and the aqua user acceptance testing (UAT) event starting Sprint 17, followed by multiple data conversions and go-live events. The details are less important than the big picture for this diagram. Once a program start date is fixed, real dates and holidays are mapped to the diagram and customers can easily see when their agile team will be active, when they will need to participate in release-level events, and when UAT and go-live are planned.

Exhibit 3: Sample milestone map for large-scale agile program.

The milestone map is also helpful for support function planning, including environment planning and organizational change management (OCM) planning for large-scale agile programs. It is totally customizable and useful when the shown HIP sprints are replaced with ongoing production releases.

For more fine-grained customer participation planning, we have used calendars to map out the sprint- and release-level activities in which a given customer product owner or subject matter expert (SME) or architect needs to participate. Exhibit 4 shows two months of a sample customer calendar used for planning participation in a large-scale agile program. In the sample, 2015 starts midstream in Week 1 of Sprint 3, assuming 3-week agile sprints. Each column is a day in a month, and each row is a different customer-involved agile team. The neon green cells show the first day of each sprint when each agile team is busy with spring planning activities, and the dark green cells show the last day of each sprint by which time the sprint demo, with accepted stories, as well as the sprint retrospective should be completed for each agile time.

Exhibit 4: Sample partial agile team activity calendar.

This calendar is typically accompanied by a description of all customer agile program role activities with an estimated effort in hours. Together, these are greatly appreciated by customers in helping them plan and manage program participation. The calendar lends itself to expansion and customization. Scrum meetings, essential for large-scale agile programs, are typically held twice a week as a stand-up meeting for all product owners, Scrum Masters, release managers, and architects, and can easily be added to the calendar. When HIP sprints occur, then the release planning events in which all teams participate are shown on the calendar. Although the sample shows sprints starting on Mondays, we typically move them to a mid-week start and finish for customer participation reliability and consequent program productivity reasons—in our experience, absenteeism in our customer companies is lower mid-week than on Mondays and Fridays.

When agile programs are large and new to an organization, agile champions, steering committees, and other planned communications are needed at multiple levels to bring all the stakeholders, particularly those less immediately involved in the program, into the fold. This requires budget, organizational change management skills, and discipline. Either the agile program manager or a dedicated OCM lead should be assigned to be responsible for these activities, which are typically more business organization facing, rather than IT or technology organization facing in the customer organization. Standard OCM practices apply and dovetail well with the agile approach to delivery. The agile coach has a special, training-related role in the OCM activities of a large-scale agile program, but typically is not positioned correctly to address the total change management needs for the customer.

Training for Agile Program Customers

One recurring reason for customer confusion and potential issues for large-scale agile program delivery is nonalignment in understanding how the agile methodology to be used works. There are many flavors of this challenge. Program participants whose prior experience provides them information about the entire solution, such as architects, data architects, environment managers, and testers, are a case in point. In 2015, most organizations have tried some type of agile delivery, but few organizations have committed to be truly agile. Gartner calls this the bimodal IT model. Because no agile program can assume that its participants are part of an enduring high-performance agile capability using a shared, familiar methodology, early training, followed by ongoing agile coaching, is essential for each agile program, particularly large-scale ones. Some individuals in the customer organization will report some agile experience, but it is rarely large-scale or in the current organizational context. Negative prior experiences with agile delivery may make many customers wary of achieving the benefits of the agile approach. All this needs to be “reset” with team-based agile training during the program initiation, planning, Epic 0, or Sprint 0 phases.

Agile adoption itself is a form of organizational change, although it is rarely the focused benefit or change the organization is pursuing with the program. According to the Prosci^®6 change management model (Prosci, 2015), organizational change demands change by all the involved individuals. This brings us back to the importance of the stakeholder analysis, to understand the types of changes being faced by all the various program stakeholders. This will help lead all of them through the appropriate ADKAR^® model, a sequence of being aware of the change, desiring to make the change, having the knowledge to make the change, the ability (skills) to make the change, and reinforcing the importance of making the change. The reality of the situation of most large-scale agile programs is that in addition to use of the agile approach, there are other concurrent changes needed or under way. The OCM lead and stakeholder analysis will reveal these, and the training approach for program participants needs to consider the entire situation. Most large-scale agile programs need training plans to cover the following five areas:

• Customer/program,
• Mandatory/security/regulatory,
• Domain knowledge/solution components,
• Processes, and
• Tools.

At first glance, customer stakeholders may not need some areas of training—knowledge of the customer and tools, for example. The relevancy of specific tools for customer stakeholders needs to be assessed before it is determined that customers do not need the training. Also, new program team members and stakeholders may arrive during the course of the ongoing program and may benefit from common training to avoid additional confusion for them individually and potential disruption to the program. Program team members are recruited based on their knowledge of the domain, the solution, and the tools typically, and so only gap-filling training is expected in those areas.

The program training plan should be tailored by role and cannot be onerous in terms of time and expense to implement. Typically, it is a combination of in-person training with computer-based training and prior-recorded sessions that can be attended at the convenience of individuals. Some training is required as part of initial onboarding—for example, security and mandatory regulatory training. Other training, such as customer and program overview, is typically part of the initial kick-off event. Those are not the focus of the further discussion and example below.

Exhibit 5 shows a subset of a training plan for a large-scale agile program, focusing on agile processes and tools. Each row represents a group of team members or stakeholders and each column is a set of training. The numbers in the body of the table are the recommended order in which the training is to be taken.

Exhibit 5: Partial sample training plan for a large-scale agile program.

In our experience, customers and other program team members attending training together for the agile overview, as well as the program-specific agile processes and tools, is very beneficial. It typically occurs during program planning or initiation or Epic 0 or Sprint 0 and allows team relationship building to start early. On a large-scale agile program, the program manager or program office needs to assess the training needs of each program participant during onboarding and track them to completion. Some training may be taken after the start of the program without impacting program performance.

For stakeholders outside the core agile program team, including executives, we recommend the program overview, and that versions of Agile 101 and the Agile Application Lifecycle Management (ALM) Tool Overview be part of their training. Both the Agile 101 and ALM Tool trainings need to be specifically in the context of the program and how its performance is being captured and reported, which will be of interest, and may be new and not based on the prior experience base for these stakeholders. The customer program leader needs to have a role in presenting this information to ensure its acceptance by these stakeholders.

Conclusion

Large-scale agile programs have many customers involved directly and many additional beneficiaries and stakeholders. Because of the collaborative nature of the agile approach, the dependence on customer cooperation and coordination is greater for agile programs than traditional software development life cycle programs. Our experience with implementing complex solutions incrementally for faster benefit realization by our customers has led us to develop an agile approach we call Daikibo, based partially on the SAFe Framework. Whether you are using a specific agile approach aimed at large-scale programs or not, the specific customer challenges you may face can be managed effectively using the frameworks and customizable tools presented in this paper.

¹ This paper focuses on Scrum-based agile software application or solution-centric programs. There are aspects of the described approach that may not apply to large Kanban or Lean implementations.

² Although this paper focuses on large-scale agile programs, many aspects of the customer management activities laid out here also apply to any large or complex program.

³ Daikibo is a trademark of Cognizant Technology Solutions U.S. Corporation.

⁴ References to color in the exhibits will be clarified during the presentation.

⁵ HIP sprints are a term introduced by SAFe, the Scaled Agile Framework. SAFe and Scaled Agile Framework are trademarks of Scaled Agile, Inc.

⁶ Prosci and ADKAR are registered trademarks of Prosci, Inc.