Scrum - two ways

I define "Scrum" as a method, though it calls itself a framework. Read my earlier post for definitions of what frameworks and methods are.

Scrum as a method

Methods are repeatable set of instructions that can be practiced. And they are prescriptive.

Here are the rules prescribed by Scrum:

  • Have a Product Owner role who orders a list of items in a Product Backlog
  • Have a role of a Scrum Master
  • Have a role of a Team member
  • Work in iterations called Sprints of up to one month
  • Have Planning each iteration - create a Sprint backlog
  • Inspect and adapt the Product Backlog, Sprint Backlog or Potentially Releasable in various events
  • Meet every day in a Daily Scrum
  • Have a Sprint Review with the stakeholders
  • Have a team retrospective at the end of Sprint
  • Use "empiricism" in each of the events
  • Practice the five Scrum values - commitment, focus, openness, respect, and courage

It is surprising that Scrum says that if anything breaks any of the above it is not Scrum. And you are not expected to apply "empiricism" on Scrum to improve it or change it or make it your own. Is that not hypocritical?

Now I am guessing that most Scrum teams are at this level. And that is the problem in Scrum. It works as a method and not as a framework.

Scrum as a framework

A framework offers a different way of looking at things. If Scrum was indeed written as a framework, it would not be prescriptive and would be written only as a set of values and principles that could be instantiated depending on the context of the environment that Scrum needs to be in.

Values and Principles based Scrum could be:

  • There is a Product Owner with a Product Backlog which has got customer and market challenges
  • There is a Scrum team that has formed itself and they are capable of using their skills and competencies to solve business challenges from that Product Backlog
  • The team to engages with end-customers to figure out how to solve these problems
  • The team can acquire whatever skills and competencies that are required in order to solve these business challenges and problems
  • There is management support to the team to remove any roadblocks and impediments that the team has in their quest to their best work.
  • The team can use any methods, practices, tools, techniques and technology to solve these business problems
  • The team ships working product as quickly and as often as required in order to test their work in the market in appropriate ways
  • The team has focus on defining and improving the quality, performance of the Product they support in whatever way they deem fit in support of the market needs and craftmanship of the work that the team does
  • The team has the ability to always and constantly improve the quality of the product and the craftsmanship of their work.
  • When the Product is sunset or retired, the team moves on to new work.
  • The team can decide whatever is their appropriate cadence to do their work aligned to what the market needs are
  • The organization creates an environment for the above to happen (and potentially practice the Scrum Values - commitment, focus, openness, respect, and courage) within the team and around the team in all those who engage with the team around the work
  • Empiricism is seen in action in every aspect of the work done by the team

I am betting that "Scrum" is not practiced the way I have stated above. Not instantiated as values and principles that are practiced in the organization and inside and outside the team.

So no wonder, your "moves" don't give you the "Big Payoff's" that you dream of.

So here is a "Small moves" tip... Try "Scrum" as values and principles. The methods is the easy part to practice once you have your foundations in place.

Source:

Definitions: Building blocks and scaffolds - https://www.2agility.work/building-blocks/