Agile Managed Services

Introduction

An increasingly important component of our outsourcing initiatives involves Agile, in which Infosys is asked to introduce or enhance clients’ Agile capabilities to advance client business objectives. In this paper we address how Agile delivers value in a Managed Services environment by combining two powerful resources:

1. Agile Frameworks - for both Application Development and Application Maintenance
2. Agile-savvy Change Management - Organizational Change Management focused on the cultural and leadership elements of change necessary to facilitate Agile adoption

Because behavioral and cultural change are so central to Agile adoption, this paper focuses on people – rather than on Agile process or tactics – the subject of much existing industry and academic research. We highlight key organizational impacts and implications of Agile Managed Services to help leaders:

• Understand - How organizational culture impacts Agile transformations
• Act - Make informed decisions about the best way forward
• Sustain - Make Agile initiatives “stick” for the long-term by equipping them with practical and actionable strategies

What is Agile?

Agile is a way of working that entails a “be” and a “do” (see Figure 1). The “be” refers to a mindset that acts as the foundation for working in ways that are based on and guided by values such as respect, collaboration and experimentation. We see these values through core Agile guides such as the Agile Manifesto¹ and Agile Principles.² The Agile mindset provides the most lasting value because it’s the “engine” that powers the “do” of Agile, which are the processes and frameworks.³ Although it is the most powerful layer, the Agile mindset is also the least visible and most difficult to change.

But Agile processes or frameworks without the mindset of core values are not Agile; they’re just another process. Instead, Agile is qualitatively a different way of working.

Figure 1. The Agile Onion

What is Agile Managed Services?

In Traditional Managed Services, a client transfers operational control of business and/or IT functions to a supplier along with the resource and process management responsibility required to deliver that service. Typically, the client retains a small Service Delivery team to manage the supplier, internal business relationships and the joint service delivery capability.

In Agile Managed Services, the same concept holds true – the supplier assumes responsibility for day-to-day tactical and operational performance – but the nature of the partnership changes based on the scope of service involved, i.e., Application Maintenance vs. Application Development. Importantly that determines how the client organization is impacted, and how the client and supplier interact to deliver IT services (see image below).

Table 1 : Comparison of Agile Organization Impacts by Scope of Service

In an Application Maintenance environment where the supplier integrates Agile into its delivery model, the client’s retained team and business partners are typically not significantly impacted. DevOps, for example, doesn’t require the level of close client coordination with the business that Scrum would for Application Development. The supplier can unilaterally introduce DevOps (and other similar Agile frameworks) to eliminate process waste throughout the software development pipeline. Examples of good practices here include integrating Ops staff into development teams and/or rotating developers into DevOps teams. This example scenario of integrating Agile into managed services does not require the client to undertake a full-scale Agile transformation. It could be leveraged as a catalyst in that direction, but can also operate independently on the supplier side.

An Application Development environment likely requires much closer client interaction and ownership, particularly for the business and where possible, the customer. A classic example is a joint client-supplier Scrum team comprised of a Product Owner, Scrum Master and various development positions. The Product Owner, ideally staffed by the business, performs a critical leadership role with responsibility for the vision, scope and goals of the release. The Scrum Master and the rest of development team can be staffed by either the client’s retained IT team or the supplier.⁵ Regardless of the composition of the Scrum team, the important point is that the collaboration required to effectively run the team across functions and entities⁶ has significant change implications for the client, beyond what is typically required in Traditional Managed Services. (Appendix 1 summarizes these important factors, by comparing Traditional Managed Services and Agile Managed Services operating models).

There are several ways Agile can also enhance Infrastructure work. IT Infrastructure encompasses hardware, software, networks, facilities, etc. used to develop, test, deliver, monitor, control, or support IT services. Common challenge areas include networks and communications, provisioning and management, data acquisition, computing platforms, data storage architectures, networks and communication, and data analytics. Each of these areas requires proper decision-making, innovation and execution. While several Agile values, principles and frameworks can be leveraged to support these activities, some key ones include Lean StartUp and Value Proposition Design for innovation and keeping abreast of trends, Scaled Agile Lean Portfolio Management for decision-making, especially with economics in mind, and Kanban for execution (both the methodology and highly visible information radiators).

A fourth configuration could involve the integration of Development and Maintenance. In this scenario, one team would have application development and support staff - and potentially infrastructure staff - on the same team. In fact, this is often the ideal team to implement DevOps due to the following advantages:

