Granular Scrum: Three signs that your Scrum board sucks.

About Granular Scrum.

Scrum is simple, as you must already know, but each aspect of Scrum application could be dissected into small but essential pieces, without understanding of which you can’t progress in your Scrum journey. Therefore, I decided to inspect a bit deeper some specifics of Scrum routines in article series ‘Granular Scrum’. This is a first one.

What about the board?

So, my friend, you got your electronic Scrum board as everyone around you, but somehow just having it doesn’t help much. It usually happens when the board, which major target is to provide some greater visibility to project members and to stakeholders, hides your progress information instead.

Hiding the vital information is not good by itself, but without a visibility to stakeholders it might results in additional (and boring) status meetings, auxiliary PowerPoint presentations on team’s progress and etc. And the root cause of this waste of entire team time is just your poorly designed Scrum board. So, why not to eliminate the root cause and not to have a useful tool, which can give a real progress overview with almost no additional efforts to the team (I mean, they just have to keep the board up-to-date)

Signs that you board has problems

So let’s examine closely what are these signs of troubled board.

1. State column actually consists of two or more states. For instance, when some development for the task is done, you’re putting it into Testing column and the testing itself hasn’t started yet, so the task would wait there until some actual testing activity will start.
2. Current state of task depends which team-member it is assigned to. Your task is hanging in ‘In Progress’ column, but it might has been developing if assigned to developer, or testing if assigned to test engineer. The trick is to know how is who.
3. State of the task is linked to it’s sub-task. When the development for all sub-task is finished, you just would create another one with the name ‘Testing’. Sometimes, it might be even worse — for each technical task you got subtasks: ‘Develop’, ‘Test’, ‘Deploy’.

So, your first question, after I named these things, could be “But why this is bad?! We’re working like this for a while and everything is fine.”

That’s a legitimate question and you don’t have to trust me without any arguments from my side. Lets discuss why I consider these things as sign of bad electronic Scrum-board.

Why can’t we live with 3-column board?!

I bet, you can. The board serves two major goals:

• Allow the team to track your work progress
• Visualize your progress to anybody interested or involved

While you as a team can track you progress keeping in mind all different kinds of arrangements you have in a team (i.e. ‘In Progress’ assigned to Tom means ‘In Testing’ or ‘Waiting for Test’), for some external spectator it could be overwhelmingly annoyed to keep in mind all these preconditions. Especially if this spectator should watch several boards and each of them might have a different rule-set.

Sometimes, Scrum or Kanban boards are referred as Information Radiators. They radiate information like heating radiators radiate the heat. The board on the wall radiate you progress to anyone passing by and it should be enough to have an instant look in order to understand the nature of the information it radiates. But when in order to decode the information you must know some rules, it radiates nothing but confusion.

And yet you can live with your 3-column board quite well, but we’ll talk about this later.

Physical board VS electronic board.

Another thing to consider: nowadays teams might not be sitting in the same location, members of a particular team even might not be in the same country. Or team’s progress spectators are located all over the world. Many people can’t see the physical board in team’s room, therefore the team must proceed with some kind of electronic board.

And there is a significant difference between physical and electronic boards. When the board is on the wall of your room, no one outside this room can change the state of the board. On the contrary, electronic board is exposed to the whole world (or at least to the whole organization) and the one got the access rights to change it — can change the state of electronic board from everywhere. That is why electronic boars are widely used by distributed teams — team members may work from a different location and his progress could be visible to entire team.

It’s a benefit of electronic board use but also it is a flaw. Somehow, using electronic board you hide from the rest of the team the exact moment when you move some task into next column. That exact moment, when you do it at the physical board, you could inform the rest of the team that some part of work is done, some discussion could spark among your team mates or you could ask them if they think your part of work is done correctly. But that is not what happens when you move something on the electronic board. When you do move your task on it — nothing happens, since usually no one is watching the board constantly. Sometimes a related message will be dispatched to your team’s chat.

I am not saying here that nothing could happen, of course it could. Actually, it should. But usually, team’s board is used to track an individual tasks rather than to organize team’s work process around it. So, let’s talk about how we misuse Scum board, how we are really hiding the structure of our working process and why it is bad for us.

States aren’t what they really are.

In reality your ‘In Progress’ column contains the following states:

• Development
• Testing
• Deployment Preparation

And ‘Done’ actually means ‘Deployed’ — either into Prod or into Stage. And you may ask: “Why this is bad? We have explained everything to our PO”. But this is bad, you’re hiding the real progress into some vague state, which doesn’t correspond with any of your activities, you are unable to see the bottlenecks in your process, every time the task changes it’s assignee — he or she have to examine what is an actual state it.

State is defined by assigned person

And there is another hack. You might say: “We detect the actual state of the task by the assignee! When it is assigned to Tom — it’s in development, when assigned to Sarah — in testing, and etc.!”

That makes your board even worse. Now it assumes that every person in your team has only one role: developer, tester or devops engineer. And that an external spectator of your board should keep in mind all the roles you got in the team. Any spectator ever looked on this board should be provided with explanation who does what. As if developer can’t do the testing and deployment, or devops engineer can’t do the coding.

State is defined by sub-task.

Another way to add unnecessary complexity to you board is, when you have 3 columns board and you want to reflect the real progress of the task, which hands in ‘In Progress’, you could just start creating additional sub-tasks like ‘Development’, ‘Testing’, ‘Deployment’. It’s not only overloads your board with unnecessary details, but also increases the possibility to mess up with your tasks completely. What if there are two sub-tasks ‘ Development’ and ‘Testing’ are hanging together in ‘In Progress’? What is there is no ‘Deployment’ sub-task?

Complexity VS complexity.

There are two types of complexity on your board. Either you got some complex rules with relatively simple board or you got a complex board with very simple rules. Of course, every board’s design is a compromise between these two complexities, but you must remember that the more complex your rules are — more error prone your system would be. So, in order to reduce rules complexity you must increase complexity of your board.

Having more columns would transform your the way you see your work. Inuit people have got up to 50 words for ‘snow’, Saami people have 180 terms for snow and ice, which describe it’s state, density, age, structure and etc. And so could you, instead of one ‘In Progress’ column you will have ‘Development’, ‘Ready for testing’, ‘Testing’ and ‘Ready for deployment’ and etc. Having that variety of states you will exclude complex conditional rules (‘In Progress assigned to Sarah means In Testing’) from your workflow and will visualize all the bottlenecks you got. And this board would tell much more to any external viewer, who might be interested in team’s progress.

Suggestions.

1. Do not try to design a complex board from a scratch. Start small and simple and then each time you find yourself explaining someone some rule “if this then that’ — split your column into two separate ones.
2. Do not base your workflow on an assumption that every one in your team has one and only one fixed role. Roles may change, may be shared and etc.
3. Automate. Unfortunately, a current state of automation within software development has not reached the level where I’d like to see it, but you might use a lot of automation tools, which should allow you to eliminate certain steps/states. For instance, once the feature marked as ‘tested’ it might be automatically deployed into Staging environment.

Unfolding and folding back.

Basically, when you start your project, you may have a very simple board, but as you go forward, this board will become more sophisticated and complex allowing you to visualize your items flow. As soon you realize there is a complex rule — you unfold one column into several. Once the flow is visualized, a bottleneck (if there is any) is discovered, an underlying problem is addressed and resolved, the team is trained to handle it and the shortcut is automated — you might want to fold these columns back into a single one. Or might not. It’s up to you. Just remember that your board is going through same evolutionary changes as your team, workflow and your product, so you have to adapt in to the current situation. Just remember my advise: rather build complex board with simple rules than simple board with complex rules.