Using the Theory of Flow to Illustrate Impediments in Two Hours Instead of Two Weeks

Simply put, the Theory of Flow focuses on two areas:

  • The steps it takes from conception of an idea until value is realized from it
  • Reducing the Cost of Delay, the revenue or opportunity lost because of delays in realizing value

Reducing Cost of Delay (CoD) is essential to the goal of business agility, the quick realization of value predictably, sustainably and with high quality. Continue reading “Using the Theory of Flow to Illustrate Impediments in Two Hours Instead of Two Weeks”

Improve Your Scrum by Using Flow Thinking

Scrum is based on empirical process control, the pillars of which are transparency, inspection, and adaptation. This mostly means that instead of following a plan we observe how things are going and adjust accordingly. But this doesn’t mean that we can’t use theory. It’s just that when we do use theory we must verify it worked. Continue reading “Improve Your Scrum by Using Flow Thinking”

Nice to See Scrum Catching Up (or Trying To)

Recently, Scrum.org announced the integration of Kanban practices into Scrum and that “Observe Orient Decide Act (OODA) is the mindset of Scrum. This comes on top of the announcement of Scrum team training a few years ago. These are all good things. It’s nice to see the Scrum community trying to catch up to the many non-certifying consultants who’ve been doing these things for 5-10 before. Continue reading “Nice to See Scrum Catching Up (or Trying To)”

Something has Happened to Me (Not My Normal Rant)

I’ve been having a very interesting two weeks. I would like to say that whenever I go into a client, I am always on, and always get my clients to see new opportunities. But I’d be lying.

However, for the last two weeks, that’s been what’s been happening… with five clients. While I feel I’ve been “on” and empathetic, that only explains half of it. Something else has been going on.

Here is what I think has been happening. In all of the cases, I started out with:

  • Depicting a value stream representing what they’d like to happen
  • Adding their team names, relating this to what people were doing now (making it less theoretical)
  • Identifying the client’s problems in this ideal flow

At this point, they started asking how to solve their problems. Often, they are stumped about how to work with non-Agile teams or how to create predictability. They would ask, “How can you do this in Agile?” “What do you think about LeSS?” Essentially they were taking solutions they knew, or had heard of, and were trying them on.

It’s like shopping for clothes. Every company is shaped differently. There may be lots of clothes (solutions) out there that don’t always fit. That’s when you want to learn to be a tailor.

This is the first of a series on the implications of these insights.

New Teams Can Avoid Common Errors by Understanding Cost of Delay

In an earlier post, I discussed how attending to the cost of delay helps us focus on removing delays in workflow, feedback, communication, and error detection. This involves a focus on finishing (not starting a new story if you can help somebody else with an existing story), working on small stories, and using test-first methods.


Note: This is a continuation of the post, Using Cost of Delay to Improve Scrum

Teams new to Scrum face many common challenges.

  • Not finishing stories at the end of a sprint because too many have been opened
  • Too many untested stories at the end of a sprint
  • Doing an analysis sprint, design sprint, coding sprint, testing sprint (“Scrumerfall”)
  • Separation of coding and testing responsibilities
  • After the demo, realizing there were misunderstood requirements

In an earlier post, I discussed how attending to the cost of delay helps us focus on removing delays in workflow, feedback, communication, and error detection. This involves a focus on finishing (not starting a new story if you can help somebody else with an existing story), working on small stories, and using test-first methods.

Review that list of challenges. Each of these challenges show up as impediments at the end of a sprint. Each can be avoided, or at least mitigated, by following the guidance of removing delays by focusing on lowering the cost of delay.

No longer will you be removing impediments after they’ve been discovered. Now, you will remove them before you even hit them!

Using Cost of Delay to Improve Scrum

If you only quantify one thing, quantify the Cost of Delay” – Don Reinertsen

Cost of delay is the overall cost of loss in revenue, lost opportunity, increased risks, customer respect, etc., due to a delay in realization of value.

This jewel of advice not only tunes us in to what’s important, but it can guide us in all aspects of value creation and delivery. It’s what’s behind CICD, small stories, avoiding handoffs, not working on too many things, automated testing, test-first and more. Pause for a moment and consider how each of these remove delays in workflow, feedback, communication and error detection.

