Return to site

SCRUM REBOOT: THIS TIME WITH THE VALUE ➡️ Common pitfalls in Agile transformation

· scrum,team,mashup

🪞 Could the scrum team skip the retrospective?

The Sprint Retrospective provides the Scrum Team with the opportunity to review how they are working, identify issues and make decisions about how they can improve.

It is at the heart of empiricism allowing us to inspect and adapt how we work.

Even if the team sticks to the framework, respects the roles, and maintains the artifacts, they will always have the opportunity to improve by learning from their missteps.


📺 The Sprint review is not a sprint report.

Do not trick/fake the sprint review, it is an honest exchange with the stakeholders that could underwhelm, disappoint, or even upset them (openly and with respect of course) in order to get the most relevant feedback.

It should foster transparency and honesty.


🤹♀️ The Scrum master is not a scrum manager.

We’ve seen this everywhere.

The product development organization adopts Scrum and the team leads or managers become Scrum Masters.

The Scrum master keeping his manager status makes the Scrum team under a hierarchical report that prevents openness.


🕴️The organization needs to respect Product Owner.

The Product Owner must be given and must be capable of wielding the power to control the destiny of the product.

Product decisions should not be made by upper management or any other organizational level.

Else the scrum team would stop asking the Product Owner, perceived as a fictive product steward.


☝️ When Scrum adoption is superficial, this happens:

  1. Lack of clarity in decision-making;
  2. frequent disruption from upper management;
  3. no sense of ownership;

  4. reporting good progress in bad faith to avoid ineffective interventions by management.


📢 It is not enough to dictate Scrum idioms:

“Commit to inspection and adaptation”;

“have the courage to review the Sprint with transparency!”;

“use the Daily Scrum to focus on the work in the Sprint, not your respective statuses!”;

“be open about how hard it is to adopt Scrum with your Scrum Master!”;

“respect the authority of the Product Owner even when the CEO barges in!”


Here are 7 principles to align with values:

  1. Self-organization
  2. Team size and composition
  3. Done means done
  4. Empowered Product Owners
  5. Servant-leader Scrum Masters
  6. Team ownership of adaptation
  7. Delivery of business value

🗺️ Self-Organization

Fundamental to Scrum is the ability for a team to self-organize: to take on work, make a plan to complete the work, and execute that plan.

Moving away from where managers managed the work means for them that they need to behave as part of a team without the authority that organizational structure would have previously given them.

By letting the scrum team self-organize, you would entice mutual commitment.


🏀 Team Size and Composition

The principle of team size and composition is quite specific: between 3 and 9 people, and consisting of all the skills necessary to do the work required of the team to produce done software.

If team size and/or composition are not right, something has to change.


✅ Done Means Done

Although the Definition of Done itself evolves over time, the principle of done means done is static.

The team takes ownership of a specific Definition of Done and only shows work done in a Sprint that meets the definition.

Defects that were previously discovered in Sprint were taken on immediately, and if not fixed by the end of the Sprint the work item was returned to the Product Backlog.


💪 Empowered Product Ownership

An empowered Product Owner is one who can make decisions about the product.

The Product Owner “may represent the desires of a committee.”

Besides, the decision is organizationally owned by and communicated to the team through the Product Owner, and no one else.

That will help stakeholders to respect the Product Owner.


🤹♀️ Scrum Master as the Servant-Leader

The Scrum Master does not manage the team or the work but manages the adherence to Scrum.

A courageous move would be to train in-the-trenches developers, have them obtain Professional Scrum Master I (PSM I) certification, and then take on the Scrum Master role.

Making managers back away, and stopping them from managing the work, would demonstrate respect for the team.

Change the tracking managers by team supporters bringing improvement initiatives like team composition changes or pursuing training/learning opportunities.


🔄️ Adaptation Requires Ownership

The driving principle behind the empirical process control is the team taking ownership of adaptation.

The team, by virtue of the principle of self-organization, is on the hook for coming up with improvement proposals.

That means not neglecting retrospectives and taking on at least one improvement backlog item per Sprint.


💰 Delivering Measurable Business Value

Scrum adoption can lead to improved morale, tighter communication, less technical debt, and more frequent releases...

But delivering measurable business value is the most important.



Developing software is complex.

A complex product with multiple people and teams is going to be challenging.

Scrum won’t make it easier.

It will simply give you a framework, principles, and values that make the hard work much more likely to result in positive business outcomes.

Scrum is an empty thing without the Scrum Values and "focus on Done".