Last week I had the pleasure of talking with Emily Toner, our Technology Projects Librarian, about how she works with developers in Library Technology Development to conduct ongoing assessment of their work on the Blacklight project. (Blacklight is the software that will be used for the upcoming enhanced version of the Library Search tool, due for general release in June 2018.) In her role as project manager, Emily coordinates between what the developers are working on and what users (librarians, patrons) need and expect in a discovery tool.
The programmers/developers work in an “agile” framework – an approach that incorporates the principles of iterative, flexible development and continuous improvement. The project work is divided into short “sprints” – concentrated effort on a specific feature or collaboration opportunity. The team’s typical sprint lasts 2 weeks. When the sprint is wrapped up, Emily facilitates a “retrospective” session with the team – they reflect together on what is working and what isn’t working so well.
In the world of agile development, there’s a whole tool box of techniques for doing retrospectives. One of the group’s favorites is the “Four L’s”. The exercise was developed by Mary Gorman and Ellen Gottesdiener and works like this: The group asks together of the sprint:
- What did we Like?
- Learn?
- Lack?
- Long For?
The exercise can be done with big sheets of paper mounted on the wall, but since TUL developer David Kinzer works remotely, they do the brainstorming entirely online now. Emily leads the team in a brainstorming session to generate feedback on the positive and negative things that happened during the sprint.
- What was productive during the sprint? This is a LIKE.
- Did we figure out how to resolve a problem, or learn about a new technology? This goes into the LEARNED category.
Likes and Learns serve to highlight the positive – to bolster the energy of the team and to appreciate the good work getting done. It also serves to build the team as a cohesive group.
- But there are also breakdowns in communication, flaws in process, occasional lack of support for developing a certain feature – these are LACKS.
- And finally, LONG FORS – identifying items that are absent from the current project.
In conducting the exercise, team members take time to write down their personal thoughts, then these are exchanged and talked through. As a group, common themes are identified.
The retrospectives serve a couple of purposes: One is to identify which project outcomes were successful and which not. Also, a retrospective provides an opportunity for the team to think about how the team is performing as a team. How is the team communicating? Too much, Too little? Is our work as a team effective? How can we make it better?
And how is this assessment? The process is all about continuous improvement; the principle that we can always reflect on our work and what’s working about it, and what can be improved. And the retrospective serves a practical purpose – putting that reflection into next steps for making the team’s work better and more effective. It’s a kind of process improvement but not just about efficiency, about effectiveness.
Getting in the habit of regular self-reflection on our work – both celebrating the positive and recognizing what is challenging, leads to team building, trust and creative innovation.
Thanks, Emily
For more about the Agile Retrospective process, check out:
- The 4L’s: https://www.retrium.com/resources/techniques/4ls
- Esther Derby and Diana Larsen. Agile Retrospectives: Making Good Teams Great. 2006. Dallas: The Pragmatic Bookshelf