In this episode of the Cherryleaf Podcast, we look at the value of retrospectives at the end of a documentation project, and how you can run one.
Transcript
This is the Cherryleaf podcast.
Hello and welcome to the Cherryleaf Podcast. We’re going to look at retrospectives in this episode.
Although within a documentation project there can be a number of stages where you will get feedback from people on the content that you write.
It’s often the case that there’s not an opportunity to reflect and to discuss overall how well the project went.
Now, one approach to having that opportunity is to organise a retrospective and in this episode what I’d like to do is talk about the ways in which a retrospective can be carried out. Thre are retrospectives are part of the approaches that are often done.
Within development teams that are working within an agile environment.
And as you can run the coding elements of a project using agile methodologies, so it’s possible to do the same thing for the documentation production.
So retrospective is generally a meeting where people can provide constructive feedback to improve the ways of working and to help.
It provides knowledge that can be useful in defining future deliverables.
And the idea is that you get feedback from different people who have a say or interest in the project and you capture that feedback and the things that you can learn from that by using notes.
Summarise the information from all the different parties and then have a set of action points and knowledge for the future that you can share with others who might be involved in the creation of technical documentation.
Well, generally it’s done as a workshop. It can be done face to face, or it can be done as a virtual meeting and it involves the participants, the people who have been involved with the documentation.
So the people that have been creating it. And also people that are using it or are the project managers responsible for that content.
And often it is done virtually with a virtual whiteboard as a way of capturing the knowledge and conversations that happen.
And there are different platforms that you can use to do that, one of which is a platform called mural, for example. And often you can get this done within one session within about 90 minutes.
We have one client who has a template for doing retrospectives.
And so when it comes to having the retrospective meeting, you work through the template.
And this means that there are some predefined sections that you go through and at the end you summarise the findings to work out the most important information.
So the way that it works or can work is that you have a section that’s called what we did well or what’s added.
And so what you can do is you can allocate maybe four or five minutes for people to write down on the virtual sticky notes that are on the whiteboard.
Or that you can create in the whiteboard application
And you write down all the different things that you think went well or where the documentation, parts of the documentation, have added value.
So there’s often guidance that says things like “based on how this past iteration went, capture your summary, ideas, processes, or tasks about the things that added value”.
And so having all participants in the workshop or in the retrospective write down those thoughts.
What you then do is you ask them to talk about what they wrote, what notes they created.
Often participants come up with the same thought, and what you can do with a virtual whiteboard like this is you can take the sticky notes, these virtual sticky notes, and move them around the board.
So you can group them together. Things that are about the same theme, the same idea.
Having spent a session on what went well, the next thing to do is to do a session on what we, as a team, could have done better.
What didn’t add value.
And again, the guidance is often based on the sprint or the past iteration.
You should capture again in brief the ideas, processes, or work that didn’t add value.
So if the way of working wasn’t very good.
If there are problems and having to rewrite content or get information or get feedback, then this is the place, opportunity, where you can describe that.
And again you can spend 4 to 5 minutes on writing those stickies.
And then after that, each participant can then talk about what they had written down on the sticky notes.
And again you can start to group common shared ideas together.
So when it comes to the more negative stage within this process, it’s important to avoid it becoming a blame game.
And I was reminded of a blog post by Sarah Richards, or Sarah Winters as she now is ,who used to head up the gov.uk content team.
And what she said was there was a poster that used to be up at the Government Digital Service that said Rules of the retrospective: Everyone did the best job they could with the information they had at the time.
People do the best that they can.
And she also recommended, when constructively criticising, we need to remember there’s a human on the other end of our comments, and they’re probably not trying to get it wrong just to annoy us.
In addition to the stages of looking at what it was added value and what didn’t add value, the third stage is about new ideas or areas where you think the process or the deliverables could be improved.
So what are the new and improved ideas that we can suggest?
And again you spend 4 to 5 minutes going through writing down your thoughts on these virtual sticky notes.
And when that session is finished, each participant in the workshop again explains what they wrote down provides more information and those ideas if they’re shared with others, can be start to be grouped together.
One client, in their template, has what they call the retrospective radar.
And the idea is that having completed the three stages that we’ve just discussed what the team agrees to do is to drag any sticky notes which can be actionable into one of the what they call the areas of focus on the retrospective radar diagram.
So the retrospective radar diagram has segments bit like a pie.
And those are
• Keep doing.
• More of.
• Start doing.
• Stop doing.
• Less off.
So what would you drag into the more of section?
Well, these are the ideas that practise is the activities that have proven to be successful. Those are the things that you want to expand on to do more of to scale up.
And there may also be strategies and tactics that aren’t currently being taken full advantage of, at the moment.
In the less of segments, that’s where you put ideas or activities or areas of efforts that are already being done, but probably need refining, because they’re not at the moment helpful or productive.
So that might be an activity. It might be a behaviour. It might be routine that isn’t efficient or value adding at the moment.
In the start doing section, this is where you put the new ideas or something learned from the activities that you carried out.
Now, one of the recommendations that the template that was used, or the whiteboard that was used, the virtual whiteboard that was used with this particular client, was that any suggestions would then go through a testing process to actually verify that they, if implemented, would improve.
In stop doing section, this is where you put the notes that describe the activities that didn’t or aren’t bringing value, or perhaps are getting in the way.
These are the things that we really want to focus on to get rid of, to change or eliminate, because they’re just not effective.
And the final segment is the keep doing section.
These are the activities that are really adding value that the team enjoys doing and are worth repeating in the next project that you carry out.
In effect, this means that the notes that were created during the process of asking what added value will, in most cases, be dragged across onto the radar diagram into the sections that are The keep doing more of or start doing sections.
And the notes that were created during the what did not add value activity, those are the ones that will probably be dragged across to the less of or stop doing sections of the diagram.
In addition to the segments, the radar diagram also has rings or circles.
Typically these rings are called the rings of control, influence and concern, and this is an idea from Stephen Covey.
So in the centre circle, this is where you place actionable steps that you can do without anyone’s approval.
The second circle is where you place actions you want your immediate boss to influence or approve on your behalf.
And then the outer circle is where you would place the items activities which need action for either helpful new ideas or removing impediments.
Where you would require sponsorship executive sponsorship for those to actually happen.
And the idea is that you assign different members to act or to take on board or be responsible for those things to happen, and for the ones where they need external approval that there are requests made from the team members to those relevant people for those actions to happen.
So the virtual whiteboard can work as a reference point of what you learned and how you want to improve for the future.
But another approach is to back that up by writing a short report. And that can be a PowerPoint presentation, or it can be a Word document.
And then in the document, typically what you would do is map to the activities, the headings within the document and those are often the lessons learned.
It’s notes that you captured during this, which we talked about these sticky notes, the next steps and solutions that we recommend. The actions that should be taken, and who’s responsible for enacting those actions.
And other stakeholders who might be involved and in terms of the content itself.
Typically the focus is on,for all of those actions, the lessons learned, next steps, actions and so on.
Looking at those with regard to the content, the product itself, the ways of working, the user journey, and any other items that might be relevant.
One of the advantages of using a virtual tool on these platforms that are out there is that they offer ready-made templates for all manner of different me.
And so what you’re able to do is often use one that’s off the shelf that’s available from the provider of the software and use that as the structure in the framework for your retrospective.
We found retrospectives to be quite a useful approach.
Now it does rely on honest, constructive, criticism.
It does rely on talking about the process and the deliverables, rather than necessarily focusing on people, and ending up as individual criticism or criticism of individuals.
And it often relies on people not getting too defensive and trying to justify or be defensive about the way in which they did something.
It can help foster a team-based approach between the team that is providing the technical writing and the development team or the customer that is creating the product related to the content that’s being created.
And one of the beauties of this approach is because it’s an approach that is used within the agile environment, is that, if you’re not familiar with retrospectives, there’s a fair chance you can find somebody who is experienced at doing this.
And you can ask them if they would be willing to be the facilitator for the meeting, to help guide the participants in providing the right answers, and following the steps in the appropriate way.
And as I said, these meetings are these retrospectives, the meetings themselves, can typically take an hour to 90 minutes, so it’s not a huge commitment. I=if you ask somebody to facilitate that.
So what are the common types of action steps and results from doing this type of exercise? In our experience, what we found is there’s often very positive feedback about the technical writing team in terms of their flexibility in terms of the quality of the outputs that they poduce.
And that’s lovely to hear another.
One result of doing this is considerations of the way in which the content was created. The operations side of things. And a recognition that perhaps the content wasn’t available for the technical writers to use the source content at the right time that they were delays in reviewing.
Or there might have been issues with the authoring tool.
And that there is a need to focus resource on fixing those operational-type elements to the writing process.
There’s not much more to say about retrospectives, really.
The best thing to do is give it a go or have a look at some of the templates and reflect on what content your questions are asking.
If you have experience of participating in a retrospective for documentation, or if you do it in a different way, then you’re more than welcome to share your knowledge, your thoughts with us. You can contact us.
E-mail info@cherryleaf.com
If you’d like to know more about Cherryleaf for the technical writing services that we provide, the training courses that we run.
Then have a look at our website its cherryleaf.com. Otherwise, thank you for listening. There’s unlikely to be a podcast next month due to it being the holiday season, so we look forward to speaking to you after that break.
Leave a Reply