You want to have Agile at scale but not to scale Agile

It’s is important that we understand the difference between Agile at scale and scaling Agile. Agile at scale means the organization is Agile. It can develop, deliver and pivot quickly. But it doesn’t mean that the projects are scaled. Large projects are an anathema to Agile as are large teams and trains. Scaled Agile should help us break workflows down into small and separate value streams so as to create efficiencies and quick feedback.

Continue reading “You want to have Agile at scale but not to scale Agile”

Does your approach enable business agility?

Many people are talking about business agility. But talking about it and doing something about it are two different things. To be clear, business agility is the ability to realize value quickly, sustainably, predictably and with high quality.

Doing this requires:

Continue reading “Does your approach enable business agility?”

Make your Essential SAFe adoption more effective by adding just one explicit concept

Starting with Essential SAFe does get people working together. But the real problem for most companies is that they can’t sequence work well and are working on too many too large items. This causes thrashing and delays delivery. You don’t have to implement the higher levels of SAFe to get much of the benefit they promise. All you have to do is make explicit a powerful concept missing in all of SAFe – the Minimum Business Increment (MBI).

Continue reading “Make your Essential SAFe adoption more effective by adding just one explicit concept”

One of the most valuable concepts in Agile is missing

Agile has moved from the team to the enterprise with the goal being business agility. We need a system that takes us from strategies to realization. This has two tightly connected phases – the discovery of what to work on and developing it.

Business has the responsibility of discovering what these small pieces are – both who is being targeted and what value is to be delivered. These are presented to the development group in the product backlog.

What these pieces are is the missing concept I am referring to. Many people are using the term MVP for this, but an MVP is about discovering if a new product is viable. It starts small and grows.

Most large organizations have strategies and initiatives for extending existing products and services. This requires going from big (an initiative) and making it small. This is accomplished by ‘asking what part of an initiative can we deliver sooner?’ This is not just about being small, however. It must also contain all of what’s needed. That is, what shared services, ops, marketing, support is required to achieve value? So it can be thought of as the smallest container of what is needed to provide the quickest realization of value.

We call this the ‘minimum business increment.’

For more on MBIs and how they relate to MVPs, go here.

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