how to Archives - Scrum Master Toolbox Podcast

BONUS: Rahul Bhattacharya on what do on your first 90 days of a scrum master for a new team

We start this episode by talking about why it is important to have a specific focus on your first 90 days when working with a new team. The first 90 days are all about setting yourself up for success, and that requires that you take certain actions.

Start preparing before you start helping

Rahul suggests that we start preparing for our new role as a Scrum Master by asking specific questions (even in the job interview if that’s the case). Rahul suggests that to understand the expectations placed on you, you must understand what others have done before, what the team might be struggling with, but also how the context around the team works. What are the hierarchies, what do the team expect the Scrum Master to do, and more!

Do the Gemba: a critical step for your success as a Scrum Master

The gemba (a term from Lean that means “the place where the work happens”) walk is all about seeing with your own eyes, and talking directly to the people that you will be working with, or that your work will depend on. It’s important for Scrum Masters that are getting started that they not only talk to the team, but also to the stakeholders of the team, and possibly other teams that represent dependencies for the team you are trying to help.

See the system: looking beyond software development

Finally, the third step in this structured approach to the first 90 days with a new team, is all about what’s around the team that you need to deal with, even if it is not at the core of what the team does. This is “the systemic view” or context for the team. Rahul shares some critical questions we should ask ourselves (and those around the team), so that you can understand what kind of pressure and expectations are placed on the team.

Mega tips to close off this episode (make sure you listen all the way to the end)

Once we review the 3 main activities to prepare your Scrum Master assignment successfully, we dive into some of the tips that Rahul has collected over the years as an Agile Coach and Scrum Master. Rahul shares some critical insights that will help you overcome the most common challenges Scrum Masters face when taking on a new team.

To know more about Rahul’s approach, check out this article for Agile Coaches and Scrum masters called “Needs-oriented model of Agile Coaching”.

And check out Rahul Bhattacharya’s podcast, The Agile Atelier!

About Rahul Bhattacharya

Rahul Bhattacharya is currently working as an Agile Coach at Delivery Hero. He is responsible for optimizing the ways of working within the organization, coaching others on best practices while simultaneously guiding teams working on different products. Rahul is passionate about constant learning through experimentation and feedback

You can link with Rahul Bhattacharya on LinkedIn and connect with Rahul Bhattacharya on Twitter.

And check out Rahul Bhattacharya’s podcast, The Agile Atelier!

Holding space, a Scrum Master guide with links and tips

As a Scrum Master that studies, and constantly tries to improve your craft, you’ve probably heard (and even used) the phrase “hold the space”.

For (some) native English speakers, this phrase may be easy to grasp, but as a non-native speaker, I can vouch for the difficulty of understanding what this means in practice.

As a Scrum Master myself, however, this phrase is too important to dismiss as “insider talk”, so I want to share some links and tips about “holding the space” as a Scrum Master.

First, let me refer to a blog post at Stanford’s site by Linnea Ann Williams called “Holding Space: A Scrum Master Overview”. The blog post is about the role of the Scrum Master, but it is also about what it means to “hold the space”. My key takeaway from this blog post: As a Scrum Master I must help the team and the stakeholders create the conditions the team needs to perform (hold the space).

The basics of the Scrum Master role and the meaning of “holding space”

But there’s a lot more about the meaning of “holding space”. Many of the aspects of that approach are in the Scrum Guide (PDF version from the year 2020 here), and some are well described in this blog post by Aditya Chourasiya, titled “Scrum Master – Roles and Responsibilities”. Aditya describes “holding space” as a set of responsibilities that include:

Shield teams from interruptions to optimize the outcome
Facilitate effective Scrum ceremonies
Help Product Owners develop a positive rapport with their team and accept him/her as a part of the family
Step back and let the team learn from its own experience – successes, and mistakes.

Aditya’s article gets into the very practical aspects of the role, and I find that approach very useful when defining my own approach to “holding space”.

Taking Holding Space all the way up to “11”: Open Space Technology as a school for Scrum Masters

Open Space Technology, is an approach that helps people find solutions to difficult problems by working together, collaborating on possible answers to those problems.

If that sounds familiar, it’s because that’s what we expect Scrum Masters to do when it comes to the teams and their search for a solution. We want Scrum Masters to help the team find a solution (or more) for a difficult problem, by collaborating inside the team, and with outside contributors, other teams, or stakeholders.

That brings me to another resource (WARNING: this is a book, not a blog post!): The Tao of Holding Space, a book by Chris Corrigan. This is a long read, and I don’t expect everyone to read it. So let me review some key takeaways from the book.

Chris is a seasoned Open Space Technology facilitator and often writes about facilitation at all levels and all kinds of organizations. Therefore he has a lot of experience to share on “holding the space” and what that means in practice.

One of the inspiring phrases from his book is right there in chapter 1, and I think it describes perfectly what the Scrum Master role is about: “Harrison Owen wrote that “holding space” is an act that is at once totally present and totally invisible”.

