I am a big believer in continuous improvement, weather that be in the form of Retrospectives, a Kaizen approach, or something else that helps the team reflect regularly. But for the earlier years of my career as a Scrum Master I found myself frustrated by a lack of improvement despite all this reflection (retrospectives that have no impact…).
Often,what I was seeing was that we talked about the problems the team was facing, and then didn’t follow-through with the actions we agreed to take.
When we tried to change our behavior. We might have succeeded for a day or two and then would forget about it. This isn’t continuous improvement this is just continuous discussion!
We need a good way to make sure we are actually making the change we set out to make!
Ajeet has come to value 4 specific ways to measure his impact as a Scrum Master. In this episode, we review these 4 benchmarks and how he uses them regularly to improve his approach.
Featured Retrospective Format of the Week: Well/Stop/Start retrospective format
In the Well/Stop/Start retrospective format (see a facilitation guide here), we have a simple format that can trigger important conversations. Especially when team members see each other’s contribution to those 3 categories.
This is a format that suits very well teams that are action-oriented, and have a high degress of collaboration already.
About Ajeet Singh
Ajeet is an IT professional with 17 years of delivery experience in application development, system integration and software testing. He’s served as a ScrumMaster for over 3.5 years for the clients of USA, UK and Australian geographies.
We like to keep our retrospectives fresh. We find it helps to reveal things we might not otherwise have found if we alter the format frequently. With this goal in mind, we follow a simple system:
Once a month we use our ”normal” retro format. Everyone in the team is familiar with this, and we can perform them quite quickly, with minimal prep work and explanation required. Basically, effective with very little admin.
Once a month we have our ”experimental” retrospective. A little more set-up time required, but a good opportunity for experimentation and explorations.
This is the story of one such retrospective.
Obviously, you can perform many Agile practices, but not be Agile. However, there are a lot of practices out there and sometimes teams can become focused solely on those that they are currently using, rather than looking at other tools they might bring to bear. This is where the Agile Practices Retrospective comes in.
In preparation for the retrospective, we created cards with various Agile practices as headlines, and a brief explanation of each listed on it. I also color coded them under various categories so they could be more easily identified from afar. Then we simply taped all these cards to a wall in their respective categories. There were about 50 cards in all.
With over 50 cards, there was a lot of information. We split into groups and started categorizing the cards under a new set of headings, it was made clear to all that they were not expected to read all the cards.
Doing (Working Well): Things we are currently doing, and quite happy with the way they currently work.
Doing (Could be better): Things we are currently practicing but could use improvement.
Not doing (By choice): Things we are not currently practicing, but have made a choice not to use in our context.
Not doing (Not tried): Things we are not doing, and have never really tried.
WTF!?!: We have no idea what this is, or what it means.
Deciding what to focus on
We obviously cannot talk about all these things. So, we used dot voting to decide what topics to focus on. Each team member was given 3 ”dots” for each of these types of vote:
We should start and or alter this practice in some way. (Indicated by a dot)
We would like to learn more about this practice. (Indicated by a +)
I also printed out simple list versions of the same information, as I knew it would be hard for everyone to gather around the board when deciding how to use their votes. Despite this, this was still not as successful as we would have hoped. Part of this is because we are actually two teams and our 3 customer representatives, so the whiteboard was too crowded. I feel this would go better with a single team.
Discussions and action points
We had open discussions and tried to create action points/experiments around the topics we had discussed. I will just give a very brief of what we arrived at:
Root Cause Analysis/ 5 Why’s
We even arrived at the fact that without formal tools, we are still quite good at root cause analysis. But perhaps a formal tool might reveal something we would have otherwise been unaware of.
Experiments: 1)Focus on using our discussion time during retrospectives (Generate Insight) to use more formal tools like 5 why’s.
2) When events are added to our timeline at daily stand-ups, then we should also consider doing a more in-depth analysis of those items.
Discussion: We felt that we very likely do have a product vision, and even a fair amount of impact mapping done for that, but this is not communicated to the entire team at a frequent enough rate. Also, we need to get better at following up these things.
Experiments: 1)Make the product vision more concrete and communicate it at a regular interval.
2)Follow the vision and impact map up at a regular interval.
Behaviour Driven Development (BDD):
Discussion: This is a discussion point we wanted to learn more about. So, the discussion was brief. We basically arrived at the fact that it was intriguing and we want to know more.
Experiments: 1)The two team members who know something on the subject will provide some links and a quick intro for everyone else.
2) Some of the team will experiment with these concepts in our ”Brain Day” next week.
This retrospective was reviewed well by the team, everyone generally liked it.
It was a fairly active retrospective, because of all the moving things around and working in teams, so the energy level remained high throughout.
Probably the best aspect of this retrospective was the addition of fresh concepts into the team, the idea to focus on things we wanted to learn more about was a good one. In the future, we would probably recommend only focusing on these things.
There was a fair amount of prep work involved in this one, although I consider it worth the investment, it wasn’t free. Hopefully, a bit cheaper for you, as we have provided the work we have done. Once again: https://tinyurl.com/l8loec6
It was too hard to get an overview with so many items, this may have been due to team size, and might have been possible to mitigate by having the team read the list beforehand.
Despite there being so many items, the list was not even close to exhaustive, and it was hard to leave off some practices that really should have been included.
Jeff is an Agile Coach who considers the discovery of Agile and Lean to be one of the most defining moments of his life and considers helping others to improve their working life not to simply be a job, but a social responsibility. As an Agile Coach, he has worked with driving Agile transformations in organizations both small and large.
Jeff is also involved in the Agile community and is one of the founding members of Gothenburg Sweden’s largest agile community at 1500+ members , and he also organizes the yearly conference www.brewingagile.org.
When Jeff discovered that Menlo Innovations (from the book Joy, Inc. by Richard Sheridan) was a drive away from his workplace, he got a few people together and started a journey that would change his view of how work should work. He decided that his work as a Scrum Master was about improving lives.
Featured Retrospective format: The Sailboat Retrospective
In the sailboat retrospective we use a metaphor to help the team identify the goal, the obstacles (the rocks), the drags on the team performance (the anchor) and the things that push us forward (sailing wind). Through metaphor we help the team explore ideas that they would otherwise skip in a more structured retrospective.
About Jeff Maleski
Jeff is passionate about working with and building up both individuals and teams using ideas from Jurgen Appelo’s Management 3.0 and Dan Pink’s Drive. When leading project teams, Jeff strives for empirical based planning and forecasting, continuous learning, and delivering high quality software products that exceed expectations. Jeff believes in leading by actions and focusing on building relationships with others.
When we start our roles, we often (and rightly so) focused on the process. How to get people to understand and benefit from the power of Scrum. This focus on process may seem counterproductive because, after all, our success depends on the success of the people around us. But is it? Listen in to learn how Ryan uses his process experience to build trust with the team, which he later on turns into a critical ingredient for his own success as a Scrum Master
Featured Retrospective format for the week: “Proud, thankful, learned”
Ryan breaks the rules once more by introducing, not one, but 2 retrospective formats that empower the team to find, and focus on the most important improvements for them.
The first format is “Proud, thankful, learned”. Three simple headings that help the team focus on, and amplify the positive things that happened during a Sprint. Consider also using this (in a shorter version) as a check-in exercise.
The second format is “Lean Coffee”. A simple way to generate and prioritize possible improvement items.
About Ryan McCann
Ryan is a former waiter, car detailer, line worker, cemetery worker, intern, financial analyst, tech support rep, team lead, QA manager, Scrum Master and Product Owner. Current husband, father, school board member, community volunteer and agile coach. He believes in building trust and social capital, which is not easy for any of us (himself included)…Ryan does his best everyday to help teams make this happen.
One of the Agile principles states that “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” These “meetings” are more likely called Retrospectives and can be held in many different formats (here are some examples https://trello.com/b/40BwQg57/retrospective-techniques-for-coaches-scrum-masters-and-oth er-facilitatorsand http://retrospectivewiki.org/index.php?title=Retrospective_Plans). The most famous is the “Mad, Sad, Glad” format, and many others are just variations of this very basic format.
Read on for the “positive retrospective” format and exercises.
These formats are based on the aim to analyze the previous team’s activities in order to achieve better results. Sometimes, it may also help to analyze the successes of the team in order to understand what helped in achieving them and how to replicate such successes: that’s what I call a “Positive Retrospective”.
The period we may wish to analyze may vary; last iteration, last month, last year and so on. What do we need to organize this retrospective? The usual materials such as some stickers, pens and a whiteboard or a flipchart.
The first action to take is to create a collaborative and positive atmosphere, so ask the attendees to write down some few words of appreciation for a colleague (or more), thanking him/her for something he/she did during the given period, for the person or for the team. Give the team 5 minutes to write.
Then ask each attendee to read aloud what they wrote, speaking to the colleague they want to thank. This phase shouldn’t take more than 5-10 minutes.
The next phase is to list all the positive results achieved in the period.
Ask the attendees to write down on the stickers all the positive results achieved, using a short statement (one per sticker) – they will be given the opportunity to explain in the next phase. Give them 5 minutes to write.
Now ask the attendees to explain the individual positive issues, one by one. They should be concise in their description but still be able to let the other attendees understand the issue. Then the sticker is pinned to the whiteboard. If any other attendee has a similar issue, he/she has to discard it. Please be careful to avoid starting any discussion. This is the time to list the results and not to discuss them (moreover, the discussion will be shaped in a particular way, as we will see in the following stage).
Once everybody has explained their issues (this stage should last no more than 10 minutes), you’ll have all the stickers on the whiteboard. It’s time to vote.
Each attendee will have six votes to give to the issues stuck on the whiteboard: three votes to vote the issues by its intrinsic or technical value (for example, the team reduced the technical debts by 50%, or has stabilized the daily standup) and three votes to vote the issues by the positive impact it had on the product (for example, thanks to this new feature, the customer increased his sales by 20%). You can use any means to vote: in my example, we used little red self-adhesive dots for one and green for the other, but you can use different signs, different colored pens, and so on.
Why differentiate this way? The answer is easy: teams tend to identify their success with the product’s success; we delivered this feature, the customer were happy, we eliminate that bug and so on, forgetting that with success stories, many other aspects must be considered. For example, adopt a more effective framework for the chosen programming language, start unit testing, practice a scrum ceremony in a more efficient way and so on. The team must learn these positive issues as well, as they allow the team to be more effective (as per the above mentioned Agile principle).
Once the voting is finished, just rank the issues by the numbers of votes (any kind).Voting and ranking shouldn’t take more than 5 minutes.
Once the stickers are rearranged on the whiteboard (the most voted ones are on top) you can start to discuss. The format may be free (you can discuss any issue as long as you want), or fixed (an issue can be discussed for a maximum amount of time of 5 or 8 minutes, for example). Choose the format you like, what counts is the discussion itself.
Ok, let’s discuss, but about what? We usually discuss what’s going wrong, and how to fix it. Now, here instead, we’re discussing what went right! Well, we can first identify what made that positive issue possible. Usually, we can identify two main paths: one internal to the team, and one external. The internal one refers to all the actions the team takes to achieve a result, which may impact the team, the process or the product. For example, by autonomously adopting a new programming framework the team was able to deliver those given features and the customer was very happy. Note the word “autonomously”: the team was not forced by any external entity to take that decision, but reached a result that had an external impact anyway.
The external path refers to all those actions taken or conditions set up by the system (your department, your local agency, your company, and so on) that made it possible to achieve that given result. For example, the team was able to learn how to deal with noSQL databases thanks to a dedicated budget for training on new and emerging
technologies/methodologies. In this case, an external reason made it possible to achieve an internal positive result. Nevertheless, we mean to say that an internal result will sooner or later reflect itself into an external positive result (or at least, this is what the system hopes…).
The discussion stage may last up to 50 minutes, to keep the whole retrospective no longer than 2 hours.
And now, just like any Retrospective worthy its name, let’s write down some action points.
Like any positive issue in any field, we aim to replicate it and also do something to improve that experience to feel even better. So we can define the underlying actions that will lead us to even better results. Some questions easily come to mind: can we replicate the positives we had during the period, applying them to current or new issues? For example, we may ask for a new course to learn a new language to create a new software asked by our customers. Or, can we improve the path that led us to have positive results to have better results or even the same results but in different areas? For example, improve the continuous integration process to have a faster/safer deployment of our deliverables.
Or just have more frequent retrospectives to improve our work!
Discussing and writing the Action Points may take up to 20 minutes.
Now the meeting may be closed. See you next Retrospective!
About Enrico Di Cesare
Always interested in improving the quality of the software produced for himself or for his customers, Enrico became an Agile enthusiast as soon as he discovered it. With extensive previous experience as a Project Manager and Coordinator, Enrico works as an Agile Coach, Scrum Master and Product Owner, introducing, mastering, facilitating and refining the adoption of Agile with new collaborative tools.
In this episode Dennis explains the difference between two tools that he uses at the organizations he works with. He explains how he uses these tools to measure System Health and System Productivity.
About Dennis Mansell
Dennis did not start his working life as a developer, but as a sailing yacht skipper and owner of a sailing school and he still trains yacht-racing teams. He always supplemented his sailing job with application maintenance, web development and project management. He has since settled down: based in Amsterdam with his wife and son. Now he works as a full-time Scrum Master and Agile Coach for companies ranging from start-ups to the Dutch governmental institutions. His linkedin and twitter: @dennmans.
In this episode Dmytro describes how the system impacts the teams and the software deliveries. He explains that in order for the teams to deliver a great quality they must be part of a system, which allows them to experiment and develop features without the daily pressure.
About Dmytro Orlyk
Dmytro have an overall 4 years of experience in PM. His latest project has been shown to the Google company. He is an Agile Expert with a strong knowledge of Scrum, Kanban and XP. Few of the engineers that inspire me are Martin Fowler and Chris MacConnell. He can be found in linkedin.
Agile Retrospectives, in Pedro´s opinion, are a great way to help teams to understand how they interact with the company system. They are a great tool to identify dependencies, interactions and even politics.
About Pedro Gustavo Torres
Pedro Gustavo Torres is an Agile Coach @ SONAE, in Porto, Portugal.
He started his agile quest in 2010. He’s a seasoned Scrum Master, Agile Coach and Trainer. He also has experience acting as a Scrum Product Owner. He’s passionate about scrum, agile and all the practices that can help teams deliver early value to their customers. He is also quite techie and a gadgets fan. You can find him in linkedin. He writes his learning’s on his blog. His twitter: @_pedro_torres
Retrospectives are a systems thinking tool that can help you understand how teams are affected by the wider system. Ben explains his views on how to build that into the way you host and facilitate retrospectives.
About About Ben Linders
Ben Linders is an Independent Consultant in Agile, Lean, Quality and Continuous Improvement, based in The Netherlands. Author of Getting Value out of Agile Retrospectives, Waardevolle Agile Retrospectives & What Drives Quality.
You can follow Ben Linders on Twitter, and connect with Ben Linders on LinkedIn.
In case you are interested in Agile Retrospectives we are at the moment preparing a 10 DAYS FREE AGILE RETROSPECTIVES PROGRAM. This is a complete self-study program where you will learn anything that you need to become a great Agile Retrospectives facilitator.