Uncommon ways of managing ET #02 - Kanban

tl;dr – Can Kanban work for ET?

Kanban is a way of managing inventory* – and by making that management visually clear, of helping workers arrive at improvements in the flow of resources. Kanban doesn’t look like a natural fit with testing: It is rather a stretch to say that test teams make things out of stuff in the way that Toyota makes cars out of steel. More to the point perhaps, testing’s inventory problem is sorting, not storage; it’s easy to find vast numbers of things to test, and simple to think of many ways to test them, but hard to find the right tests right now.

Then there’s ‘Kanban in Software Development’**, which is related, but different***, and describes a way to manage not inventories, but software development work in progress. It’s interesting to read Chris McMahon and Matt Heuser’s take on Kanban.

Either way, Kanban helps to visualise flow and to discover how that flow interacts with the capacity to work. As such, I imagine that it might be a reasonable fit with some of the logistics of managing exploratory testing. Perhaps by giving a snapshot of what the exploratory testers are paying attention to (and what they’re not) it might not only intrigue people across the team but also show up process problems that are ripe for fixing.

This isn’t a note about how to fit in with Kanban-driven software development, but a note about how I would use it as a tool within the test team. Also, I’m doubtful about Kanban as a way of managing work in general, and I wouldn’t use it to manage all the work in a test team. So let me give context to the situation in which I think Kanban could be a handy to people managing exploratory testing:

• You’re already working with charters (from session-based testing or something similar).
• Your project has budgeted enough effort for ET to make it worthwhile managing the flow of the thing****.
• You feel the need to visualise and tweak your flow.

---

Here’s how I would use it:

Set up a chunk of available and visible wall as your Kanban board. Split this up into four columns. A great big fat one on the left for ideas that need to be touched on in the foreseeable***** future. Next right, a skinny column for what you might hope to do today, then a skinnier one that will show the exploratory testing going on right now. Finish up on the far right with a fat one for ideas that don’t need to be considered again in the foreseeable future. You’re going to fill the space with sticky notes. The sticky notes will be moved from left to right. At a glance, anyone in range will be able to see what’s left to do today, what’s being done, what’s been done, and whether testing is going on right now.

Sticky notes start out in the far left column. There will be lots here, probably rather more than the team might be able to test in the available time. Each one will represent a charter that you’re happy to spend a chunk of time on; you’ll write the charter on the note. I think it’s a good idea to put the originator’s name on the charter, so people know who to ask about its history. You’ll also want to represent the time****** you’re giving it, either by note size or with a number.

As a collective, fill up the ‘today’ column with notes. Kanban is a tool to help visualise work, so if you’ve decided that today the team will spend 10 hours exploring but you’ve got 18 hours of charters lined up, it will be obvious that you’ll need to iterate until sanity prevails.

The ‘in progress’ column is to help the team visually manage the flow of work. If you see people as the limiting element of your capacity (ie one person can only do one charter at a time*******), and you’ve got two people testing today, you’ll split the ‘in progress’ column into halves. You’ll give the halves the names of your testers. To give you a sense of today’s capacity, you might even block out chunks so that there is only space for two stickynotes in the column. The two spaces start out empty. When someone starts testing, they move the related stickynote into the ‘in progress’ column.

If that someone was me, I would write my start time and hoped-for end time on the stickynote before I stuck it back onto the Kanban board. Then I would explore, using the charter to direct my testing, within the timebox I had set myself. While testing, I would be very likely to generate more test ideas********. I’d deal with some of these the session, but some would need to become charters themselves. I’ll keep track of these on new stickynotes. When I finished my session, I would move the stickynote out of the space representing me and into the far right hand column, leaving the space empty for a new stickynote.

I would put any new charters on stickynotes into the great mass of notes in the far left hand column. I might even re-jig the work for today, if one of my new charters was more urgent than something else we’d planned. Then, assuming I had more time to explore, I’d move another stickynote from the ‘today’ column into my ‘in progress’ space, and get on with stuff.

---

That’s the basics. Let’s go one iteration on, and consider some wrinkles.

There’s going to be a surfeit of stickynotes in the left hand column. Too may ideas, and too much to do, is the nature of the testing beast, and I think it’s desirable to show this truth. Having the notes physically available means it’s easy to rearrange them. I suggest that the rearranging happens all the time, by anyone. If activity is dependent on something not-yet-delivered, I’d like to see the stickynotes grouped somehow – perhaps on a sheet that is itself stuck on the the board. If some activity is likely to be done soon, I’d like to reposition its stickynotes on the right of the column, ready to jump into the next day’ work. I’d encourage the team to bubble-sort vertically; to adjust pairs of vertically-adjacent notes from time to time so that more important ones rise. I’d like us to explicitly mark off a ‘pit of pointlessness’ at the bottom of the column containing all the stickynotes that represent things we can’t do*********, won’t do or just don’t want to do.

