Scrum Masters are the future CEO’s, and a podcast by the Lean Enterprise Institute

I’ve been working on a collection of great blog posts about the Scrum Master role. If you have a favorite article on the Scrum Master role, or it’s goals and responsibilities, let me know by submitting it here: https://bit.ly/TheBestScrumMasterBlogPosts2020

I believe that one of the most well-kept secrets of the Agile community is that the Scrum Master role is the role where the future CEO’s are born.

I know, I know. This sounds like an exaggeration. True. But I do have some good arguments for this below, so read on!

Scrum Masters are about building organizations that work together

I was listening to this podcast by the Lean Enterprise Insititute (a non-profit that tries to advance Lean practice) with heard Alan Mulally, the ex-CEO of Boeing and Ford.

In that podcast, Alan explains how he implemented the “people first” model he learned about at Boeing (being involved in all of the plane projects at Boeing) and later implemented also at Ford.

His perspective is refreshing. But especially it is very much in line with what we think the Scrum Master role is. Take this quote for example: “Pull everyone together around the Vision for the Product, and around the Strategy for achieving that Vision”

“Pull everyone together around the Vision for the Product, and around the Strategy for achieving that Vision”
– Alan Mulally, ex-CEO of Boeing and Ford

For me, that’s a great description of what the role of the Scrum Master is about: pulling people together around the Vision for the product that the Product team has put together with their stakeholders, and pulling people together around the strategy to achieve that Vision!

Scrum Masters are about building organizations that put “people first”

The podcast goes on and talks about something that is incredibly important: how do we build high-performance teams. The lessons Alan shares are also crucial, and we’ve talked about this here on the Scrum Master Toolbox podcast: when a team member does not want to play by the rules the team has setup (low “working together skills, as Alan puts it), that’s poison for the team.

(On Working together and peer accountability) “Everyone who does not operate this way is poison”
– Alan Mulally, ex-CEO of Boeing and Ford

As Scrum Masters, one of our greatest responsibilities is to make sure that the team comes together and agrees on how to work together, and keep themselves accountable! Just like a CEO as Alan explains!

Alan shares his approach to bringing people together on the execution aspect of the work: be clear about the rules (work with the team to define those), and define a method for self and peer accountability!

“Most of the time, when you are clear about the process, and the rules of working together, people will come together and become great team contributors”
– Alan Mulally, ex-CEO of Boeing and Ford

As Scrum Masters, we are responsible for making sure everyone on the team understands (and contributes) to the rules of the work! Just like a CEO as Alan explains!

This was a great podcast with Jim Morgan (Lean Enterprise Institute) and Alan Mulally (ex-CEO at Boeing and Ford), and is filled with insights for Scrum Masters, who are the future of the CEO role!

One more quote to finish (from the podcast, at around minute 29)

“My biggest contribution, was holding myself and the team accountable for following the process and acceptable behaviours”
– Alan Mulally, ex-CEO of Boeing and Ford

That’s a quote from a CEO, not a #ScrumMaster. But it could be from a Scrum Master!

Help us grow as a Scrum Master community, share your best 2020 articles below.

Developing Teams the Scrum (and Lean) way! by Lean.Org’s The Lean Post

I’ve been working on a collection of great blog posts about the Scrum Master role. If you have a favorite article on the Scrum Master role, or it’s goals and responsibilities, let me know by submitting it here: https://bit.ly/TheBestScrumMasterBlogPosts2020

Scrum Masters are key participants in the teams, and key contributors to the improvement of productivity in the organizations they work in. Even if the Scrum approach and Agile, in general, are very new (from late1990’s, early 2000s), there are other approaches that have been with us for nearly more than a century now.

One such approach is “Taylorism”. In that approach, the main premise is that “some people” know “what needs to be done and how” (the planner/thinker), and other people “do it” (the doers).

“Take it to the team”: a Scrum Master Mantra

Unfortunately, that Tayloristic approach has become prevalent thanks to the work of some early consultancies.

In Scrum, one of the most important changes to the world of work is that the “doers” are also the “thinkers”. This is one of the reasons why here on the Scrum Master Toolbox Podcast, we often say: “take it to the team”. In other words, anyone can raise an idea of improvement, but only the team knows what can/should be done to achieve the goal. Sometimes that team is the development team, sometimes it is the development team + stakeholders, but it’s “the team” that owns and develops the process of work.

This perspective is revolutionary for many, including many consultancies that still push “process improvement” à lá Taylor (you know which ones).

What’s better than Taylorism for developing our teams and organizations? 

That’s why I want to highlight this post in Lean.Org’s Lean Post blog: “Develop Your People Patiently Rather Than Rely on Super Taylorism”

