Flow of work and, most importantly, value is paramount. There are times when you keep looking at the process and don’t understand what is going on, what is wrong, and why stuff is not getting to done. All the answers to questions asked sound like a bunch of excuses (they most likely are not, but a bit later on this). The delivery, for which a burndown chart is an OK proxy, looks like a knife fall of a broken guillotine – the head was severed half the way leaving the victim suffering in the terrible agony.
One of the potential ways of breaking that impasse is to radically limit the work in progress, bringing about the unwavering focus, and inflict a lot of pain on the team members who all of a sudden find themselves in need of changing the ways they used to work immediately. It is radical, it is unpleasant, and it is rather painful.
A little bit of self-organization. I would argue that very few teams without solid understanding of product development flow principles will agree to, lest introduce these practices. A skillful agile coach will probably spend some time introducing the practice and digging through a pile of objections that will likely start with “But we can’t”. The art of coaching is to figure out how to turn those “can’ts” to “we can try” at least. There might be a long list of factors in play. Unreasonable deadlines, technical capabilities, lack of focus on what’s important, you name it. The goal is to show that none of those are the insurmountable barriers and impediments that cannot be overcome. In many cases they are easy to tackle if one stops, and thinks of the way of doing so, rather than throwing her hands up and saying “but we can’t”.
This process change is not designed to break the blockage and get work moving. It is designed to uncover a lot, if not all, of inefficiencies, unearth all the answers that felt like excuses and deal with them straight away, as they can’t be voiced and swept under the rug anymore.
It is the proverbial andon cord on the production line. As a deficiency is noticed, a cord is pulled and a siren goes bonkers. Everyone got a very limited amount of time to swarm on the problem and solve it before the whole of the conveyor is stopped.
In this specific case the deficiencies are abundant. I am a backend developer and this is a front-end PBI. We don’t have a pipeline set up properly. The pipeline takes long time to run. We don’t have anyone available to review the commit and merge. The QA is busy. The Product Owner is not available. It’s a BUG!
These are the deficiencies in the process that pop up all over the place. The difference is that a WIP limit of 1 per a team member doesn’t allow them to move on. At first people are disoriented. They are frustrated and sometimes scared. What am I supposed to do? If I can’t do development, should I just sit around and wait?
Well, no. The concept of ownership is worth re-hashing. You are responsible for getting your work from to-do to done, and solving all the problems on the way with the help from your fellow team members. It is amazing how many problems are quite easy to solve when people have no other way, but putting some thoughts to actually solving them rather than saying, “can’t do it, let’s move on”. Just to re-iterate. The job is not to get a PBI to dev done. Or QA done. Or any other intermediary state of “done-ness”. The job is to get it to “Done” (capital D).
With all the eyes on the painful and uncomfortable process, Daily Scrum might serve as a checkpoint where the new behaviors are surfaced, the problems and impediments are discussed, and, as Daily Scrum goes, plans for the day are adjusted.
I find it useful to introduce the Kanban way of walking the board kind of process. The question I suggest the team focuses on, “if this item is still important for ours achieving the Sprint Goal, what can be done, to move it to the Done today?” Start from the rightmost column of your workflow, and work your way to the left. Focus on getting items in progress over the Done line, then move to those, that require more elbow grease to progress them on their way to done-ness.
I am not an advocate for such a draconian measure. We should understand that some of the inefficiencies will take long time to iron out. Some will take long time to get more comfortable with, like a front-end developer picking some PBI that deals with the backend or the database for example. But this is an extreme forcing mechanism that brings up all the questions, and does not let them linger in the air.
Bring them up and solve them right away. You’ll be glad you did.