In case of you arrived at this article without knowing what “elephant carpaccio” is about, don’t worry, at the end I will leave several links so that you understand and learn how to practice. First of all: It’s worth it!
As expected, I do not intend in this article to teach how to apply the exercise with the team, for this I have left the links at the end of the text. This post is almost a statement of what I see as the benefits of exercise in addition to what problems I believe it helps to treat.
What problems are we talking about?
Being aware of opportunities to learn when they arise – and taking advantage of them spontaneously to practice new skills – is a quick way to improve.
DANIEL goleman, Richard boyatzis, annie mckee and berilo vargas in: the power of emotional intelligence: how to lead with sensibility and efficiency (in free translation)
A big “problem” is undoubtedly the team’s difficulty in looking at the product without “seeing its gears”, I mean, looking at the product as a consumer, without thinking about its parts, how to make it, complexities, restrictions, etc.
Another common challenge is to stipulate priorities and dependencies. To create a less dependent work flux. (Do you remember INVEST?)
Stipulate a delivery plan that looks like more “a piece of cake than a layer of the cake” so that the delivery is truly usable and not just another piece of complexity in the system that promises – in the future – to be something useful to those who need the product.
How can activity help?
Be quick, not hasty. You don’t need to speed up; just don’t stop
JOEL MORAES in: BE, live, remain 100% The power of discipline, focus and mini habits to realize your maximum potencial
This activity seeks to make the team deliver “pieces of the elephant” that still “Look like an elephant”. That is, any deliverable part is unmistakably a part of the expected system. Believe me, it seems easy, but it’s not.
Given the time restriction and scope abstraction proposed in the activity, the development team needs to free itself from the constrains of technical thinking and look at the product as a deliverable. Each sprint end needs to have a deliverable and it needs to be usable (that piece of the elephant that looks like an elephant).
The development team will need to understand and think about the complexity of what is being delivered and specially about what is being left undelivered without compromising the delivery result.
As the dynamic is carried out in small teams, in a second moment the “plan” of each team is presented to the others and this makes everyone compare their solutions and learn from the group’s reasoning, also creating a new working method taking the best of each proposal.
Finally, the team will be near of what really is the MVP e how it could be decisive for the digital product success.