Framework Tunnel Vision

Originally posts August 2013.

Disclaimer: I could have named this framework/method/process tunnel vision, but that seems a bit redundant. So don’t infer I mean to pick on any Agile approach that is a framework over one that is called a method or a process. I am just using the word framework generically. For the purposes of shortness, whenever I use “framework” in this blog, pretend I’ve said “framework/method/process/…”.

Continue reading “Framework Tunnel Vision”

How a framework just implying what needs to be done causes damage

Scrum proponents have long espoused that Scrum is intentionally simple and expect the teams to figure out what’s needed. I have never understood the validity of this approach. Simple is in the eyes of the beholder- a simple starting point may be simple for some but not for everybody. Being incomplete requires reinventing the wheel. Admittedly being more complete without adding complexity takes more effort to create. But that’s a methodologist’s job.

Continue reading “How a framework just implying what needs to be done causes damage”

A return to ethical certification

FIrst a disclaimer, I am mostly talking about Scrum and SAFe certification. I think iCAgile’s certification is fine and am not familiar enough with the others to comment.

I say “return to” because in the early days it was known that the course didn’t do much and few foresaw the consequences of a course providing certification. The original intent was to take people from competency to more competency.

Continue reading “A return to ethical certification”

Why We Need a New Meaning / Name for Kanban

Originally written July 2013.

What Is Kanban?

When Kanban first came out for software development, it was not the Kanban Method. It was A Kanban System for Software Engineering. It was a system for managing flow in software development and maintenance teams. It was developed over a few years by several different people at Microsoft and Corbis. It was essentially what I have sometimes referred to as “Team Kanban” and is actually what most folks mean by Kanban. David Anderson’s book, Kanban: Successful Evolutionary Change for Your Technology Business, introduced the Kanban method, a way of effecting evolutionary improvement. In many ways the Kanban Method is little more than Lean Kaizen with a particular starting approach and with some additional, sometimes useful, practices (e.g., service level agreements). I tried sorting this out a couple of years ago with my article Demystifying Kanban and several webinars on that theme that Kanban is an overloaded term meaning all of the following:

  • A signal card and usually referred to as “small k Kanban”
  • A team management method using Kanban to manage flow and usually referred to as capital K Kanban. This is essentially the original Kanban system for software engineering which I will refer to from this point on as Kanban Software Development
  • A thought process
  • A transition, or education, method (the Kanban Method)

While I have been troubled about this for years, even suggesting years back that we needed to come up with different terms for different things, I thought it mostly was an annoyance, but not dangerous. Recent insights and events has had me shift my thinking here.

It is quite clear that a number of Kanban consultants, particularly those in Lean Kanban University, are attempting to usurp the term to mean that Kanban is the Kanban Method and that any use of Kanban other than the Kanban Method is a “shallow implementation of Kanban.” I am not trying to draw any aspersions to their motivations for this. I am certain they feel they are doing what is in everyone’s best interest, as the Scrum folks did when they blurred the terms Scrum and Agile. But I do not agree that equating Kanban (in the sense of the original Kanban) with the Kanban Method is beneficial for most in the industry.

Kanban and Lean

I have long felt that Kanban (both software development and method) is a subset of Lean Software Development. Our industry will forever be indebted to David Anderson, Jim Benson, Corey Ladas, Darren Davis, and others who brought Kanban into existence. Kanban software development opened ways of doing Agile software development to companies for which cross-functional teams were either impossible or prohibitive or who couldn’t otherwise make the jump to Scrum.

Lean-Agile Newsletter – June 20/26, 2019

Net Objectives

Note: This newsletter is a blend of our full newsletter of June 20 and our LinkedIn newsletter of June 26.

We have four exciting announcements this newsletter – including one for those trying to improve their organization’s development process and one for you techies.

Becoming a FLEX Trainer

First, the really big news – we’re looking for trainers in our new FLEX patterns framework for Agile at all scales

As many of you know, I have been working on a better approach to Agile at scale than is currently available. There are several challenges I have seen with virtually all of them. I recently wrote a blog Checklist for a good framework that lays out what I consider to be the minimum requirements for a framework.  FLEX has developed to the point of meeting those requirements and more. If you’re looking for a method where you can learn to train it or if you are a consultant and want another offering, please let me know. You can learn more about FLEX here

Some other blogs:

Webinar: June 27th. Creating the Next Paradigm Shift in IT and Product Development
Agile has been around for more than two decades. This is more than a lifetime in the information age. Dark Agile has been around for just about as long and seems to be increasing. The reason is reflected in Einstein’s observation, “We cannot solve our problems with the same thinking we used when we created them.” The next paradigm is not based on Agile but on flow and Lean-Thinking. It acknowledges the reality that it is easier to work your way into a new way of thinking than it is to think your way into a new way of working.

