Working with the Professional Scrum Trainer community, and particularly with Ken Schwaber as one of the Professional Scrum Master Stewards has been a very rewarding learning journey.

This is the fourth in a series of posts exploring Scrum Mastery. In our first post, we introduced the four dimensions of Scrum Mastery:  Team Identity, Team Process, Product Value, and the Organization.  In this post, we will explore the product value dimension.

Dear friends, I want to share an unusual view of Scrum with you. Perhaps you've never thought about such a point of view before. I hope it will be useful.

This info is about Joel Gascoigne, CEO of Buffer, who facilitated social media management. Ok, how do I know? In fact you, like everyone else, can see the salaries of around 75 people, who are Buffer's employees including its CEO from the link (you can find at the references section) shared by Buffer.

Does your Finance Department discourage Agile software development because it would all be charged to operational expense?

Getting your thoughts down on paper is a great way to reflect on and sort out the complicated aspects of our industry. The three Vs of Product Ownership is an example of this and is a major theme of our book — and the topic of this post.

Throughout my career I have helped many leaders adapt their style to one that better supports teams reach a high-performing state. Across a wide range of different industries the patterns of high-performing teams, and how leaders help shape them, have some striking consistencies.

When delivering a Professional Scrum Master training or helping clients creating awesome products with Scrum, some people ask me how to adapt (downgrade) Scrum to make it work in their organizations.

This is the third in a series of posts exploring Scrum Mastery. In our first post, we introduced the 4 dimensions of Scrum Mastery. In the second post, we explored how to grow a strong team identity. Now we will explore the team process dimension.

If you worked in large organizations you have probably heard about the term "dependencies". I am convinced that dependencies need to be eliminated, not managed.

Often I hear people say that Scrum does not take care of risk: there is no risk log, risk is not on the agenda of the Sprint Review or Retrospective as a standard agenda-item. The Developers need to be accountable for the quality of the product and how it's made. And ultimately each role in Scrum has accountabilities that effect risk. But ... if there is not one person accountable for quality, being on time, within budget, building the right thing... How is risk managed in Scrum?

The Times News were on a journey to re-platform their system. While working diligently behind feature flags, using elements of Scrum, it wasn’t clear to the stakeholders the value being delivered and how well the teams were progressing towards their end goal.

This is the second in a series of posts exploring Scrum Mastery. In our first post, we introduced the 4 dimensions of Scrum Mastery.

The University of Applied Sciences at Albstadt-Sigmaringen (HSAlbSig) is respected for its well-balanced curriculum. However, even the best curriculum can benefit from outside sources and experts.

Bottom line - Toyota Improvement and Coaching Kata is the perfect partner for flow-based retrospectives.

Agility is the ability of an organization to adapt to new conditions and to change its direction. The modern service-based format of the production-based economy of the previous century renders the competence of companies to change even stronger than before.

"An Agile Coach know more than just Scrum", said one consultant in a boardroom meeting, "he/she knows organisation dynamics, executive coaching and other Agile practices like Kanban and DevOps", he continued.

Bottom line - PSK improves the performance of Scrum teams, but WiP must be optimized for flow and work in progress should not relatively age compared with other in progress items

Last year I reached a very important goal I had set for myself: I became a Professional Scrum Trainer (PST) on behalf of Scrum.org. But why was this so important to me, and how did I get on this path?

Behavior Driven Development (BDD) and Test Driven Development (TDD) are Agile Practices that are complementary to the Scrum framework. Both are focused on improving the quality of the software product under development. That said, they approach building valuable software from different perspectives.

We all understand, every field has a skill quotient that you need to achieve to be able to qualify and deliver. It’s a Doctor of Medicine for someone who wants to practice medicine, be a Doctor, and save lives.

Imagine this, you are at the weekly company meeting in a room of 60 people. All of them are co-workers who you have been working with for several years. You feel engaged and committed to the goal set by your company. 

The purpose of Scrum is to deliver Increments of releasable functionality. So at each Sprint Review, a “Done” Increment is required to make transparent the progress made by the team.

There is often confusion when organisations transition to an agile way of working, particularly with the mapping of roles. This blog explores the role of Project Managers in Scrum.

From my go-to barbecue chicken to practicing Scrum, I have tried adding many different ingredients over the years. Is there a point when too many ingredients get in the way of the original recipe?  Would the Scrum framework in your world of work be more optimal with less of them?

Bottom line - WiP limits must be applied to improve flow of the delivery of value. It's a key lever to improve the performance of Professional Scrum Teams, and it's required by the Kanban Guide for Scrum.

The world is becoming more technologically complex, interdependent, and culturally  diverse, which makes the building of relationships more and more necessary to get things accomplished and, at the same time, more difficult.

