Managing your input queue will seriously increase the chances of agile success

The smoking ruins of failed agile seem to be wherever I look these days, with people bemoaning how it doesn’t work and has if anything made things worse. There can be a multitude of reasons for agile to fail (frankly it’s not just agile that fails but the hype sometimes does agile a disservice), however a common reason is the lack of proper prioritisation of work, particularly when teams service more than one product or project.

At this point some people will be smugly looking at their neat prioritised backlogs and feeling distinctly superior. However a neat backlog alone is not the solution to the problem. For instance is your backlog iterative? Do you have stories that build on earlier stories? Have you just got a list of things to do where the business value is delivered after a whole batch of user stories are delivered? Is your backlog prioritised infrequently or only once? And finally, is your backlog a mess of chaotic user stories in some random order that you dump on the team from time to time in order for them to try to pick their way through. (Isn’t that what self organising means?)

If you recognise any of the questions above it’s normally because the queue of work to be done is badly managed. In Scrum that might be that the product backlog is too granular and disorganised. In Kanban it might be that managers are just slapping stories into the input queue with little regard for what needs to be done next – then re-ordering minute by minute for no clear reason (Isn’t that why you ditched scrum and did Kanban instead?)

By helping to prioritise the backlog or the queue of work, instead of a great morass of work being thrown at the team for them to work out the priorities, the team is empowered to pull the next item in the list without having to pick through a messy backlog.

This is often where managers can begin to resist agile practice, normally with excuses about not being able to prioritise because everything needs to be done. Really what they are saying is “I don’t want to be responsible for prioritising”. In that way they push the decision-making to the team without the required empowerment and therefore the blame of things go wrong. Or worse they try to take further control away from the team and tell them which user stories must be done in minute detail, accounting for every minute of a developer’s time.

However there is a way to wrest back control. Have a firm queue limit (in scrum your sprint backlog, in Kanban a WIP limit on the input queue) with a defined policy for how work can get into the backlog and be removed from the backlog. The manager or more commonly the managers then must talk to each other to ensure that the highest value work is being done in relation to other projects and other parts of the business. Also it may encourage more communication within the team during prioritisation. Scrum prescribes this sort of behaviour, Kanban allows this behaviour to emerge.

This simple area is often where agile begins to fall apart as it is commonly grown from within a development team. The team is then often unable to do anything about the input queues of their own work. This usually means agile adoption ends in work being done to the “whoever shouts loudest” model of management. This bakes in existing bad behaviour, or worse allows it to emerge!

The key is to ensure the person(s) who own the queue take responsibility for it. In Scrum that’s the team, including the product owner (most scrum implementations I’ve seen seem to neglect this vital role). In Kanban that’s limiting WIP with clear policies for how the queue is stocked and how work is pulled from the queue.

The reason this is so vital to agile success is that it acknowledges that agile practice does not exist in a development vacuum. It is part of the wider aims of the organisation and it requires us to look at the entire value stream and manage the flow of value/work in relation to the overall organisational objectives and priorities.