Community Blog

When we are confident that we know everything, certain that our perspective is correct and our plan is good, we miss things. Sometimes these things are critical.

In this blog post, PST Ravi Verma shares tips on how to manage outcomes with Evidence-Based Agility

Velocity has become a word specifically associated with measuring how well a Scrum Team is doing. This metric is often associated with negative feeling new Scrum Teams are feeling towards Agile in general.

We've all had challenges with various stakeholders coming to us with a whole bunch of different information and wanting a whole bunch of different things. Who do I listen to? What’s most important?

There are loads of blog posts, articles and podcasts about agile - what it should be, what it should do, how it should look? The problem is that a lot of what’s out there is hypothetical and not based on field experience.

I'm slightly uniquely placed in that I am a Scrum Master, Professional Scrum Trainer and Scrum Coach, as well as being a Rugby Coach, and as such I've always been intrigued by the name Scrum...

Complaining is like releasing gas. It’s a natural occurrence. Everyone does it. But no one wants someone else to do it next to them. How to complain less and do more by Sahin Guvenilir.

“Thanks for the feedback!” “I’ll put it on the backlog.” Or, the dreaded: “Let’s talk about that offline.”

The term organizational agility is everywhere these days, but what does it really mean? Can we even define it at all? Deepen your understanding of the manifesto and why it is essential to implementing healthy agile that delivers meaningful value.

Have you ever noticed people keep talking about things, but they've not aligned with what their words mean? I have seen agility measured as the number of "agile teams" and the "number of training attendees" more often than I like to admit.

“I keep six honest serving men (they taught me all I knew); Their names are What and Why and When And How And Where and Who.” - Rudyard Kipling

I need your advice to solve a personal problem...

Scrum is hard. To be more specific, learning Scrum is easy, using Scrum to develop complex products is hard.

Story Points and velocity have been used for many years in the Scrum community and have been engrained so much in the way that things are done that most folks believe that they are part of Scrum.

The following are the changes that struck me the most in the 2020 Scrum Guide...

In Leslie Morse's first Scrum.org blog post she explores the intersection of professional coaching and agile coaching, and the opportunity we have as agilists to overcome the limitations of an industrialized mindset and create space for ushering in the future of work.

If you currently are in search of the answer to this question, enjoy this video.

Lors de mes formations Scrum ou coachings en entreprise, il n’est pas rare que les participants expriment leur souhait d’accéder à davantage de contenus Scrum de qualité en français. ..

I've learned and experienced that most symptoms can be traced back to not adhering to the Scrum Roles. Let's have a closer look at the Scrum Master role.

What is agile – I asked everyone what it means to them. Got responses like “being flexible,” “respond faster,” “move quickly,” and “adapt to change,”

"He puts everything in place to get the ball up to the final third of the pitch and then trusts his team to finish the job in the only area of the field that can’t be planned for."

In this post I want to explore whether the Increment, a core concept to Scrum, needs to be changed for Scrum in a non-IT context. In future posts, I will do the same for the Definition of Done, or other concepts that may provide a better understanding of Scrum when applied to non-IT context.

As a servant leader, a Scrum Master focuses on the needs of others, before her/his needs...

In my daily life as a Scrum Master, I witness many crazy situations. I want to share my experiences via this comic series featuring Koos Coach, the silly Scrum Master struggling to understand and master Scrum.

The most important question to stakeholders is often “When can it be done?” There is a lot that goes into answering that seemingly simple question. What is involved in the work?

In a series of blog posts, I want to share how you can use Systems Thinking to resolve complex problems such as software teams not delivering the right software fast enough.

Earlier this year, I released the complimentary Scrum Poster with the goal to give Scrum Teams around the world a medium to see the Scrum Guide in visual form.

Hey everyone. How has your week been going? We are entering summer here in Perth. And in today's vlog, I'd like to share with you how to evaluate the Scrum Master's performance.

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;

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.

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.

“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.

The traditional approach of RFI – RFP – Review – LOI is neither lean or agile. The Lean Agile Procurement approach reduces the sourcing cycle time to days, with collaborative clarification of the product with prospective partners while reducing the risk of a poor partner and company evaluation.

La velocidad es uno de los temas de Scrum más discutidos online y offline. Sólo hace falta acercarse a la comunidad de Scrum Masters en Facebook para comprobar como muchas de las cuestiones planteadas están en la linea de la velocidad de entrega de los equipos de desarrollo de Software.

One of the regular listeners, Daniel Lachmann-Nishibane, appeared on www.agile.fm after he has participated in one of my recent Professional Agile Leadership (PAL-E) certification courses in Munich Germany.

An executive is a person who owns the strategy or sets the direction of travel or sets justifications for spending. This exec could be the Product Owner for a chunk of the organization.

The purpose of Scrum is to create a potentially releasable Done Product Increment, in order to realize business value. Many teams struggle in improving their Definition of Done. The technique described here allows for greater transparency on what the Definition of Done is, and what the next steps are.

Most organizations are using Scrum, however, many of them feel like the agility of their organization has degraded, and they might be right! Often, using Scrum starts out as a way to improve development efforts coordinated within an IT division or department, but that is not the most effective organization structure to potentially get maximum benefit from Scrum.

I first met Sally,and then later Francis her husband, at a local user group - Agile in Leeds, where Sally delivered a fantastic 10 minute talk on how she implemented Scrum to help Francis with ADHD. 

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.

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

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.

Your team has been trained and coached to deliver new chunks of software in a short time frame. Those using Scrum will be able to deliver in a Sprint. Those using Kanban will deliver as soon as their small feature is done.

This is a very common myth, frequent on people used to develop software only within the context of a closed scope (traditional project).

People always as ask me if agile is just for software. Saying agile is just about software is like saying software is just about science. Initially, computer science was about replacing manual processes. Now, it’s about creating human experiences.

THE (MIXED) BLESSING OF NEXTGEN REWRITES  About 10 years ago, I experienced the mixed blessing of being part of yet another nextgen rewrite project.

Clients and training attendees ask me "Can you use Scrum for something else than software?”. What they usually mean is building some other products or organizing team’s work. Let’s explore a more exotic idea.