- About Us
- Infosys Knowledge Institute
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:
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:
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 Manifesto1 and Agile Principles.2 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.3 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
|Scope of IT Service||Agile Frameworks (Examples)||Client Impact / Magnitude of Change||Business-IT Collaboration||Key Business Benefits|
||Low – Moderate||Moderate||
||Low - Moderate||Low - Moderate||
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.5 Regardless of the composition of the Scrum team, the important point is that the collaboration required to effectively run the team across functions and entities6 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:
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.
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.
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, or7 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.
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.
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”8 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.9 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.10 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.11
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.
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.
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
|Operating Model component||Traditional Managed Services||Agile Managed Services|
|Business – IT Interface||
|Structure and Funding||
|Skills & Competencies||
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:
Appendix 3: Talent Management Best Practices
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:
|Train and enable staff on Agile ways of working||
|Continuously coach and mentor teams to drive behavioral change and in particular, to help Product Owners understand and perform their new role||
|Establish Agile ways of working and performance expectations for team members||
|Scale teams through distributed Agile||
Appendix 5: Agile Distributed Teaming
New Agile managers can bring significant positive impact by considering the following actions for distributed team environments: