BONUS: Diana Getman – How checklists make Agile teams faster and deliver with high quality, without adding more processes

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.

You can link with Diana Getman on LinkedIn, or visit Ascendle’s blog for more on checklists.

Remy Fletcher: From the “how” to the “why”, how great product owners empower the team

The level of detail and involvement with the implementation decisions is a good indicator of the quality of the Product Owner’s work.

The Great Product Owner: Focusing on the “why?”

Great Product Owners are open to the team’s questions, and even encourage them to ask questions. They focus on communicating the “WHY?” of the product instead of narrowly focusing on the detailed functionality.

The Bad Product Owner: Micro-managing the “how?”

In contrast, the Bad Product Owner focuses on the “HOW?” and may even try to micro-manage the team’s technology and implementation decisions. 

Are you having trouble helping the team working well with their Product Owner? We’ve put together a course to help you work on the collaboration team-product owner. You can find it at: bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO’s collaborate.

About Remy Fletcher

Remy is a Scrum Master at a Fin-Tech corporation outside of Boston. Currently working with 3 scrum teams with a focus of migrating individual products onto a centralized, scalable platform.

You can link with Remy Fletcher on LinkedIn and connect with Remy Fletcher on Twitter.

Remy Fletcher: The Lean Coffee as an Agile Retrospective format

Can the team work well without you? This is only one of the questions that Remy asks when evaluating his own contribution to the team’s progress. But there are other questions. In this episode, we discuss questions we can ask ourselves that help us understand how autonomous the team really is. 

Featured Retrospective Format of the Week: Lean Coffee

The Lean Coffee format has been a regular on the podcast. In this episode, we discuss how this format can help teams execute a retrospective in a short time, but still be focused on creating concrete improvement ideas to take on.

In this segment, we also refer to the Kudos practice whereby the team members highlight positive behavior and attitude by other team members.

About Remy Fletcher

Remy is a Scrum Master at a Fin-Tech corporation outside of Boston. Currently working with 3 scrum teams with a focus of migrating individual products onto a centralized, scalable platform.

You can link with Remy Fletcher on LinkedIn and connect with Remy Fletcher on Twitter.

Remy Fletcher: Moving from testing at the end of the Sprint to continuous testing

Many Scrum Teams will, at some point, go through the process of improving how they run the QA process. Many start with the QA at the end of the Sprint, and then bump into the hard wall that is the timeboxed end of the Sprint. The consequences are many, from stories that spill over to the next sprint, to stressed out testers. In this episode, we walk through a change process that took a team from testing everything at the of the Sprint to testing much earlier and reducing the stress on the testers. 

About Remy Fletcher

Remy is a Scrum Master at a Fin-Tech corporation outside of Boston. Currently working with 3 scrum teams with a focus of migrating individual products onto a centralized, scalable platform.

You can link with Remy Fletcher on LinkedIn and connect with Remy Fletcher on Twitter.

Remy Fletcher: How Scrum Masters can work with authoritarian managers and survive

In some teams, the role of the leader or manager can be a blocker to the team’s adoption of Agile and ownership of the product and process. However, those same managers usually develop their command and control approach due to past successes. As Scrum Masters, we must learn to work with those teams, starting by creating a close relationship with the team members. 

Featured Book of the Week: The Advantage: Why Organizational Health Trumps Everything Else In Business

In The Advantage by Patrick Lencioni, Remy learned about the concept of an executive team that he could apply to his own product when his team was struggling with direction. 

In this segment, we also refer to Start with Why, by Simon Sinek, a book that helped him understand the importance of communicating the rationale behind the decisions and involving the team in owning those decisions.

About Remy Fletcher

Remy is a Scrum Master at a Fin-Tech corporation outside of Boston. Currently working with 3 scrum teams with a focus of migrating individual products onto a centralized, scalable platform.

You can link with Remy Fletcher on LinkedIn and connect with Remy Fletcher on Twitter

Remy Fletcher: How 1-on-1 meetings fail to solve some conflicts

Scrum Masters often need to deal and help resolve conflicts in the teams and with the stakeholders. In this episode, we look at a case of conflicting priorities. We discuss the different approaches, and how the 1-on-1 conversations may cause problems that can be solved unless Scrum Masters get all the parties into the same room.