Projects miss schedules not because of one big delay, but due to a succession of small delays – each having a cumulative and cascading sequence of events that compound each other.

Using a mantra of eliminating these delays provides insights for how product owners, ScrumMasters and the team itself can work. Anticipating delays can even enable avoiding impediments instead of having to wait to hit them. The causes of delays are primarily working on items of lesser importance, lacking a focus on finishing, having too much work in process, lack of cross-functional teams, large stories and lack of collaboration. Understanding this greatly speeds up the adoption of Scrum for new teams.

 

 

 

 

No, Scrum did not back its car over my dog

On twitter someone suggested this is why I have so much energy on Scrum. Here was my response.

No. Scrum is great and can really help teams. What’s backed over my dog is the way it’s taught to teams. The common focus on the framework anticipating people will figure out what they have to do to do Scrum well has a history of being ineffective. Scrum should be taught by showing people how to solve their problems. Then it’s power can come to the fore. I have been saying this for a decade, and I know it’s getting old for some. For me what’s old is not solving the problem.

Teaching Scrum the wrong way and having ppl not figure out what they have to do results in bad scrum & then them getting blamed for not doing it right by not doing Scrum as defined.

I believe those who promote scrum have some responsibility in why this happens. And they should look at the way they train and the assumptions they use.

So yes, I have a charge on Scrum, but it’s on the damage being done via ineffective training. So what drives me is getting people to understand that Scrum is good, but that doesn’t mean that those certified in teaching it are doing a good job.

I was wrong, but it’s worse than I thought

I admit to being wrong with my focus on how Scrum doesn’t prepare teams when it’s prescriptions don’t apply. But I’ve been seeing even more cases of when they do and teams flounder anyway

The challenges of not being able to write small stories, devs and testers working separately, unclear requirements, not finishing stories before starting others, ineffective standups and ineffective retro are all too common

10 years ago having stable cross-functional teams and working on sprints was a massive step forward since merely doing that resulted in a 3x improvement. Focusing on the framework and hoping people would figure out the rest made sense. But what is needed now is how to solve these common challenges

It is not hard to teach this, but it requires changing the content of a 2-day introduction to Scrum class to be tailored for the team being trained. Certification courses are often taught with a set curriculum and thereby providing you with 3 choices:
1) Take a CSM class and need a tune-up later (expensive and incomplete)
2) Take an Agile class tailored for your needs
3) Take a CSM class with an added day for the tune-up (expensive)

But cost is only one part – unprepared teams or an extra day of them not being available for work is more significant

Walking my Talk – Integrating our On-the-Job Online Master Class With our Onsite Class

I’ve been espousing (a nice word for rant) about the need for scaled learning methods and how 2-day classes have low retention. I’ve decided to integrate our On-the-Job Online Advanced Scrum Master / Kanban Coaching workshop with our Team-Agility Coach (our integration of Scrum/Kanban workshop.

Our online workshop is normally $595 but when you take our Scrum/Kanban master course we’ll include that for $200 a person. This means that our 2 day workshop followed by our 3 month program is $10,400 for 12 people ($500 for each additional person).

The onsite aspect of this integrates Scrum and Kanban. The three month program has me work with participants helping them apply what they’ve learned, as well as advanced topics of Agile, with their teams.

Please message me if you’re interested.

Why I’ve Decided Not to Raise the Cost of Our On-the-Job Online Agile Coach Workshop

After writing about how our workshop avoids the issue of the 80-90% retention loss of normal trainings, covers twice the material of an Advanced CSM class, provides a performance support system and is provides timely coaching to its participants in their working with their teams, I had decided to raise the price from $595 to $895 – still a bargain compared to the common $1295 fee for an Advanced CSM class (not to mention the 2 days lost in an Advanced CSM class and likely travel time/cost).

But I’ve decided to go in the opposite direction. While the program is 3 months long, I will let people have access to the live coaching sessions included for 6 months along with the already annual access to the performance support system for a year.

I am committed to disrupting the current ineffective manner the industry now relies on for teaching people how to be Agile coaches. I am leading this workshop myself and promise it will change both how you look at Agile and Lean as well as your effectiveness.

We’re starting the next workshop this week, so please ping me if interested.