Awesome bell

I mentioned the “awesome bell” (pictured) in my post about some of the tools I’d require to implement Scrum.

I want to briefly say a little bit more about why this bit of kit is so important.

The way it works is that whenever a Story in the current Sprint goes to Done (i.e. done-done), the person who “owns” the Story gets to ring the bell. In our implementation of Scrum, we’ve found that nominating an “owner” of a Story helps to invest a single person with overall responsibility for progressing that Story. Of course, the entire extended team shares ownership of the product, and as Product Owner I myself am responsible for ensuring the overall product offering is optimal in terms of balancing various customer requirements against total cost of ownership. The kind of “Story ownership” I’m talking about is intended as a transitory measure on a per-Story basis to focus responsibility on that Story. Story ownership doesn’t imply design ownership — that remains shared — it only extends to the operational responsibility of pushing the Story through its lifetime.
Stories are never “assigned” to owners — somebody volunteers to own a Story, almost always the same person or people who will be working most closely with that Story; so every team member ends up regularly being a Story owner.

So, the Story owner gets to ring the bell. This action marks almost the very last item for which they will be responsible in the Story’s lifetime (presenting in the Sprint Review is one example of a following item) and is usually greeting by some moderately spirited cheering from the rest of the development team and by other non-baffled people who happen to be in the office.  To the baffled, I explain: “Every time you hear the bell ring, it means [the Product] just got slightly more awesome.”

Is the awesome bell a mere triviality? Just a bit of fun which momentarily adds a boisterous interruption to an office usually filled with the peaceful sounds of people concentrating in silence? My answer would be, No — the awesome bell is an incredibly important part of the team dynamic, and here’s why:

1) It gives us a reason to celebrate the untainted completion of something: Okay, so the Sprint Review every 2 weeks is a completion, but it’s rather a muddled one. Sometimes everything works out perfectly and we complete the Sprint as planned, but sometimes things come up and a Story might slip and not get Done. I would never describe this as a “failure”, as such, but it can take the edge off the celebration of a Sprint Review to some extent. Sure, awesome things happened, but there’s a little bit of detail hanging over which needs to be tidied up.

Conversely, when a Story gets done-done, there’s no quibbling — the product really did get more awesome — measurably and demonstrably so.

2) It rewards ownership: It’s fun to ring the bell, and it gets you a round of applause. The association is a good one: we can all agree that the sound of a bell ringing means value has been added. To those who sometimes question the value of what they do, this reassurance is very important. The Story owner in particular has, for a week or two, assumed personal responsibility for tracking the realisation of that value, and the ringing of the bell reinforces the fact that ownership and shared responsibility are rewarding habits to be encouraged.

3) It announces our progress: Everyone in the company is theoretically invited to Sprint Review, but I can count one one hand the number of times someone outside the extended development team actually attend. That’s okay – they can be a little drawn out, especially if we managed to get loads of stuff done! They also feel a little too ritualistic to many people outside the team. Finally, the level of detail is usually a little too high for outsiders – they’d rather wait until the next product release is officially launched to really catch up on what’s new.

But everyone in the office gets to hear the bell ring, and the impression is surely a positive one: that work is constantly getting done in development; that those slightly odd looking folk sloping around in hoodies and trainers are actually doing something useful instead of sharing incomprehensible jokes with each other or listening to music on their headsets instead of conference calling.

4) It allows us to show off: Do you think showing off is conceited? Then I’d humbly suggest you don’t know enough software developers. Software developers, for the most part, love to show off. Let’s not forget that developing new software is fundamentally a creative pursuit. Like a sculptor, or a painter, a software developer sits down in front of a totally blank canvas and calls forth their creativity and ingenuity, honed by years of experience, to create something which simply didn’t exist before. Those who do this in an amateur capacity (or off the clock, say) do it for the sheer enjoyment of creating something and don’t necessarily feel the need to share it with the world (or even keep their creations); but the proposition for the professional is very different. Not only do they expect financial compensation for the exercise of their skills, they also must be totally comfortable with the idea that there will always be an “audience” for their wares.

But perhaps I’m making it all sound a little too virtuous — it’s also true that the best software developers are really smart cookies too, and smart people do generally love to flaunt their intelligence. In an environment of many smart people, this can take on a fairly competitive edge.

Should we encourage such boastful behaviour? Quite simply, if it makes people happier in their jobs then absolutely we should. Everyone wants to feel like they’re doing a good job, and for developers that feeling comes from being able to show off how great they are. Fulfilled and happy employees means better quality work, lower employee turnover and a more pleasant working environment.

Let’s not forget that software developers are a seriously expensive commodity. Not only do they command the salary attributable to other highly skilled workers, they also require an extensive ramp-up investment to get up to speed with a given working environment, product domain, and to learn to work most effectively with their current set of peers. Making these vital employees as happy and as proud of their contribution to the team and the company as possible should be the number one priority of anyone who’s charged with getting the best out of that team.

P.S. The bell cost me £4.49 from Amazon. I didn’t claim it back.