Through my professional experience, while serving my customers, working with Scrum Teams and training people in Professional Scrum, I have observed that some Scrum Masters only work to serve the Development Team and the Product Owner.

Ask any Agile practitioner these days what Agile values are and he/she, most likely, will recite you some lines from the Manifesto for Agile Software Development.

As many Professional Scrum Trainers have experienced, there is always a good discussion around the Sprint Goal. A similar discussion recently led me to address this not so well understood aspect.

One of the most important things we can do to help individuals and teams improve is coach them to embrace the agile mindset. The Manifesto for Agile Software Development provides values and principles to help guide teams in navigating the complexities of product delivery.

Our trainings around Scrum aim at gaining knowledge in applying Scrum to improve on product development. To achieve this in an ideal way, we deliver our training in the language spoken locally.

Building (and hiring) a great team takes time and effort. Patrick Lencioni’s “The Five Dysfunctions of a Team” became a staple reading in an Agile community these days.

A common phrase that I use in my classes is that Scrum is like the poker game Texas Hold’em; it only takes a few minutes to learn but a lifetime to master.  The “few minutes” may be a bit of a stretch but my students get the point. 

What is Scrum Team Velocity? This is a tricky one, and you need to be answering it in the context of the organization you are interviewing with and its complementary practices.

I have been fortunate enough to have a successful career as a change agent. I leverage my experience of navigating the world with Cerebral Palsy — a world that was not yet ready to deal with a person with a disability — to help companies deal with their disability: their inability to change from the status quo.

Have you heard the term “lamp post metric”? [i] This is a measurement that is easy to gather and may even seem like common sense. If you lose something on a dark night, where are you going to look?

In the previous 3 articles on the Agile Metrics topic, I reviewed some of the most important Agile metrics that ActionableAgile software helps you to get with ease. Here we take a look at the ways the software can help you in forecasting your work.

In the first part of Getting to 85 – Agile Metrics with ActionableAgile we looked at the Cycle Time Scatterplot created by ActionableAgile software. The second part was all about the CFD. Now it's time to look at the Aging Work in Progress chart.

This question "What is the duration of a Sprint" is seemingly simple, but depending on the interviewing situation, company, interviewer, and their familiarity with Scrum you might need to give them more or less details and answer additional questions your answer might bring up.

In today’s complex ever-changing work, we need to make full use of the collective intelligence of the whole team, even if the whole organization to be able to solve and deliver on these needs.

In the first part of Getting to 85 – Agile Metrics with ActionableAgile we looked at the Cycle Time Scatterplot as generated by ActionableAgile software. That piece also discussed some ideas the scatter plot could bring about and conversations that potentially might occur.

Scrum and Kanban are a great combination. With this insight more and more Scrum Teams become aware of terms and phrases used in Kanban. Like 'WIP'.

The topic of Agile Metrics inevitably comes up in many situations and conversations. For the Scrum practitioners these somehow are a subset of Velocity and Burn ups and downs. Now, there's a whole world out there, that operates with much reacher vocabulary of metrics. Professional Scrum With Kanban (PSK) by Scrum.org brings that world of fantastic Agile Metrics back to Scrum. In this series of posts I will review those metrics using great software - ActionableAgile, provided by fellow PST, Daniel Vacanti.

As a Professional Scrum Trainer for Scrum.org I get to think about the Definition of "Done" and its meaning a lot.

As leaders, we are connected 24/7. Being connected with our mobile devices has meant we’re always available all the time. We have the pressure to move faster. Do more with less time. To our benefit and also to our detriment, we end up doing it.

What exactly is “agile” or even an agile leader? This is one of the biggest problems our industry faces. Ask a room full of people to answer and you may get as many answers. Common ones include “it’s a mindset” or “it’s a software methodology” etc…

A few days ago, I was observing a Sprint Retrospective. The Scrum Team decided to work on the Definition of Done (DoD), identified as the most important topic to adapt for the next Sprint. The discussions were open and animated, when an unexpected discussion emerged during the session.

An Agile mindset is crucial in management roles for organizations that are moving towards Agility. I observed this while working in various organizations and currently am a witness of it while assisting my customers.

