Let me quickly describe a potential situation how this came about.

I talk to a lot of people (if the day is long enough) and so I get them to ask interesting questions like:

“Shirley, anything worth having is worth working hard for.”, that was how my friend Steve Porter from 

This is a very common myth, frequent on people used to develop software only within the context of a closed scope (traditional project).

I was honored to participate in the Women in Agile panel discussion last week.

A recurring Scrum myth I see in my training and coaching is that there is no planning in Scrum.  Unfortunately, this myth can lead to two negative consequences.

At first sight, Zombie Scrum seems to be normal Scrum. But it lacks a beating heart. The Scrum teams do all the Scrum events but a potential releasable increment is rarely the result of a Sprint. The team also don't have any intention to improve their situation. Actually nobody cares about this team. The stakeholders have forgotten the existence of this team long time ago.

This post is part of a series on debunking Scrum Myths.  While my business cards say Professional Scrum Trainer, I may change that to Scrum Myth Buster.

People always as ask me if agile is just for software. Saying agile is just about software is like saying software is just about science. Initially, computer science was about replacing manual processes. Now, it’s about creating human experiences.

The Scrum Team consists of 3 distinct Scrum roles that promote self-organization: the Scrum Master, the Product Owner, and the Development Team. The accountability of each role complements the accountability of the other roles.

When Scrum is introduced in a company, most of the time, the development team embraces it with lots of enthusiasm.

THE (MIXED) BLESSING OF NEXTGEN REWRITES  About 10 years ago, I experienced the mixed blessing of being part of yet another nextgen rewrite project.

One of the recurring Scrum Myth discussions I have with colleagues, teams new to Scrum and those attending training when comparing Scrum & DevOps relate to a misinterpretation of the following paragraph from the Scrum Guide.

One common consequence of teams that do not deeply understand Scrum and the nature of its events is that they believe it is possible to run sprints which do not produce a Done and releasable increment of the product.

Clients and training attendees ask me "Can you use Scrum for something else than software?”. What they usually mean is building some other products or organizing team’s work. Let’s explore a more exotic idea.

The Scrum framework thrives on empirical process control. The inspection of observable results gives us insights in what might be most valuable next, always acknowledging that the future is unwritten.

One of the arguments used against Scrum and a common misconception at the same time is the idea that quality is traded for speed in Scrum. As a PST with years of experience in Quality Assurance I decided to challenge this myth.

At Amsterdam Airport Schiphol we're using an Agile approach to realize a large digital program. This program includes 5 value streams with multiple teams. Due to the increasing scale of the program, some challenges arise. For example:

IMAGINE Imagine you have just been asked to build an Agility Enablement Organization for your company. Sounds like fun, but there are some constraints you need to work within or around…

NEW YEAR RESOLUTION

Scrum Teams will always face impediments because the work is complex and dynamic. The question is whether we tackle those impediments or live with them. In this post I share 5 challenges and actionable tips to overcome them.

In Scrum, delivery is a usable Increment by the end of a Sprint.  Because we are dealing with complex work, we do not know everything about what is needed and how to deliver it before we start working.  This is where the concept of emergence comes in.

This year I was in the lucky circumstance to be part of some awesome (Scrum) teams. It certainly wasn't all "Scrum by the book" but I've learned a tremendous amount of lessons and generated lots of values insights.

I would like to kick off a series of posts in this blog trying to debunk some common myths about Scrum. Many of them arise sometimes from a poor understanding of the Scrum Guide, and even more often, from not having read it at all.

The Sprint Goal helps provide focus on an objective we want to achieve and allows the flexibility to negotiate the work to achieve that objective. Creating a clear Sprint Goal can be challenging for Scrum Teams.  Here are four common problems with Sprint Goals and a few tips for improving them.

In a previous post describing challenges to creating a Done Increment, I identified a lack of team collaboration as one of those challenges.

In a previous post describing challenges to creating a Done Increment, I identified a lack of team ownership as one of those challenges.

Recently I got asked what I consider the most common challenges with Agile projects. These are projects that have such a high rate of uncertainty and complexity on how and what to build, an Agile approach is necessary.

​

Because there's no easy way in telling you this, I'll just share it straight away... Next week I'll be setting up a Jira environment for the product teams I'm coaching...

Development Team was removed from the Scrum Guide in the 2020 release. However, the ideas expressed in this blog still provide value when understanding the dynamics of the Scrum Team.

What Is Self-Organization? “Knowledge workers have to manage themselves. They have to have autonomy,” says Peter Drucker.

Are we there yet? It’s becoming like nails-on-a-chalkboard to hear phrases like “We’re going Agile” or “We’re doing this because it’s agile.” People are putting everything they can under the Agile umbrella, right down to clea

Empiricism means working in a fact-based, experience-based, and evidence-based manner.

EMBARRASSING CONFESSION

I am listing out some commonly observed Scrum Myths, Mysteries, and Misconceptions from my experience.

UNFLATTERING WISDOM OF HIND SIGHT

SCRUM IS NOT THE END. IT IS A MEANS TO THE END… The end goal of empirically building strong, self-organizing Scrum Teams to help your business…

I see four common reasons an agile implementation doesn't get the benefits hoped for. These reasons include a failure to limit risk, long end-to-end delivery lead times, consistent cost-overruns, and no one knows why you do what you do.

This week I got a question from a colleague about the Scrum Retrospective. She's Scrum Master of a team that for sure has room for improvement.

In the Professional Scrum Product Owner course, we teach that high performing Product Owners are entrepreneurial. They not only act with the business in mind, they have the authority to make important decisions. What should we do now versus later?

 

You hear a lot in Agile circles these days about the ‘declining need for managers.’ We may not need the managers of yesterday but, make no mistake, we certainly need the leaders of tomorrow.

The Daily Scrum, or most of the time referred to as  the "stand up." Probably the most well-known event when we talk about Scrum.

Organizations who don’t understand why they want to become Agile also often take the wrong path to get there. Agility requires empowering teams and helping them make decisions on their own, learning from their experiences as they go. They must organize themselves, yet they often have Agile practices forced upon them.

I’m currently helping a small software shop within a government organization where multiple Scrum Teams are serving the same cause. They are building one product that has several sub-systems, which sometimes need to be integrated.

According to the Scrum Guide, the Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.