Nothing to talk about on Retrospective, huh?
Discover more from Marcin Konkel's newsletter
Nothing to talk about on Retrospective, huh?
How to tackle an empty mind and get value from a “retro”.
This is an article orginally posted on Medium.com in 2016 now made available to subscribers for free.
Recently, I was asked to observe and feedback a team (actually 3 teams working closely together) on their Scrum events. They were having review, retrospective and planning together on the same day. When it came to the “retro” they did not know what to talk about and, in general, lost around one hour for extended lunch or pre-planning discussions instead of inspecting and adapting. This was another situation where I saw a team stuck in a rut on this particular event and decided to dwell a bit on the subject.
The why
A good retrospective, according to Scrum Guide, should:
Inspect how the last Sprint went with regards to people, relationships, process, and tools;
Identify and order the major items that went well and potential improvements; and,
Create a plan for implementing improvements to the way the Scrum Team does its work.
These meetings, from my experience, are often held with a weekly or bi-weekly frequency. I asked myself why do people, at times, have very few ideas for a solid retrospective. Are we as perfect as we think we are? Nothing special happened during the sprint? We don’t have any major problems, right? Well, the answer came rather quickly.
The reasons for an empty mind during these events I found (with some suggestions from my colleagues) the following:
formula — the same formula used over and over again and / or not addressing certain aspects or needs eg. just throwing ideas out of our heads on the board.
time — not enough time dedicated to stopping and thinking about the last sprint like rushing through retro or not giving enough time for subjects to emerge.
misunderstanding— the purpose of the meeting and scope it covers, not seeing the short- and long-term benefits it can bring.
introvert nature — few people said to me that developers are mostly introverts. I find it hard to discuss without any data and I don’t find the need to label people. On the other hand, what I experienced, was that some people are more fluent in conversations and are more happy to take part in a discussion then others.
lack of trust within the team — some prefer to talk about hard things anonymously rather then on a forum as they do not know how others will react or they have experienced a situation where their problems were not taken seriously.
not learning — not working on action points from last retro; not reviewing them makes it pointless to discuss anything as we don’t know if we succeeded or not.
“blinded” eyesight — as people are in the process they might not see some things (like inefficiencies, problems, unwanted workarounds, lack of SLAs) which they got accustomed to so there is no need to talk about them.
long sprint — people can’t recall the problems that happened due to the amount of things or situations that happened since they last time had a retrospective (or is it just an excuse?).
too many meetings — the team is engaged in various meetings apart from the regular scrum events and does not want to have another one — they just want to code (a paradox as the retrospective is one of the places where you should state that this is a problem).
As you can see there can be quite a bit going on and by no means I regard this list as complete. Understanding the the true reason behind why things are not happening can help you to find the right solution for the problem. Tackling only what is on the surface can demotivate people and make it harder for them to trust you on a next meeting. Try using the 5why’s technique to dig deeper into what’s the issue.
Continuous improvement
I regard retrospective (and other Scrum events) as part of the Continuous Improvement (CI). The concept is connected with Kaizen approach which means kai (“change”) zen (“good”). Various organizations and people understand CI slightly different. According to Wikipedia, it’s:
(…) an ongoing effort to improve products, services, or processes. These efforts can seek “incremental” improvement over time or “breakthrough” improvement all at once.
To me these actions should be leading in some way to increased productivity. I find that some teams misunderstand the concept and think that they are expected to be always better and always tweak their process at least a bit to reach a kind of a “Holy Grail”. Well, this is only partially true.
To my mind, the purpose of improving is rather to adapt to current circumstances and reach the best possible efficiency at the time being. Efficiency (or productivity) in this case I understand as a combination of delivering higher value, improving communication and doing the right work at the right time.
In most cases people concentrate on doing more work because it’s, perhaps, the easiest thing to notice at the end of a working day or a sprint. Doing the right work means doing the things that bring the most value to the Client.
Tackling an empty mind
One of the things that needs addressing in the first place is “the why” which will help you in the long run. Some things are easier to deal with then others. For instance, the formula — think what’s the most important thing to discuss based on your observations or, even better, take it to the team to choose a new formula.
There are various sources of those on the internet and you’ll find them in the “further reading section” of this essay. One can also take care of the action points by establishing the role of a “sheriff” (one of the members, the role rotates after each sprint) that will pay attention for the team to abide by them.
Things that are worth remembering and getting back to from time to time like:
product — How do we know that we are doing the right stuff at the right time (it’s not only a question to the Product Owner)? How are we working with our strategy? Do we have long term goals and vision for the product? What is missing? How can we approach building our product better? How do we measure the value of our product? What should we measure and what we don’t need to measure? What better measures could we use?
architecture — Do we know how to work with building our architecture? Do we have a vision for it? How often do we need to refactor the code? Why in that way? Are we using the right technology for the product we’re doing?
development — How can we deploy more often into production? Do we strive to use continuous integration? What practices that we use have become obsolete? What could we experiment with in the next sprint? How can we share our best practices with others?
process — Does the process that we follow support creating better value for our Clients? If we were to change one thing what would it be? What could be even better? How do things we do fulfil our mission / goal? How do we measure what we are doing and how do we know that the measures we use are the right ones?
stakeholders — How do we know our stakeholders are content with our work? How can we communicate more efficiently with them? How can we gather better feedback from them? How and when should we test our product with end-users?
happiness — What are we proud of as a team? What distinguishes us from others and how should we maintain and develop it? What supports us as individuals and as a team in difficult situations? What is stopping us from being better?
The above are just examples might find useful in your circumstances. Surely, some of them you already got covered and refer to from time to time.
The end
So when does it stop? When do we know it’s the end? As you know there is no end as the world is changing constantly and if we don’t change and adapt we (or our companies or products in that case) die. The journey we undertake, on the other hand, is important and has it’s milestones. Those represent the end of something and a new beginning. We should review this journey to appreciate ourselves and learn on the choices we made.
Looking forward all the time let’s you miss on here and now and not appreciating what you achieved might not help you grow.
—
Further reading / links:
Retrospective on Steroids with Toyota Kata
Tasty Cupcakes — various retrospective ideas
Getting Value out of Agile Retrospectives — a toolbox of retrospective exercises
PS. I love working with creative people 👇🏼
—
🎈Share this post if you think it can help others making better use of their retrospectives.