This is a common question in my Professional Scrum classes.  It often comes up early when we are still learning the basics of the Scrum Framework.  And it comes up because people are already splitting their time between multiple Scrum Teams or are being told by their organizations that they will be.

I believe there are three things you need to do regardless of the framework, methodology or program you are embracing with your organization.

La agilidad puede verse como una estrategia de negocio, una estrategia empresarial a través del cual las empresas pueden mejorar, mantener y desarrollar su ventaja competitiva en el mercado.

While working with plenty of Scrum Teams and teaching Professional Scrum Product Owner classes, I observed a similar anti-pattern regarding Product Owners, which resembles anti-patterns of Scrum Masters who are not empowered.

Many thanks to attendees at my PAL-E workshop in London on 26-27 October who reviewed & debugged my change story for "what is organizational agility?"

Scrum uses a concept called a “Sprint” to eliminate the risk of complex product development and deliver value sooner to stakeholders. These Sprints are no longer than 30 days in length.

The role of Scrum Master is often completely new for many organizations, and often misunderstood. So what are the responsibilities of the Scrum Master? And what is a Scrum Master supposed to do the whole day?

Hello awesome people. Just a few weeks ago somebody from the internet sent me an email saying that his company already used Scrum but he felt that it is not more agile than when he used waterfall. 

Do you always hear the same people speak up when you present a new idea or when you ask for feedback? You might be dealing with an important voice here. The voice of the system! A voice any leader should (learn to) listen to. If you don’t? It will never go away!

In my experience, the Daily Scrum is the Scrum event with the highest anti-pattern density among all events. Learn more about the Daily Scrum anti-patterns that threaten to derail your transition.

El Framework Nexus de Scrum.org permite el escalamiento de Scrum a nivel de varios equipos, a nivel de varios productos y a nivel organización con varios Nexus usando Nexus+. Nexus es Scrum, Nexus no es un nuevo Framework.

User stories are business needs, not requirements in the traditional sense. They are oriented toward the user and a business need. The big difference between a user story and other types of requirements is that a story describes a business need, not the system’s functionality.

A User Story is the most widely used Agile Practice for capturing needs and requirements and describing Product Backlog Items. To get the most of any technique it is good to understand the why behind it not just the what. Let’s discuss how to write better User Stories in Scrum.

Just to set the scene, I haven’t figured this out yet. I can tell you my story, in all its ugliness. It’s based on a real story, but it’s changed significantly from reality to protect the innocent. I hope you still find my account useful.

Imagine a project with hundreds of people, a lead time in months, few releases a year. You could compare these as large cruise boats or tankers navigating for few weeks in the immensity and emptiness of the oceans and seas and then stopping to ports very far away from each other.

As promised, here is part two of the three-part blog series, inspired by the writings of John C. Maxwell, “The 15 Invaluable Laws of Growth: Live Them and Reach Your Potential.”

Hi Duncan, I took your Scrum Training class a couple of months back. You mentioned if we had any questions, we could email you and I have an interesting situation I found myself in regarding QA’s in our Scrum teams.

I often wonder about the Trustpilot reviews straight after a workshop. Did I entertain? Did I perform? Were attendees satisfied? Are attendees inspired? It matters. I just think it matters more if the workshop made a difference to the work lives of attendees. I can't take credit. The client does the hard yards.

When working with a flow-based Kanban system there are a few statements that I would suggest most teams should bear in mind.

Hello awesome people. Back at it again with new learning from the trenches. Over the years working with Product Owners who mainly work in large corporations, I see common challenges.

During this Liberating Structures strategy for Scrum meetup we addressed dealing with uncertainty — a particularly useful skill in highly competitive markets. Learn more about how to train and grow the resilience of your team when dealing with the unexpected.

Food for Agile Thought’s issue #214 delves into Scrum agility; we follow a notion for time-based estimates, and we learn more about similarities and differences between Cynefin and the Stacey matrix.

As part of the Scrum.org webinar “Ask a Professional Scrum Trainer - Martin Hinshelwood - Answering Your Most Pressing Scrum Questions” I was asked a number of questions.

In organizations in which agile transitions take place, the ancient English proverb Blood is thicker than water is frequently appropriate. It is decided to adopt agile working, there is talk of Scrum, self-organizing teams, Sprints, standing meetings, sticky notes on the wall, etc. etc.

It's been a while since I wrote a blog, here is some good news, this is part 1 of a 3 part blog series, inspired by the writings of John C. Maxwell, “The 15 Invaluable Laws of Growth: Live Them and Reach Your Potential.”

