Demand respect. Why “Scrum-ish” can be better than Scrum

The Scrum Guide tells us “Scrum’s roles, events, artifacts, and rules are immutable”

This presumes people need this structure and can’t think on their own without it. Structure is good, but it can be achieved by specifying outcomes and principles while providing a starting point that can be changed as long as the outcomes are still achieved. Agile adopters should be focused on getting their work done, not on following a single set of rules that some people are advocating for everyone.

Continue reading “Demand respect. Why “Scrum-ish” can be better than Scrum”

The contradictions in many Scrum-based Framework Training (Scrum, SAFe, …)

Many proponents of Scrum based frameworks say:

  1. knowledge workers are people who know more than their managers
  2. we must trust & respect people
  3. people must self-organize

Continue reading “The contradictions in many Scrum-based Framework Training (Scrum, SAFe, …)”

Rethinking ScrumBut &ScrumAnd

This is an excerpt from a chapter my new book Achieving Business Agility at Small to Mid-Scale.

Scrum.Org defines “ScrumBut” as meaning “that Scrum has exposed a dysfunction that is contributing to the problem, but is too hard to fix. A ScrumBut retains the problem while modifying Scrum to make it invisible so that the dysfunction is no longer a thorn in the side of the team.”

Continue reading “Rethinking ScrumBut &ScrumAnd”

Why We Need to Inspect and Adapt How We Do Scrum Training

Inspect (Where we are)

Years ago Ken Schwaber observed that only about 25% of organizations got what they wanted from their teams adopting Scrum. I would guess that number hasn’t changed much since then.

Back then we didn’t have the understanding of Lean principles or Kanban. We didin’t know about ATDD or GWT. Our tools were horrible. So why hasn’t improvement happened? I would suggest it’s because “Inspect & Adapt”, a key tenet of Scrum, has not been applied to how it is taught.

The symptoms of bad Scrum now are essentially what they were back then:

  • running Scrum as mini-waterfalls
  • developers & testers not working well together
  • unclear requirements
  • too many interruptions & too much work

I know certified Scrum trainers are concerned about this as much as myself. But when I ask them what’s the cause I get virtually the same list of answers:

  • management hasn’t bought in
  • people aren’t doing Scrum right
  • people aren’t being Agile

While this may be true, the question is why? A clue to that may be seen by asking yourself “where is the responsibility being placed in those answers?”

Taking Responsibility

I have heard “Scrum is like chess. You either play it as its rules state, or you don’t. Scrum & chess does not fail or succeed. They are either played, or not.” The Scrum Guide tells us that – “When the values of commitment, courage, focus, openness & respect are embodied & lived by the Scrum Team, the Scrum pillars of transparency, inspection, &adaptation come to life & build trust for everyone. The Scrum Team members learn &explore those values as they work with the Scrum roles, events, & artifacts.” Unfortunately, most teams I know new to Agile do not work in an environment where those values are encouraged, let alone manifested.

The opening line of the Agile Manifesto states–“We are uncovering better ways of developing software by doing it &helping others do it.” The “helping others do it” means you have to come from their needs & their way of learning. This is your responsibility. It doesn’t mean just giving them a chess board, pieces & a quick overview of the rules & say “learn.”

While new Scrum teams have the responsibility in what they do, trainers have the responsibility to prepare the teams. This means trainers must adapt their methods.


Virtually all initial Scrum workshops focus on the roles of Scrum. The lack of whole team training is a core problem. The presumption that teams will figure out how to work together is not based on evidence. Instead, the focus needs to be on the actual work the team needs to do. Ironically, because Scrum is so simple, it can be taught in a day with the extra time available focusing on the work itself.

After initial Scrum training, most teams are facing even more pressure since they’ve just been trained. The challenges mentioned in pt 1 of this post should actually be expected. This often leads to them modifying the rules of Scrum without understanding how this can be done effectively. This, of course, leads to Scrumbut. Many people continue the shift of responsibility by calling them “Scrumbuts.”

The truth in Jerry Sternin’s observation “It’s easier to act your way into a new way of thinking, than think your way into a new way of acting” must be recognized. Scrum should be taught by teaching the entire team to work together in the process of creating features & breaking them down into stories while establishing how the entire team works together.

A New Approach

A new approach must recognize the following:

  • not all teams have the same challenges
  • many teams want to be told what to do

as well as provide the following:

  • a curriculum adjusted for the team(s) involved
  • teams must actually do some Agile in their initial workshop
  • Scrum Masters and Product Owners must be trained with the teams so all roles can learn how to collaborate with each other
  • SMs should be provided a flipped classroom style learning over time so they can learn “on-the-job” & stay ahead of their team so as to be able to guide/mentor them
  • a scorecard that provides clarity on the team’s effectiveness & how they can improve should be provided
  • some Lean-thinking, principles and practices (e.g., a little Kanban) since they can help teams adjust Scrum as needed

This can be delivered for about the same cost as sending teams to a CSM class if we focus more on the work & less on the framework. Using a combination of the latest training techniques (back of the room training, flipped classroom) also makes it more effective.

Doing this in initial training also avoids the resistance may teams have to adopting Scrum because they mostly see new meetings instead of actually helping them.