If you work in IT — the department responsible for ‘everything with a plug’ — you might feel a little suspicious if your manager asked you to embrace Agile working.
But just as real IT people don’t answer the helpline with barked instructions to reboot, neither is Agile a thinly veiled attempt to sweat the asset. Not where I live, anyway. On the contrary, your Scrum Master is here to help.
By Marie Andrew, Scrum Master at MPB
Let’s put this another way: You don’t have to spend long with the IT people in your organisation to see things from their perspective. Consider, at your average imaginary SME, the kinds of everyday requests:
- “The internet’s down — can you sort it out?”
- “How soon can we install 4K cams in all conference rooms?”
- “PowerPoint won’t let me […] ”
- “My computer doesn’t work.”
- “I can’t connect to […]”
- “How do I update a Wiki page?”
- “I want a new computer as this one is slow and doesn’t work.”
- “Sorry, my computer still doesn’t work.”
The operative is expected to prioritise these concurrent needs — and quite possibly close them all off, too. Is it any wonder they grow nervous at the thought of process meetings? It’s yet another distraction when they’d rather get on with work.
Ironically, that’s exactly the problem we’re out to solve.
Balancing the (cognitive) load
We’re growing our company, MPB, and the solutions we ask of our IT department are scaling up too. But it’s a small team, recently formed. How are they meant to focus on bigger pieces and all those everyday urgent requests? How should you prioritise tasks? And what happens if your colleagues are located in different countries?
All this task-switching is a recipe for — euphemism alert — heavy cognitive load. If IT is there to support, then who supports IT?
We decided that Agile methodology might just hold the answer.
Time out
In most IT departments, the traditional way of working goes like this: “Here’s some work. Go and do it.”
The concepts and terminology around Agile aren’t generally familiar, especially in IT. As far as I know, this is the first case in which Agile working has been used in the IT support context.
And, when you’re busy, the last thing you need is a bunch of extra meetings in your diary. But, to succeed, you need the team to buy in. So we scheduled a kick-off meeting to explain that their needs — not mine — would be the driver.
We began with a review of the way support tickets were raised and I came away with eight pages of densely-scribbled notes to process.
Breaking down the barriers
To make sense of the backlog, further talks brought us to a logical set of steps:
- Introduce IT to the basics of Agile
- Canvas the wider business to determine expectations of IT
- Define the functions of IT
- Create workflows for reactive (urgent) vs proactive (project) tickets
- Design a single unified ticket submission system
- Design a robust, transparent triage system
- Communicate all the above to the wider business.
Our rationale would still be to prioritise urgent items and drop everything else to fix them. The interesting part would be what happens between those jobs.
At regular refinement meetings, the big pieces of work are broken down into smaller tasks. Once these are defined and prioritised, they can be picked up and closed off — as time permits.
Because this admin has been done at the allotted time, there’s no confusion in the air. People already know what needs doing, in what order, and how long it will take. Cognitive load, schmognitive load; the decisions are already made.
Giving the good news
As we’re defining where IT can add the most value, some of the usual things may have to wait. That’s not an easy message to communicate, so we’ll need to manage some expectations.
But the real issue is about sustainable practice: doing the right things in the available time. Saying “yes” to everything isn’t the same thing as finishing everything.
To make that point, we’ll need a transparent way to prioritise work — precise enough to settle arguments, but not so detailed it makes ticket submission a chore. There may be difficult conversations ahead, but hopefully not too many. If we’re enabling our people to do their best work, there isn’t all that much to argue about.
Wheels in motion
Meeting time needs to be balanced against hands-on time. Otherwise, it’s just adding complication for the sake of Agile theatre.
For many people, scrum is the defining feature of Agile. For a small, busy IT department, it’s probably overkill. Refinement, on the other hand, happens twice a week and focuses on proactive work. It’s fair to say the team doesn’t exactly find these meetings fun — it’s still a new way of working — but people are coming to understand that the whole point is to make things easier.
We run fortnightly retrospectives to review what went well, what could improve and what other things we might do. We aren’t using them to define the new way of doing things, once and for all — it’s simply looking back, learning and adapting.
It’s still early days, the process will inevitably evolve and mature. And that’s exactly how it should be.
Challenges and learnings
I’ve been running Scrum teams for a long time. But I’m finding there’s plenty to learn in Agile IT. The thing I love is that the team really is up for it and they understand how it’s going to help. Seeing the start of that change is amazing.
We’re learning a lot about communication, too, about how IT is seen in the company, how people talk to them and how they communicate what they’re doing.
Our IT support is a dispersed team, with people in Brighton, Berlin and (soon) Brooklyn. That makes solving some of the challenges a little harder. How do people know what everyone else is working on? Who needs help and who has spare capacity?
Our Scrum teams in Product & Engineering are based in Brighton and hold group sessions twice a week in the same office. That isn’t possible for IT. But there’s a positive side: we’re working hard on some of the dynamics around distributed working and that can only benefit the wider organisation in the long term.
The point is that we’re working together on the solutions. I’m not coming in and telling people how to do things — they’re solving the problems themselves.
First wins
This is just the beginning of our journey. But we can already see positive results:
- Standups give us focus amongst the hectic day-to-day influx of tickets
- Refinement sessions, which make sure the tasks adhere to our Definition of Ready, clarify for everyone what needs to be done
- The task breakdown helps the team swarm that work as needed for more efficient delivery.
Retrospectives also help increase the team’s psychological safety and transparency, but that is a topic for another blog post!
See also
Marie Andrew is a Scrum Master at MPB, the world’s largest platform to buy, sell and trade used photography and videography kit. https://www.mpb.com
