Late last year, whilst on an Agile Testing course, Janet Gregory shared a little secret with us. We didn’t realise how awesome this secret was until we did a simulation and saw the effect on the entire team. Recently we taught this secret to a company we coach. Once again the behaviours we witnessed was inspiring.
Lets talk about the things that usually happen on scrum teams…
Most scrum boards have 3 columns: To Do, In Progress and Done.
Most teams have a code review task. It’s usually the last task and often forgotten or rushed at the end of the sprint.
Sometimes issues the code review finds are too big to fix before the end of the sprint, so they get ignored, or put on a backlog somewhere.
Usually the code review task is only related to development code. The automated code and test cases are not reviewed, and sometimes the unit tests are not reviewed either.
Often during the daily standup team members have no idea what each of the tasks mean, and only care if it impacts them directly.
Sometimes team members have no idea what other team members are working on. We’ve even seen teams where two people are doing the same thing without realising it.
If any of the above sounds a little familiar then read on to learn the secret 🙂
What is the magic column and how does it work?
The magic column is called To Review and it slots in just before the Done column.
Every task must go into this column and have another person look at it before it can move into “Done”. The person who does the task, put’s it into the column and finds someone on the team to review it. The person doing the review moves the task to done, when all the issues they find in the review have been fixed. It’s even better if the team agree that the task should be moved to done, before the person takes another task. (And yes – of course within reason, just be careful your reasons are not simply excuses).
This is what we notice when the To Review column is used:
Tasks become smaller. Smaller tasks have quick reviews – about 5 minutes. Its easy to get someone’s attention for 5 minutes to review something you’ve done. Tasks like “write the unit test for the addition function” or “implement the addition method” are far easier to review than “code the story”.
Every thing that gets done, gets a second set of eyes on it. Often the person who did the work realises problems just by explaining what they did to someone else.
Small reviews on small tasks usually find small issues, that can be quickly corrected. Misunderstandings and differences in interpretation were ironed out early on in the story development when change is easy and quick.
As people review each other’s work, knowledge in the team grows about what each person is doing, and what each task involves. Testers learn to read code, developers learn how to think about test cases, and everyone has an appreciation for the work the others do.
When it gets to the end of the story – the team is all on the same page about how everything was coded and tested. There are very few, if any, surprises.
We saw teams working closer together, collaborating regularly.
This simple column can radically change how a team works. – Try it!
Send us photos! But most of all – let us know if it changed behaviours on your team – good or bad 🙂