There has been so much written about Velocity and its impact on teams yet it is one metric that eludes everyone and keeps cropping up whenever there is discussion around productivity.

Hearing a senior executive announce "We're committed to becoming agile!" is not the bombshell moment it used to be. It no longer indicates a personal revelation or board-room epiphany.

As a Global Vice President at a major financial institution, I spend two days a week teaching Product Ownership, Agile Leadership, Scrum, and Kanban to 25 employees per week. As a Professional Scrum Trainer, I’ve taught over 1500 people through the years. This experience has made me a better leader.

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 2019 Scrum Master Trends Report by Scrum.org and the State of Agile 2018 shows numbers that provide insight in the maturity of agile adoptions.

The Scrum Team consists of accountabilities devides over three roles. The only three roles needed in Scrum. But all needed! And all equally important to be successful. If we would practice Scrum within our companies the way described in this way we can all be successful in delivering incremental value to our customers each Sprint.

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.

Questions about agile certifications (especially those from Scrum.org) are an integral part of my routine. People always come to me saying that they are going to act as a Scrum Master / Product Owner / Developer on an agile project and they want to know what to study and what's the best first certification.

Struggling to integrate UX Designers into Scrum? Use these actions to make Scrum teams more user-centric and UX Designers full-time members of the Scrum Team!

We all know that developing ourselves intellectually requires sustained dedicated effort toward continual learning. We take classes, read books, read from experts online, we find mentors, we collaborate, and many of us learn by teaching others.

The Scrum Guide is markedly ambitious in the standard of professionalism it demands of a team. Development Team members must be self-organizing and cross-functional, to the point that they will repeatedly and sustainably create a valuable product increment...

Compare the use of Scrum's Definition of Done to the professional procedures in other fields such as surgery and aviation.

In the last decade, we have realized that we cannot plan all up front in a linear process to develop software. We are solving complex problems, which require us to use an empirical process, lean UX practices, and a supporting technology platform that allows us to build, measure, learn and apply the learning in a repeatable fashion.

I am learning awesome things that can relate to our world of “Agile” and “Product Ownership.”

This blog post is about what I learned working with my team as a Scrum Master and improved between one year using Professional Scrum with Kanban.

In this article, I will discuss the dangerous dynamic that can arise when a Product Owner, Scrum Master, or the management of an organization focuses a Development Team on velocity.

Scrum limita el riesgo, proporciona transparencia y ayuda a la adaptación a través de los Sprints y la entrega alto valor. Scrum funciona bien con equipos auto organizados que tienen todas las competencias para entregar el incremento de producto.

Scrum is easy to understand, yet difficult to master. The Scrum Guide says so and it's true. If you have worked with Scrum in your organization you probably recognize it also. It's not difficult to start with Scrum.

Scrum is intended as a simple, yet sufficient framework for complex product delivery. Scrum is not a one-size-fits-all solution, a silver bullet or a complete methodology.

In my experience, the word YES is one of the biggest things holding the organization back from focusing on their desire towards innovation, disruption, agile, or more customer-centric.

The Professional Scrum with Kanban (PSK) class was launched a year ago - Feb 26 to be precise.

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

In this blog post, we describe how to use Conversation Cafe, as a Liberating Structure, within Scrum.

In 2016 the Scrum Values were added to the Scrum Guide. In this article I share a workshop I run several times, with excellent feedbacks, hoping that you'll see value in reusing it in your working environment.

I just celebrated my 48th birthday. This is quite a milestone because being born with Cerebral Palsy the odds were not in my favor to reach this age, let alone a professional career in leading change and leading leaders.

In January 2019 I was at Prowareness in Delft, Holland, and attended the 2 day Professional Product Owner course delivered by Ralph Jocham, co-author of The Professional Product Owner book. I thought I'd share my thoughts on the course with you.

No hay necesariamente una relación directa entre la complejidad de un PBI definido en términos de puntos de historia y el tiempo de desarrollo. Es decir, un PBI o historia de usuario que tiene mayor complejidad en puntos de historia puede terminarse en menos tiempo que un Item que tenga menos puntos de historia.

As people become more empowered and capable of taking ownership of their process and executing on their decisions, the next area to focus is raising the bar. This is about a drive for continuous improvement. In this article, we look at 4 ways to raise the bar.