The power of play

These days, more a coach than a player, I've been thinking not only about scrum, agile and all the rest but how best to communicate on these topics and how best to generate and/or impart knowledge generally. The power of scrum lies in self-organisation and that complicates the coaching role; even if it were possible, there is no value in telling your team from moment to moment how they should tackle the challenges they will face along the way – you need to get people on the right track and help them develop whatever skills or practices are necessary to stay on that path.

In this regard I am beginning to understand the potential power of play. For instance, Innovation Games can be a powerful tool in getting those mental cogs a-grinding. The sail boat (variation on the speed boat) exercise can be used both for envisioning risks & leverage at the start of a project and as a tool to facilitate retrospectives. Formulating an elevator pitch or designing a product box are also great ways to generate collective focus and get the creative juices flowing.

In developing my coaching skills (and our service generally) I am lucky to be able to interface with a product development group here at our own company; the Qafé team. If I want to try out any ideas that I come across, and the Qafé team and I can identify some reciprocal advantage, then we collaborate accordingly. For instance, having read Derby & Larsen's excellent Agile Retrospectives, I asked the team if I could facilitate their sprint retrospectives for a set period. I gained through practical experience and the team gained through the generally refreshing approach to retrospectives.

We (Wouter and I) also 'tested' our user story (splitting) workshop on the Qafé team. Apart from all the excellent feedback that we got on the workshop itself we also learned that the Qafé team was having a problem relating to potential customers. Strange as it may seem, it is not at all unusual that developers do not explicitly think about who their users might be and what they might expect from the software being built. I decided to run a pared down version of Jonathan Rasmusson's Inception Deck exercise – even though Qafé was long past inception, in fact it is already in production and about to take off in a big way, more of that in a moment – to focus the development team's mind on the why of their daily what.

The inception deck is a technique for envisioning projects which comprises, among other things, several popular innovation games. Some elements of the inception deck were not applicable given the timing of our exercise but in a little under 2 and a half hours we went through Why are we here?, Create an elevator pitch, Design a product box, Show solution and What keeps us up at night? It proved to be a very valuable exercise and thereafter the team was generally much more focussed on who they were building for and why.

Some weeks later the company CEO arrived in the team room with good news and a serious challenge. Several large integrators had voiced an interest in Qafé and had undertaken to invest in some training and, assuming the product matched the potential of the idea behind it, to add Qafé to their list of supported/preferred development frameworks for enterprise systems. “But,” warned the CEO, “realise that this is make or break, if these guys don't like the system, that's it, you won't get another chance and the bad publicity will kill the product before it takes off. How confident are you that the product is ready, that it's stable enough?”.

The answer was a less than resounding “Quite”.

Don't get me wrong; this team is confident that they have a good product, they know that it's well conceived, designed and executed. The problem lies in the limited feedback they have been able to generate up until now – several enterprise applications have been built (by a sister organisation) using Qafé, each one resulting in invaluable feedback in the form of bug reports, feature requests etc. but the team might have been more comfortable with one or two more implementations under their belt before being faced with such a make or break opportunity.

The PO jokingly recalled the inception deck exercise, “Do you still wonder what keeps us up at night?” he asked of me. Suddenly inspired, he instructed the team to think on what would keep them up at night in the specific context of the news they had just heard. At the following planning meeting, with a focus on the release to the big vendors, the team detailed what their greatest concerns were. These were then collated and prioritised. Starting at the top of the list the team translated their concerns into actions and so determined, in cooperation with the PO, what their product backlog should be for the coming period. Sprints were reduced from 2 weeks to 1 and the team has gone about methodically addressing and eliminating the risks identified. 

Confidence has soared.