Lean

Debunking more SAFe® misconceptions 10x – The Scrum master

Posted on Updated on

In this short article we will prove the poorly crafted argument about the Scrum master role in SAFe incorrect as posited in the “Remove Scrum from SAFe” petition. I’m not really writing this to defeat the arguments presented in the petition because any rational person who looks into the details will come to the conclusion that the petition is 1.) wrong 2.) inconsistent 3.) factually incorrect. My goal here is more to take the opportunity to educate folks on the SAFe so that they will have more knowledge of how to use the #1 scaling framework in industry to improve business results and outcomes.

Read the rest of this entry »

Exploring the economics of decision making in SAFe® through gamification

Posted on Updated on

Economic thinking and principles

In the popular Scaled Agile Framework for Lean Enterprises (SAFe) we strive to “apply a comprehensive economic framework” through Principle #1: Take an Economic View. Certainly, part of how we deliver on this framework is through the natural decentralized decision making process that occurs when real Agile teams hypothesize their way through optimizing batch sizes, building quality in, and relentlessly improving. Breaking down work into slices of working software/deliverables/efforts that are potentially shippable (i.e. features) each iteration.

I believe that the dominant paradigm for managing product development is fundamentally wrong. Not just a little wrong, but wrong to its very core. It is as wrong as we were in manufacturing, before the Japanese unlocked the secret of lean manufacturing. I believe that a new paradigm is emerging, one that challenges the current orthodoxy of product development.

Reinertsen, Donald G.. The Principles of Product Development Flow: Second Generation Lean Product Development (p. 1). Celeritas Publishing. Kindle Edition.

At scale, we apply the same core thinking to how we invest in Epics and Features. Run experiments.

Read the rest of this entry »

DevSecOps Bungling

Posted on

Sometimes it is important to call out missteps even when there is good intent. Feedback is critical, and an important part of DevOps after all…

The authors, brilliant knowledge workers, amazing researchers, and well known marketers of the DevOps movement do not overload the already loaded term trying to capture acronyms for every element of the body of knowledge. Kim, Humble, Debois, and Willis did not call their book the “DevSecOps Handbook.” I wonder why? 

Read the rest of this entry »

DevOps, Automation, Batch Size, Swarming – Formula1 videos

Posted on

There are a few Formula1 videos around the web that we use to teach about the economics of batch sizes, particularly in the SAFe, where the teachings of Don Reinertsen are embedded in the body of knowledge. I found this new video on LinkedIn today and thought I would share them with the community.

Remember, we are trying to reduce the transaction cost of a batch. In these videos the older pit stop people, process and tooling resulted in a much higher transaction cost compared to the modern pit stop with automated tools and swarming. This can be done through automation, architecture, tools, kaizen of process, and through new ways of thinking and working, and even new ways of feeling. We must pay particular attention to the relationship between tools, people, and process as optimizing one without tuning the others may not improve anything (systems thinking).

Don Reinertsen, Principles of Product Development Flow
Read the rest of this entry »

Cliffs Notes: Principles of Product Development Flow – Reinertsen

Posted on

A coach shared this with me and I thought is was pretty good stuff. Here ye go in PDF format. Not from Cliff, but…

Team building patterns for SAFe®

Posted on

Here are some patterns to think about the next time you are planning an Agile Release Train (ART) launch. The ART launch should be preceded by a successful value stream identification workshop. Even still, old mental models may prevail that are deeply embedded in the culture of the organization.

Mechanical Scrum

Mechanical Scrum is bad for everyone.

You cannot force or assign shared ownership. Management must learn to trust her people and the system. An appropriate quote follows.

Edward Lorenz’s original metaphor for a chaotic system—the world’s weather where the nonlinear nature of forces potentially makes it possible for a butterfly in Beijing to affect the weather a few days later in New York—managers today seem to be living in fear of butterflies.

A potential misstep in launching an ART is allowing management to “assign” team members to teams based off of an overly simplistic view of the value stream or a set of unmanaged assumptions. If the knowledge workers know the work best, then leadership and management should allow the team to be part of the conversation and part of the decision-making process (SAFe Principle #9) for organizing and aligning the ART to the value stream.

This involves a process of self-organization. It is more than just a sequence of steps. If an organizations creation is facilitated mechanically through process steps, then the result will be uncommitted teams and forced misalignment.

Read the rest of this entry »