Recently I have been doing a considerable amount of work on the Theory Of Constrains, Scrum and Kanban. I have been working with a team for quite some time, which as changed considerable during out time together for the better. We started with a group of individuals and now we have a cross functional team who take responsibility for all their goals. The makeup of the team is 4 developers and 3 testers in the traditional skill set sense.
Initially we started with a traditional scrum board using the standard scrum practices. The workflow was that of a standard team over 6-8 lanes which followed the standard sequence :
- Sprint Backlog
- Dev
- Testing
- Done
Although being cross-functional and working as a team was encouraged, patterns emerged which clearly showed the division of developers and testers. I was becoming frustrated with this as it was facilitating mini-waterfall practices to some extent.
As part of a team building exercise I encourage teams to build their own board designs and avatars to visualise the workflow. This creates a sense of ownership and fun which are useful components when teams use the board on a regular basis. Personalising the board increases the level of engagement and encourages the team to work with their board. We evolved form a traditional grid board, to an octagonal board as seen here with our previous Super Hero Scrum Board. I’m fortunate to work with an open minded team who welcome changes of anytime in the name of improving.
This was a great setup and team really got more out of it. However, although the team was really working well together and sprints were successful, we got comfortable and the next step of the evolution needed to be taken. A symptom to date was there was too much work in progress and it was observed that a developer was looking to pull in the next card when the previous card moved to testing. What this meant was that the developer was introducing 2 and sometimes 3 cards into the sprint and creating a bottleneck with testing. It also showed a split in the team. However this worked well in most cases and everyone was happy, but more could be done.
Reflecting on Kanban’s ‘Work in Progress’ (WIP) limits and considering the Theory Of Constraints, exploit the bottleneck and subordinate every decision to the bottleneck we altered our workflow and visualised the change.
The first change was to limit the number of active lanes to 3. Having 4 developers and 2/3 testers this was a suitable number as it meant developers had to communicate and work together. In line with this rule, it meant that if a team member wanted to pull in a story and 3 lanes were already active, they couldn’t. The outcome was that the person had to have a conversation and with others on the active lanes and offer to help complete the story.
The outcome to this change was quite profound. This promoted team work and helped get WIP items done quicker not to mention improved knowledge sharing. The team become a lot more autonomous. Previously developers and testers had more of a separation. Now if a lane was being used and the story was in testing phases, the developer would get involved with testing. This resulted in much better knowledge sharing and a better understanding and respect for each of the development/testing processes. From this, significant improvements to the testing process emerged because developers could help improve automated testing using their development skills, freeing up time for more in depth manual exploratory testing and having capacity to accomplish more productivity.
The second change we introduced is that only two tasks of a story could be worked on at a time. This improved the workflow as it encouraged tasks to be completed and moved whereas previously it was less obvious on the workflow and status. This only applied on stories which were broken into tasks and in a lot of cases this wasn’t the case as a pair would pick up the story as a whole.
The third change which is noticeable on examples shown is that we abolished the development/testing lanes. This helped the team communicate and work together to get move the card through it’s requirements to get it ‘Done’. The ethos within the team is that everyone is a team member and not developers and testers. Each person as strengths and weaknesses which can be shared. Although there are obvious constraints, having less physical restrictions (lane divides), this encouraged the team to progress and become more cross-functional.
Hourglass Storyboard Lane
Hourglass Storyboard Lane
As a result of these changes, the teams output increased and continues to do so. We have also seen significant improvement in knowledge sharing and improvements into the structure and workflow as there is a better team understanding of how changes upstream affect the process downstream. Therefore the workflow has become more efficient. We have taken on the 5 steps of the Theory Of Constrains and continue to apply them to continuously improve especially through the retrospectives :
- Identify the systems constraints/bottlenecks
- Exploit the constraints
- Subordinate everything else to the above decision
- Elevate the systems constraints
- Start Over
The Changes We Made To Our Scrum Board
You will notice that the board looks quite different to the standard Kanban/Scrum board grid. We wanted to emphasis the WIP limit and an hourglass represents this well. You could rotate this 90 degrees left and see it as a standard grid lane, but the hourglass is more fun and represents flow well.
Hourglass Scrum/Kanban board
This is our actual Scrum-Ban Board
Competition
Since sharing the blog post it went on to Win the Best Card Wall competition with ThoughtWorks Studios. To watch the card wall hangout review, view more here.
If you have any questions on this post or would like to add comments, please feel free to do so below.
How have you implemented your Hourglass Card Wall ?
If you have implemented an Hourglass Scrumban Board, send your photo’s over with a brief explanation and I’ll post it on here with a trackback to your site.
1. Callum Sneddon uses the hourglass board to visualise work flow through a higher level over 5 teams
The following board was sent over by Callum who works in Data Warehousing and BI. I was really impressed with this, it looks professionally designed and takes it to a level above each team to visualise workflow. Thanks to Callum for sharing this!
Overview : The BI Chapter has a member (The BI Lead) from all the teams in the release train. In total, there are 5 teams. The BI Chapter is in charge of setting standards, building templates and so on, so Callum created an hourglass for each team so they could see what the teams were working on. Regarding WIP limits, Callum has tried to limit it to a single story per team. They try to break our stories down so they don’t need task, but in cases where task are needed, there is a limit of 2 task’s per story to be played at any one time by a team. As for the jail, the idea is that a story can be blocked, but it might only be blocked internally to the team, so they just put that in “just visiting”, but if the story requires a PM, then it goes into jail.
Hourglass scrum board visualising release backlogs over 5 teams