It was only about 30 minutes into the meeting when the senior developer uttered the dreaded words: “Rewrite”.

"There are no shortcuts when it comes to getting out of debt" - Dave Ramsey

Today Scrum.org announced a partnership with the DevOps Institute to provide a foundation to building stronger working relationships between the Scrum and DevOps communities

When is a Scrum Team successful? Which criteria do you use to determine if a Scrum Team is doing a great job?

The Scrum Guide talks about coaching as a part of the Scrum Master role.  First, let's define what coaching is.  You can find many definitions, and here is how I describe coaching.

Over the last weeks I've been working on a paper about the role of a Business Analysts within Large Scale Scrum, and I thought I'd write a little post on it too, here it goes.

The blog post covers 8 preferred stances of a Scrum Master and common misunderstandings.

I've recently been involved with several Scrum Teams that are struggling to have the right level of detail in their Product Backlog items. Some symptoms: difficulty during Sprint Planning sessions, a massive or very small Product Backlog, or a lack of understanding during a Sprint. All of the teams I spoke with had refinement activities in place.

The Scrum Values are easy to remember, but it can be difficult to understand what they mean, how to apply them, and how to recognize them in teams and individuals. These values are essential to maximize the benefits of Scrum. In this article, we look at how courage is essential in solving complex problems and growing high performing teams.

As I get older, I'm turning into one of those annoying nostalgic-types who reminisces too much. Things were better back in the day, son. We had standards see, and there was less of this "dumbing-down". Yip.

Having ‘agile expertise’ is in high demand these days – it seems everywhere I turn there are companies and recruiters looking for agile experts. Agile knowledge is important, but the expertise of being an effective change agent is even more important.

The Scrum Values are easy to remember, but it can be difficult to understand what they mean, how to apply them, and how to recognize them in teams and individuals. These values are essential to maximize the benefits of Scrum.  In this post, we see how openness is crucial when we are dealing with complexity and unpredictability. 

The Scrum Values are easy to remember, but it can be difficult to understand what they mean, how to apply them, and how to recognize them in teams and individuals. These values are essential to maximize the benefits of Scrum.  In this post, we look at how focus is essential in order to get anything meaningful done.

"Gross ignorance is 144 times worse than ordinary ignorance" - Bennett Cerf

In this article I'll describe two topics that I've used as a tailor made Product Owner self-assessment. One is about Roman Pichler's Product Management framework. The other concerns the acronym DRIVEN which is described in Geoff Watts new book "Product Mastery - From Good to Great Product Ownership".

In this blog post I've shared my experiences using the Team Radar as a Retrospective format.

As an agile coach, I find that organizations often have a narrow and constrained view of where agility ought to be practiced.

Do you want to work in an ecstatic state, losing track of time, doing meaningful work? Here’s how using Scrum helps!

If someone asked you “what is the role of the Project Management Office in an agile organization”, what would you say to them?

A review of the Scrum Guide section in the Sprint Backlog to consider and debunk the myth that the Sprint Backlog is a fixed Commitment by the Development Team.

I was talking to a company that is implementing the Spotify model and needed some help.

As part of the on-going Scrum Myths series at Scrum.org, here are three myths related to people skills.  When I say people skills, I mean topics like emotional intelligence, emotional IQ, and person-to-person interactions.

In this introductory-level article we look at the mechanics of a Sprint, and at how team members are expected to collaborate in order to produce a release-quality increment.

A Scrum myth that I have encountered: Not finishing all Sprint Backlog Items in a Sprint is perceived as a failure. I have seen organizations go as far as implementing performance indicators around Sprint Backlog completion percentage (yikes!).

The Scrum roles connect with the three drivers of motivation: Autonomy, Mastery and Purpose. Discover how.

This myth is my favorite. There are three challenges with this myth. First, it misses the point of Scrum. Second, it sets teams up for failure. Third, it's impossible to prove.

Per a January 20th, 2017 article by Daniel Shapero, VP of Talent Solutions and Careers at LinkedIn, the role of Scrum Master is in high demand. It’s ranked number 10 on his list of most promising jobs of 2017.

Let’s start with a question. When is the Sprint Planning over? Usually, the first answer that comes to mind is “when the time-box expires”. It is a good answer. However, Sprint Planning is a maximal time-box.

“What is a good speed to drive?”. The answer depends on a lot of things like: where do you drive (in a residential area, on a highway), are there speed limits, what are the weather conditions, etc.

Your team has been trained and coached to deliver new chunks of software in a short time frame. Those using Scrum will be able to deliver in a Sprint. Those using Kanban will deliver as soon as their small feature is done.

“I added a Refactoring Story for the next Cleanup Sprint”

"Not a tester, so what are you then?" you might ask. Being that offending is generally not helpful. Unless you try to catch the attention as I do in this blog post ;-)  

Ok... Let's make this a short one.

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.