Agile IT — Individuals and interactions over processes and tools

If you’ve been to any IT services conference recently you’ve probably seen at least one talk about “Agile IT”. Yeah I put that in inverted commas, don’t judge.

I find this concept interesting, especially for IT teams working in an agile business. I work at Skyscanner. A travel meta search website that started in the UK in 2003 . We currently have nine global offices and are growing fast. I love working at Skyscanner for all sorts of reasons, one of which is that everyone is striving to be the best at what they do, IT is no different.

Agile, by its very nature, is constantly helping to improve how Skyscanner develops software so I want to find out what IT can learn from those same principles and methodologies

As a starter, I’m going to look at each part of the agile manifesto and see what it could mean to IT teams, whether they are working as part of an agile business or not.

First up,

Individuals and interactions over processes and tools.

I think this is the easiest part of the manifesto to draw useful lessons from, and its something that a lot of people would come to realise without ever having to think about Agile. The most common way IT folks first engage with a colleague who needs something from them is through a service desk ticket. To raise that ticket the person has followed a process (“for the love of all that is holy please stop emailing me, follow the process and raise a ticket!”) and has used a tool (the service desk). …so not a great start.

Should we get rid of service desks and go back to answering phones and relying on walk-ups? I don’t think so, good service desks give you data, if you want to learn what the team is spending their time on, what services are causing you issues and where requests are coming from — you’re going to need that data.

Also people raising requests shouldn’t have to know what number to call, which person to speak to, who’s on green-flag and which desk to walk up to if they have a specific issue. Giving one route in makes everything easier.

I think the learnings from this part of the manifesto come after the ticket is raised. A lot of the time when the ticket comes in you need more information, and often if you think that you don’t — it can turn out that you probably did. The communication required to get that information is going to be a whole lot easier if you take it out of your service desk and have a conversation with the individual who raised the ticket.

It sounds simple and obvious, so why doesn’t it happen? Usually because of time, if you’re getting dozens of requests a day, you don’t want to have to go find the person who raised it and check up on the details when you can just do a quick comment on the ticket and get on to the next thing while you wait for them to reply.

That’s usually a false economy, having that conversation for 5 minutes can save you and them a lot of back and forth on the ticket and also save some context switching for both (which is why I think speed to response is also so important — but that’s for another post).

Give people what they need, not what they want.

One of the most common frustrations I’ve seen with folks working on IT service desks is that they feel people keep asking for insane things and/or they don’t give any detail about what they want. While a good portion of that could be fixed by the requester taking the time to give some detail, I think it’s often because they don’t know what they want themselves. They have a problem, so to the best of their knowledge and understanding — they’ve asked for a what they think might be a solution for that problem.

Having a conversation with the person has to include figuring out the problem that they are trying to fix, you can then use your knowledge of the systems you support to help solve that problem and hot damn if you guys haven’t just collaborated to make life easier for everyone.

It can all too easily feel like us and them between IT and the rest of a company, as well as between any other operations team and the rest of the business.

Really, there is absolutely no reason why that should be the case. All the people working for that company should be there for the exact same reason — to make sure their company wins at what it does. If that’s the case, then how can there be an us and them? If there is, it has to be down to some serious misunderstandings about what each team is there to do. Interacting with individuals, hearing what they’re trying to do and understanding the value that request could have for the business is the fastest way I’ve seen so far to make sure everyone is pulling in the same direction. It means the person who made the request understands what you need to consider and the decisions you have to make, while you get to fully appreciate why they made the request in the first place and what they were hoping to achieve by raising it.

IT can value tools and processes over individuals and interactions too easily, because their job relies on getting the tools and the processes right so stuff doesn’t blow up. The service desk doesn’t need to reflect that, it’s where IT can collaborate day in, day out with anyone else and really add value to how well that business gets stuff done. Putting interactions with individuals at the centre of how IT approaches issues and requests can only add value.

Next up, Working software over comprehensive documentation…