Slice 🔪 and Dice 🎲
Recently I had the opportunity to attend a Slice-a-palooza workshop run over an entire day at Everest Engineering. Daniel Prager led the sessions and we had a wonderful collection of engineering and product-type people from numerous organisations in the room.
So, what is slicing?
Well, I’d describe it as the breaking down of your requirements into smaller “slices” that you can deliver while ensuring that each delivery provides value. Pare back any requirement to the minimum set of actions that could still provide value — remove the bells and whistles for time being and just prove that you can do what you’re saying on the box. Forget about your fancy UI and the extensive error handling and validation and just concentrate on the thinnest slice of the function for one scenario. Build a foundation that you can improve upon.
How did we do this in practice?
The first part of the workshop was conducted in the typical Elephant Carpaccio workshop style (as created by Alistair Cockburn of Agile Manifesto fame) and introduced workshop participants to the principles of ultra fine slicing.
Then, in pairs, taking the slicing approach to the extreme, we used 8 minutes sprints (yes — 8 MINUTES!) to provide some value to a given problem space. This 8 minutes included the planning, executing, testing and demonstrating — RINSE and REPEAT.
Of course 8 minute sprints are no recommended in your day to day but, as a mechanism to learn by doing, it was a fantastic approach. You could see each pair find their groove and light bulb moments hitting throughout the room. The buzz of providing some value in 8 minutes and then working on the next priority and/or debugging that thing you just built (because 8 minutes flies by!) was brilliant.
OK, so you’ve taken a mythical problem and some guidelines and requirements provided by a workshop facilitator, but how can I draw adequate parallels to my real-world problems? How can I take this back to my workplace and reap the value?
Workshop participants were asked to bring a real-world Epic with them. While not all organisations may be comfortable with that approach, enough Epics were provided and we broke up into groups of 3–4 and discussed the problems. In an effort to gain a basic understanding of the requirements, we brainstormed, asked questions and began making notes about potential slices, or at least smaller chunks of what was being asked.
The subject matter expert (the person who provided their Epic) in each case was the guiding light in each group as we discussed, drafted, corrected and moved forward with our slices. The ability to apply workshop/training course concepts to your real-world work is a massive benefit of this workshop and it was widely agreed among all present.
Once we had worked through our Epics, each group discussed the outcomes with the workshop and in most cases had something tangible to take back to work or had their existing approach validated, or maybe even improved based on the conversations.
What did I take away?
It’s super important to have your team onboard with any concept or approach you’re going to introduce, and slicing is no different. I can already hear arguments or excuses ringing in my ears to back up the decision to add further functionality “while I’ve got the hood up” and similar. At the start of a new project, take the time with your team to discuss the benefits of slicing and to work through some examples (as we did in this workshop). That should go a long way to getting people on board, and entice them to give slicing a red hot go!
Note: For another take on this workshop, take a look at this post from Ash Jenkins detailing his experience attending the online version.
