Month: April 2016

The User is Drunk

GlassOfWater.png
What’s so unpleasant about being drunk?

I’m not a UI expert by any means, and in fact most of my current testing role doesn’t include a lot of UI testing.  However, I found this to be a useful, entertaining, and thus  easy-to-remember summary of what it is a user wants and needs.

Happy testing.

Advertisements

Kanban, the key point that no one seems to get

 

CanBan

So this post started life as a rant about Kanban and how it seems to be misused / misunderstood by many software teams who want to use the magic buzzword to make everything more efficient.  I’ve tried to mangle it into something a little more constructive though.  If you know nothing about Kanban, then this post isn’t the right place to start – I’m assuming lots of context.  Instead, I’d direct you to this excellent book, which is what lead me into thinking about Kanban (The Kanban bit is actually covered in an appendix).

Right, still here?  Good, good.

 

Here‘s Kanban as used at Toyota.  The key revolutionary idea behind Kanban is that you don’t *ever* push work into or through the system.  You *only ever* pull it out.

You don’t say “I need a car; I’d better start by building some wheels, and then… and then… and then spray the car and then sell it.”.

Instead you say, “I need a car, so I take one off the end of the production line… which creates a space in the finished car showroom for the spray finish robot to spray finish another unpainted car… which creates a space in the unpainted car pile for………..  which eventually creates space in the pile of wheels for the wheel-making robot to make another four wheels.”  It’s like a sliding block puzzle – the finished product moves first and everything flows backwards from there.

Flowing from that, Kanban then lets you identify where the pain points / inefficiencies are in your process and reduce inventory.  I’m not going to get into how – go and read about it.

Now here‘s Kanban as used as a software development process, which doesn’t mention that key principle at all, which is a shame because then people implement Kanban with no real feel for how it works and how it can help them.  Which leads to stupid decisions like squeezing extra tasks into the Kanban board rather than than realising that the board has probably identified a pain point that you can fix.

So if you’re using Kanban, STOP and check  that you’re thinking properly.  Make sure that your thinking is all about removing work from the board, not adding it.  Work on whatever gets work out of the system, and if you can’t take something out of the system, work on whatever immediately unblocks that, and then backwards.  Don’t start at the beginning, shoving more designs and code in the front, and then worry about what those have to push through in order to fit in the board.  Pull the work out of the board, to create space for those lovely new projects to start into.

Here endeth the rant.