Why IT user support can’t ignore the call of Agile, Kanban, Scrum, Sprint, and DevOps

Although Agile and its sister concepts major around development, and support is a production service, service strategists should still consider preparing IT Support for Agile Development.

In recent times, IT management thinking has found itself in the middle of its greatest revolution since 2002, back when ITIL first got credible. This is big – really big – indeed big enough, if it ever hits maturity, to replace both ITIL and Prince2.

Although the ideas of ‘Agile’ development, Kanban-based production control, Scrum-Sprint project output and DevOps techniques for getting systems to the users, have all been around for a while – indeed some, for decades outside of IT – it is only in the past couple of years that these have gained real traction in our industry.

Broadly speaking, these ideas are being driven by IT development. But I’m currently working with a number of clients who are going through this, and having seen it on the ground and designed responses to it, I have no doubt that it impacts everybody; development, operations, network support; even – perhaps indeed especially – the service desk. We need to be thinking about preparing IT Support for Agile Development.

The concepts

‘Agile’ software development is a set of practices to make IT development quicker and more focused and consistent. It differs from traditional methods in that it has does not intend to develop a complete product before handing it over – rather, it is a set of iterations of releasable, usable, code segments.

These iterations are produced using a technique known as ‘Scrum’ (a guide to ‘Scrum’ is available here). The product owner, development team and a ‘scrum master’ regularly huddle together to decide, from a known backlog of requested developments, which of these are currently the highest priority. A production goal is agreed. Then over a period of typically two to four weeks, the decided priorities are committed to code; this is known as a ‘Sprint’. Feedback loops, in the form of reviews or the more formal group ‘Retrospective’ (or ‘Retro’), keep the Sprint on track.

In Agile development, the ‘backlog’ does not necessarily have the same negative connotations it does in user support. It is simply the name for the repository of work requested by users or product owners, but not yet scheduled into a Sprint.


One way of tracking the movement of work, through the Sprints to release, is on a Kanban board. If you’ve wandered by the developers recently and seen a whiteboard divided into columns and plastered with post-it notes, chances are your developers are using a version of Kanban. Each of those post-it notes names a unit of work, on its way from left to right, from ‘To do’ to ‘Done’. They are tracking changes from backlog to release, via cancellation if appropriate.

Essential here is the limitation of ‘work-in-progress’ (WIP) because that’s where delays are caused as WIP hangs around a ‘constraint’ or bottleneck, awaiting its turn for the attentions of an overworked resource. WIP overloads have been shown (by Dr Eli Goldratt, author of ‘The Goal’, and by others) to have a disproportionately damaging effect on production control. Kanban is a technique taken from Just–In-Time manufacturing, most notably at Toyota, and prior to that from the observation of how supermarkets control stock levels – never too much, never too little, control the flow. It is more about logistics than inventory, and specifically the capacity of channels rather than the workload passing through them.


As part of this philosophy of minimizing WIP, a lot of companies are reorganising IT into a DevOps way of working. The traditional handover of ready product from development to IT operations, in order to get the product into production and get the users making money with it, is often a bottleneck. It can also be a source of dispute or even rancour. Developers keen to relieve themselves of user pressure will want a rapid release, and may be oblivious to operational considerations such as capacity, security and ensuring support staff are trained. Meanwhile, ops are seen in development circles as bureaucratic, slow and limiting. The DevOps idea is to make a separate, joint department consisting both of developers with network awareness and operations technicians who have been involved in the development from its outset. They are jointly responsible for the release. A happy by-product of DevOps is that it can also help with product quality – because that group builds not just the final release environment, but the testing one too, actually as part of the development – so hopefully, no more developers’ claims like “It worked fine on my laptop” and subsequent post-release mop-ups.

What it all means for IT support

It is not safe to assume that Kanban-based Scrum-Sprints could be used as a routine way of managing the IT support backlog. This is because the two work queues have very different natures. The development backlog is a list of systems that do not yet exist, and are waiting to be assigned to coders who will invent them.

The support backlog, conversely, is a list of requests that may include what ITIL, rather ridiculously and unhelpfully, calls ‘incidents’. We should call incidents’ what they really mean – ‘user impeded’ – and these should never go into a backlog. If your support process has a backlog of users who cannot work because they are waiting for IT support, then it has already failed the company, worsened a financial loss and failed to ensure that sufficient resources have been committed to the most important IT job there is – keeping the users working.

It is legitimate and even recommended, however, to use Kanban-tracked Sprints for working through local projects, installations and other non-reactive work. If we did that in support, we’d also get the kudos of using the same methods as the development department. Wow – the CIO might even take us more seriously…

Defining ‘Done’

A key concept in ‘Agile’ is that of ‘done’. The method calls for a universal definition of ‘done’ and a standard way of working. So this may be our chance. All the development teams have to work the same way. So, get yourself a clear idea of what support needs when a product is launched, such as training, escalation routes and so on, and get that list to the Scrum Master, product owner and anybody else you can think of. Get them to realise that no product is ‘done’ – i.e. in production – until you are ready to keep the users from being impeded by it.

Another key concept is this ‘Work In Progress’. It must be minimised. You cannot have your queue clogged up with requests for a new mouse, messages for a missing technician, enquiries about “what’s happening with my enquiry” and escalations waiting for second line to deign to look at them. All of that is WIP, and all WIP distracts resources and delays everything else. If your development goes Agile, then so should user support. Chastisement should befall he who causes WIP, for in an Agile environment, superfluous WIP is a major No-No.

What it means for the service desk

The implications of this new thinking for the service desk give me special concern. Agile computing is all about controlling workflow, to operate in an environment of continuous development. Kanban, Scrum, Sprint, and DevOps have the same idea at heart. It all comes from the idea of keeping resources optimally occupied, while not overloading potential constraints, so to avoid backlogs.

Unfortunately, the fundamental design of the service desk, and the very thinking that brought it into existence, stand in complete opposition to those ideas. The service desk takes a wide range of enquiries, some technical, some clerical, some about computer usage, some about procurement. To do that, it must either have a mix of skills – or have non-technical enquiries taken by technicians. This loads up resources with work unsuited to their skillsets and commonly produces the “depends on who you get” effect, where the quality of the service cannot be guaranteed.

In an Agile environment, this makes parts or all of the service desk into a potential ‘constraint’ or bottleneck, and means it doesn’t fit the new methods. In other words, the case becomes stronger still for routing enquiries differently, technical going straight to diagnosticians, clerical to clerical, and ideally, for non-technical enquiries such as equipment and change requests, an intranet form.

The service desk in its original conceptualisation has been procedurally obsolete for a while. For example, the need for the one-stop shop has been surpassed by the arrival of online user support portals. Nevertheless the IT service management movement seems unable, or perhaps even unqualified to address that truth. Well, now Agile development holds that obsolescence up to our noses. We have to deal with it, or be guilty of holding the rest of IT back.