In this episode, we also talk about the book Getting to YES! by Fischer, Ury and Patton

About Remy Fletcher

Remy is a Scrum Master at a Fin-Tech corporation outside of Boston. Currently working with 3 scrum teams with a focus of migrating individual products onto a centralized, scalable platform.

You can link with Remy Fletcher on LinkedIn and connect with Remy Fletcher on Twitter.

Micah Stamper: Contrasting detail-oriented and holistic Product Owners

The topics Product Owners choose to focus on, impact greatly their, and their team’s effectiveness. In this episode, we contrast two types of focus, and how those different approaches affect the PO’s work.

The Great Product Owner: The holistic PO

Product Owners, as described in Scrum, are responsible for the success of the Product they own. In this segment, we talk about the whole ecosystem of the product. The PO role is not only about User Stories and Backlogs, and we dive into other critical aspects that are often forgotten.

The Bad Product Owner: The tech-centered, order taker

Product Owners can have a big impact on the effectiveness of the teams they work with. Some PO’s will take that seriously and invest in their growth in either technical or business knowledge. However, when that does not happen, we experience PO’s that take orders from business or want to dive into the technical details – because they are familiar with the technology. In this segment, we talk about the perfect storm of a PO: a PO that only takes orders and wants to dive into the technical details. Listen in to learn how you can help those Product Owners.

Are you having trouble helping the team working well with their Product Owner? We’ve put together a course to help you work on the collaboration team-product owner. You can find it at: bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO’s collaborate.

 

About Micah Stamper

Micah worked in technology for about 7 years. He has a background in lean principles and how to bring that to technology. Has done everything from Project Management to Software Engineering, Leadership, and Scrum Master.

You can link with Micah Stamper on LinkedIn and connect with Micah Stamper on Twitter

Micah Stamper: 2 types of questions to assess Scrum Master success

The process of reflection Scrum Masters go through, helps us find our own personal and contextual definition of success. In this episode, Micah describes the types of questions he asks of himself when assessing his success as a Scrum Master.

Featured Retrospective Format for the Week: The 3 questions that focus teams on concrete changes

Micah likes simple formats, and he recommends a format where we focus on 3 questions that help the team members reflect on concrete things they’d like to change. Listen in to learn about what questions he asks his teams.

About Micah Stamper

Micah worked in technology for about 7 years. He has a background in lean principles and how to bring that to technology. Has done everything from Project Management to Software Engineering, Leadership, and Scrum Master.

You can link with Micah Stamper on LinkedIn and connect with Micah Stamper on Twitter.

Micah Stamper: How to introduce WIP limits to a Scrum team

In this episode, we explore the story of a team that was starting to adopt Agile. We discuss the successes, and also the need to accept Work-In-Process (WIP) limits before the team can succeed. 

We discuss a possible set of steps you can follow to introduce WIP limits to your team.

About Micah Stamper

Micah worked in technology for about 7 years. He has a background in lean principles and how to bring that to technology. Has done everything from Project Management to Software Engineering, Leadership, and Scrum Master.

You can link with Micah Stamper on LinkedIn and connect with Micah Stamper on Twitter

Micah Stamper: The type of execution focus that leads Scrum teams astray

The focus that some teams have on “execution” can be a great resource. It helps teams get into the details, and push forward even when finding the inevitable setbacks. However, when teams are completely focused on execution there are other aspects that lose focus, and that can derail the team. In this episode, we talk about how the execution focus that some teams have lead them astray from certain critical aspects of the software development process.

Featured Book for the Week: The art of doing twice the work in half the time, Jeff Sutherland

In The art of doing twice the work in half the time by Jeff Sutherland, Micah found a great reminder and introduction to the Lean principles he now applies in his own work. He also found a great reminder that software development has its own context, that needs to be taken into account in the work Scrum Masters do with software teams.

About Micah Stamper

Micah worked in technology for about 7 years. He has a background in lean principles and how to bring that to technology. Has done everything from Project Management to Software Engineering, Leadership, and Scrum Master.

You can link with Micah Stamper on LinkedIn and connect with Micah Stamper on Twitter.