Full-Project Retrospective
Audience
Members of an agile team; in this case, everyone who participated on an 18-month project effort, but not including the client. (2014)
Team
I was not a member of the team for this, I was acting as moderator and facilitator of the discussion as a ‘neutral party.’
Challenge
Small software consultancies survive on being efficient: satisfying clients’ needs without wasted effort. As well, they must keep their employees satisfied with the work they are being asked to do. The retrospective is an important tool to make the development process efficient and enjoyable.
techniques & tools
The whiteboard and the power of good questions.
outcome
Learning from what went well, who made strong contributions and also by examining mistakes and opportunities to do better is what a retrospective is all about.
What Happened Here?
I was asked by the team and management to lead the full-project retrospective of approximately 18 months of effort. This had been a long project. Patience had been tested and at times tempers had flared; people had burned out and left the project. We needed to understand ‘why’ in a deeper way than just saying ‘it was a tough project.’
Participants included UX leads for the project, developers, salespeople and project management. Note that the client was not included in this meeting. Because I was relatively new to the company and had not been a participant in the project, I was asked to facilitate a half-day full project retrospective: asking questions, moderating discussion, probing for more information and—this is where the real power is—holding the pen!
The Concept
I firmly believe in the concept of the agile retrospective: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” Principles behind the Agile Manifesto Although a retrospective covering multiple months is not the ideal, there are still principles which apply for any good retrospective.
- Getting everyone to speak is very important. When possible I like to go around the room getting every person to give their answer to a question before letting any one individual dominate the discussion. This is particularly effective in the context of asking “what went wrong/what went well:” everyone contributes short answers before selecting a few of them for deeper conversation.
- Keeping it ‘safe.’ Should there be any kind of harmful friction between individuals, try to focus on roles: instead of “Bob didn’t give feedback soon enough” frame this as “Quality Assurance didn’t respond quickly.” At the same time, when there is positive feedback, attach an individual’s name to it if appropriate.
- Work to build trust, but realize that trust is not given, it is earned. This is easier for smaller teams when they meet to reflect more often. And related, conflict is not always bad. Accepting conflict is tough for me, but if I’m having trouble with it I reframe it in my mind as ‘dynamic tension.’ (And no, I don’t mean going camping and doing “trust falls.”)
- Find a limited number of things to focus on and actively generate ideas for improvement. Changing a work process after every sprint is challenging, so don’t try to change too much. But don’t leave a retrospective without some kind of agreement on what new idea we will try during the next sprint.
- Also don’t forget to celebrate what is working well, especially if it is something which was a new idea from the previous retrospective.
The Power of the Pen
The whiteboard captured in the attached image is from near the end of the meeting—which lasted several hours—and the colors of marker are significant: blue represents facts or events (in a loose timeline), orange represents some of the “feelings” or concerns over facts or events, and the sticky notes represent callouts for individuals who had made helpful contributions at some point (we were trying to avoid blame of individuals at this point in the discussion).
I’ll be absolutely honest with you about including this example in my portfolio: I don’t remember much about the outcome of this meeting—it was a long time ago. I have included it here because one of the things I really enjoyed about my time as an agile coach was leading retrospectives (or helping others to lead them). Being able to coax out nuances about how we work together and improve our working relationships is important to me. Being asked to lead this particular retrospective, as deep and important as it was, made me feel good about the relationships I had made at the company and the trust people placed in me.