When I first embarked on my own journey towards Scrum Mastery, I was eager to learn.  I attended Scrum training courses.  I went to and eventually spoke at agile conferences and meet ups.

Impact Mapping is a powerful technique that helps teams understand how to link the work that they do with results that their organizations would like them to achieve. We’ve been using this technique for a while in our Scaled Professional Scrum and Professional Scrum Product Owner courses.

A common question I hear in Scrum training courses and in coaching sessions is, “how much Product Backlog refinement should we do and how much detail should be in the Product Backlog?”

Why are there so many meetings?" is a complaint a Scrum Master often hears, especially from team members who are new to agile practice. It's the refrain of those in an organization which is more likely to be doing agile rather than being agile.

I need to get something off my chest. It's a personal thing, so don't mind me. But maybe it will get you thinking also. It's been on my mind for quite some time. Troublesome sometimes.... Here it goes.

I was presenting at a local user group and wanted to explain the concept of what it is to be a Servant Leader. I find that by providing an example of something people can easily relate to the concept.

In this post, we bust a myth that is at the heart of why refinement feels like a chore to many Scrum Teams: the belief that ‘Product Backlog refinement’ should be done as one or more required ‘meetings’ that must be attended by everyone in the team. We also offer some alternative approaches that fit more naturally with the flow of development.

Over the centuries, humans have managed to adapt to many situations and evolve to become what we are today. History shows that we have an innate ability to adapt and evolve. This remains valid as part of a change in business, such as the adoption of Scrum.

What we avoid is still being processed and affecting our thoughts, emotions, and behaviors.  Sometimes we are aware this is running in the background, and we catch ourselves thinking about it.  Then we try to distract ourselves.  Often we don’t even have awareness, and the effects still show up.

Based on the feedback that I have received from my blog about the most popular blog articles, I have decided to do the same for the Scrum.org video series.  Over the past few years, we have generated more than 160 videos to help people learn more about Scrum. Updated June 26, 2024

A description of the Liberating Structure "User Experience Fishbowl and how we've used it within Scrum.

People who attend the PSM course or the Professional Scrum Foundations (PSF) course are given two attempts at passing the Professional Scrum Master I assessment.

In this blog article, we provide a quick overview of the most viewed blog articles over the past 18 months, giving readers insight into what they mind valuable to read.

Agile Metrics are meant to serve certain purpose(s) and can be very useful if leveraged appropriately. In this series, I want to share my experiences of how metrics may be used, abused and effectively become focal point of failure of Agile adoption in an organization.

I recently finished writing a book with fellow Professional Scrum Trainer, Don McGreal, titled,  "The Professional Product Owner: Leveraging Scrum as a Competitive Advantage." I learned a lot from this experience and wanted to share it here. 

When many organizations wanted to incorporate Scrum, it was a big disappointment. The leaders saw it as a failed experiment that did not yield the positive impact one would hope for. Nevertheless, I have witnessed the transformational results and great rewards an organization reaps when it truly embraces Scrum values.

Vor kurzem haben die beiden Autoren des Artikels sich einmal mehr mit der Frage beschäftigt, wie sich erfolgreiche und weniger erfolgreiche Teams unterscheiden und was die Erfolgsfaktoren für erfolgreiche Teams sind.

One of the new concepts we introduce in the Kanban Guide for Scrum Teams is the Service Level Expectation, defined as: An SLE forecasts how long it should take a given item to flow from start to finish within your workflow.

One of the key Kanban practices is Limiting Work in Progress. If you want to be pedantic, actually what this practice aims for is Reducing and stabilizing Work in Progress. This improves flow, provides predictability, and is actually even more important for creating a pull-based Kanban system than visualizing your workflow using a Kanban board. I worked with several clients that limited their WIP but didn't use Kanban boards. One could argue that maybe this practice deserves to be first in the list of Kanban practices, ahead of Visualization.

In the Kanban Guide for Scrum Teams and the Professional Scrum with Kanban workshop, we introduce 4 key flow metrics that we believe Scrum teams can use to improve their flow.

As a servant-leader, the Scrum Master sometimes has to make very difficult decisions. This might even include removing someone from the Scrum Team. Obviously, this a difficult decision that should not be taken light-hearted. In this post, we'll share some perspectives on the kinds of situations where removal is a viable option and some tips to do help you do so in the best way possible.

It is beyond debate I'm afraid; business projects are prone to failure – particularly large and complex projects. There is some irony in that, no? The more you hope to achieve, the more likely you are to be unsuccessful. Learn how the tech industry uses the Scrum Framework to curb failure and deliver customer value.

I often use innovative games as a useful addition for Sprint Reviews. They help clients better understand and thus improve the product. One of my favourite games is the Speed Boat. The Speed Boat game explores user’s pains and jobs.