As the article puts it: while the “west” was focused on separating the thinking from the doing, and using “Super Taylorism”,  “in Japan, Toyota was developing a different approach to strategy, one based on technical learning on the gemba through trial and error–a process that aimed to serve all customers with a broad product line of high quality and at the right price.”

Does that sound familiar? Scrum is exactly that kind of approach: “based on technical learning on the Gemba through trial and error”

Check out the post, and learn about the roots of Scrum and Agile. Don’t get stuck in a Tayloristic approach that leads to frustration, dis-enfranchising the team, and long term problems.

Help us grow as a Scrum Master community, share your best 2020 articles below.

BONUS: How to setup Agile and DevOps teams, Team Topologies interview with Matthew Skelton and Manuel Pais

Setting up teams to work collaboratively is one of the challenges that organizations go through when adopting Agile. The functional team setup (all DBAs, all testers, all windows devs together, etc.) is not acceptable for teams that want to quickly develop and deliver products and services to the market. But neither is it possible to have all possible skills (sometimes 10’s of skills) in one team because organizations simply don’t have that many people with certain skills. 

In this episode, we talk about the possible team topologies, and how each of those affects our ability to deliver in different organizations. 

How we set up teams directly affects the quality of the software teams deliver

Continue reading BONUS: How to setup Agile and DevOps teams, Team Topologies interview with Matthew Skelton and Manuel Pais

BONUS: Lean and Agile Financial planning with Maarit Laanti and Rami Sirkiä

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

Continue reading BONUS: Lean and Agile Financial planning with Maarit Laanti and Rami Sirkiä

Why Agile frameworks fail and what to do about it: #ToolsOverFrameworks, the context-aware solution

4 minutes read

I have worked at many organizations that were trying to adopt Agile using a framework as the starting point. SAFe, LeSS, or even Scrum were the frameworks of choice.
Scrum, for example, is a very simple framework. It stands to reason that it would be easy to adopt and therefore benefit from the value that Agile brings. Or is it?
If we look deeper, Scrum is a collection of patterns or thinking tools. The daily meeting pattern, the time box pattern, the single owner of the requirements pattern, etc. There are many patterns that were considered when creating Scrum, and together they form what we know as the Scrum framework.
As the Agile community, the problem we face is that Scrum (and other frameworks) did not make Agile adoption easy. The Scrum Theatre many teams play attests to that fact. Using a framework is a problematic approach for Agile adoption because it assumes a prescriptive solution would help us tackle agile adoption. However, Agile adoption is a problem that requires constant evolution and changes.
As the Agile community, the problem we face is that Scrum (and other frameworks) did not make Agile adoption easy.
We need a different approach. One that builds on what we’ve learned from others (books, podcasts, conferences), but also that adapts to our context and the specific reality we live in.

The patterns we’ve seen working before, fail later on

When we work with different teams, we start to get a “feel” for what works, and what doesn’t. We try to apply the same ideas to another team, and then start to understand what consultants mean when they say “it depends…”

When we work with different teams, we start to get a “feel” for what works, and what doesn’t.

For example, the star-fish retrospective may work great for one team, but it just bombs when we use it with another team. That’s ok. Nothing works all of the time. The good thing though, is that there’s always something that works, we just need to know what it is.

The solution is not a process or a framework, it’s a toolbox!

Having worked with many teams, I’ve come to value a few tools that I try to use often. Some retrospective formats are one example of that. But not every retrospective format will work, so I’ve collected over time a large set of “thinking tools” or retrospective formats that I use depending on the context.
As a Product Owner, I’ve successfully used Backlogs. But in some teams Backlogs get abused and create the “slave to the backlog” anti-pattern. With those teams, I’ve been using Impact Mapping and Story Mapping instead. Different situations require different tools. The challenge is collecting a good and large enough toolbox, and the stories to go with it.
Stories, when attached to a tool, help us define where the tool will work, and when it might not. Stories are our “labels” for tools.

Collect tools, not frameworks

No doubt you will be part of teams using different frameworks: Kanban, Scrum, Extreme Programming or Scaled Agile (SAFe), Large Scale Scrum (LeSS), etc.
Don’t fight the framework! Instead, use concrete tools that help you progress and achieve your goals.
As Agile Coaches, Scrum Masters, Product Owners and Team Members, we should be collecting tools, not frameworks. Our goal is to deliver something valuable to our customers/users, not be good at SAFe, Scrum or some other framework.

How we collect tools

