My colleague @MelisaCollett and I set about writing a workshop to explore & appreciate the elements that make teams exceptional. We ran this session with the NewVoiceMedia Scrum Masters and this is a simple ‘How To’ guide if you wanted to do the same sort of thing.
Inspiration came from this quote:
“Beauty is due more to harmonious relationships among the elements of a composition than the elements themselves”
Unlike many of the workshops I usually do, this was quite linear in format, with no quirky reveals. This is a topic centred on behaviours, so we felt that this was complexity enough unless you live and breath it on a daily basis (is that really just me?!) Coupled with the need to accommodate remote attendees, we knew we needed to stay fairly simplistic in approach.
We ran it as a 90 minute session, starting with each of us sharing what we remembered about the best team we had ever seen in action. We then followed it up with what we remembered about the worst.
We divided the workshop in to 3 main sections: People, Practices & Purpose, allowing around 20 mins for each.
The first section of People was the most meaty, and focussed on types of people. We deliberately chose generic types that could apply to any role to steer away from type-casting testers or developers. We also wanted to stay away from names of actual people. Neither of these are ever helpful.
I feel it important to just add a further note of explanation here. We were over simplifying deliberately in order to isolate and simplify some recognisable aspects of human behaviour. Once done, we could then move on to explore them. No one is a single person type – I myself am usually at least a dozen different ‘types’ before lunch!
Here are a few examples of the people personality types we used, there were more:
“I’m the best there is”
“No one ever listens to me”
We then went on to look at what behaviours we might see in a team with each of these types present. We discussed the types of behaviour we might observe in people that had these personality traits. The Perfectionist developer might spend a long time on each story, with a tendency to over-deliver or gold-plate their work. In the case of a Perfectionist tester, they might feel the need to test ALL the Exploratory Testing Charters. We did this for each of the personality types we had listed
Now we wanted to consider how such behaviours might affect the team containing with such a personality person type.
Expanding the last example of a Perfectionist team member, stories taking a long time to deliver obviously have a higher cost. Perhaps a Perfectionist tester would always have a backlog of work, no matter how few developers were part of the team, or the amount of ‘low priority’ bugs raised by the tester may be high. A Perfectionist Developer may report the need to re-factor more than average during stand ups. And so on.
Now we had identified some behaviours we might observe and we had explored how these behaviours might manifest in a team.
You can’t fix something until you have observed that it is actually broken – many eager Coaches and Scrum Masters jump this particular gun. See my post on ‘please don’t rescue me!’
We were ready to approach the final part of this section on People.
For each of the behaviours we had identified ( 2 or 3 examples for each type of team member) we looked at how we could coach and enable those people to better contribute to the team as a whole. How could their ‘types’ be turned from disruptive behaviour to a strength for the team?
It is important that differences between people peoples differences are celebrated in a team – a beautiful team is not made up of cookie-cutter superstars.
To illustrate by using our current example, a Perfectionist could be encouraged to view the Definition of Done as their target of what to finish ‘perfectly’. This helps them feel true to themselves, whilst keeping things efficient for the team and the rest of the business. Coaching is vital as you will need the team member’s co-operation with this – we aren’t manipulating or dictating, but rather trying to shine a light down a different path for the team member in question.
The second section of the workshop, began by listing some of the practices we particularly value at NewVoiceMedia.
Pair working, test driven development, Definition of Done and many more were quickly brainstormed, however, I also wanted to draw attention to other practices too.
Respect, sharing the pain, willingness to fail, and collaboration are a different sort of practice, but no less valuable.
We then posed each of these questions and we discussed them.
- Why do we think some companies feel the need to mandate practices?
- Are practices important in their own right or are they merely tools to help us form good habits?
- Is there any benefit cost to tolerating mavericks who choose not to adhere to a practice we value?
- Is scaling easier if we share common practices?
- Should we respect our team members enough to set their own practices? This was particularly interesting question after we had discussed the value and cost of mavericks.
Finally we moved on to look at practices through the lenses of our People Personality Types.
What would happen to a team if we allowed each of our People Personality Types to optimise the team’s practices to their own preference? What kinds of practices would we see?
Ultimately, do we think their team as a whole would be able to still improve? Does their ‘type’ blind them to this revelation to some degree?
This section was really important for looking at how our responsibilities as a scrum master dove-tail in with our obligations for enabling the team. We reminded ourselves that ‘team’ as a whole is not the same here as the collection of individuals that make it up.
We time-boxed the open-ended discussions above to around 20 minutes for the whole section. This discussion otherwise could have gone on for quite a while!
Melisa started our final section with an anecdote of her time in the best team she ever worked in, which was a start up company. Many of the key indicators we imagined for a great team environment were absent in her story . They worked horrendous 80 hour weeks, sleeping in the office, and they didn’t know if they would be paid each month (often they weren’t). Clearly this wasn’t sustainable long term, but it was the most enjoyable team she ever worked in. This is because they were united as a team towards a single, clear & common purpose.
We reviewed our initial thoughts about good & bad teams we had experienced before and saw lots of correlation.
We then reminded everyone of one particular ambition of our current CEO (to be a $1B company). Its a great example of a clear and common goal as everyone in the company knows of it. We discovered that although we were all very committed to this goal, it was too remote from our day to day work for us to say for example: which of these 2 stories brings us closer to that goal, fastest?
So what makes our teams get up in the morning? Is it the sprint goal? Probably not, this is too short-term. We felt it could be some element of the Product Owners vision though. In the case of one team, it was a very definite objective to shortening feedback loops. One thing was clear though: it had to be medium term (longer than 2 weeks, shorter than a year) and it had to be binary. If you couldn’t say “yes” it was achieved without referring to a list of acceptance criteria, it wasn’t binary!
From here, uniting the team behind it as a common purpose is simply a case of testing all work through that lens. Will delivering this story next move us closer to our purpose? Yes or No? Will delivering this sprint move us closer towards our common purpose? Yes or no?
In the end, this last section was widely regarded as the toughest section by a long way.
All workshops should end with actions, or people leave and forget 2/3 of everything they just learned. At the same time ‘homework’ is never received well ;). This time we did send our attendees away with some suggestions for ways they could practice using these ideas. We also arranged to meetup and talk through learnings and experiences in an informal way in a couple of months time.
Building a beautiful team is about recognising and rejoicing in the differences between the team members, and about utilising people’s strengths, whilst minimising the conflicts that occur between differing personality types.
Building a beautiful team is about having clear understanding of the practices used, and the constraints in which the team functions, as well as an appreciation that teams exist within a wider organisational system, and that local optimisation may in fact not be optimal.
Building a beautiful team is about more than doing the right thing, its about having the great motivation to do the right thing, and a clear line of sight to your next goal on the horizon to tell you when to do it and why it is important.