And the book goes on with inspiring phrases. In chapter 2, Chris writes: “Sitting in stillness invites [other] people to move.” This reminds us that when we don’t take action – as Scrum Masters – we are helping others “find the space” to express their own ability to lead and help the team.

In chapter 10, we are reminded of one of the key aspects of Open Space Technology: “Whatever happens is the only thing that could have”. This encourages us to work with what happens in the team, instead of trying to direct the team towards what we think is “the right thing”. Accepting what happens in the team, at every turn, is also part of “holding the space”

Conclusion

This is a short blog post about what “holding the space” is for Scrum Masters.

It has some very practical blog posts and a resource that inspires us to look at the activity of “holding space” from a different perspective: the Open Space Technology perspective.

“Holding the Space” is not just a phrase, it’s a very practical and pragmatic thing we do as Scrum Masters.

What is your approach to “holding the space”? Share your thoughts below!

Do you want to grow as a Scrum Master?

Get an invite to the Annual Global Online Scrum Master Summit. Enter your email below to be notified when the Summit registration opens

Do you want to grow as a Scrum Master?

Get an invite to the Annual Global Online Scrum Master Summit. Enter your email below to be notified when the Summit registration opens

Top 3 challenges we face as product developers – #PDevTOOLBOX

After running a survey of product developers, I collected the following 3 top challenges that product developers face in their work.

Unclear specifications with missing information like acceptance criteria, and that require large amounts of rework after we start developing a particular functionality
Finding out critical use cases too late (via bugs, real-user feedback, etc), which leads to long delays in the project.
We don’t have a clear and measurable definition of value, therefore it is always a fight of opinions where the HIPPO (highest paid person’s opinion) prevails most of the times – even when it goes against survey results.

A toolbox to solve these problems

Given these 3 main findings, it is easy to understand why delivering on time is hard for many teams. No matter how much goes into planning and estimating, when the agreement on value is missing, and the specifications of what to do are too fuzzy, we will inevitably find big gaps that lead to massive scope creep and delays.

But it does not need to be like these. There are simple tools I collected in my product developer’s toolbox (#PDevTOOLBOX) that can help alleviate or remove these problems. Based on your input through the #PDevTOOLBOX survey, I’ve created a booklet (15 min read) you can download and read while on the run in your mobile phone or tablet.

Click here to download the booklet: “How to deliver on time and eliminate scope creep by scoping projects around Impacts, not Features”

Agile Practices Retrospective – How to help teams get unstuck!

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.

This is the story of one such retrospective.

Click to learn more about how you can help your PO

Agile Practices

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.

Special thanks to Jurgen Appelo for providing the initial list I worked from:
http://www.noop.nl/2009/04/the-big-list-of-agile-practices.html

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.

About Jeff Campbell

Jeff Campbell is the author of Actionable Agile Tools, a book with practical tools and practices to help you amplify your impact as a coach and Scrum Master

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.

You can link with Jeff Campbell on LinkedIn and connect with Jeff Campbell on Twitter.

BONUS EPISODE: Critical lessons on Leadership with Sean Dunn

In this Episode we explore Leadership, what it means, and why it is such an important discipline for Scrum Masters.
Sean is an officer in the Canadian army reserves, turned Agile Coach. He shares with us what he learned about leading teams in his military career. How those lessons apply to knowledge work, and how to develop our Leadership skills.
In the armed forces, we look at leaders as someone who will be with us in harms way. To be able to function effectively as teams, leaders need to learn to work with teams in a manner that builds trust and empathy. Scrum Masters can learn a lot from how that is achieved in high-pressure situations.
The book mentioned on the topic of Trust: The 5 Dysfunctions of a team by Lencioni, includes many examples and practices on how we can help build trust within our teams. We also refer to Turn the Ship Around by Marquette, a book dedicated to explore the topic of leadership filled with lessons for Scrum Masters.
We also discuss what it means to be a successful leader, and review some of the Agile Manifesto principles that bear directly on leadership, and the practice of that discipline.

We are temporary stewards of our profession
Sean helps us to challenge our personal visions of leadership, what it means for our profession, and how it should influence our actions. “What type of organization do you want to build?”, Sean asks.
To help us develop our own understanding and vision of leadership Sean recommends 3 books:

About Sean Dunn

Sean is an Enterprise Agile Coach with IHS Global. He has been involved with agile development for 8 years as a developer, product owner, and agile coach. Prior to his exposure to agile development Sean spent 13 years in the Canadian Army. In fact, Sean is known to point out that the Army is far more agile than most people think.
That background in the Canadian Army influenced his view of Leadership and the role of Leadership in creating and developing great teams.
You can connect with Sean Dunn on LinkedIn, check out Sean Dunn on the Scrum Alliance or email him at sean.dunn@ihs.com