Taming the Tornado of Agility in Infrastructure
I worked with an Infrastructure group recently that was desperate to apply Agile methods within their Shared Services areas in IT and, when the inevitable debate of KTLO (Keeping The Lights On) work versus Project Work came around, they referred to it as “The Tornado”.
The Tornado was defined as the “whirlwind of requests for infrastructure support that come in from many different directions, by the minute or even second, which they have to simply comb through and prioritize 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 priorities get tossed out the window.
One can never commit to a body of work and allow that work to remain static over a 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 services we support on a daily basis that include many, many products.
There is no single voice of priority as we have many varying stakeholders.
All of these items are true. So, the appearance is Agile methods simply won't work here. But consider, 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?
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 Infrastructure look like then?
Start with the often misunderstood concept that Agile is a group of frameworks designed to force us to change process (e.g. Agile = Scrum).
Agile is a set of principles designed to change how we think about delivering value. The frameworks are only 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 can easily work to apply:
Environment – Support – Trust
Just to name a few.
One of the more challenging areas for Infrastructure groups is to understand and manage their own capacity while creating visibility to their workflow. Here are a couple of techniques I’ve witnessed as successful in these environments:
Challenge: Iterations - I’m not saying Scrum can never work in Infrastructure, I’m just saying it takes some tweaking and horseplay. When your job requires 80% day-to-day support and 20% static project work, it's hard to commit to a two-week sprint.
Solution: Kanban – Visualization of work and Lean Manufacturing techniques. I’ve witnessed too many teams get wrapped around the axle on dedicated sprints and then say “Agile won't work in our group.” Set a team agreed-upon size threshold for support items to visualize in a Kanban board in addition to project work (Ex: 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 – One guy who knows how to set up virtual servers. He goes on vacation and that goes on standstill until he gets back. That’s a huge problem for agility.
Solution: Cross-training – Start peering up on work and mentoring immediately. We want T-Shaped people who have a depth of knowledge in one area but can also be dangerous in other areas as needed. Mentors and leaders don’t get released because they are expendable; they get promoted.
Challenge: Priorities – We get priorities from service levels, project teams, leadership, HiPPOs (highest paid person with an opinion), and squeaky wheels. So, at the end of the day, we determine priority as the team.
Solution: SVoT (Single Voice of Truth) – One thing Scrum has going for it is the dedication to a single voice of truth for the team. This doesn’t change because we are doing Kanban. 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.
Challenge: Knowledge Groups – 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 services having to be addressed by all these groups who have to become collaborative across many areas.
Solution: Service Support Teams – Cross-functional teams are being created in favor of the knowledge groups in order to provide both project work and support to specific 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 service area.
These are just a few suggestions. You can include many more 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 be able to be perfectly “Scrummy” in how we operate in Infrastructure, we can 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.
You can actually tame the tornado.