We collect tools and stories by sharing our experiences, and listening to those that have solved the problems we are facing now.
For a while I’ve been collecting challenges and tools that product developers use to solve their most important challenges. I’ve collected those in the form of workshops that tackle specific types of problems.
In the #NoEstimates workshops, I share tools and techniques that have helped me and many others deliver on time. Sometimes you can’t fight the deadline. If the product must be out for Christmas, you just deliver. Period. How? That’s what we tackle in the NoEstimates workshop: tools, techniques and thinking models that help deliver on time. These tools are context specific, they come with stories and we practice those in the workshop. Click here to find out more and join the next #NoEstimates workshop.
In the Product Owner Success Toolbox workshop, we review, and practice tools that have helped teams deliver products and services that have a market impact. Impact for the users, customers and also the companies we work with. The biggest waste is that of human potential, with these tools we build our Product Ownership toolbox, and tackle the biggest challenges people have faced when trying to define and deliver products with market impact. Click here to find out more and join the next Product Owner Success Toolbox workshop.
In the Agile Strategy workshop (still in alpha, contact me to know more), we tackle the biggest challenges that companies have faced aligning the teams, and focusing larger number of teams on concrete value for the customers and the organisation. The Agile Strategy workshop collects tools related to funding of work, strategy definition, product strategy, strategy deployment, and progress follow-up at the organizational level. Email me to know more about the Agile Strategy Workshop.

Join the conversation

Have an opinion on the use of Tools vs. Frameworks? Join the conversation on Twitter/LinkedIn with the hashtag #ToolsOverFrameworks

2 major challenges I faced as a product developer

When I started developing software as a team member, and later as a project manager, I started to face some of the challenges that you are probably familiar with.

With the little experience I had, these challenges proved to be difficult to solve. During part of my journey, they even felt impossible to solve. I know better now…

The first and most important challenge for me was the need to meet a strict deadline.

We ended up calling it the Christmas problem.
Continue reading 2 major challenges I faced as a product developer

BONUS: Dean Leffingwell on scaling Agile and the Scaled Agile Framework, SAFe

scaled agile overviewFor this first Christmas 2018 special we focus on scaling Agile, and specifically how the Scaled Agile Framework (SAFe) can help organizations take Agile and apply it in the large.

There are many systems that require multiple teams to work together. As more and more industries adopt software as a core part of their services and products, we also see many organizations developing many products concurrently, and large engineering organizations that require coordination across tens or hundreds of teams, including non-software teams.

In this episode, we discuss how SAFe can help you take Agile to that type of environments and organizations.

Read on for the detailed show notes, as well as all of the links.

Continue reading BONUS: Dean Leffingwell on scaling Agile and the Scaled Agile Framework, SAFe

How Agile and Lean saved a hospital from bankruptcy! Twice!

All of us working with Agile and Scrum are used to the (sometimes) large transformations that these approaches can have at work. But it is not everyday we see the impact, the amazing impact, it can have on other types of work. How about this: Marcus Hammarberg, walks into a hospital and the hospital is about the crumble. Literally! The roof has collapsed, there’s dripping water and buckets everywhere and the second floor is overrun with debris. But that is not where the problems end…

A few months later, and using Kanban, Agile and Lean ideas the hospital is saved. But how did that happen?

Marcus explains his story, and the amazing transformation in his latest book: The Bungsu (now available for pre-order at Amazon), and we have a short video to explain the main points of the story right here.

Click on to see the video, and sign-up to get the first chapter of the book.

Continue reading How Agile and Lean saved a hospital from bankruptcy! Twice!

How trust, kanban and a little structure changed a life

Work life is a serious thing. We spend (at least) one-third of our time awake at work, and in some cases much more time than what we spend with our families most days of the year.

Now imagine what would happen if your work would be falling apart. You have too much work, and are being constanly interrupted. Your authority and ability to contribute is undermined. And on top of it your place of work is literally crumbling: the roof collapsed and what is left is being innudated by dirty water that runs off from the roof’s debri.

Meet Ibu Elsye!  Ibu Elsye is the lady dressed in black in the picture or “Mrs.” Elsye if you don’t speak Indonesian ;).

She’s General Manager of a hospital, Rumah Sakit Bungsu (aka The Bungsu), that Marcus Hammarberg helped, in Indonesia. General Manager; what is that, in a hospital? I’m happy you asked: basically she’s in charge of everything that is not health care. Food, laundry, maintenance, security staff, drivers … you name it.

In The Bungsu, if you need something fixed – go to Ibu Elsye.

But Ibu Elsye’s work life was not going very well…

Continue reading How trust, kanban and a little structure changed a life

Using Lean and Agile to save a hospital from bankruptcy: twice! The Bungsu Hospital Story

When Marcus Hammaberg first started to work with the Bungsu hospital they were in a devastating situation. Their finances were on a bottom low after years of decline of patients visiting, their operational permit had not been renewed and they were operating on a probation, the staff was disengaged and blasĂ© … oh, that’s right – the roof of the entire second floor had collapsed.

Read on for more…

Continue reading Using Lean and Agile to save a hospital from bankruptcy: twice! The Bungsu Hospital Story