Scaling the use of Scrum in any organization is not easy. In this episode, we discuss Izis approach to that challenge from the Scrum Master perspective. Scrum Masters in larger organizations end up having to work with multiple teams. We explore an approach that may help Scrum Masters serve more teams, while amplifying their impact.
About Izis Filipaldi
Izis’ mission is to help people to improve their knowledge and professional value inside organizations, applying the agile way of working. She has been working as an Agile Coach for more than 7 years, helping people to deliver products, developing an environment free of judgments where they can fail fast and learn faster. Continuous improvement of: people knowledge, product delivery, and work environment, are her 3 main focus on work. And she loves what she does!
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.
Scrum Masters all over the world make a significant effort to get better at facilitating retrospectives… Until they have to host a Distributed Retrospective. At that point, we learn that all you learned about facilitating retrospectives is still useful, but not nearly enough!
Preparing, hosting, and facilitating a Distributed Retrospective is a completely different challenge.
The 4 things that you need to make Distributed Retrospectives work
The financial processes of companies can defeat their own efforts to become more agile. It’s simply impossible for an organization to be adaptable if their project processes require all projects to be specified up-front and funded months ahead of their starting date.
Tackling the financial process changes in our organizations is one of the make-or-break aspects of helping organizations become Agile and adaptable.
In this episode, we talk about Lean and Agile Financial Planning (PDF article download), an approach that tries to adopt Agile and Lean thinking in the funding and financial processes of an organization.
The reason why Lean and Agile Financial planning is a core aspect of Agile transformation in enterprises
This is a guest post by Jeff Campbell, author of Actionable Agile tools (available on Amazon, and direct from the author at bit.ly/aatbook)
Visualizing Continuous Improvement
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!
This is a guest post by Jeff Campbell, author of Actionable Agile tools (available on Amazon, and direct from the author at bit.ly/aatbook)
Keeping retrospectives impactful and fresh
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.
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.
Prep Work
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.
Here is a link to a google doc with the prep work I have done, to save you some time: https://tinyurl.com/l8loec6
Reducing the complexity
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.
Headings:
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
Discussion:
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.
Product Vision
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.
Conclusions:
The Good:
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.
The Bad:
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.
Scrum Masters understand the importance of having many tools for different situations. The quality of our work is often related to the quality of the tools we have in our toolbox and the context in which they work.
In this episode, we review some of Jeff’s favorite Actionable Agile Tools, a book that collects 19 tools and is now available on Amazon in black and white as well as full color. Not to mention Kindle!
Tim was faced with a problem. How to be a leader without any formal power. All Scrum Masters and Product Owners who have felt the responsibility, but not any “line authority” have faced the same problem. You need to help move the project along, but you can’t tell people what to do!
In this episode we explore the concept of Lateral Leadership how it can help you as a Scrum Master or Product Owner.
If you can’t join us on the Facebook live event for Scrum Masters, don’t worry. We will be making a recording available. Just sign-up below to make sure you get notified when it is available.
Photo credit and copyright: By Minnesota Historical Society [CC BY-SA 2.0 (https://creativecommons.org/licenses/by-sa/2.0)], via Wikimedia Commons
Izis’ mission is to help people to improve their knowledge and professional value inside organizations, applying the agile way of working. She has been working as an Agile Coach for more than 7 years, helping people to deliver products, developing an environment free of judgments where they can fail fast and learn faster. Continuous improvement of: people knowledge, product delivery, and work environment, are her 3 main focus on work. And she loves what she does!
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.
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.
Tim was faced with a problem. How to be a leader without any formal power. All Scrum Masters and Product Owners who have felt the responsibility, but not any “line authority” have faced the same problem. You need to help move the project along, but you can’t tell people what to do! 