Over the day’s work, I want to see the number of stickynotes reduce in the ‘today’ column reduce, and the increase in the ‘done’ column. I’d like a second pit of pointlessness in the ‘done’ column for any notes representing a session that went bad. I would want to organise the notes in the ‘done’ column so that I could see, day by day, when something was done. You might want a different organisation. We would talk about it, and the board would have bought out a useful discussion.

The capacity element of this Kanban board only really applies in the ‘today’ and the ‘in progress’ columns. I’ve assumed above that the capacity for ‘today’ (or whatever period you use) is in hours, and having one hour represented by a note of given size might help understand how much time is needed, and has been spent. I’m less comfortable with the capacity of the ‘in progress’ column being named individuals – I’m well aware that an empty slot looks like someone’s not working, and I’m also keen that people can explore together and at times of their choosing. I think that I would prefer to work towards capacity in terms of Test Lab resources; clean data, single links to stubbed-out systems, hand-held devices, or whatever causes our primary bottleneck. Again, that’s something for a self-organising team to sort out for itself.

Frankly, I don’t know what to do about activities and time taken logging my bugs and stats and reports, or how to mark a brief debrief. I’ve worked in teams that have included and excluded plenty of activities from their charters, and I’d suggest consistency of approach within a group is more important the approach itself. Instinct suggests to me that this if board is only for visualising exploratory testing work in progress, that I include time spent doing diagnosis for bug logging and exclude the rest.

---

No huge surprises here, I hope – but let’s remember that one reason to use Kanban is to optimise away the need for Kanban. In the article referenced in **, Jeffery Liker was quoted in The Toyota Way: “Kanban is something you strive to get rid of, not to be proud of”. The approach I’ve described above should be seen as diagnostic tool rather than a solution to a scheduling problem. I expect that in use, one would see plenty of tweaks to not only to the Kanban board and its processes but – more importantly – to the actual work of managing exploratory testing. I hope that you, dear reader, will sort them out in a way that suits your team, and then will share your solutions (and your context) with the rest of us.

I’ve done bits of this from time to time, but not all of it together. If you’re interested in the ideas above, remember Elisabeth Hendrickson’s mantra: “Empirical evidence trumps speculation. Every. Single. Time.”. Some testers are already on this path, but I can’t find references to their experiences. Perhaps readers will furnish those references in the comments. I want to get to hear Adam Geras’s take on the subject, given that he’s not only lived with, but talked about “A Personal Kanban for Exploratory Testers”. I have a memory, which may be made up but feels as if it arrived in the last six weeks, of a series of pictures posted on twitter, with test activities represented as sticky notes that marched left to right across a board. I can’t find a reference to those pictures in any of my notes or bookmarks. If you recognise that as your work or the work of one of your colleagues, I’d love to hear from you, and to discover what you’ve learnt from the real world, and how badly it beats up my imagination.

---

* Arrived at by Toyota in the 01950s, refined into a cornerstone of the lean movement since, and now a perhaps just-past-trendy meme in the agile community. Here’s Wikipedia on Kanban. As I understand it, Kanban at Toyota describes a system of signalling that a small, local inventory is empty. It is used not only to manage the flow of components, but also to make that flow explicit, and adjustable. One reason to use Kanban is to optimise away the need for Kanban. This appeals to me. I’ve never seen this kind of Kanban in action, but it’s clearly inspired lots of people.
** see Karl Scotland’s Aspects of Kanban for text, David Anderson’s A Kanban System for Software Engineering for video. Here’s a currently poorly-cited article on Wikipedia so you don’t have to take your hands off the mouse. I have seen it in action, but never the same way twice, and you’re better off going to the sources than reading an inevitably compromised footnote like this one.
*** Tokens indicate presence, not absence. It’s about making inventory, not consuming inventory. Capacity and optimisation seem (in practice) to play second fiddle to visualisation and flow.
**** As a rule of thumb, this is more likely to be true if you’re not just concerned with what to test first, but what might be handy to test next. If you’re jamming ET into the gaps around the edges of your existing testing, I wouldn’t bother managing it with Kanban, because there’s no chance it will flow.
***** My horizon for foreseeable is pretty short. The absolute maximum might be the end of the sprint or the date of software release, and it tends to be less than three days. Your team will have a different attachment to the future. As a group, work out what your horizon for “foreseeable” will be and write it large somewhere obvious. Do change it if you need to.
****** Unless you’re working with fixed-length charters.
******* hmm
******** distractions
********* too big, too difficult, too dependent to consider in the foreseeable future. It’s not just the trivial things that are pointless.