Software and Elephants - you won't believe how thin an elephant can get!


Like a lot of people in the agile world, I've observed that the smaller a story, or feature the better. In my experience we,  software people, are crap at predicting how long software takes to deliver. The bigger the thing, the worse we get at it.
So, it follows, that, if we make smaller promises we are much more likely to be able to keep them!
Enter Elephant Carpaccio, a great facilitation exercise to teach teams, engineers and product people, the value of small stories. Alistair Cockburn first blogged about this way back in 2008 and it is still, even more, relevant today.
Henrik Kniberg posted a facilitation guide here and described it thus: "The Elephant Carpaccio exercise is a great way for software people to practice & learn how to break stories into really thin vertical slices. It also leads to interesting discussions about quality and tech practices."
My experience with running Elephant Carpaccio has been universally positive. We've run the exercise 3 times at iflix Kuala Lumpur. as well as at Aconex. The exercise itself is high-energy and generates great discussions and a-ha! moments.
The mechanics are well described in the posts above, but I'll do a brief rundown: Make sure you have a minimum of 10 participants, at least 2 per team. I think 5 teams are a good number but it can be done with more. You'll need a couple of hours, 2.5 hours works well. You're going to build an app so having engineer minds involved is a must, but first, you have to build a backlog.
The facilitator sets the scene, it's a simple retail calculator, but... Get the team to slice what looks like a single user story into as many 'end to end' stories as possible. We've had teams range from 6 to 24 stories. This backlog building phase is really key, it's the whole point actually, dont start until each team has at least 10 stories (that's my twist)
Once you've had your initial discussions, (read the guide) and the backlog is prepped, the fun begins. The project is to be delivered in 5 sprint of 8 minutes each (I know!) There is coding involved, so get techies in each team. As you finish a story, yell out 'SLIIICE!!' brings the pressure on the other teams. Keeping the pressure on is so important, I like to roleplay the part of a demanding Customer, it helps and is great fun.
It's amazing how much like a mini-product/project the whole things feels like, compressed into a really short time span. The discussions are so important here, don't forget them. What did we get out of it? Almost no story is so small it can't be sliced further. Great discussions about the value of incremental delivery.
Some revelations: "Software people often fall into the trap of believing they know what the customer wants. It isn't until the customer sees the thing, that they know what they wanted in the first place, spoiler: It's always different to what they thought it was! If the customer doesn't know what they want, why are we so confident we do?"
"We've now got a Working agreement in our team, we don't take stories that are longer than 1 day into our sprint, anything bigger than that must be sliced and sliced again!"
Have fun slicing!


Popular posts from this blog

Skillus interruptus, being interrupted and loving it...a key skill for agile people

A survey on release processes with organisations that 'sef-identify' as folowing agile practises.