1. Reduced delivery time and cost stemming from less “throwing work over the fence” between app dev and support/deployment translates into less rework.
2. Shortened wait time, since team members can immediately ask for blocker removal vs. waiting for someone on another team, with different priorities, to respond.
3. Increased quality, since team members with different skill sets work more closely together; for example, development, QA and deployment specialists.

Cultural Shift

Agile values derive from an organization’s culture which we define as the assumptions, deep structures and mental models that drive behaviors. Underestimating the importance of culture in Agile transformations is a common mistake that can lead to stalled initiatives and employees reverting to old ways of working. A key success factor in any Agile transformation is helping the organization become “a learning organization,” so that they can sustain relentless improvement after the consultants walk out the door.

Most organizations that are hierarchical tend to value “command and control” mechanisms, whereas Agile teams perform best when they are autonomous and self-organizing. This inherent conflict can undermine Agile initiatives because managers who feel threatened by Agile will not readily relinquish control to teams.

Unfortunately, most Agile initiatives focus almost exclusively on Agile teams and fail to consider middle and senior management’s roles as Agile leaders. This creates a gap in awareness and commitment for the very people responsible for governing and guiding the success of the initiative. When middle and senior leaders do not see what’s in it for them, they often misperceive their Agile roles as a loss of power and influence. A comprehensive training and coaching plan for all levels of management impacted by Agile is essential to help them understand what Agile leadership behaviors looks like, their role in that, and why it’s so important. See Appendix 2 for other common barriers that prevent Agile success.

Agile requires an equal partnership between the supplier and client in fulfilling client business objectives. Traditionally, some clients misperceive the supplier role as being limited to an order taker. Although this can occur in Traditional Managed Services, it becomes even more deleterious in an Agile Managed Services relationship where greater collaboration and a shared responsibility for service delivery are paramount.

Leadership Commitment

Embracing a high level of collaboration and trust is the foundation of an Agile initiative. This is especially true when Agile represents a radical change in culture, leadership behaviors and responsibilities. But we need to be realistic – cultural change won’t happen overnight. Culture shift happens over time, in some cases years, and relies on sustained and intentional sponsorship.

It is critical for leadership to have a visible and active role in facilitating and growing the change. Leaders do this in a number of ways. They communicate the end-state vision and business objectives, and importantly, act as change agents and role models themselves. Ideally they also define an Agile roadmap, both for Agile product development, and the organization at large, to implement the change. They define Agile team performance expectations and publicly celebrate successes. In short, they create the workplace conditions for Agile ways of working to take root. A key success seen in the industry is when leaders themselves actually adopt Agile in their own work vs. simply asking others to do Agile. Examples include: Activating portfolio level visible Kanban processes, regularly doing retrospectives on their own work, and spending less time on operational tasks and more time developing people and strategy.

Talent Management

As with Traditional Managed Services, clients sometimes disregard the importance of aligning their talent management practices (e.g., job and organizational redesign) to enable Agile transformation. Employees who transition to an Agile team for the first time can’t be expected to adopt the new ways of working if they are not properly supported. Please see Appendix 3 for details.

Similarly, the supplier also needs to adjust to Agile ways of working, particularly for incumbents accustomed to delivering services in a non-Agile and/or non-Managed Services environment (such as staff augmentation, or⁷ hybrid resource models). In such cases, supplier resources may be used to taking direction from client managers rather than operating independently as equal partners in an Agile Managed Services environment. Bridging the gap between order taker and strategic partner can be a significant challenge that requires a period of adjustment from both the supplier and client. Embracing and modeling Agile behaviors not only applies to the supplier’s onsite delivery resources, but offshore staff and management as well.

Transition Support

As noted above, leadership involvement is a key component of transition support. Often times leaders want their organizations to “do agile” without understanding or adopting agile themselves. This anti-pattern can be addressed by talking with leaders about what agile leadership looks like while avoiding vague axioms such as “Don’t command-and-control.” Examples of agile leadership behaviors include creating and regularly refining a backlog for the leaders themselves, as well as using lean techniques such as weighted shortest job first to move portfolio level and program level service offerings through approval and funding pipelines. Finally, some people oriented examples of agile leadership include leaders becoming curious, humble, relentless learners, and growing their people to be and do the same. See Appendix 4 for additional interventions to help staff transition to Agile.

Distributed Teams

