To explain the reason for this post I should probably take a step back and explain that I’m currently fascinated with system design and the idea of workflow as described in The Phoenix Project and The Goal. I should also add (in case there’s any doubt) I hate shopping! So as Lucy and I were stood waiting in line on a particularly busy Saturday morning I had an epiphany.
Because I didn’t have anything better to do I mapped out the process in my head. The boxes on the left represent the customer, the ones on the right the cashier – at the end of the process they would tell me how much I owed and I’d dutifully hand over my money.
You’ve probably been involved in this process firsthand!
As I was loading my shopping onto the conveyor belt I couldn’t help noticing that the process wasn’t smooth. For a few minutes the belt would keep going, I was adding more and more groceries into the queue – then, for no reason I’d have to wait until more space became available.
I became convinced that if I wasn’t forced to endure this wait then the whole system would balance nicely, after all – the checkout assistant seemed to be able to scan groceries as quickly as I could load them (input and output were reasonably balanced). Then suddenly, frustratingly he would stop and complete the transaction with the customer and I had to wait for more space to become available.
In my mind the entire system mirrored a typical release schedule – features are requested, created, and released. The last part, the creation of a signed off build is often what holds up the process (either through bug fixing or code freezes) and that was exactly what I was seeing here.
Scrum practitioners advocate having a build which is good enough to ship at the end of your Sprint, this prevents large delays being caused in your process and helps make your deployments routine and safe. I’ve written previously about the quality benefits this can bring.
As I looked around me in the supermarket I began to wonder why there wasn’t a second person on the till. One could scan the items and the second would complete the transaction to ensure the workflow continued uninterrupted. That was when I realised that many have introduced something far more revolutionary!
Consider the new Scan as you Shop processes popping up around the country. These hand held devices let you scan your purchases as you work around the shop, this reduces the over complicated process above to this much simpler one:
This simplified process reduces the need for staff and makes the entire end to end process far more efficient, there are even customer benefits such as being able to keep track of your trolley’s value as you shop. The supermarkets are so keen that they’re even willing to take financial risk on you not to steal their stock!
Tesco, by reworking their system have simplified their process and hugely increased bandwidth – I wonder if there are any similar process changes can we make in software development which will have such drastic effect our productivity?
dotdotdev.com 