Ian’s journey from journalism to becoming a Scrum Master is a testament to his adaptable mindset and persistence. His transition stemmed from a unique start; he secured his first job due to his fast typing skills and a desire to meet Peter Jennings. Ian’s persistence in seeking a meeting with Jennings honed his tenacity. The introduction to the Scrum Master role came through recognizing the news industry’s agile, continuous delivery setup. Despite challenges, like sending out 400 resumes for just 3 interviews and a job offer, Ian’s honesty on his resume and his ability to relate his existing skills to the software field were pivotal. In interviews, he remained coachable, acknowledged his learning curve, and emphasized genuine interest in others. He underlines the importance of not striving to be the smartest person in the room, instead focusing on collaboration and curiosity.
In this episode, Oz (Oguz Ozyurt) shares a story of a difficult collaboration with a Product Owner. He was working with a team and Product Owner who had different levels of experience, and while the team had completed the functionality for the iteration, they were not ready to release it. The Product Owner was surprised and pressed the team to release the functionality, which led to a failure. From this experience, Oz learned the importance of defining the definition of done with the team, as well as partnering with the Product Owner to define the goal together. He also emphasizes the importance of accepting that sometimes we fail, and working together with the team and Product Owner to define a plan for how to handle failures.
The inspiring story of how a failing hospital turned things around with Agile and Lean
Recovering from failure, or difficult moments is a critical skill for Scrum Masters. Not only because of us, but also because the teams, and stakeholders we work with will also face these moments! We need inspiring stories to help them, and ourselves! The Bungsu Story, is an inspiring story by Marcus Hammarberg which shows how a Coach can help organizations recover even from the most disastrous situations! Learn how Marcus helped The Bungsu, a hospital in Indonesia, recover from near-bankruptcy, twice! Using Lean and Agile methods to rebuild an organization and a team! An inspiring story you need to know about! Buy the book on Amazon: The Bungsu Story – How Lean and Kanban Saved a Small Hospital in Indonesia. Twice. and Can Help You Reshape Work in Your Company.
About Oguz Ozyurt
Oz came from a technical background, and has worked across multiple industries, applying agile practices toward the technical and non-technical areas. He is passionate about agile, he has leveraged his passion for delivery value and agile practices by coaching, teaching, mentoring many teams to transform from traditional software development life cycle to Agile principles and practices.
You can link with Oguz Ozyurt on LinkedIn.
Brian’s story is enlightening regarding the value of the Definition of Done. A team that had set the DoD bar too high, and chose to not change the DoD. That led to an anti-pattern that had to be untangled by the Scrum Master.
Samantha shares the story of a Scrum Master that had the tendency to lead all the conversations and how she was able to recover from that pattern with a technique she calls “the pregnant pause”.
About Samantha Menzynski and Brian Ziebart
Samantha Menzynski has spent her entire career in software. Starting in support and account management, moving to customer support management, and with Penta’s transformation to Scrum becoming Scrum Master for the Core product team.
You can link with Samantha Menzynski on LinkedIn.
Brian Ziebart started his career in software as a developer, but found himself wanting to move towards coaching and developing people rather than product development. When Penta’s Scrum transformation started in August 2019, he jumped at the opportunity to work more with people while still staying involved with development.
You can link with Brian Ziebart on LinkedIn.
You can read more about Samantha’s and Brian’s work and the Agile transformation they were part of in this Scrum.org blog post.
This team that Nick was working with had trouble delivering on time. When Nick looked into it, he discovered that the team did not take into account all the work necessary to adhere to the Definition of Done. Once he found that, however, he had to work with the team to help them realize what was going on, and how they could become more predictable by simply taking into account what they had committed to: the Definition of Done criteria.
Featured Book of the Week: The Goal by Elyahu Goldratt
When reading The Goal by Goldratt, Nick had a lightbulb moment. In that book, the author describes the impact that one single aspect of work can have: throughput.
The book describes how not paying attention to that aspect may destroy the ability to deliver value.
In this episode, we also discuss The Phoenix Project by Gene Kim et al.
About Nick Stewart
Nick has worked in the “Projects Space” for the last 5 years, initially working with business change, then in IT using Prince 2, Waterfall and ultimately found Agile organically through pain of delivering projects using the other methodologies. More recently he has taken on a Delivery Lead role which allows him to continue to learn whilst helping teams deliver continuous value.
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.