Process

Last week I wrote about the value of finding issues early. How it becomes increasingly expensive and time consuming to fix issues the further down the development lifecycle you get. With that in mind we can now appreciate that anything we can do to find bugs earlier makes our software not only better but cheaper to develop.

Something we’re trialling at the moment are at desk demos. The idea is simple, before signing off a piece of work and passing it onto the next link in the chain (Dev to QA, QA to Support Analyst, Support Analyst to Dev and so on) you demonstrate the issue or feature to them.

For example, before I finish a feature and pass it onto someone who specialises in testing I invite my buddy over to “give it a bash”.

Remember last week? I talked about the time it takes to move from on link in this chain to another. I discussed how it can take a few hours to build your software, another hour or so to deploy it, and a day to run the signoff scripts (obviously this varies if you’re fortunate enough to be working on a ‘modern’ solution or have invested in some proper CI). Time moving backwards is time wasted, if you can avoid rework then you should always take the opportunity to do so!
By offering up my work to the QA for a few minutes before formally handing over can save hours of wasted time. These guys know what they’re looking for and can often find edge cases and give feedback on a few scenarios you’ve not considered. By having these pointed out to you early you’re saving all this extra time!

The same theory can be applied to a Support Analyst demoing bugs to a Developer rather than just recording replication steps on a ticket or a Developer showing a bug fix to the same analyst before shipping it to a customer’s UAT environment for testing.

So far it’s working well for us. Do you demo before handing over? Do you feel it works for your team?

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.

supermarket_flow

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:

kiosk

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?

Tag: Process

Have you tried At Desk Testing?

Continuous Delivery at the Supermarket Checkout

*Thanks to draw.io for the flowchart software I used to create these images.