In this episode, we interview David Horowitz who’s the CEO of Retrium, a company that builds tools to help you facilitate remote retrospectives. The links to Retrium’s Retrospectives Academy below are affiliate links, if you prefer to follow a link that takes you to Retrium’s site, but does not give anything back to the podcast, you can. Just follow this link: Retrium.com. On the other hand, if you want to help us grow this podcast, you can follow the links below or this link to Retrium’s Retrospective’s Academy.
As David started his Scrum Master journey, he was faced with a big challenge. He struggled with remote retrospectives. No wonder, he ended up creating and being the CEO for a remote retrospectives company. He experienced the pain first-hand!
As he got started experimenting, he found the Lean Coffee format to be effective (see our Lean Coffee episodes). However, he found that even when the format worked well, there was something else missing.
The collaboration that can be had when the team is in the same room simply isn’t the same when we are all remote, and sometimes even without video!
In this episode, we explore the role that checklists can have in helping teams improve their process and their performance without adding more processes.
It is a normal tendency to “add more processes” to fix a problem a team is experiencing. In this episode, we challenge that view. Checklists, we argue, are a simple, effective tool that helps you reach a similar goal, but does not require the process to grow, and become bloated.
2 Common types of checklists that help teams improve how they work
There are several types of items we can add to a checklist. In this segment, we discuss 2 common types of checklists, and how they can help teams. We start by discussing the “process checklists”, which may include important tips on how to execute a certain process.
The key thing to remember is that checklists don’t replace processes, but are rather a set of reminders, or items that help teams execute a process once they’ve already read and understood the process.
The second type of checklists we discuss are those that summarize a series of requirements or pre-conditions that a team needs to follow-up on. This may include quality requirements or certain tasks that need to be completed before a certain work item is considered complete.
The most common checklists Scrum teams use
Scrum teams have a common set of checklists that they use. We discuss the commonly used Definition of Done, and also talk about the importance of having a Definition of Ready, and how that may help teams get started on the right foot when a new Sprint is about to kick-off.
Additionally, we talk about a pre-release checklist. With a pre-release checklist, teams are able to keep a memory of what they’ve learned from the past about meeting the release requirements, and can continuously improve that critical aspect of any team’s process.
In this segment, we also tackle the usual objections that people given when asked to consider the use of checklists. Checklists may be seen as “more bureaucracy”, but instead, they are there to help teams summarize a process that already exists, provides transparency about the process execution, and ultimately it should be a time saver for the team.
How about you? How have you used Checklists in your work? Share your experience in the comments below.
About Diana Getman
Diana Getman has more than 25 years of experience as a project manager leading cross-functional teams, in both startup and non-profit organizations. Diana has held the roles of Scrum Master, Product Owner, and Agile Coach and is the current President at Ascendle, a custom software development firm in Portsmouth, NH.
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!
Woody Zuill discusses systems, and tools to help us understand the system. We also discuss how important retrospectives are, and how to go about increasing the amount, and value of your retrospectives: Just-In-Time retrospectives.
About Woody Zuill
Woody Zuill, an independent Agile Consultant, Trainer, Coach, and Guide and has been programming computers for 30+ years. As a pioneer of the Mob Programming approach of teamwork for software development he has been sharing presentations and workshops on Mob Programming for conferences, user groups, and companies all over the world. He is considered one of the founders of the “#NoEstimates” discussion on Twitter.
You can connect with Woody Zuill on LinkedIn or contact Woody Zuill on Twitter.
If you are interested, check the MobProgramming conference.
Retrospectives are both important and hard to get right. There are many teams that stop having retrospectives and feel lost as to how to run them effectively. Niko shares with us his own view of how to run effective retrospectives, filled with tips and advice, this is a must listen episode about retrospectives.
When a team faces a problem they have a choice between blaming someone else (“them”), or taking ownership and making it happen even if that improvement looks beyond their reach. We as Scrum Masters can help teams take ownership, even when they need to involve other people in the resolution of the problem. Alex explains the problem, and some of the possible techniques to get the team to understand that they own the results of their work.
About Alex Fürstenau
When he was 12, his father bought him his first computer, a C64. The moment he saw characters appearing on the television was the moment when he knew he would do something with computers. Several years and a computer science study later that “dream” became true.
Alex quickly realized that the customers were not happy with our product. The first approach was to fix more of the requirements but it made things worse. During that time (around 2002) he thought “There has to be a better way” and he found several, among which was Agile.
It is hard to help teams take steps that move them to the next level. It is human nature to seek comfort and safety. Cliff developed an approach to get teams out of the rut, by helping them want to take their game to the next level. He uses some very simple tools that he explains in this episode.
About Cliff Hazel
Cliff Hazel is a coach at Spotify who is trying to learn about how to build effective teams, and how we can create the conditions for them to thrive. His main interests are: Complexity and Systems, Visualisation and Information Radiators, Curiosity and Continuous Learning
You can link with Cliff Hazel on LinkedIn, connect with Cliff Hazel on Twitter and catch him in some conference near you.
Many teams get stuck in a bad place, but there are some teams that also get stuck, but because they think they already are “good enough”. Listen in to learn how Zuzi learned to work with teams that already think they are “good enough”.
About Zuzi Sochova
Zuzi help companies and individuals to be more successful. She teaches teams and their managers how to be more efficient, how to provide better quality and how to communicate and organize teams so that people have fun, they are motivated and have high commitment. Zuzi helps teams and managers find out how to handle customer relationship to help them improve customer satisfaction.
You can visit Zuzi’s website at: http://sochova.cz/, and link with Zuzi Sochova on LinkedIn, or connect with Zuzi Sochova on twitter, or your favorite conferece.
We’ve all done it in one way or another. We spend time in a retrospective criticizing what is wrong, and assigning blame to others. Jeff Campbell has been there as well, and in this episode he explains how you can get teams to stop spending their valuable time whining, and start taking action.
About Jeff Campbell
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 organisations both small and large. He is one of the founding members of www.scrumbeers.com and an organiser of www.brewingagile.org in his spare time. He is also the author of an open source book called Actionable Agile Tools, where he explains how he uses 15 of the tools he uses in his daily work as a scrum master and agile coach.
You can link with Jeff Campbell on LinkedIn, and connect with Jeff Campbell on Twitter.
We can sometimes overwhelm the teams we work with by introducing too many methods. Anton explains how he likes to introduce methods to the team, by running experiments with the team to see if the method fits the team, and solves the problem they want to tackle. He also gives a critical advice on one of the most common anti-patterns for Scrum Masters: wanting to help too much.