When an organization struggles to move forward too often simple prioritization is being used as a way to manage the chaos. It may have worked to some degree when the organization or the project was new but with growth came complexity and what was once a single project has become a program. Tasks constantly bobble up and down while momentum suffers causing frustration amongst stakeholders, damage to team morale, and a constant accrual of technical debt. All of these things continually feed back into the system making the whole thing worse.
Tasks that are constantly being (re)prioritized may or may not be closely related. Assigning priority typically comes down to fiat which likely does not take risks into sufficient consideration. Fiat becomes the only way to perceptibly move anything forward since there isn’t an adequate framework in place on which to hang any sort of true consensus. Decision making is seen as boldly taking risks. This ripples outward making actual risk mitigation extremely difficult if not impossible.
Now stack on the difficulty of making accurate development estimates when priorities are not stable. It doesn’t help that simple prioritization typically does not provide retrospective metrics or worse yet it provides metrics that are really personal notions of what was. It is difficult to figure out where to go when you’re not even sure where you’ve been.
Sticking to this scenario the gravest issue is that improvement is all but impossible.
From the perspective of management by simple priority the first logical step toward improvement is to use a shared system where the team can view the (changing) priorities. It’s shared so it’s better, right? Unfortunately the bobbling does not subside but instead becomes worse as more input comes in from more people across more teams. And yet still, metrics provided by the system are opaque due to the nature of decision making in such a system. Frustration grows because the tool was supposed to fix the problem.
Been there. Done that. So what can be done?
Can Agile help? An agile methodology such as Scrum can definitely help bring order. Scrum’s simpler concepts such as stand-up meetings are a great way to get team members communicating but other bits such as acting as a Scrum Master, managing backlog, and burn down charts can be intimidating and too disruptive for a group coming from simple prioritization. Is the situation hopeless? Absolutely not. We just have to take a lighter approach and Kanban just may be the ticket.
What is kanban? From the book Kanban and Scrum making the best of both this is it in a nutshell:
Visualize the workflow
- Split the work into pieces, write each item on a card and put on the wall.
- Use named columns to illustrate where each item is in the workflow
Limit Work In Progress (WIP)
- Assign explicit limits on how many items may be in progress at each workflow state.
Measure the lead time (average time to complete one item, sometimes called “cycle time”), optimize the process to make lead time as small and predictable as possible.
A visualized workflow makes it easier for everyone to get on the same proverbial page. The stakeholder(s) and the team(s) may come to realize that the situation is more or less complex than previously believed. It’s easy to think that those on the other side of the fence have it greener. Such feelings tend to be lessened when visibility is increased.
If a workflow turns out to be overly complicated visualization is an early step in identifying and fixing the problems. If less complicated, the notion that more work can be immediately heaped onto the dev team must be resisted. To do so would likely violate WIP limits and grind the system to a halt thus offsetting kanban’s low threshold of adoptability.
Work In Progress limits help prevent both task bobbling and the multitasking of developer productivity into oblivion. WIP limits are crucial for maintaining and improving positive development velocity.
Measuring lead time is necessary for setting improvement targets. If a team cannot confidently make an estimation of completion for a feature now they will know exactly how long it took once the feature moves to the end of the workflow. This approach helps teams get a handle on seemingly overwhelming projects. They don’t have to have all the answers up front to start making a difference. And this information does not need to be inferred by the developer from amongst all the other daily tasks. It’s built into the system.
A major benefit that may not be perfectly obvious lies deep within these 3 concepts; visualization, WIP limits, and measured lead time. The benefit is that kanban requires more desire to improve than technical expertise to get started. This aspect is crucial for an overwhelmed team/organization already struggling with the work that pays the bills. The beautiful part is that improvement starts no matter how or when you begin. Knowing this sure makes it a lot easier to take that first step on the journey of a thousand miles.