Agile Coaching

Retrospectives: Appreciations & Commiserations

A common technique for retrospectives is to invite Appreciations from the group, which provides an opportunity to acknowledge individual efforts have not gone unnoticed by their teammates. Appreciations are described by starting with the person's name followed by a short description of what they did which you appreciated. When inviting appreciations, I ask the team to write a post-it note for each team member and list one helpful/useful thing that you personally appreciated.

However, sometimes developers can find it uncomfortable to work in postive-mode as they normally prefer problem solving. I think it makes Appreciations easier when you couple them with surfacing some Commiserations. Where a commiseration is "one thing that a person in the team did that you wish could be avoided". 

Inviting the team to call out commiserations is a practical way to connect heroic efforts with areas for potential improvements. You can then use the commiserations as a stepping stone into identfying areas to discuss how they might be avoided in future.

Hierarchy of Developer Needs

At Agile Coach Camp Barcelona, I convened a session on “Hierarchy of Needs” and how this might be used by coaches working with software development teams to understand where to focus their efforts.

The idea of putting needs into a hierarchy was inspired by Maslow even though I’m well aware that the ordering of his model has not been validated by empirical research. However, I'm thinking that perhaps, like Empathy Maps, a hierarchy of needs can be used as a practical tool to tease out factors impacting the team and help figure out what to work on next.

 

Our group started with a simple activity that might easily be adapted for use in team retrospectives. I drew a person-shape on the board and asked our everyone to brainstorm around what developers need to work well. We wrote each need on a sticky note and then I invited the group to sort the sticky notes using a vertical axis from essential(bottom) to optional(top). Here’s what we came up with. 

We found that that many of the essential needs (at the base of the hierarchy) were practical ones such as decent network, version control, and big screens that enable us to write code. Then came the personal needs of puzzles to solve, valuable work, being listened to and trusted. At the top were again more environmental factors, such as whiteboards, snacks, and toys.

In our discussion, we agreed that when working with teams, it's often the essential needs that take a long time to resolve, especially when infrastructure kit is involved. Whereas the needs near the top could potentially be "quick wins". The more personal needs in the mid-section are where coaches tend to focus their attention and perhaps are those requiring coaching skills. We also noted that these issues are more likely to require trust-building between coach and team. See the photo (below) for the full set of notes and some wider perspectives on this.

As a coach you might run a similar activity when starting work with a team - perhaps using different colour notes to show which needs are fully or partially fulfilled and which needs are unmet. Or over time you might build your own checklist of typical needs, to help remember what to look for when observing the team. We also thought that a coach might use this understand and share what your own needs are as a coach and compared with team needs.

When discussing the contentious issue of whether cake should really be at the top of this hierarchy, I was reminded that Kent Beck originally said in “Extreme Programming Explained” that "perhaps the most important job for the coach is the acquisition of toys and food"

Later that same morning Sebastian Schürmann convened a session on Marshall Rosenberg’s Non-Violent Communication and I was interested to hear him reflect at the close that this model might be relevant to the developer needs we discussed earlier. I'd be interested to hear your thoughts on whether this activity is useful.