While teaching and consulting, I’ve had many existing Scrum Masters pull me aside looking tired, frustrated, and worn out.

In my Professional Scrum classes, I always get asked about best practices.  It may be about facilitating events, Product Backlog refinement, defining value, forming Scrum Teams, or creating good Sprint Goals.

People always have questions and concerns about Risk management and Autonomy in the Scrum Team...

Hello awesome people. It's me again with a new learning from within a Scrum Team. The Development Team I was working with around 3 months ago challenged the Product Owner about the User Story she brought into the Sprint Planning.

Your Sprint is over. Your increment is “Done”, you have coded cleanly, your unit tests and integration tests are bright green, you are proud of your work. The Sprint Review is running smoothly. The Sprint Retrospective allows the team to find 1 or 2 areas of improvement without revolutionizing the world.

Teams often run through the motions of Scrum and get very hung up on story points, velocity, committed percentages and as a result struggle to deliver value. But what I’ll share today is what unlocks the value of Scrum;

End of September we went to Stockholm with 15 agile leaders. We wanted to visit several companies in and around Stockholm to see how they created a thriving environment for agile teams.

A few years ago, I was part of a team that was starting to work together under very difficult circumstances: We had to finish a showcase in the Industry 4.0 area within just six weeks.

As part of the Scrum.org webinar “Ask a Professional Scrum Trainer - Martin Hinshelwood - Answering Your Most Pressing Scrum Questions” I was asked a number of questions. Since not only was I on the spot and live, I thought that I should answer each question that was asked again here, as well as those questions I did not get to.

I'd like to share another story with you... Thank you Paul and Charlie for sharing your story. It moved me and left me with huge smile on my face. 

A few weeks ago we considered the Agile Manifesto from a lean perspective. We saw that it is possible to map the 12 agile principles to the 7 canonical “Lean Wastes” in terms of a mitigation approach.

Hello awesome people. I want to share with you my recent experience and discussion with a senior manager who needs advice on how to measure his organisation agility.

There are four key words in the first value of the Agile Manifesto: “Individuals and their interactions over processes and tools”

Imagine you’re a Scrum Master and the line manager of your team believes that the best sign for a successful agile transformation is a steady increase in the Scrum Team’s velocity.

In the world of tech, many industry giants such as Google choose to use a management framework known as Objectives and Key Results (OKR).

The legendary Steve Trapps has been talking to me for months about featuring in an interview. So here we are, I finally agreed and we spent 25 minutes talking about me; obviously mainly avoiding being narcissistic.

As part of the Scrum.org webinar “Ask a Professional Scrum Trainer - Martin Hinshelwood - Answering Your Most Pressing Scrum Questions” I was asked a number of questions.

Warning - this post is not about Scrum. It is about Technical Debt in my home!!! Please do not judge me!!

If you want your organization to become agile, adding more whiteboards to the workspace will not suffice. You have to abandon the idea that the workspace is an assembly line for white-collar workers. You need to let go Taylorism. We are now in the age of the creative worker.

As part of the Scrum.org webinar “Ask a Professional Scrum Trainer - Martin Hinshelwood - Answering Your Most Pressing Scrum Questions” I was asked a number of questions. Since not only was I on the spot and live, I thought that I should answer each question that was asked again here, as well as those questions I did not get to.

Does your firm exceed your customer's expectations regularly? Is just meeting expectations good enough in your market? Businesses pursuing an improved ability to deliver customer value using Scrum face numerous challenges.

Sprint Goals are one of the more elusive parts of the Scrum Framework. Most teams know they are important, but few use them - for a variety of reasons. In this post, Barry Overeem and I bust the myth that Sprint Goals are optional in Scrum. And we make an effort to show what makes them so vital in the face of complex work. And more importantly, what you can do to start working with Sprint Goals from now on.

The Kanban Guide for Scrum Teams aims to help Scrum Teams leverage the ideas and practices of Flow and Kanban in a way that is coherent with Scrum as defined by the Scrum Guide.

Last year, I ran a (non-representative) survey on how Scrum Masters are allocating their time when working with a single Scrum Team. Much to the surprise of many readers, the direct Scrum Master engagement with a single Scrum Team of average size and a typical 2-week Sprint turned out to be about 12 hours per week.

I have my own biases,  having seen co-located teams work very well and having struggled with “dislocated” teams, I often recommend my clients to reconsider “dislocated” teams.