Community Blog

We recently introduced our latest retrospective technique called Scrum Value Pairs, which helps Scrum teams improve areas of their process in regards to the 5 Scrum Values.

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 for a moment what frequently asked questions around agile transformations look like. Which questions do you hear most often as it seems agile transformation has been a hot topic lately?

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.

Many Scrum Teams are not very familiar with the Scrum Values as described in the Scrum Guide, and if, they have their own interpretation of it. We have also met many teams that were able to name the values, but not many live by them.

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. 

En Scrum cada Sprint tiene como objetivo producir un incremento de producto completamente terminado y que potencialmente puede ser lanzado al mercado. La inspección de este incremento permite la adaptación del Product Backlog, así como evaluar el progreso hacia el objetivo del Sprint y los objetivos de negocio.

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.

Product Owners have a tough job. I was in a Sprint Review recently where the Scrum Team had some stakeholders talking about an idea they thought was excellent. So, like any studious Product Owner, they immediately typed up the idea and added it to their Product Backlog.

Let’s look at some factors that cause diffusion of responsibility.

At a recent training class one of the delegates spoke about their present company, about how it was the most “Agile” place he had ever worked.

I share my thoughts in this video about the practices and activities the Scrum Master should be doing to increase his/her awesomeness. Hopefully it will help you to find the gap towards awesomeness.

Scrum se basa en un proceso empírico. El empirismo se basa en tomar decisiones basados en la información concreta obtenida de la observación que muestra el progreso del desarrollo de producto, el empirismo se basa en la experimentación para validar las hipótesis.

Every year I like to deliberately go somewhere far from the crowd to take a break and reflect. You can say that it's similar to a retrospectives. Often times I may not realised whether as a Scrum Master my service to the organisation is already effective or not.

A customer I was working with asked me to help out with the intake process for recruiting a new Scrum Master and a new Product Owner. I asked them what they had so far. They provided a clear job description describing what they wanted to see from the candidates.

Software developers are mostly guys, happy to work by themselves at night in dark rooms. And they turn coffee, cola and pizza into code. Right?

Defining Agile/Scrum for Marketing Scrum.org joined the discussion around Agile Marketing recently. This is an area close to my heart.

TL;DR: Scrum Master Duties, Serving a Single Team Scrum Master Duties: supposedly, a great Scrum Master serves only one Scrum Team—that’s at least a popular narrative in the Scrum community.

The Liberating Structure "Wicked Questions" makes paradoxical realities transparent. By doing so, you can engage in deeper strategic thinking and explore new possibilities.

Why is it that when the going gets tough, “agile” gets the blame? There is so much online bashing of [insert random agile framework or method] going on, that it made me wonder if there is a pattern behind it. I believe there is.

This blog gives a Lean perspective on the Agile Manifesto.

The unpredictability of the market and competitors are the main reasons of traditional management is not enough/fit to reach success.

Unclear language leads to incomplete transparency and ambiguity. The careful use of words like ‘bug’ will improve decision-making in your organization.

The core responsibility of the agile leader is creating the right context for the agile teams so they can thrive and self-manage. One of the characteristics of this context is all about ownership. In my book ‘Agile Leadership Toolkit’ I dedicate a whole part to this important topic.

How common misunderstandings about the Scrum Roles prevent Scrum Teams to become effective

In this blog post, I’ll explain how it’s possible for managers to work with Scrum Teams so no one has to worry about rebuilding their resume.

If Scrum were to be reduced to one purpose and one only, it would be the creation of a "Done" increment. Although the DoD serves as a crucial part of Scrum, it is also often neglected by many Scrum teams. Try out the DoD EvoCycle, a simple technique to effectively manage your Definition of Done.

Want to know if your team or organisation is suffering from Zombie Scrum? Find out with our free symptom checker and get help. And join our worldwide research into how teams work with Scrum, and what works for them.

“We want to be more agile in our delivery.” “We need to build up our teams.” “How can we do Scrum well?” Companies are asking themselves these questions every day and looking in various places for the answers.

‘Autonomy without accountability equals anarchy’ summarizes an essential design element of any agile organization. Without these checks and balances in place any aspiration to transform an organization is likely to fail.

This article will give you a clear explanation of how to become a good leader in this competitive world, and the techniques and tools required to reach the height of success.

Este artículo es la segunda parte de otro donde hablaba de como integrar el trabajo de los especialistas de UX y los desarrolladores de software.