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.

Do your team members have a tendency to pick up the next task to work on in case they get stuck with current task because they are measured for ‘utilization’? Such multitasking isn’t just bad, but also has harmful effects and causes stress on the person as proven by a study at Stanford University.

Over a wet weekend in the UK, my 12 year old daughter was looking for something to do and decided to draw a poster to while away some time. My daughter decided that she would help me by making a poster about Scrum ( honestly!, I am not making this up. I didn't realise how much I talk about a scrum at home.)

I recently wrote an article for Entrepreneur on why Tech Companies need a code of ethics which got me thinking more broadly about the role of ethics, values and professionalism and why the agile community have been thinking about it more than most.

Vor kurzem habe ich mit einem Team die interessante Frage aufgeworfen, ob Softwareentwickler Leidenschaft für das Produkt das sie entwickeln benötigen oder ob Leidenschaft für Technologie wichtiger ist.

I remember going on a PRINCE2 course a few years ago, and trying to determine how this celebrated stage-gated framework might be applied to an agile mode of delivery. I was employed in the UK public sector at the time, and I had come to know how instrumental "PRINCE2 compliance" can be to the striking of a defensive organizational posture. When all eventually fails you must be able to show that you followed appropriate procedure.

In this blog, PSTs Sjoerd Kranendonk and Wilbert Seele explain how to achieve more and risk less by being a less visible Product Owner. In the Scrum Guide the following is written about the role of the PO: "The Product Owner is responsible for maximizing the value of the product and the work of the Development Team."

One of the reasons Scrum allows opportunistic discovery is due to its short and fast feedback loops. With the aim to build a high-performing Team and to get the best potential out of each individual and to help them be successful, Agile Coach needs to provide straight feedback to them. But giving straight feedback is a daunting task especially since we are dealing with human emotions. In general, just the utterance of the statement, “I would like to give you feedback” sends the heart racing for a lot of people.

If you give a developer a verbal warning for surfing social media all day, you are crushing their autonomy. Insisting on core hours of 10am-4pm violates self-organisation. Personal development plans are so PRINCE II. Right? Well, maybe. On the other hand, having someone relatively experienced and influential on your side, to help shape your career and keep you off the annual redundancies list might actually be quite useful.

In this blog post we've shared our ideas on "Your Scrum Master Journey" and the first steps we've made at a Dutch customer.This week Christiaan Verwijs and I facilitated a workshop at a Dutch customer in which Scrum Masters could provide a pitch for participating in "Your Scrum Master Journey".