Visualisation of “Very very important tasks”

“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.

 

 

 

 

 

 

Doing Scrum – Leading the way – Learning agile

“I have heard Scrum is ‘the thing’, please google it and implement accordingly!”. This was the exact words from a previous boss of mine, when he wanted me to make our team deliver on time and with the desired quality. This was the beginning of my career in “doing Scrum”.

I have learned quite a few lessons since. In this blogpost I will deal with a few of the hardest challenges I have faced. You will most likely not learn from my mistakes, but being aware of them, may help you overcome them faster when you face them. Continue reading “Doing Scrum – Leading the way – Learning agile”

Let’s call off Scrum!

A software development team, had been “doing Scrum” for years, since it was decided that Scrum was the “way to go”. A classic. All meetings were conducted, but gave no or little value. It was just accepted like “that’s what happens when Scrum meets reality”. Failed sprints were the standard, frustrations were building and unfortunate leadership mecanisms were “needed” to get things done.

When I was appointed as the ScrumMaster, I quickly realised that I had to do something drastically to gain the team’s trust to Scrum, and to build the team’s trust in me, as a ScrumMaster. Especially because I do not have a developer background. I had to relaunch Scrum in a way I had never tried before…

So I said: “Let’s call off Scrum!”

Continue reading “Let’s call off Scrum!”