Tuesday, May 23, 2017

A Slicing Journey

I first came across the idea of story slicing at Agile North when Seb Rose ran a workshop about it.  Our primary goal was to slice a story for a twitter clone from memory this was the ability to post a tweet of 120 chars.  I recall during the exercise we never quite sliced thinly enough, with Seb always challenging us to slice thinner.  Eventually the initial slice was just a web page with a text box to enter some text no restrictions.  I thought at the time this slice was way too thin, with little or no value - I really struggled to understand slicing so aggressively. 

I've tried over the last 4 or 5 years to understand slicing and apply it more in my every day to work.  Some environments allow this, and some don't.

The example that I've come up across recently is getting the product information for a product on an ecommerce site from a different place.  This is my attempt at slicing it thinly:

  1. Pick a single product
  2. Feature switch getting the title for the view from existing location to be hard coded in the view
  3. Push back the hard coding back through the architecture - i.e. this might be calling a api to retrieve the data
  4. Manually enter the title in to the product store & retrieve from there

Each slice should be deployed and monitored.  There are other tasks contained in each of these thin slices - like monitoring and setting up deployment pipelines potentially.  However, these steps shouldn't take that long.

By slicing this thinly you can learn about your architecture and get the walking skelton in place relatively quickly.  Therefore, understanding if you have any issues with the path you are taking. 

You could then expand this out to another product or build out some other capability.

The take home is try to half what you do now, then once you get good at that, half it again.  You should aim to get something delivered every day which extends your understanding of the problem domain.

Wednesday, January 25, 2017


My car went in to be serviced today, my wife takes it to the garage.

So that means I usually leave a note, if there are other problems with it.  I've had an issue with my front head light.  Last time I talked to them about it, they said it would probably be the bulb.  I'd proved this not to be the case by changing the bulb from one head light to the other.  I had to hand this information off, so I wrote a note.

During the day I got a call from the garage.  The guy on the line wasn't the mechanic doing the work, we had a garbled conversation about what the problem was, and what my note really meant.  After about 2 minutes of not getting anywhere, he put the mechanic doing the work on.  I managed to explain the investigation work I'd done, and my (google car expert) diagnosis of the issue.

As my drive can be long home, I began to wonder about what had happened.  It got me thinking about this diagram:

This has a couple of things:

  • I'd done some initial work - investigation and tried to express this in a note (hand off).  Which was useless, it was only useful as a conversation starter.  Maybe my badly written note would have been better "Front Headlight not working please call me", rather than trying to describe what I'd done to investigate.
  • Why it's important to talk to the person doing the work instead of a middle person.
  • Would it have been quicker face to face, with the car in front of both of us, to discuss.