Community Blog

In this little blog I share some tips for multi-team Product Backlog refinement.

Back in the early days of Scrum, the Scrum Master role was exciting. The days of the pigs & chickens, the days when being a Scrum Master was considered dangerous. In those times there was the saying a dead Scrum Master is a useless Scrum Master  And even today I still use that when selecting a Scrum Master to work with.  If you never got fired as a Scrum Master then you probably did not show enough courage to achieve breakthrough improvements.

Some companies develop 1 product with 10s to 100s of people using Scrum. And they do that without adding any roles, events or processes to Scrum. They can do this because they use an organisational design that optimises for the right goals.

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.

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

In this little blog I want to share a simple canvas that I use to kick-off agile adoption and answer the following questions:

These days scaling Scrum is a hot topic. How can I use Scrum to deliver a big product with multiple teams? The most common approach I see at my customers is scaling Scrum by adding more Scrum teams with a Product Owner and Scrum Master per team.

Have you ever seen a Sprint Backlog that can be reused across Sprints? I have!  

I was coaching a number of teams and their Sprint Reviews were boring status meetings and few stakeholders attended.

Recently I gave a talk on the ScrumDayEurope 2014 conference.