We are sometimes asked, “Does Agile Managed Services really work?” The question reflects understandable skepticism; after all, the Agile Manifesto’s most important rule emphasizing individuals and interactions overs processes and tools, naturally works best in a co-located environment. However, distributed resources are simply a fact of life for many organizations as they enter new markets, grow through acquisition, expand teleworking, etc. Although co-location is the ideal, it is not necessary for successful Agile adoption. A more important consideration is whether the underlying culture facilitates Agile behaviors and whether the team is proficient operating Agile methods. Consider, for example, a co-located team where management approvals and bureaucratic sign-offs are the norm. If that team is unable to develop collaborative behaviors, close physical proximity won’t matter. Whether physically or virtually, the key point is to create an environment for regular and meaningful team interactions, such as efficient, disciplined daily stand-ups and regular retrospectives to find out, “What should we keep doing that worked in the last two weeks? What should we stop doing? What should we start doing?” This includes leadership teams as well as delivery teams.

Another best practice is to co-locate key personnel when first deploying an Agile team, e.g., having key developers travel to the client site. There is no substitute for establishing personal rapport with key stakeholders, understanding the client environment firsthand and establishing ground rules, like the ”Agile Team Social Contract”⁸ for how the team will operate, including observable signs of success. Too often, however, clients choose not to invest in travel or even to use collaboration tools. A very simple, yet highly impactful tool is to turn on cameras during meetings between distributed participants. See Appendix 5 for other distributed team considerations.

Business and IT Alignment

Business and IT Alignment is a strategy in which IT is leveraged to achieve specific business objectives, which include financial performance and marketplace competitiveness. Agile enables this strategy by integrating business and IT stakeholders in development teams often, ideally with full-time team members.⁹ This de-siloing team structure allows the business to both better organize around customer value, as well as to play a much larger role in product / software development than in more traditional structures, where they operate independently of IT.

As IT evolves towards Agile, the business also ideally adopts Agile mindsets and processes. Otherwise, a lack of business involvement leads to misalignment and disconnect across the enterprise. One challenge with low business and IT alignment is the absence of a mechanism to ingest and process business requests from the development team and program levels. Another common challenge is when the business staffs a part-time PO or one without a sufficient decision-making authority over product direction. This puts the PO, Scrum Master and entire Agile team, and mostly importantly, the customer, in a no-win situation. A PO is not a glorified business analyst, but instead more like the CEO of a startup.

In order for the business to adopt Agile in any form, they need to see what’s in it for them; real, concrete benefits. Simply communicating that IT is doing Agile will not work.

High levels of business-IT alignment on Agile roles requires leadership agreement on shared outcomes and role definition.¹⁰ Common goal alignment ensures that the Business and IT operate on valid assumptions. Explicitly articulating goals and periodically assessing progress helps eliminate misunderstanding and confusion. Decomposing executive-level goals to departmental and team-level goals enables Agile teams to deliver on those goals and to align to the entire IT organization and its culture.¹¹

Agile Change Agents

Change agents comprise a network of individuals selected from across the enterprise to facilitate, support, monitor and coordinate the roll out of changes associated with transformations. Often they are the people who are the pioneers, visionaries, dreamers and risk takers. Typically, they are also highly respected by their peers, and as such, are natural leaders of change. In Agile transformations, change agents take on an expanded role of helping impacted managers understand their new roles and responsibilities. In many success stories, they ARE the managers. This is critical to combatting the myth that managers no longer have value in an Agile world; in fact, they are integral to Agile success in their new roles as Agile leaders, spending more time on strategy, product direction, people development, and creating a learning organization. Role transition does not happen automatically; it requires the ongoing support of experienced transformation coaches at the team, management and enterprise levels.

Metrics

An important but sometimes forgotten component of Agile implementations is success measurements. It is important for both Agile practitioners and clients to ask and answer the question, “How well are we performing against our goals? What are 2-3 observable signs that will tell us along the way that we are being successful? “

This means constructing observable success indicators that not only satisfy key stakeholder needs but are also simple and easy to measure on a regular basis. Since Agile values short time boxes (to accelerate learning) a recommended cadence for observing and adjusting visible success indicators is two weeks in Scrum, more often in other models, like Kanban. This means that the success indicators would likely be both qualitative and quantitative, and the qualitative data could be supplemented by quantitative data once it becomes available. Examples of qualitative data include customer satisfaction, team engagement levels or team self-organizing levels. Examples of quantitative data might include number of features delivered per sprint or per quarter, velocity or throughput metrics.

Client Procurement / Vendor Management Offices, whose traditional perception of the supplier’s role in an outsourcing relationship, will also need to adjust to Agile Managed Services. For example, the rigidity of traditional budget and schedule performance measures are based on a fixed waterfall mindset that is inconsistent with Agile’s iterative, short execution cycles. Traditional SLAs, which are also rigid, and intended to motivate the supplier to resolve incidents according to pre-defined severity levels, will also need to be updated. In Traditional Managed Services, the client’s Service Delivery team coordinates with the supplier to prioritize lower severity incidents, in order to manage the supplier’s workflow. In Agile Managed Services, this prioritization process becomes the purview of the Agile team, whose criteria for incident resolution is now based on value stream analysis vs. closing tickets driven by a traditional SLA framework.

