A few people here at the Lean Software & Systems Conference have asked me to write more about using the Dreyfus Model to game culture.
I’ve already written quite a bit about the Dreyfus Model – how to use it to create experts, grow teams, etc. – but this is more of an experience report.
I was working with a number of other coaches to transform a small IT organisation. We were asked to come up with some strategies for spreading the adopton happening in a couple of teams. When we presented our options, the head of IT went with one of the faster ones: giving us an afternoon every 2 weeks to play a game with the developers.
We assigned developers and testers to teams made up of people they hadn’t worked with before, one tester to two developers. Then we gave each team the requirements for the Game of Life – just the basics:
- Cells with less than two neighbours die
- Cells with more than three neighbours die
- Cells with exactly three neighbours are born in empty spaces.
We gave them 15 points for developing these rules, and also scored them according to the cultural values we saw, taken from Kent Beck’s XP books:
- Respect
- Communication
- Courage
- Simplicity
- Feedback
We were already using Dreyfus models with numeric values to help individuals move forward. We adapted these for the game:
- Novice: team exhibit antipatterns
- Experienced Beginner: team are human
- Practitioner: team are behaving like successful Agile team members
- Knowledgeable Practitioner: team behaviour influences others
- Expert: superhuman.
By the end of the game I don’t remember that we had any 2s left, let alone 1s, and one team were exhibiting 4s. Here’s what we did.
How we did the marking
The 5 coaches got together at the end of every session to share their notes – what we had seen, how the teams had behaved, what points we thought they should have. If we hadn’t seen anything particular, we gave them a 2 – ordinary human beings.
Whenever a team exhibited particular antipatterns (1) or particularly excellent behaviour (3-4), we gave them feedback as to why. We also only ever marked whole teams. If a particular member of the team was showing anti-patterns, it was the whole team’s responsibility to help them adopt a better culture.
We also held a clinic in which team members could ask for clarification, or advice about how to improve their score the next week.
An example of marking
On the first day, one team named themselves “Team Buttplug”. The coaches had spent a while putting the game together – coding a UI for the teams to use, setting up version control, etc. – and we felt that this wasn’t very respectful of our efforts. So we gave the team a 1.
The next week, the team renamed themselves “Team Redemption”, and scored a 3. We appreciated their turnaround!
The stories
After the first week, we added more stories, which made the software progressively more complex. The testers started having plenty to do!
The stories we added were:
- The grid can now switch from bounded (no cells outside it) to infinite (gliders run off the edge).
- The grid can switch from any other to wrapped (gliders return on the other side).
- The cells change colour depending on how old they are.
- The cells change size depending on how many neighbours they have.
- The rules can change from Conway’s rules to High Life (cells are also born when they have 6 neighbours).
- Users can step backwards.
- Users can scroll around infinite or wrapped grids using a joystick.
Gaming the culture
The teams quickly worked out that behaving according to the culture was an easier way to get points than developing the increasingly complex software.
“What will you do if we just pretend to be courageous?” one developer asked.
“How will you do that?”
“Well, we’ll just pick up things we’ve never done before. Or we could pretend to communicate; just get a whiteboard and talk about what we’re doing and draw on it.”
“Sure, we’ll give you the points if we can’t tell the difference…”
Of course, these cultural values are really hard to game without actually adopting them. Teams pretending to communicate better actually were communicating better. Teams exhibiting respect engendered respect around them. The culture of all the teams gradually improved. People started to be more forgiving; to provide feedback to us as well as to each other; to treat each other with respect and collaborate more and more effectively.
The end-game
On the last afternoon, two teams from the 8 we had were almost neck and neck. There was 1 point in it. One of them had developed more of the software – they had a particularly heroic developer who did much of the work.
The other team had started off poorly. They weren’t the best at development. However, they were using their tester very effectively, talking to us and clarifying the requirements, discussing their design on the whiteboard… and slowly overtaking the first team.
They won by 1 point. Thoroughly deserved.
All the teams who participated were amazing, but most of all I remember the head of IT who let us run the game in the first place. That commitment to learning really helped the teams understand the importance of what they were doing.
Swanky prizes helped, of course!
Liz, great work and thanks for sharing this.
About the suspicious team name… In my experience, when teams (especially of all men) are comfortable and having fun, this is exactly the kind of name that they pick. Of course there may have been other clues about their mindset, but I wouldn’t read into the name alone, since it may actually have indicated a willingness to own the process in their unique way.
Sean
Having worked on teams with equally *cough* disrespectful names, I know it wasn’t serious. It was useful to call out an example of opportunities to be respectful that were being missed, though. They were a great team, and we all had a lot of fun.