Recently, while we were facilitating an EVDnC, one of the teams was having difficulty deciding what tasks should be done by whom, and which of them should be done together. Things like this kept coming up: “But I didn’t know you needed that”, “I was waiting for the Back-end to do it and they didn’t even look at it”, “I’ve some dependencies with you, but I haven’t told you yet”. A lot of discussions and not much alignment.
This was a team with the following specialties: User Experience (UX) and User Interface (UI), Back end, Front end and Quality Assurance (QA). The Kanban board didn’t translate the dependencies and nothing was moving. So we created a different board.
The Board of dependencies
Using a Flipchart sheet, we made a circle for each separate specialty.
Then we drew a line linking each specialty.
We took the user story with the highest priority on the Product Backlog, the one generating the most discussion, and set the following challenge: Everyone list on post-its all the technical tasks each specialist needs to do so that the story fulfills our Definition of Done. Each specialist uses their own post-it color.
The tasks depending on the specialist and only the specialist go inside the circles. All tasks depending on work together with another specialist go on the line. Any task requiring 3 or more specialists should go in the middle of the board.
This Figure shows the board once completed.
Board of dependencies
What we can see here is:
- UX/UI have 2 tasks and don’t depend on anyone;
- Front end has 6 tasks, 2 depending on UX/UI and 1 depending on Back end;
- Back end also has 6 tasks, 1 depending on UX/UI;
- QA has 5 tasks, 1 depending on Back end and 1 all the others.
Movements
When the dependency is removed, the task can be moved inside the specialist’s circle.
When the task is concluded, it can be removed from the board. The User Story is ready when the whole board is empty.
Tasks can emerge during development or the team can come across a dependency. Just be careful this doesn’t become an aid to masking rushed or bad planning. New dependencies should always be communicated and agreed upon between parties.
Agreements
A few agreements are necessary
1 – We should try to resolve the greater dependencies first (center of the board), then the lesser ones (lines) and lastly the specialists’ tasks (inside circles).
2 – Tasks mustn’t be attributed to others. I can indicate a dependency, but I don’t write post-its in colors which are not my specialty.
3 – Agree the best moment for the dependencies to be dealt with. Don’t just wait for the Daily Meeting.
What if there are more specialties on my team?
You can create other board formats (pentagons, hexagons, etc.), but be careful not to have too much team specialty. Remember Brooks’ Law. The quantity of communication interconnections is an explosion of combinations shown in the formula:
Brooks’ Law
Bringing it to an image
Examples of Brooks’ Law
Each specialist node you add to the team adds a communication overhead, increases coordination costs, adds to the complexity of story handoffs and hinders important agile practices like WIP (Work in Progress) limitation and Swarming.
