Software development teams have to track many different types of work in many various statuses as they develop working software. One of the most common ways development teams track their work is using a kanban board. Kanban uses “swimlanes” to designate the status of work. The simplest version of a kanban board has three statuses: to-do, doing, and done. The complexities of the business world often necessitate more than three statuses.
Some additional statuses include (but are not limited to):
- Needs refinement
- To do
- In progress
- PR review
- Merged
- UAT
- Final business approval
- Done
Each of these stations can have flexible meanings between teams and projects. Generally speaking, though, they mean roughly the same things in most organizations. They’re also elastic enough that both Agile and Waterfall teams can use them. One status that is absent from this list is “blocked.”
No Blocked Column
You should never use a blocked swimlane in an agile software development project.
“But Justin, business environments are complex. Some work does become blocked! You need to operate in reality!” Stick with me here. I’m keeping it extremely real.
In my experience, design ideation is a very difficult process for traditional business organizations to understand. This is fascinating because, while it is not well understood, almost all businesses use design ideation, just by very different names and conceptions.
Design Ideation Overview
Design ideation has flavors and permutations in the software development world. To keep things simple I’ve made my own generalized version. The phases are:
- Empathy
- Definition
- Ideation
- Build and Test
Empathy helps us understand the human beings who are our users. Definition helps us understand, “the what” a person does for their job. Ideation is where ideas come together to converge and diverge so we can make an effective piece of software that serves the human beings operating in a business role. Build and Test is where new software is created and used by human beings to do their specific jobs and who then give feedback on that new software.
This process flows like a river from ideas to new products capable of generating a return on investment for the business. This flow creates a more efficient and hopefully enjoyable work experience for the employees. You will notice that I did not use the word “blocked” at any point in that description of the process. The reason is that, barring very rare circumstances, things do not become blocked. Let’s try an example.
When a Block Isn’t Really a Block
Assume the following is true:
- You’re working from an office in an area you know very well.
- You have from noon until 1 p.m. on your calendar set aside for you to go to lunch today.
- You have a 1 p.m. meeting that you must be present in the office for.
- You’re hungry and want to eat lunch.
- There are many restaurants within walking distance that you have eaten at and enjoyed in the past and that require no reservations.
- All the restaurants are currently open.
- It is presently 11:59 a.m.
- You cannot make up your mind about where you want to eat lunch.
In the above scenario, you are not “blocked” from eating lunch. You have yet to make a decision. The only thing stopping you from going to lunch is you. If you do not resolve your indecision, you might not have time to eat lunch by your 1 p.m. meeting. If you were to seek help with this problem, people would likely suggest places to eat or ask you your preferences to help you narrow your options. But, you alone would need to make that decision, dear reader. Let’s try another scenario.
You have a brilliant idea about social policy and determine that you need to speak to the president of the United States to get your policy implemented. You try all of the usual methods: snail mail, email, tweets, sliding into the DMs, telephony. Nothing is working. You proceed to 1600 Pennsylvania Ave. in Washington, D.C., and attempt to make entry. You will find your access blocked by the Secret Service. This is an appropriate use of the word blocked. An external force is preventing you from doing something, and nothing in your power can alter that situation.
Blocked Column vs. Indecision
Many businesses conflate the concepts of being blocked and indecision. Somewhere, some entity within the business has determined that something is important enough to be done. They have gone so far as to put features or user stories together that have managed to find their way to a dev team. Sometimes these stories even wind up on a team’s kanban board.
If a team cannot play the story within a sprint (a given amount of time, generally about two weeks in duration), the term many business stakeholders and teams reach for is “blocked.” Why do they reach for this term? Because they are attempting to signal to the business that the team cannot complete the work at present. Often this is because the work has not yet been defined, a.k.a. indecision.
“But Justin, the team cannot complete the work until someone makes a decision! Surely this is a blocker!”
No, it is a story still in the ideation phase and has been moved forward prematurely to the dev team. Somehow, a piece of potential business functionality has moved forward beyond the bounds of the chain of logic used to develop software. When this happens, what the person who moved the story forward prematurely means to say is something like, “Surely I can buy a plane ticket before I know where I want to go!” This is a great example of business logic being applied in the field.
Go to your favorite travel website and try to pay for a flight before selecting a departing airport and a destination. You can’t. Airlines would subject themselves to extreme liability if you could, say, book a plane ticket for $200 and then later choose to fly from LaGuardia to Tokyo Haneda Airport. Any airline could be bankrupted in a matter of days if such a policy were put into place, so they have business rules regarding the order of operations required to successfully book a seat on an aircraft. The converse of this situation is that you cannot angrily raise Delta Airlines’ customer service and tell them they are “blocking” you from taking a vacation because you haven’t made up your mind where you want to go.
An example of a blocker to development would be something like the production environment being down due to an AWS outage. The dev team cannot do work, no matter how hard they labor to resolve this situation. You are at Amazon’s mercy until they restore the service or until you switch to a new provider.
Decision-makers and Workflow
“We cannot play this story because legal has not signed off on all of the language yet. Ha ha, got you, Fitins! This situation is surely a blocker!” No. It is incomplete work lacking a decision. Nobody should bring such a task to the dev team in the first place because not all of the business requirements have been met yet.
If you mention that the dev team is not in control of the legal team, you would be correct. I would also ask you to survey the rest of the dev team’s kanban board and see how many other legal team tasks are in a software development team’s to-do column. The answer (hopefully) is none. This is because when you put work into the backlog of a team that cannot do it, it causes immediate business problems. Put the task, ”Unclog basement toilet by storage closet” on your company CEO’s to-do list and see how well that dog hunts.
The problem with a blocked column is that it takes the problem of leadership indecision and warehouse it in a development team’s workflow. The reason this is bad is that development teams are often evaluated on how much work they move through their workflow. A blocked column signifies that there is a near-constant amount of work being brought to the development team in an incomplete status. Storing it on a dev team’s board will eventually make this the dev team’s problem. The person who needs to make the decisions should have the task on their personal workflow.
“Wait for Jane to decide what to have for lunch” is not a task. Waiting is synonymous with doing nothing. Dev teams will not just wait around and do nothing. Instead, they will pick up other work to focus on — items that can be completed. This is a good thing. Where should a team track work they can’t complete within a sprint? Not on a dev team’s workflow.
What often happens is that people acknowledge that they do not have enough time to make a decision. This is to say making a decision isn’t a priority. If it were a priority, it would be completed. It is psychologically easier to say, “I do not have enough time to do this right now” than it is to say, “This is so low a priority for me that I do not know when I will get to it.” Both of these statements are functionally identical, particularly for those people waiting down the chain of command for an answer. Companies should leave the artifact of incomplete work in the workflow of the decision-maker, not the workflow of the subordinates who cannot complete the work themselves. When they do this, an organization can begin to see where the actual bottlenecks in decision-making occur.
As always, “If everything is priority one, then nothing is priority one.”