In test column
Update 4/1/20: I’ve also written about How to move away from the In Test Column
A colleague recently asked me why I think the in test column is a bad idea. So I had a quick search around and couldn’t find anything specifically on the topic I decided to put some of my ideas down on why we shouldn’t have one and instead to opt for a more generic In Progress column.
What’s a board?
Most delivery teams have boards of some sort to make the work they are doing more visible and show progress towards some goal. The two most common ones I see are physical boards with sticky notes and avatars representing individuals in the team
The other is a digital one usually Jira or Trello
The usual configuration of these boards are Backlog, In Dev, In Test, Done with tickets moving from left to right as the work progresses though each column. This helps the team visualise where work is currently up to and making it less abstract.
This all seems sensible as you can monitor the number of tickets in each column and create whatever stats you need to report on but from my experience these types of boards that break down in progress work into Dev and Test roles encourage certain types of anti-patterns.
Inner team silos
Boards like this have a tendency to encourages invisible silos within teams. The backlog column becomes Product Owners (PO)/Business Analyst (BA)/Project Managers (PM) responsibility and overall ownership
The Dev and Test column’s belonging to their respective disciplines and things only getting into done when Test say they are done.
Therefore settings up the disciplines into their silo’s and only doing work that is in their column and handing work off to the next column. Rather than jumping into different columns when they can help or pairing on tasks.
Pushing testing towards the end of the delivery pipeline
With the In Test column coming towards the end of the board and normally the one just before Done it starts pushing testing towards the end of the delivery pipeline rather than continuously throughout development. It also starts putting Test in the position of releasing the software rather than it being a team decision.
It almost sets up Test to be the last line of defence before a release.
More work in progress
Another consequence is that Devs starts picking up new work from the backlog while the Test team are verifying the previous ticket. If Test find an issue the ticket has to either go back into the Backlog or straight back into Dev.
Now the team has to decide do we let the Devs switch context, fix the issue so Test can carry on. Or finish their existing ticket, make Test wait, let them context switch to pick up something new from the Test column?
Context switching for either side isn’t a good thing as there is always the usually spin up time to get familiar with the ticket. Which can lead to people taking short cuts to get the work done quicker.
Testing becomes the bottleneck
The only constraint on the Devs doing more work (tickets) is what can be pulled in from the backlog and the amount they can do. Given the nature of our work (building software solutions) teams always have more Developers then Testers. So teams have a tendency to use the Dev teams to 100% capacity churning out more and more tickets.
As the Devs begin to get through more work, tickets begin to pile up in the Test column waiting for Testers to become free. This naturally leads to Test becoming the perceived bottleneck in the system as this is where the tickets are being held up.
How do you fix the bottleneck?
1) Add more testers
2) Automate more of the Test teams work
This usually leads to more automated UI tests which is surely all that the Testers are doing… right?
See UI Automation, what is it go for? (AKA the Automation fallacy) on why automating at this level isn’t going to give you want you want.
The third which is rarely discussed is
3) Remove the In Test (and Dev) columns
This may sound strange as it looks like all you’re simply doing is hiding the work so let me explain.
You switch to having an In progress area instead. This is pretty much any work the team is currently working on and by this I mean actually doing not something they were doing and are now waiting for some information. This should be almost anything: meetings, training, coding, spike work, testing, absolutely anything any of your teams members could be doing that day that takes longer than eg 1 hour or whatever makes sense to your team to have on the board.
Now instead of just adding a Dev (or Devs if they pair) to a ticket also include a Tester as soon a the ticket gets pulled in. As the Devs are getting up to speed with the ticket the Testers should be too forming a 2-3 way pair/group (I’ll refer to this as pair for the duration of the post). This pair will stay with the ticket all the way to Done. No handoffs, no queuing up work in other columns. It is their responsibility to see the work to Done, preferably to production with Testers providing there and then feedback to the Devs on how the work is proceeding and helping them to bolster any automated testing eg unit or integration testing.
If you find that the Devs are taking longer on a ticket then it’s probably a sign that the ticket is too big and needs to be broken up into smaller, independently deliverable parts.
By having just a In Progress column and pairing Dev & Test from the start will foster a more collaborative approach to getting the work actually done in a team. It also stops more work being pulled in while other tickets are still in progress, reduces the amount of context switching for all and starts addressing the issue of Testing becoming the bottleneck.
Remember Testing isn’t something that happens once the Devs have finished it’s something that should be happening continuously.
Hi Jit. How does the team distinguish between the different activities it takes for an item to move to done? Or is that unimportant (at least in your context)?
This should really be conversations between the individuals involved within the team and collectively should know when the ticket needs to move to another column. I’ve found that having a strong team lead/PM can really help the team figure out where a ticket should be if there is uncertainty.
Another idea I’ve seen being used is actually having entry and exit criteria for each column actually on the board to help guide teams as well and really helps teams new to using boards.
It feels a bit funny to me when you speak about a “Test team” above, when I’ve used Kannan we’ve just had a delivery team with people with mixed expertise. With Kanban team members worked together to prioritise getting tasks furthest right to done together before taking on any new work as a team. This approach worked well for us but may not work for everyone.
It’s a good point Robert and agree delivery teams should ideally be mixed but from my experience I’ve only ever seen hybrid approaches to Kanban where teams have almost cherry-picked the ideas that suited them best. They have a board and columns that look kind of like a Kanban board, some may even be pulling work in as opposed to pushing.
But it’s usually some hybrid scrum-kanban type process which when you dig in it’s just mini-waterfall with two week sprints and a board.
In the example I was thinking of the ‘test team’ was actually two testers so I should have been clearer.
This could also be due to the tasks taking too long in test. Tasks that are too large are the most common problem I’ve seen after communication problems, which can mask task sizing problems, of course. Often that happens because tasks are too big. They can take too long in dev and then suddenly pile up in test. Alternately, they can take much longer to test than the amount of dev time. In either of those cases, making tasks smaller can help.
The automotive assembly lines we based our “software kanban” on did not have stations where people did several days of work on one part. It’s worth pointing our that these lines weren’t designed to maximize throughput so much as to have constant flow; to be JIT. No, not to be you but “Just In Time.” As a tester, I want JIT tasks because that means faster, better feedback, the whole point of testing. I don’t think that’s what everyone always has in mind, though. Like Fragile and Scrumbut, there is always the risk of Kantban unless everyone understands the goals of the process.