Here at Emerge, we run agile-style retrospectives for agile development sprints as well as client projects.  We believe agile retrospectives are a powerful tool towards improving outcomes, team performance and team happiness.  This is not, however, another article about retrospectives.  This article explores a means to take consistent, detailed note-taking throughout projects in order to promote more effective retrospectives.

Team feedback is crucial to running effective retrospectives that yield meaningful improvements.  Our team members have shared that on long-running sprints or projects, a substantial amount of the useful feedback during the course of the project/sprint work is forgotten by the time the retrospective meeting occurs.  Ideas, comments, concerns, that are borne of the moment, which are not recorded in that moment, are subsequently difficult to recall come retrospective time.  While a short period of reflection after the project/sprint has completed can be helpful to step back and identify the larger trends and holistic problems, the detailed, in-the-moment feedback is equally valuable.  This type of feedback can provide particularly useful data points for collectively identifying larger issues.  

Generally, I prefer more data to draw conclusions or make decisions.  Suffice it to say I did not feel content losing these insights from the team.  That is the crux of the problem: how can we avoid losing this valuable team insight over the course of the project?

How Can an Agile Process Improve Ongoing Project Retrospective Note Taking?

I was surprised to discover that the collective agile community has yet to create a concise best practice to record ongoing agile retrospective notes.

Left to my own devices, the most obvious and easiest solution was simply better personal note taking.  Every team member should employ their personal method for recording their individual notes to be referenced during the retrospective process. I attempted to implement this process myself.  Despite the fact it seemed an easy solution, the results at capturing this real-time feedback over long-running sprints/projects were not as good as I’d hoped.  At the outset of each project, I’d start well, but as time progressed, my note taking would tail off.  Consequently, at retrospective time, I’d still struggle to recall all of the feedback I had accumulated.  The feeling of missing data points still lingered.

While the trial period with manual note taking didn’t bring much improvement in my retrospective note taking, I wasn’t quite ready to give up.  The experience of trying to manually take these notes gave me an idea of what to try next.  One friction point for me with the manual note taking process was that despite it being easy, it took me out of my primary workflow and toolset.  It was yet another application open on my desktop.  It would be better to leverage a tool I already use every day on project work.

With this in mind, I took a look at the toolset common to all our projects, hoping to find some candidates to build on top of.  Two quickly stood out: Slack and Confluence.  Both of these are tools that most, if not all, members of our project teams use on a daily basis.  Furthermore, they seemed well suited for the purpose of recording notes; both in terms of their respective roles and responsibilities, and because they offer accessible APIs for extensibility.  Time to design a custom solution!

Solution: Slack Retrospective Note Taker

With my goal in mind to implement an easy way to record agile retrospective notes in real time, and some software to leverage (Slack, Confluence), I set out to create a custom solution (this means bespoke software, which we do here at Emerge). 

Firstly, users need an easy way to record these notes as they occur over the course of a project.  Slack seemed perfect for this.  Our team members use Slack habitually, I would not be introducing a new tool or step to their workflow to capture these temporal notes.  Moreover, Slack has a fairly straightforward and well-documented API to create custom commands, known as “slash commands,” giving me a strong option for implementation.  The slash command needs a service to communicate with, meaning we’d have to build a simple, but custom, API and put it up on the web.  

Next, I needed a durable place to record these ongoing notes.  Ideally, a spot the project team and the person who ultimately facilitates the retrospective can easily access.  It’d also be nice to enforce some structure on how these comments are recorded to make them easier to understand after a variable amount of time has passed.  Since Confluence is the starting point to access all project information for our teams at Emerge, this seemed like a natural home for these notes.  Furthermore, like Slack, Confluence also offers a well-documented API for writing data to a page.

So the proposed workflow went like this:

From there, things were pretty simple to build out.  The custom API was fairly easy to design and develop as both Slack and Confluence had done a good job documenting the specs for the functionalities I needed.  

One new requirement did emerge during implementation: the need for an admin interface to manage which Confluence page a Slack channel will write to.  It may help to expound on this.  At Emerge, we use discrete slack channels for projects.  The custom API we wrote needed a way to understand what specific Confluence page a particular Slack channel should write to.  So we added a quick and dirty web interface to manage these mappings.

The final solution architecture looked like this:

After some coding, I had a python/Flask web application up on Heroku, ready for a test drive.  

Here’s what the slash command looks like in Slack:

Here’s what saved notes look like on the project page within Confluence:

As a beta test, I set this up for a project I was working on, and introduced it to the team.  My hope was to get feedback on how it worked and catch any bugs before putting it into wider release company-wide.  The test went well.  Upon completion of the project, feedback from the team on this new tool was positive.  They felt it was easy and convenient to use.  We also captured more retrospective notes than usual, my primary metric for success.  The main challenge reported by the team was remembering this tool existed, and using it when feedback occurred to them.  No real surprise there; forming new habits is hard!  Given the uptick in retrospective notes, I felt this pilot successful enough for wider release within our company.

Retrospective

It’s been a year since we put this Slack agile retrospective note taker into use company wide, and in general, we’ve seen a consistent increase in the number of retrospective notes taken when this tool was in use on a project.  Usability feedback is positive.  The main challenge has been training folks to use it consistently, which was not altogether unexpected.  Still, we feel the gains from using this tool are significant enough that we’ll keep it a part of our project workflow.

Since we love self-improvement, and view useful agile retrospectives as a tool for just that, we’ve open-sourced the code for this tool (download it here).  It is by no means perfect, but hopefully you find it useful as is, or as a foundation to build something even better for you and your project teams!  Instructions and further details can be found in the README file, within the code repository.  Don’t be shy if you need some help setting it up.