“I have this very important task that needs to get done. Who will do it?”
This is a phrase often heard, and every ScrumMaster eventually will have to deal with. A mature agile team will have it’s work agreements and processes to deal with this type of request in an efficient manner. However, not so mature agile teams, and teams in a early state of their agile journey, should be very alert when hearing this sentence, as it maybe a symptom of an underlying and more serious problems.
But why should we be alert? It’s just <someone> who wants to get this task done, what is wrong with that?
There is nothing wrong with the desire to get things done. After all, this is what companies live from. But there are many underlying problems that this particular sentence can be a symptom of.
In a software development team of mine, we faced failed sprints. Every 2 weeks. Mostly due to this type of requests. Ever changing priorities was one reason for not meeting sprint goals. The solution to this, according to the “Scrumbook”, is obviously to lock scope of work for a sprint, and move the incoming requests to succeeding sprints. This just didn’t work for us. Developers felt this was the same as saying “No, your tasks is not important”, and product management did not like to hear that. It worked for nobody. We did not have a full time product owner, which was also a part of the problem. I have written about this subject in another blog post https://agilereflections.dk/2016/10/12/lack-of-product-owner-what-to-do/
All tasks are important, otherwise it won’t be a task in the first place. Therefore the argument “I have this very important task” is not an argument for getting the task first in line. Believe it or not, adding another “very” or even “very very very” doesn’t make the argument better. So let’s stop discussing if a task is important, let’s discuss how important is it compared to the other task we have, seen from a company perspective. This may sound simple, and result in what we know as a “prioritised backlog”, but it can prove to be difficult to understand for some – even people with agile training.
It was a big issue being part of a team who got “slammed in the face” every other week with “The sprint failed – Again”. So to keep our motivation up, we decided to kill “sprints”. With that decision our board turned into a plain kanban board, where the highest priority was on top. This gave instant advantages such as:
- As developers we could say, “We can do the task, it will be placed on our board”
- Product management no longer felt their tasks was not taken seriously.
- Priorities became very visible, and a constructive dialogue instantly began.
Even though the amount of task on the board exploded, it was a relief for the team, because, we were able to focus on the task on the top of the board, and we could be flexible. As product Management experienced that the tasks on the top of the board got done quicker that the others, they began discussing priorities from a company perspective rather than a personal perspective.
The visualisation of work was the first step towards managing the flow of work, rather than managing people to do the work.
Agile Reflections 