Simplemente no funcionará: Desmontando el mito de la agilidad en los servicios compartidos

“It just won’t work.”

As an Agile consultant, that’s what I hear on a pretty regular basis coming from Shared Services teams.

Sure, it’s great to see when our AppDev partners can iteratively provide value on a single product. We will even support those efforts from a back-end perspective. But our work is too fluid; too dynamic. We don’t have one single product. We support many products and many tools spread across the entire company.

We are a different animal.Agile just won’t work here. The list of reasons is long. In addition to the above, you could include: 

• We are traditionally perceived as an operational expense as opposed to a value-add organization.
• We are strategically set up in knowledge siloes.
• Our priorities can change by the minute so committing to a body of work that won’t change is nearly impossible.
• We have to work nights and weekends so a sustainable pace is simply not achievable.

When you are looking from the outside in, it can appear that what we are referring to as “Agile” is not a great way to construct a Shared Services environment. But it’s important to understand what Agile actually is.

Agile is a set of four values y 12 principles designed to change how we think about delivering value; regardless of how you define value.

Can you display “agility” in ‘Waterfall’ or traditional project management? Yep! It’s just that ‘Waterfall’ doesn’t support the Agile mindset in the same way other frameworks such as Scrum or Kanban do (and waterfall can encourage bad behaviors).

What if I was to tell you that Agile methods can, and have, been applied in Shared Services and Infrastructure groups with huge success? They’ve even been able to do it using some of the same methods seen in other areas of the company.

Let’s take a look at some of the most common areas of concern and the techniques used to gain Agility.

Emergent Work Requests

Challenge: Let’s get back to that ever-present tornado of requests that haunt Infrastructure and Shared Services teams. It’s simply the nature of the workflow. For these teams change happens by the day, the hour, sometimes by the minute.

When your job requires 80% support (or more) that changes by the minute and 20% static project activities, it can be difficult to zero in on a singular body of work or even have the ability to commit to a 2-week Scrum Sprint Backlog.

Solution: There are a couple of ways to tackle this problem within an Agile framework. Scrum, still being the most widely used framework, has what is referred to as the “Interrupt Buffer”. This little tool is designed to create transparency to all of the changes going on and create a space for what is eating up your time outside of committed work. This helps you measure it and plan for what we can “yesterday’s weather”. How can we use that information to make ourselves better; more predictable?

Some areas have found success in employing Kanban as a continuous flow, or lean manufacturing, style of operating. 

While this eliminates the need for iterations and having to potentially change the work and priorities mid-sprint, a team does well to remember it is still important to have a single voice of priority on the backlog, an owner and coach of our process, time to stop and inspect\adapt for continuous improvement and plan as a team. Those are just good ideas regardless of framework.

Measuring Shared Services Impact On An Organization

Challenge: Can you put a value on the creation of a new type of steering wheel on the overall value of a newly designed car? Unless you’re an actuary, probably not.

Yet that new steering wheel has added value in some way, shape, or form. What does this have to do with Shared Services or Infrastructure teams.

Everything.

As I stated before, these teams often don’t own their own product or service - they empower those that do. They augment other teams with their specialized expertise and skill-sets. Empowering others is a powerful thing. But this can make it difficult to show how these teams helped the organization as a whole (or subsets of the organization) reach their Product Goals.

Metrics matter. So how can you measure the value of a Shared Service or Infrastructure team?

Solution: When you’re measuring the impact of shared services, it’s important to have clear, shared goals to work from. OKR’s (Objectives Key Results) are just such a tool now being used by a growing number of organizations.

The purpose of Infrastructure and Shared Services teams is to move the needle in specific areas. 

To provide specialized services no one else can. However, if your organization has clear, shared goals then measuring impact is as simple as showing the team added value by helping achieve specific goals in specific ways. Your team may not be designing the whole new car, but your new steering wheel added value and was a key component of reaching that Product Goal.

Knowledge Silos

Challenge: We have the server team, networking team, data team, telecom team, security team, etc. The problem is that we are increasingly seeing one set of business services having needs from all these groups who need to be collaborative across many value areas. Additionally, when a support ticket comes in, it invariable bounces from one team to the other while everyone is pointing fingers as to where the problem lies.  This creates massive customer dissatisfaction.

Solution: Business Service Support Teams – The Small, cross-functional teams promoted in Scrum are being successfully created in favor of the knowledge silos to provide both project work and support to specific business services provided; not unlike a cross-functional team to support a single product in AppDev.

Members from each of the groups described, as needed, are placed on a single team, who work as a team and develop “T-Shaped-ness” in support of a Business Service Area. This means a ticket goes to one team with all the skills to resolve it; all but eliminating the support ticket carousel.

Remember, Agile methods were developed to help tackle the typically change-heavy areas of work. If Infrastructure and Operations are anything, they are change-heavy. Take a deeper look at the methods and frameworks Agile provides.

Portions of this post originally appeared in a blog for the Agile Alliance also written by Robert Woods.