Team Collaboration Patterns Part 3: The Service Provider

The concept of placing people into market facing teams is at the core of Agile Organizational Design. But we won't always be able to get everyone working on the same initiative onto the same team. Sometimes the political, and even economic reality is that we will need to deal with cross team hand offs.

If we want to support agility in many of today's organizations we need to accept that not everyone will want to be (or can be) part of a market facing agile team, even on a temporary basis. We need to complement the idea of full time team members with other ways people can engage with teams than just the full time, dedicated model.

I use Team Collaboration Patterns as a means to represent these different ways people can can engage and interact with teams. These patterns provide us with options, and I have seen them enrich conversations focused on agreeing on how people can interact with each other within and across teams.

Today. I'll provide an overview of the Service Provider pattern.

Like this article? Download my book on Agile Organizational Design.

Summary

You service the need of other people in your organization by fulfilling an order request, largely in isolation from the person making the request. The service provider works closely with other service providers of the same type, and does not work closely with the team requesting their services.

Problem

You need to fulfill requests from many different teams. Individual work requests tend to be smaller in duration / effort. Reducing the cost of the services you provide is paramount, in other words you are looked at as a cost center. Your work is considered to be highly repeatable and does not vary greatly from request to request. Economies of scale can be applied to share demand, reduce cost, and increase efficiency.

Solution

Perform your work as a Service Provider, as a part of a Service Center. A Service Center is a group of other similarly skilled service providers formed to service requests for a similar set of services. As a Service Provider you handle requests for your work using a service request and respond, order ticketing mechanism. A work ticket is placed on a queue by a requesting team, a service provider working in the service center picks the ticket up off the queue, performs the work required to service the ticket, and then moves on to the next ticket.

In this model work can be thought of as travelling to the team, rather than the team travelling to the work. You may provide periodic consults to your clients, but the vast amount of your work is completed while working independently of them. You spend the majority of your time working within the service center, delivering the output to the requesting person / team once the work is complete.

Discussion

Of all the collaboration patterns presented so far, this one is the one that will lead to the least amount of organizational agility! Consider other team collaboration patterns if you want to maximize shared learning, to increase ability respond to shifting demand or if you want to accelerate the ability to respond to customer feedback.

Service providers reduce agility because every time you are relying on them you are creating a hand off! Hand -offs erode self-organization. They cause loss of context, they cause information loss, they cause lead times to go up, and they require coordination, typically management coordination across the teams.

Most service providers will not have your context. They won,t understand why they are doing something for you, and will not be able to effectively trace why they are doing something for you to the customer or market outcome that is being achieved. This lack of context causes poor results, results that often that miss the intention of the person who needs the work completed. The result is re-work and reduced efficiency, the very reason we want use a Service Provider in the first place.

Most back office functions are organized by placing Service Providers into service centers. They should not be. The majority of functions provided by HR, Legal, Compliance, security, IT, etc would be an order of magnitude more effective if they collaborated as Travelers ot Enablers. If you have the buy in and political will, help Service Providers to make this transition.

That being said you will find some situations where the Service Provider is the best way to provide a service or capability to an upstream team. Activities that require a lot of manual labor and manual processing may need the economies of scale offered by this model. As software becomes more pervasive, and we continue to automate our work-flow, the need for Service Provider diminish. Activities that are truly repetitive, become ripe for this model, as we can standardize the tasks, and focus and reducing over head and lowering cost. Producing products in commoditized markets, where the value of feedback is low, is one such example.

Again, in a world typified by uncertain markets, the amount of people being positioned as Service Providers should go down, and the Service Provider starts to becomes an anti pattern. One of the biggest values of the Service Provider pattern is that it allows us to describe the opposite of what agile looks like. Anyone responsible for defining a more agile organizing structure needs to describe describe the option we come to when we are not able to successfully negotiate a more agile solution. Not everyone will want to give up their organizational control. Not everyone will want to be part of an agile team. Using the Service Provider in these cases allows us to represent the organization as it can be right now, as opposed to representing some idealized future that may never come to pass.

Service Providers can start to increase their agility by adopting practices such as backlogs and visual managements system to introduce transparency and better customer engagement. The Kanban Method is an excellent way to introduce feedback and continuous improvement to Service Centers, and encourage Service Providers to consider different collaboration patterns as a means to providing value.

Options

Service Provider From the View of the Outside

A team may seem like a service provider from the perspective of the customer of the team, it provides a common service using a request response approach from the perspective of the requester. That team could also appear to be comprised of Dedicated Team Memberswithin a classic agile team when looked at from the perspective of the people doing the work. It is an unfortunate truth that most agile teams housed inside of the IT departments of large enterprise fall into the category. Very few, or even no one, on the team has direct market contact, work comes to them from various outside stakeholder who (hopefully) provides frequent advice to the team. The user and the customer are far from the team, and while the team may exhibit great internal agility, they are not situated to exhibit great market agility. This team can be said to be a Service Provider From the View of the Outside.

Intent Owner Traveler

One way agile teams mitigate the impact of being engaged like a service provider is try and get stakeholder / sponsors / users to come and spend time with the team to share context, provide feedback, and otherwise bring market connectivity with them. This is a reverse kind of travelling, the person that needs skills / capabilities in order to deliver value travels to the team that can provide those capabilities. This Intent Owner Traveler collaborates closely with the Service Provider Team, in effect this allows the team to operate much closer to principles of an Edge team. As more an more intent owners travel to the team, and start to spend more time with the team, the team starts to look more an more like a true edge team made up of cross functional Dedicated Team Members.

Dependent Edge Teams

When two teams agree to work on a complex piece of work that is shared across teams, and neither decides to pick up and move to work with the other team, than both team are acting like Service Providers to each other. They are now Dependent Edge Teams. Sometimes this can’t be helped, but in most cases we are dealing with social inertia and a mindset that once someone is in a team, than they should stay in that teams. Ownership, safety, familiarity, politics all come into play. Once we dictate where the work happens than that is where the work always happens, regardless of the rework or confusion it creates. Remember, hand-offs kill agility, don’t be that guy who refuses to travel or refuses to allow people to travel, and thus creates a hand-off.

Like this article? Download my book on Agile Organizational Design.