Celebrating impact
In my early web development career, I was quickly taught the importance of celebrating shipping.
The size and enthusiasm of the celebration was usually a factor of:
- the length of the project
- the size of the team involved
- the amount of pain and torment it induced
The celebrations were more often than not an outpouring of relief built up over the course of a long waterfall project. We had no idea yet whether the project would be a ‘success’. For me, getting the thing out of the door was my measure of success. Often, I didn’t care all that much whether anyone actually used what we’d built, or whether it was useful to them.
These days agile and iterative release models have become the default. But many teams still focus on shipping big features or epics as their moment of success - their definition of done. My celebration habits became more frequent, but far smaller in scale. Instead of a night out, sometimes our celebrations would be limited to a quick ‘Well done everyone’ on company chat.
With agile, it’s all to easy to make default, minor celebrations a part of the sprint cycle. But if you celebrate in exactly the same way each sprint, you’re essentially saying ‘Well done for getting through another 40 story points!’
When a team shifts their focus from outputs (features / story points shipped) to outcomes (impact on users and/or the business), you can also change the culture of celebration to emphasise the impact the team is having.
Instead of “Let’s go go-karting to celebrate the release of Module X!” you can say “Let’s go go-karting to celebrate reducing our churn to under 5%!”. Even better if you can quantify the impact this will have on the bottom-line, making the case for a fractional use of that benefit on a really big splurge!
What and when does your team celebrate?
All the best,
– Jim
