My team is using Kanban. A key tenet of kanban is to limit the amount of work in progress (WIP). Work-in-progress limits highlight bottlenecks in the team’s process due to lack of focus, people, or skill sets. For us this is always about testing. To resolve this bottleneck we have found boiler room testing to be a great solution. The name is based on the ‘high pressure’ boiler rooms in submarines. You need to be in there sometimes, but you want to get out as quick as you can. So, how does it work?
At any given time a day, when the team decides to ship new features that are ready, our UX designer usually gives the sign to go into shipping mode. At that point in time all of the team moves to a different room and starts testing on the new features. This includes all developers, the ux designer, the marketeer, everybody. Only the features that pass the testing succesfully will move forward to production. Some features will be deployed after hotfixing and other features get cancelled because there are still too many things to fix and improve. There is a couple of rules:
- One person is hooked up to the big tv in the room. Everybody can watch.
- No coffee unless everybody goes
- Bring your own device, in fact, bring as many devices as you can.
- No bug fixing while in testing mode
- No blaming, we are all on the same team.
Why does this work? We discovered a couple of things:
- Everybody learns. It is the best way to learn about new features that ship when you were not involved in the implementation of it.
- Group pressure. You must be a real @#$ to decide to start doing other things during a boiler room session.
- It helps to stay focused on the most important task that needs to be completed before shipping. Especially when you are easily distracted… look a butterfly!
- Share test experience. Learn how others are testing and learn to be a better tester. Even if you are a programmer and really hate testing.
- Exploring test paths is really effective when you are thinking as a team.
(It might not be the testing that is the problem in your team. As far as I can tell, you can apply this to any task that is a limiting factor for your kanban team).