This talk discusses the main shifts required for the next wave after Agile:

  1. Focus on achieving Business Agility, the quick realization of business value predictably, sustain-ably and with high quality.
  2. Attend to lowering the cost of delay to achieve this. The cost of delay is the costs to an organization of deferred value achieved, higher risk sustained, and lost opportunity.
  3. Provide a customized starting point and road-map.
  4. Focus on the work to be done, not on the framework.
  5. Understand the critical factors of systems thinking, attending to complexity, and the role of Lean-Management.
  6. Organize practices as groups of patterns so that knowledge can be added without making things more complicated.

For those considering or wanting to improve SAFe.

As a former contributor to SAFe, an SPCT and Gold partner, I know how to make SAFe better. If you’re considering doing SAFe or want to see how to improve it, see Part IX: Using FLEX to both enhance and simplify SAFe.

The TDD Companion

TDD Companion

This book is meant to be a lightweight companion to the TDD practitioner. Each entry is a page long at most.

These pages are loosely organized, except where specific pages relate to each other.

The idea is that you can pick it up, open it anywhere, and gain a useful insight without having to spend hours poring over it.

As always, happy to chat with you about your challenges and how we can help.

Al Shalloway 
CEO, Net Objectives
425-269-8991 @alshalloway

SAFe® is a registered trademark of Scaled Agile, Inc.

Don’t see one in your area? Let us know so we can see about scheduling one nearby!
Date Events
June 27 Webinar: Creating the Next Paradigm Shift in IT and Product Development
July 22 Online Course: FLEX for SAFe Scaled Learning Workshop
July 22 Online Course: FLow for Enterprise Transformation Workshop
Now Online Course: Advanced Scrum Master and Kanban Online Workshop
Now Online Course: Lean-Agile at Mid-Scale: FLEX Essentials
Now Online Course: Foundations of Sustainable Design
Now Online Course: Agile Product Management Essential Concepts (Free!)
Sep 25-27 Public Course: FLow for Enterprise Transformation Workshop
Let us know if we can schedule a public course in your area

FLEX as a Pattern Framework

A pattern is a solution to a recurring problem in a context. Christopher Alexander, who created the concept, says :
“Each pattern describes a problem which occurs over and over again in our environment and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.”

In FLEX’s case, the context is achieving business agility – the quick realization of value predictably, sustainably and with high quality. This, of course, requires solving several problems with each of these problems being solved in a different manner. FLEX groups these patterns those patterns that solve the same conceptual problem. Hence it consists of pattern groups with each group consisting of a set of patterns that solve the problem associated with the group. The primary groups are:

  1. Value stream management
  2. Strategies, & initiatives
  3. Portfolio management
  4. Product management
  5. Intake process
  6. Planning
  7. Development
  8. Release
  9. Realization

Patterns must include their purpose, the forces they deal with and their proposed solution(s). Patterns are also named in order to be able to identify them. This has the added value of improved communication.

Checklist for a good framework

Creates a customized roadmap that attends to the needs and culture of the organization adopting it. This includes a customized starting point. Together these avoid a “one-size fits-all” mentality

Provides a support system used by practitioners to help them solve their challenges

Is geared towards practitioners becoming self-sufficient.

Is based around the value stream, making it easier to see how well the organization is doing and what they have to do to improve.

Provides a measure of improvement not based on how well the framework is being followed.

Doesn’t require a change in values in order to start. While the framework should help improve the culture of the organization, values change slowly. Remember, it’s easier to work your way into a new way of thinking than think your way into a new way of working.

Makes explicit how its practices manifest Flow and Lean principles

Has meaningful certification. Merely taking a class and passing a test just means they learned some information. Courses should include how to train and enroll people in new ideas. 0->60 in 3.5 days is meaningless.

Does not get more complicated as it evolves. It must be organized in a way that both scope and depth can be added without adding complexity.

The real lesson in Steve Denning’s Understanding Fake Agile

Ref: Understanding Fake Agile by Steve Denning

There has been a lot of buzz around Mr. Denning’s comments in this article as SAFe being “the epitome of fake Agile”

But the real message is earlier, when he postulates the “3 laws of Agile”

  1. Law of the Customer—an obsession with delivering value to customers as the be-all and end-all of the organization
  2. Law of the Small Team—all work is carried out by small self -organizing teams, working in short cycles and focused on delivering value to customers
  3. Law of the Network—the firm operates as an interacting network of teams, all focused on working together to deliver increasing value to customers

In summary, focus on the customer with small teams working as a network

What does this require?

Clear vision of who your customer is and what value you are going for. Work on delivering value in small increments so small teams can do the job. Create the alignment and proper communication channels networks require. These don’t just don’t happen on their own

I suggest that these three ‘laws’ can be used by those selecting an approach to take by considering how the approaches manifest them (or not). Designers of frameworks need to consider them as well.