The “ITSM Tornado” has been defined as the “whirlwind of requests for Platforms, IT Service Management, and infrastructure support that come in from many different directions, by the minute or even second, which requires combing through and prioritizing based on severity and who’s screaming the loudest.”
It’s the Tornado that leads many shared services folks to feel that Agile methods simply can’t apply in an Infrastructure or a Shared Services environment. The reasons include:
- Change happens too fast and previously agreed upon priorities get tossed out the window.
- One can never commit to a body of work and allow that work to remain static over any period.
- The teams aren’t cross-functional but instead based on knowledge silos for support services.
- We don’t have owners of a single product. We have many business services we support daily that include many, many products.
- There is no single voice of commonly understood and communicated priority as we have many varying stakeholders.
All these points are true. So, the appearance is that Agile methods simply won’t work here, that is until you consider that this is exactly the type of environment Agile was designed for.
Oh sure…you can argue “Agile” was born out of software development. Many would argue it was born out of Lean Manufacturing concepts. That being the case, isn’t Shared Services simply another form of Lean Manufacturing?
Agile in a Shared Service
Much of what infrastructure groups do can be considered assembly line work. The goal is to deliver value in as short of a timeframe as possible regardless of whether or not it is support or project level work. So, what does Agile in a Shared Service look like?
Start with the often-misunderstood concept that Agile is simply a group of frameworks designed to force us to change project management processes.
Agile is a set of principles designed to change how we think about delivering value. The frameworks are there to support the ongoing application of the mindset. Can you display “agility” in Waterfall? Yep! It’s just that Waterfall doesn’t support the mentality as well as other frameworks and potentially encourages bad behaviors.
Infrastructure groups have begun enjoying Agile principles such as:
- Face-to-face communication
- Continual improvement techniques
- Technical excellence
- Simplicity
- Customer focus
- Welcoming change
- Environment – support – trust
Just to name a few.
One of the more challenging areas for Infrastructure groups is to understand and manage their capacity while creating visibility to their workflow. Here are a couple of techniques I’ve witnessed as successful in these environments:
Challenge: Iterations
Challenge: Iterations – I’m not saying the use of iterations can never work in Infrastructure, I’m just saying it takes some tweaking. When your job requires 80% support that changes by the minute and 20% static project work, it can be difficult to zero in on a singular body of work that ideally never changes. It’s simply the nature of the workflow.
Solution: Continuous Flow – Visualization of work and Lean Manufacturing techniques. I’ve witnessed too many teams get wrapped around the axle on unchangeable iterations and then say, “Agile won’t work in our group.”
Set a team agreed-upon size threshold for support items we will choose to make transparent in addition to our project work (e.g. I saw one team determine anything they knew would take more than an hour was put on their board). Measure lead and cycle times, watch for bottlenecks, cumulative flow, and throughput.
Challenge: Capability Bottlenecks
Challenge: Capability Bottlenecks – One person knows how to set up virtual servers. He goes on vacation and VM delivery goes on standstill until they get back. That’s a huge problem for agility. In IT, we refer to that as a single point of failure.
Solution: Deliberate and Timely Cross-training – Start pairing up on work and mentoring immediately. We want T-Shaped people who have a depth of knowledge in one area but can also contribute in other areas as needed. Mentors and leaders aren’t expendable because they trained other people in what they know; they get promoted.
Challenge: Priorities
Challenge: Priorities – We get priorities from service levels, project teams, leadership, HiPPO’s (highest paid person with an opinion), and squeaky wheels. So, at the end of the day, we have no choice but to determine priority as the team.
Solution: SVoT (Single Voice of Truth) – Something Scrum has shown us as invaluable is the dedication to a single voice of truth for the team. This doesn’t change because we are potentially not Sprinting.
The team needs someone (staff manager, dedicated service lead, etc.) to be the person that helps communicate vision and priority to the group. In Scrum, they call it a Product Owner. In Shared Services they call it a Service Lead or Service Owner. The role continues its criticality for communicating priorities to the team.
Challenge: Knowledge Siloes
Challenge: Knowledge Siloes – 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.
Solution: Business Service Support Teams – Cross-functional teams are being successfully created in favor of the knowledge siloes 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.
Find Your Own Agility
These are just a handful of proven techniques that demonstrate the ability for real agility within the “Tornado.” You can include other techniques ranging from how we track and use our time spent to gain predictability and improvement to the ways we can utilize current ALM tools to our advantage.
The point is that while we may not look exactly like our AppDev partners in how they operate day-to-day, we can still display high degrees of agility by purposefully thinking through what being Agile truly means and adapting it to the needs of our shared services teams and our customers.
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.
Don’t shy away from finding your agility because someone else’s workflow doesn’t match your own. Find your own agility. Seek to continuously improve.
