Many companies right now are going through agile transformations. The goal of practically every agile transformation is to create a network of self-organised teams that work in an iterative and incremental way and deliver toward a common vision, mission, and goals.
Empowered individuals and self-organized teams are at the heart of agile. But here’s the thing: most companies have a mixed sourcing strategy where some of their talent is internal—and the rest comes from outsourcing service suppliers.
Which has many leaders wondering… can agile apply to IT outsourcing? Do the same principles that apply for employees of the company that’s going through an agile transformation also work for the employees of its service suppliers?
Agile can apply to IT outsourcing. To adopt agile and keep outsourcing, companies need to revisit the buyer/supplier relationships with their service suppliers. The fixed-price model of work with waterfall project management no longer applies. Instead, they should consider time and materials with performance incentives and risk sharing.
In my professional experience, I’ve been on both sides of the fence. I’ve worked for IT outsourcing service suppliers that built software development teams for some of the leading companies in the world. I’ve also worked for Fortune 500 companies and built agile teams using agile teams that consisted of in-house and outsourced talent.
In this post, I’m going to share everything I’ve learned. And give you my two cents for how to successfully apply agile to IT outsourcing; no matter if you’re working at the scale of a single team or tens of agile teams delivering on multiple programs and projects.
How to Apply Agile to IT Outsourcing
Choose the right model of work with your service supplier. The traditional model of work in IT outsourcing—where you throw a set of requirements at your supplier and get a fixed-price proposal and waterfall project plan in return—won’t work in an agile relationship.
Agile is about building self-organized teams that consist of capable individuals who are given the resources and support they need to solve problems or build products in an iterative and incremental way. These individuals and teams work in short cycles, shipping increments at each cycle, seeking out feedback early, and continuously improving their ways of working.
This requires companies and their service suppliers to rethink their master contracts, purchase orders, and buyer/supplier relationships as a whole. The focus is now on sourcing the right talent for programs, projects, and teams, fostering a culture of accountability and responsibility, and providing support through timely and adequate removal of organizational impediments.
Many companies who want to adopt agile and keep outsourcing find that time & materials is the best pricing model to start with, as it gives a good balance between flexibility of scope and predictability of cost. Over time, some companies and their service suppliers evolve the time & materials model of work by adding performance incentives and risk sharing clauses.
The specifics of the incentives depend on the scale of the relationship. Fast-growing startups or international corporations looking to quickly scale their agile teams up or down with the right talent will look at success criteria and performance metrics for the buyer/supplier relationships with their IT outsourcing partners differently than smaller ones aimed at achieving a sustainable pace.
Choose one agile framework and lay out an implementation plan. Which agile framework to use is one of the most critical choices that you and your service suppliers need to make. The framework needs to be connected to the way of working in both organizations and, depending on that, be prescriptive or non-prescriptive enough to allow agile teams to self-organize and work toward a common vision, mission, and set of goals.
Not every agile framework is made equal. Some agile frameworks, like Scrum, are intentionally lightweight and give the individuals and teams using them room for interpretation. Its scaled counterpart, Scrum at Scale (Scrum@Scale), attempts to make agility and use of Scrum repeatable by taking the components of Scrum and scaling them to the highest level of the organization.
Other frameworks, like the Scaled Agile Framework (SAFe), are much more prescriptive and how things should be done across all levels — and give different sets of roles, events, and artifacts to different stakeholders in the organization. Whereas Scrum and Scrum@Scale are better-suited for companies that need to act quickly and course-correct fast, SAFe is more suitable for companies that want to work in an agile way, but deliver in a more controlled/gated way and plan/work in longer time horizons.
Once you’ve chosen an agile framework, creating an actionable implementation plan that you and your service supplier co-participate in is going to be critical for the long-term success of your IT outsourcing relationship. You will probably need to do change management in your organization to bring in the notion of agile teams and agile leadership, making sure that stakeholders and team members are aware, understanding of, and trained in agile.
Your service supplier, on the other hand, will need to train the rest of the agile team members that they will be supplying in agile and the agile framework of choice. At this stage, it’s critical that everyone from both organizations comes in with the same level of knowledge about agile and the selected agile framework. Neglecting this will cause cultural problems and delivery weaknesses later on.
SAFe gives a good example of an implementation plan that companies who are about to adopt the scaled agile framework can adopt and adapt to their needs:
The implementation plan starts by training lean-agile change agents in the organization, who will drive the adoption of agile and the SAFe framework across departments. It continues by training executives, managers, and leaders in agile leadership and the change required in their mindset and ways of working to be true sponsors and supporters of their future agile teams.
Then, SAFe recommends a step-by-step training and implementation plan that’s relevant to its framework and the roles, events, and artifacts that it prescribes. No matter what agile framework you’ve chosen to use and scale for your company’s agile transformation, having a similar plan or roadmap is an absolute must, as it helps you determine the sequence of events to roll out agile with.
Clarify which party supplies the agile teams with which roles. The purpose of any agile transformation is to create a network of agile teams that self-organize and deliver, in an iterative and incremental way, toward a common vision, mission, and goals.
When the individuals that belong to these teams are hired by more than one organization, it’s key that each organization is clear on the roles that they need to supply talent for—and the mindset, behavior, accountabilities, and responsibilities that this requires from them and their employees.
Though there’s no rule of thumb approach, here’s how this typically pans out:
For each agile team, the Product Owner and the key members who need to bring in core competencies and organizational/customer knowledge should come from your organization. In an IT and software development context, these key members are usually Software Architects and Senior Developers, who work as part of agile teams and provide guidance and support to the rest of the team members who come from the service supplier.
The service supplier usually provides team members of varying degrees of seniority for the agile teams. This includes Junior, Mid-level, and Senior Software Engineers, Quality Assurance Engineers, UX/UI Designers, Business Analysts, and/or any other competencies required to build a self-sufficient and self-organized agile team.
One role that’s often neglected is the Scrum Master. I’m going to make the unpopular statement here and tell you that all Scrum Masters for your agile teams should come from your organization — and not from your service suppliers. Agile Coaches and Scrum Masters are the champions of agile across the organization as a whole and within individual agile teams.
Too often, Scrum Masters at service suppliers are project management professionals more experienced in waterfall project management than with change management with Scrum. I’ve seen this backfire in a number of ways where the Scrum Masters start to speak instead of team members at Plannings and Retrospectives, acting as a gatekeeper and intermediary where they should be acting as a coach and facilitator.
Depending on the agile framework that you and your service supplier have chosen, the names and responsibilities of these roles may vary. But the overall approach remains: the people making the decisions, leading the change, and setting the context should come from your organization. The professionals who know how to make things happen and get things done should come from the IT outsourcing service suppliers.
Look for geographic proximity and cultural fit. No matter if you’re using an agile or a waterfall approach to manage your projects, the best-performing project teams are almost always colocated.
If your service supplier can source talent for your agile teams that sits in the same rooms and works from the same office as your employees, that should always be your preferred option. Else, consider nearshoring (contracting a team that sits as geographically close to your office location as possible, preferably a couple of hours away by plane) as a secondary option and offshoring (such as service suppliers in Latin America or Asia-Pacific) as your last.
Build diverse teams and encourage inclusion, but don’t underestimate the importance of cultural fit. Different cultures have different attitudes toward work and behaviors in the office that may be productive or counterproductive to the way of work in your organization. Keep the national culture in mind as a selection factor when considering multiple geographic locations.
Understand the role of management in agile. How your and your service supplier’s management teams think and act can make or break an agile IT outsourcing relationship. This is why many consulting firms and enterprise agile coaches recommend that transformations start by training the management teams in agile leadership.
In agile, the role of the management team changes from a top-down, command-control body to a servant-leader community that sets the goals (“What do we want to achieve?”) makes capital allocation decisions (“What projects and teams do we have the appetite to sponsor to achieve that?”). The more important and often neglected role of a management team in agile is to remove organizational impediments for the team—and do it quickly.
Different agile frameworks solve this problem in different ways. Scrum at Scale (Scrum@Scale), for example, takes the roles, events, and artefacts in the Scrum framework and scales them as-is across the enterprise in a model very similar to fractals in mathematics. The same formula gets repeated at all levels of the organization, from the most junior individual working in an agile team to the executive leadership team.
The Scaled Agile Framework (SAFe) solves this problem in a different way by creating a diverse set of roles, events, and artefacts for stakeholders across the chain. On the highest level, Epic Owners and Enterprise Architects coordinate a portfolio of Value Streams. On the mid-level, Solution Management and Solution Architects drive Capabilities and Enablers in a Solution Train. And agile teams deliver, using Scrum or Extreme Programming (XP), in a synchronized cadence called Program Increment (PI).
No matter which agile framework your company has decided to use and how you approach your buyer/supplier relationships with your IT outsourcing service suppliers, remember that management in both your organizations will make or break your adoption of agile.
The management teams of both sides should therefore become quick to make decisions and remove organizational impediments for the agile teams, with the end goal of achieving a sustainable pace (rhythm) of delivery in an iterative and incremental way.
Why Agile Is Better Than Waterfall in Outsourced Projects
When speaking about agile, I often get asked, “Why is agile a better approach than waterfall?” My favorite story to explain why comes from Jeff Sutherland and Ken Schwaber, creators of the Scrum framework and co-signers of the Manifesto for Agile Software Development.
In the early days of Scrum, Ken Schwaber collaborated with process control scientists at DuPont, one of the leading chemical companies in the world, to understand what made the framework work so well.
In the 20th century, DuPont experienced a number of disasters in its plants worldwide. After the Bhopal disaster, a gas leak that exposed 500,000 residents of a city in India to methyl isocyanate gas, DuPont hired the world’s best scientists to prevent problems of this magnitude from happening again.
The reason why Scrum worked so well, Schwaber found out, was in one of the first principles of industrial process control theory. According to industrial process control theory, there were generally two types of processes: predictive processes and empirical processes.
- Predictive processes were complicated, but could be run as an assembly line. Every step of the process had a highly predictable outcome with little deviation. Predictive processes could be run with a predictive control system where every step, its inputs, and its outputs, could be planned in a linear and sequential way.
- Empirical processes were complex and their outcomes were difficult to predict. These processes, like mixing chemicals in a vat and exposing them to high temperatures to trigger chemical reactions, required close monitoring and continuous adjustment. Empiric processes had less predictable outcomes with high deviation. They required a different, empirical control system.
“In every case of an exploding chemical plant,” Jeff Sutherland recalls his and Schwaber’s learnings, the process control scientists had found “that somebody had applied a predictive control system to an empirical process.”
From the lens of industrial process control theory, software development was an empirical process. Research has shown that as many as 65% to 70% of a software development project’s original requirements would change throughout the course of the project. Yet waterfall, the most widely used project management approach at the time, was a predictive process.
The Bottom Line
Yes, agile can apply to IT outsourcing. However, this requires you to revisit the way you approach the buyer/supplier relationship with your technology partners.
The focus is on sourcing and developing talent and fostering an agile culture where empowered individuals work in self-organized teams toward a common vision, mission, and goals.
This can be difficult to achieve when one organization is buying services and the other is providing it. However, many companies across sectors have found success in making that happen.