Conclusion

We have focused on the people component of Agile adoption in Managed Services because, like all major transformations, the behaviors (and underlying mindsets) of people ultimately determine whether the transition will be successful. This is especially true when the shift required to operate Agile teams is dramatically different from that status quo. In such cases, organizations need to take a realistic measure of the gap between their current and target states, both business-wise and culture-wise, and decide how well positioned they are to start the Agile journey. Only when leaders are willing to commit the necessary resources and management attention, and teams are open to trying new ways of working, will Agile Managed Services be able to succeed.

Companies can grow and nourish that willingness over time by starting with respected staff who are curious, open to learning and interested in exploring dynamic ways to help their organizations succeed. These trailblazers become the catalysts for organizational shifts that will allow Agile to flourish in a managed services environment.

Appendix 1: Comparison of Traditional and Agile Managed Services Operating Models

Appendix 2: Barriers to Agile Success

Organizations typically explore Agile because of the clear business benefits it is capable of producing, such as speed, cost, quality, innovation, customer engagement, etc. In order to reap these results, often the people leading Agile pilots or adoptions can use help making the distinction between, “Is this really Agile? Or does it just look like Agile?” and “What are some common pitfalls to avoid?” and “What are some observable signs we are being successful?” This information helps leaders know whether Agile is producing the intended results. Some barriers that commonly surface in Agile transformations include:

• Unclear roles and responsibilities especially at middle management levels.
• Staff selection is not based on Agile needs because organizations don’t understand Agile role requirements or are not committed to Agile methods, often because they don’t yet see what’s in it for them.
• Broader organizational practices don’t align to Agile ways of working, such as performance plans and incentives, budgeting and planning practices.
• Inability to integrate or operate Agile teams within the traditional organizational structure, i.e., coordinating Agile and non-Agile teams and other internal project teams, PMO, etc., as well as interfacing with traditional customers (internal) or clients (external).
• Inability to shift control or governance mechanisms to allow for self-organizing, autonomous, collaborative Agile teams. The key here is failing to understand or integrate the core principle of Agile, which is a constant “adjust and adapt” cycle, often practiced in weekly retrospectives, beyond team boundaries.
• Conventional short-term team structures (project-based) don’t fully transition to long-term Agile structures (product-based). If leaders - the architects of culture - continue to drive project- vs product-based cultures, the full benefit of Agile cannot be realized.
• Innovation isn’t valued or understood as essential. Companies in this category are in danger of becoming obsolete but often don’t yet realize it, sometimes because they’ve been living in a bubble or haven’t been exposed to innovative forms of Agile such as Lean Startup.
• Failure isn’t tolerated, experimentation isn’t valued. This may be observed in cultural mismatches, in which an organization says one thing, but does another. For example, an organization claims that small, frequent failures are beneficial but continue to punish these failures or fail to build in regular Agile adjust and adapt cycles.
• People don’t collaborate effectively across functional boundaries. Ask, “Is this a can’t or a won’t?” In many cases, people want to collaborate across boundaries, and even have cross functional teams, but the effectiveness of that team gets limited by the fact that individual team members’ loyalties and priorities still lie in their direct reporting line, not to the team, product or customer. This is often related to broader cultural and governance issues that discourage freely sharing information.

Appendix 3: Talent Management Best Practices

• Job Clarity. Understanding Agile ways of working does not come naturally to most traditional organizations, even for IT. A training program to help managers and team members understand role changes and behavior expectations is critical. And since 80% of all learning happens on the job, we also recommend both for the client and supplier teams, to integrate job-based learning around Agile roles. Examples here might include community-based learning, and regular access to Agile coaches, not only for consulting, but for coaches to observe new Agile practitioners trying new practices and giving them growth oriented feedback.
• Team Selection. Agile teams require a different set of skills and competencies than traditional teams. For example, comfort with continuously evolving customer needs is a critical Agile trait vs. the more traditional approach of exhaustively documenting requirements. Also plan for some degree of attrition which results from any cultural transformation. Ideally the initial team members selected for pilots are high performers and continuous improvement enthusiasts. They are typically the pioneers and the explorers. Find them, offer them Agile pilot opportunities, and publicly recognize their successes.
• Career Development. Defined career paths and professional opportunities sustain Agile product teams, and helps attract and retain talent. Staff Agile-specific career paths with talented people who are respected by their peers and willing to try new things. Career paths should include options for middle management, as they often need guidance on the importance of their roles in Agile.
• Performance Management. Changing the way managers and teams are evaluated is important to enable and reinforce new Agile ways of working. Examples include more frequent performance reviews (quarterly, for example) and more involvement of peers (such as 360-degree performance reviews).
• Organizational Design. Thinking about how newly formed Agile teams will operate within the organization around value delivery is a key design principle. This isn’t necessarily a reorg exercise but a deliberate plan for how work will get done in an Agile world. For example: What is the composition of Agile teams, at team and program levels, for both Business and IT? What are the new reporting relationships? How will Agile teams interact with one another and with non-Agile teams? How will you enable self-organizing, self-governing teams while also promoting accountability?
• Agile Leadership Program. In addition to HR policy updates and role-based training, mentoring managers in their new roles over an extended period sustains Agile transformations. Often in Agile transformations, middle and senior leaders are interested in Agile leader roles but don’t know what they involve or what’s in it for them. Two key roles of the Agile manager are to be a change agent (vs delegating this), and to govern work, including business case analysis, budgeting and approving work to get done by teams. Agile leadership is a new skill set for many. In our experience a model that has worked well to grow this skill set is to create a cohort of managers that meets quarterly in person, and receives both group facilitation (on actual cases they bring from their own work) and weekly individual coaching sessions. This promotes the best of adult learning approaches with community based learning and practical, case-based problem solving

Appendix 4: Transition Support Interventions

In any transformation the one question that is top of mind for every employee is, “How will you (the employer) help me succeed?” Without this support, indifference and/or active resistance can be expected. Leaders should carefully consider specific actions to make that happen, such as:

Appendix 5: Agile Distributed Teaming

New Agile managers can bring significant positive impact by considering the following actions for distributed team environments:

• Choose resources best suited for the job rather than local resources, by default. Ideally the first resources should be highly respected by their peers, seen as trail blazers and thought leaders.
• Create a shared environment supported by tools/processes that enhance team productivity (e.g., communication, project management, source code, etc.). Empower the team to decide what tool/processes they will use, but provide a high level of support early to help them make the right decisions early on. Some coaches, for instance, tell new teams that they can modify Agile practices as soon as they improve their velocity by 300%.¹⁴
• Until you have demonstrated some basic level of proficiency with co-located teams, try not to start off with distributed teams. If you must, supply a highly experienced Agile coach on site at all locations. Organizations sometimes think that training is enough. But the real learning happens on the ground in the workplace, with an Agile coach working alongside new Agile practitioners.
• Establish clear ground rules for how the team will collaborate across distances, time zones, cultures, languages, etc. Use the Agile Social contract, not just at the beginning of a team kickoff, but in every retrospective. Ask, “In the last two weeks, how well did we succeed against our Agile Social contract, on a scale of 1-10?” “What’s one thing we could do better in the coming two weeks?”

References

1. Agile Manifesto: https://agilemanifesto.org/
2. The Agile Principles: https://agilemanifesto.org/principles.html
3. Example Agile processes (Scrum, Kanban, DevOps) and scaling frameworks (SAFe, Disciplined Agile, and Scrum at Scale)
4. Not exhaustive.
5. Clients may choose to retain / staff core functions such as architecture and UX, leaving other roles for the supplier to staff (e.g., testing, coding, document writing, etc.).
6. Includes the client’s retained team, client business partners, the supplier and potentially other service providers.
7. Hybrid models combine elements of staff augmentation, project support and managed services.
8. Social contracts are informal agreements to establish and reinforce team norms and behaviors. Since Agile teams are self-organizing, it’s important for them to define their own behavioral standards (e.g., stand ups begin at 8am daily, everyone has an equal say regardless of rank or location (onsite or offsite), etc.).
9. Or the highest percentage possible, ideally not less than 80%.
10. For example, a well-occupied PO role includes: Business person (not IT proxy) with decision-making authority, close contact with the customer, passion for and belief in the product vision, and 100% team dedication, whether remote or in person.
11. A starting point to align the organization is to assess the whole system – IT, the Business, and the Business-IT relationship. The study should seek to understand common system patterns, enablers and blockers, including potential leverage points for change interventions.
12. Team is funded based on project’s pre-defined scope and schedule. The team dissolves when the project ends.
13. Team is funded on a rolling basis and organized for the long-term, through multiple product cycles that support the customer’s ongoing needs.
14. This usually takes 3-6 months in a well-supported team.

Download