--- title: "Podcast 126: Retrospectives for documentation projects" id: "16325" type: "post" slug: "podcast-126-retrospectives-for-documentation-projects" published_at: "2022-07-11T10:00:02+00:00" modified_at: "2022-07-08T13:52:51+00:00" url: "https://www.cherryleaf.com/2022/07/podcast-126-retrospectives-for-documentation-projects/" markdown_url: "https://www.cherryleaf.com/2022/07/podcast-126-retrospectives-for-documentation-projects.md" excerpt: "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...." taxonomy_category: - "management" - "podcast" --- 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. ### Share this: - [Share on Facebook (Opens in new window) Facebook](https://www.cherryleaf.com/2022/07/podcast-126-retrospectives-for-documentation-projects/?share=facebook) - [Share on LinkedIn (Opens in new window) LinkedIn](https://www.cherryleaf.com/2022/07/podcast-126-retrospectives-for-documentation-projects/?share=linkedin) - [Share on WhatsApp (Opens in new window) WhatsApp](https://www.cherryleaf.com/2022/07/podcast-126-retrospectives-for-documentation-projects/?share=jetpack-whatsapp) - [Share on Bluesky (Opens in new window) Bluesky](https://www.cherryleaf.com/2022/07/podcast-126-retrospectives-for-documentation-projects/?share=bluesky) - ### *Related* ### Leave a Reply[Cancel reply](/2022/07/podcast-126-retrospectives-for-documentation-projects/#respond) This site uses Akismet to reduce spam. [Learn how your comment data is processed.](https://akismet.com/privacy/) #### Previous post [Podcast 125: Who we, and others, are hiring](https://www.cherryleaf.com/2022/06/podcast-125-who-we-and-others-are-hiring/) #### Next post [The Teachable platform we use for our elearning courses is down at the moment](https://www.cherryleaf.com/2022/08/the-teachable-platform-we-use-for-our-elearning-courses-is-down-at-the-moment/) #### Browse posts by month Browse posts by month Select Month October 2026 (1) September 2026 (12) August 2026 (8) July 2026 (7) June 2026 (14) May 2026 (8) April 2026 (6) March 2026 (14) February 2026 (9) January 2026 (9) December 2025 (7) November 2025 (9) October 2025 (10) September 2025 (7) August 2025 (6) July 2025 (1) June 2025 (3) May 2025 (2) April 2025 (5) March 2025 (3) February 2025 (3) January 2025 (2) November 2024 (8) October 2024 (3) September 2024 (2) August 2024 (3) July 2024 (4) June 2024 (1) May 2024 (2) April 2024 (4) March 2024 (1) February 2024 (2) January 2024 (1) December 2023 (2) November 2023 (9) October 2023 (8) September 2023 (5) August 2023 (3) July 2023 (1) June 2023 (1) May 2023 (2) April 2023 (3) March 2023 (2) January 2023 (2) December 2022 (4) November 2022 (1) October 2022 (1) September 2022 (1) August 2022 (1) July 2022 (1) June 2022 (1) May 2022 (2) April 2022 (1) March 2022 (1) February 2022 (1) January 2022 (2) December 2021 (1) November 2021 (2) October 2021 (1) August 2021 (1) July 2021 (2) June 2021 (3) May 2021 (5) April 2021 (3) March 2021 (3) February 2021 (1) January 2021 (2) December 2020 (4) November 2020 (4) August 2020 (3) February 2020 (3) January 2020 (1) November 2019 (3) October 2019 (1) September 2019 (1) August 2019 (3) July 2019 (2) June 2019 (3) May 2019 (4) April 2019 (1) November 2018 (2) October 2018 (1) July 2018 (2) June 2018 (4) May 2018 (2) April 2018 (3) March 2018 (4) February 2018 (2) January 2018 (3) December 2017 (2) October 2017 (3) September 2017 (1) August 2017 (3) July 2017 (2) June 2017 (7) May 2017 (4) April 2017 (5) March 2017 (1) February 2017 (7) January 2017 (1) December 2016 (3) November 2016 (4) October 2016 (1) September 2016 (5) July 2016 (1) June 2016 (3) May 2016 (1) April 2016 (2) February 2016 (2) January 2016 (5) December 2015 (1) November 2015 (4) October 2015 (2) August 2015 (1) July 2015 (1) June 2015 (2) May 2015 (3) February 2015 (2) January 2015 (6) December 2014 (1) October 2014 (1) September 2014 (4) June 2014 (4) May 2014 (1) April 2014 (2) March 2014 (3) February 2014 (4) January 2014 (4) November 2013 (2) October 2013 (5) September 2013 (3) July 2013 (3) June 2013 (11) May 2013 (4) April 2013 (6) March 2013 (7) February 2013 (4) January 2013 (4) December 2012 (9) November 2012 (23) October 2012 (14) September 2012 (8) August 2012 (4) July 2012 (12) June 2012 (12) May 2012 (10) April 2012 (8) March 2012 (12) February 2012 (3) January 2012 (6) December 2011 (2) October 2011 (3) August 2011 (1) June 2011 (5) May 2011 (2) April 2011 (1) January 2011 (1) December 2010 (1) November 2010 (3) October 2010 (4) September 2010 (8) August 2010 (5) May 2010 (2) April 2010 (3) March 2010 (3) February 2010 (2) January 2010 (3) December 2009 (2) November 2009 (6) September 2009 (1) July 2009 (6) June 2009 (7) April 2009 (8) March 2009 (3) February 2009 (3) January 2009 (3) December 2008 (1) November 2008 (3) October 2008 (3) September 2008 (4) August 2008 (1) July 2008 (3) June 2008 (5) May 2008 (2) April 2008 (2) March 2008 (3) February 2008 (2) January 2008 (1) November 2007 (3) October 2007 (2) September 2007 (1) July 2007 (3) November 2006 (1) October 2006 (2) September 2006 (3) August 2006 (1) April 2006 (1) March 2006 (3) #### Browse posts by category