On most software projects, there is a far higher percentage of developers on a team than any other role. In general, this works to the team’s advantage. The developers, after all, are the ones who make what everybody else works for come alive.
In a retrospective, however, it is important that no one group of team members is favored over others. This is harder than it may seem, especially when the developers make up more than half of the team.
The way most retrospectives I’ve been a part of have worked is some variation of the following:
- Individuals think of a few things that have gone well, and a few things that have gone less well over the past set time period
- These thoughts are put on post-it notes, then placed on a wall
- Individuals read all the thoughts and vote for the ones that they agree with (each person has a limited set of votes)
- The retrospective facilitator tallies the votes and discusses the highest vote-getters with the team, and discusses ways to fix problems and continue successes
Now, as you can tell this is a quite democratic process. The problem is, when the ratio of developers to business analysts is 4:1, you start to see the topics discussed err towards the technical. If you’re lucky, you have a facilitator who realizes this and steers the conversation in a direction that helps the entire team, not just the developers.
Moral of the story: Make sure you’re paying attention to the distribution of people on your teams, and the topics that are covered in your retrospectives. Sure, the idea is to make software, but the process is only going to improve if the entire team is learning from their steps and missteps.
6 responses to “Agile anti-pattern: Developer-focused retrospectives”
[…] Another reason to have frequent retrospectives By Kerry Josh Evnin writes in Agile anti-pattern: Developer-focused retrospectives: In a retrospective, however, it is important that no one group of team members is favored over others. This is harder than it may seem, especially when the developers make up more than half of the team. […]
This is a test
I hear you.
I think any new professional HCI/d-er is going to be constantly put in situations like what you describe, where the perspectives for which we advocate are not going to have a voice in the conversation without us being assertive and effective. My guess is that you are better at that communication with each meeting.
My short experience as a user experience guy in a room filled with programmers is that they are very used to quickly focusing on what they can do for this week. There isn’t an unwillingness to explore ideas, but there is pressure (and a personal need, I think) to have those crazy design ideas translate into something tangible that has business value. Unless one works in a design research firm that doesn’t need to implement, or doesn’t have a bottom line to follow, this will always be the dynamic.
The culture changes only when the seemingly slower, crazy design approach yields better results. Patience is a rare commodity.
I’d like to experiment with value stream focused retrospectives. Hopefully the focus would then be on what is most important for the overall system irrespective of how many people identify with any particular role.
I agree that it’s an unfortunate consequence, but don’t agree that it’s an anti-pattern.
I’m thinking this for a couple of different reasons…
To start with, I think that the voting will show what the team feels is the highest priority item. I don’t think that a team should focus on roles at this point; we are all simply team members (not analysts, not designers, not developers). If a particular thought doesn’t receive more votes than another item, that’s simply a statement by the team that they don’t think that it’s as important as other alternatives. The point of the retrospective is to focus on the team (not individual roles).
The second thing that stands out is that if you are repeatedly being out-voted, you need to help the other team members see the value in the items that you are trying to fix. If others see the value and believe in the thought, they will vote for it and it will be addressed. In the situation that you describe above, I would focus on effectively communicating what the thought is and why it’s important.
The third point is that I don’t think that it should be in the power of the facilitator to trump the decisions of the team (which they decide by voting) if they think that other items are higher in priority. I believe that swaying votes, voting, or changing the teams decision are all bad things for facilitators to do during any type of session. The role of the facilitator should be to facilitate the meeting, not to participate in the outcome or take sides.
The last thing (and likely the most relevant) is that I think that the real anti-pattern is in relying in the retrospective to be the only place where issues, concerns, smells, etc. can be addressed. Retrospectives are great, but they shouldn’t be the only opportunity to address items. If you are passionate enough about something, you should focus on fixing it as soon as possible.
If all else fails and you are passionate about getting something changed, you can often start to address the items yourself. Forgiveness over permission can be powerful in extreme cases 🙂
very interesting, but I don’t agree with you
Idetrorce