Elephant Carpaccio V2
- leverage the power of microslices -
DISCLAIMER: NO ELEPHANTS WERE HARMED DURING THE WORKSHOP. THE PRODUCT OWNER GOT SICK AND SOMEBODY SHOT THE SCRUM MASTER BUT THAT’S ABOUT IT.
The original recipe
Since it was created by Alistair Cockburn and described by Henrik Kniberg in his guide, I facilitated several sessions of Elephant Carpaccio, in its original version. For those not familiar, this is an exercise in which a software development team, stable or temporary, can do to better understand the benefits that can be obtained in dividing the user stories into very thin but still vertical slices. Hence the name of culinary origin since carpaccio is meant for a preparation that includes slices (usually meat slices) so thin as to be translucent. When I think of a team I do mean a cross-functional one with developers, testers, product owners, ui and ux specialists and whoever else you need in your project.
If you already have a little experience with user stories and you share the principles behind, the concept of micro slices should sound quite natural if not easy. At least in theory, because I realized that often even the more mature team have a backlog diligently divided into a story for each architectural layer or each component (e.g. back end and front end) and this usually depends on endogenous causes for more than anything else, it’s not the elephant fighting you.
Now, try reading the sentences in the list below: if it seems that at least one of them describes the stories in your backlog, then you can invest two hours to perform the Elephant Carpaccio exercise, with the help of an external expert facilitator with (so keep the fun for you and making sure not to distort the meaning of the exercise):
- stories are very large, often last for several weeks
- stories don’t meet the INVEST characteristics (*)
- stories are splitted in back end and front end ones
- before we can use a functionality, we must develop several stories related each other
- we split each functionality in stories, one for each component we should develop or modify
- not all stories are vertical and testable and represent user value
- it happens sometimes that due to priority changes it needs a lot of time (several sprints) to see a functionality
- story estimates are very diverse (no matter if you use story points, ideal days or any other units of measurements
- we feel that the complexity of the system is increasing
- we feel that in the past stories of similar complexity (compared to those currently in the backlog) would have required less effort
Surely we consciously stumbled in at least two or three of these cases, especially the first ones and especially in the early stages of the adoption of user stories. The other cases are more subtle and therefore less easy to spot.
Let’s add some ingredients
Before you continue
If you have followed me this far may be you are a coach that usually facilitate Elephant Carpaccio sessions, so you can pursue and evaluate whether variations that I suggest can do for you. It ‘also possible that you’re never come in touch with this exercise, but you’re interested in its application: in this case jump to the bottom of the article, look for the references to the original version and start from there.
Are we missing a spice ?
A couple of months ago I was at home, reading some stuff on the web. It was about 10 minutes to midnight. The day was spent quietly, Stefano and me had facilitated a session of Elephant Carpaccio with a relatively new team. Then I received an email from Pasquale, one of the developers who had participated in the workshop. The subject seemed ominous: “8 minutes”. Fortunately, the content of the email was not about the end of the world. That was the time had taken him to develop from scratch, using Python, the same application that he had failed to complete during the workshop. The coding phase in the exercise lasts 40 minutes, and Pasquale had used PHP which is a language that he usually use.
What went wrong ? It wasn’t a speed exercise, it was about splitting and about incremental development. Midnight came, the world is still here, my certainties about the workshop are gone.
So I remembered two teams I have met in a previous session: the first has split the application into 12 slices and has completed the development, delivering the first valuable slice at the end of the the second sprint (out of 5). The second team has splitted into only 5 slices, has finished the application but has delivered the first valuable slice at the end of the the sprint 4.
Then I realized that although we had tried to be crystal clear, seasoned developers have concentrated on the code rather than on continuous delivery of value. The old, bittersweet waterfall process, blessing and curse for developers.
At that point I spoke with other coaches, Stefano, Francesco, Valerio and we thought possible variations that I started to test immediately.
Obviously, the result of a workshop is influenced by both the participants and the way in which we facilitate. There isn’t the best variation for all occasions, but now I have more options to choose from, including the original version.
Variation 1: Stop at sprint 4 because the budget is over
For each sprint concluded I record on a white board or on a flip chart the value delivered by each team. I defined 4 tests, each test satisfied is point. At the end of the fourth sprint I stop everyone and i say that the client’s budget is over. No more code. The team that worked incrementally should have delivered more value, while those who worked with larger slices might have a nasty surprise. It’s a realistic situation. Unfortunately the solution dos not leave a pleasant memory. Use it just to get a disruptive effect and annoying. If you adopt this variation, bring it to the end without remorse. Do not start the last sprint, the effects would be rendered meaningless.
Variation 2: Team uses earnings to buy advanced tools
For this version, I was inspired by the Kanban Pizza Game from Agile42. Each team start coding using the worst tool they have, for example notepad or even the console appender (the MS-DOS “copy con” command). When a team delivers value they receive chips (fiches) and they can use them to buy tools, such an editor, then an IDE. In this case we are playing with constraints but we are using them just to point out the cash flow.
Variation 3: Risk / Risiko
In the original exercise we must develop functions for five states (Utah, Nevada etc.). Paint on a whiteboard a simple map of United States. Now imagine the team is developing and offering a service: delivering value for a state means the team starts to earn one or two chips for each state. We can also have the customer earning from each state but the result is almost the same. And … what about a Monopoly variation ?
Variation 4: Customer losses will increase if no deliveries
The customer starts to receive requests since sprint one. Each uncompleted sell will be presented as a customer loss. Requests arrive from every state. Losses for a state won’t stop until all requirements for that state are satisfied. You can also develop a simple application that send requests: each uncompleted sell will be tracked. This is more difficult because you must be connected to the same network and, moreover, you are asking to develop a web app (or whatever able to accept network requests).
Variation 5: Ask a fatal change
Between the fourth and the fifth sprint ask for a change, such as: “I am the customer and I am asking you to change the software in order to manage the case a customer from Utah sends a request to the shop in Nevada”. In this case we are likely playing with design: an incremental design favored by a higher number of slices should lead to a easier change, while a non incremental design should lead to a panic situation. Use this variation if you want to join the practice of TDD.
Tips
- Have a two phases planning: during phase one split the project into stories while during phase two the stories should be splitted into incremental slices. Usually testers have a remarkable ability to suggest the slices.
- A team started developing the app using a spreadsheet: well, probably this was good idea but … hey… I was the customer and I haven’t budget for Excel.
- During the exercise a team must be really focused on value and on keeping everything simple: if a team is working on bell and whistles (such as GUI, input validation or configuration data entry) let them go on until sprint 3 or even 4.
- May be you are impersonating the customer: don’t reveal every single detail, you are the famous “on site customer”, the team can ask you when they are in doubt.
About INVEST acronym
- Independent: it is easier to work with independent stories. A few times it will be impossible to avoid inter-dependencies.
- Negotiable: incrementally includes details which are unnecessary to planning but required later to implementation.
- Valuable: must be real value for the customer / user (see next paragraph).
- Estimable: easy to be approximately estimated to allow its scheduling.
- Small: in order to be predictable and allow a continuous and fast delivery of value to the customer / user.
- Testable: if not easily testable, then a story is not clear, first of all to those who required the development (if the request is not made by the customer then go back to “V”).
Who should be the recipient of the value
In some cases, usually few, it is permissible that the value of the product is not intended directly to the end user or customer. In general, from a lean point of view, it should always be possible to follow a path whereby at the end we can see that the effort has been directed towards the customer and / or end user but it might not be worth it: for example, we can imagine being able to reduce costs production by adopting a new technology. This does not bring new value to the user, but a saving for the company that may have more capital to invest in order to produce real value to the user. It could be a useful exercise to think about it, but I do not feel the need to complicate user stories with these stunts. Other times it is necessary waste: for example, we may need to implement changes to adhere to specific regulations. Digging we could find value to someone, but dig too much is wasted effort, again.
Web resources
· Elephant Carpaccio
o Original version (Alistair Cockburn) : http://bit.ly/1kaiag4
o Facilitation guide (Henrik Kniberg) : http://bit.ly/1kahTJW
· Kanban Pizza Game
o Original facilitation guide: http://bit.ly/1nErx86
· TDD
o Start from here: http://bit.ly/1ke1B2F
· User Stories
o INVEST (Bill Wake) : http://bit.ly/1kaijQA
