Today, unfortunately, many agile teams are not yet able to create a true shippable increment every sprint. This is because their Definition of Done (DoD) is weak (immature).
As such, teams have a lot of UNDONE work at the end of every sprint. This work may take a lot of different forms and is usually passed on to a ‘special’ UNDONE department or group to be handled. In Scrum and in Large Scale Scrum UNDONE department do not exist.
It may seem that reasons for having UNDONE department are purely technical [limitations]. But this is rarely so. For the most part, they are political and have to do with traditional organizational design and sphere of control.

 

Download materials: 

02-18-2021-What_UNDONE_Department_in_LeSS_And_How_ To_Eradicate_It_DeveloperWeek2021

“Can Kanban be used in conjunction with LeSS (or instead of LeSS)?” – this is the question that we hear all too often.

Since LeSS is Scrum (nb: organizational design impact of LeSS is much stronger), perhaps, the above question can be also re-phrased into:  “Can Kanban be used with Scrum (or instead of Scrum)“?

First, we need to understand what is the reasoning behind this question. What makes Kanban more attractive than Scrum to people?

Here are some possible scenarios:

Scenario 1: Kanban greatly increases efficiency of work management, by its focus on:

• Throughput-based forecasting
• WIP limits and one-piece workflow management
• Queueing Theory and Little’s Law
• SLA-level escalation (e.g. L1-L3) mechanism
• Enterprise-wide Convergence and divergence of flows
• Management of Lead Time, Cycle Time, aging etc
• Balance between holding costs vs. shipment costs
• Batch-size optimization

or…

Scenario 2: Kanban is simple and too forgiving, with respect to:

• NOT mandating a customer/feature-centric way of working
• NOT mandating a real Product Owner and product definition
• NOT mandating  a dedicated full-time Scrum Master
• NOT mandating  cross-functional, self-managed teams
• NOT mandating  commitment and participation by a business community (e.g. Product Owner, users and customers)

 

The first scenario implies that we really value some of the goodness that Kanban brings to the table, most of which could be still swiftly leveraged within every sprint: by a single team (Scrum) or by up to eight teams (LeSS).

The second scenario implies that we are looking for short cuts, for “forgiveness” – NOT to address organizational design challenges that Scrum (and LeSS) expose. Going immediately, to ‘Plan B’ (Kanban), because it is simpler, easier to fit in a current organizational construct, electronic tooling, etc…. instead of trying to understand why Scrum (or LeSS) does not work, would most likely mean that soon even Kanban’s light rules will be also compromised.

---

Scrum is a light framework, used by single team to develop a product. LeSS is Scrum-based organizational design framework that enables large-scale, lean and agile product development by up to eight teams (NB: In LeSS Huge, more than eight teams work within separate product requirement areas – and it may involve hundreds of people).

Both, Scrum and LeSS  require a clear product definition, well defined priorities (vision, strategy), well -focused customer-centric approach and dedicated engagement by business and technology.

Making a right decision around choosing Kanban over Scrum (or LeSS), requires good understanding and seeing a distinction between Scenario 1 and Scenario 2 above.

“In over a decade of supporting large-scale agile transformations, one thing has become abundantly clear; focusing on processes, practices and frameworks alone is a recipe for failure. Yet that is exactly where many organisations spend 99% of their energy. While it is important to focus on these ‘ways of working’, there are many other, largely ignored, areas which must be addressed to enable success.In this talk, I will run through what I believe to be the 6 enablers of business agility, how re design organisations for agility, and how to avoid shallow transformations which ultimately end in failure.”

Additional Self-Study Assets:

• 05/05 – LESS TALKS: Dave Snowden: Answering Tough Questions (Q&A)
• 02/27 – LESS TALKS: Q & A on “The Spotify “Model”: Don’t Simply Copy-Paste”, with Evan Campbell
• SAFe: Market Share Increase. Rapid Growth. What is the recipe? (please, make sure to reference to large collection of references at the bottom of this page)
• LeSS NYC meetup

Let’s provide some clarification for the top-3 (there is really no official data to back this up, other than a gut feeling) misused, and frequently abused, words: “agile”, “scaling”, “enterprise”.

Agile – if this word cannot be seamlessly substituted with some of its direct synonyms (adaptive, light-footed, lithe, nimble, fast-reacting), it is likely that it is used incorrectly.  For example, an “agile process” can only be agile if it can be easily changed, modified or simplified, on-demand.  “Agile team” – is a team that should be able to react quickly and easily to a fast-changing situation or market demands. If the above suggested substitution leads to a loss of meaning, the use of “agile”, as the term, is likely incorrect.

Scaling – using the original, Euclidean geometry definition of this word, scaling is a linear transformation that enlarges (increases) an object by a scale factor that is the same in all directions.  In our case, such “object” could be a team, process, experiment, or anything else that we wish to have more of.  Clearly, we want more of good stuff, not bad stuff. Then if so, when we say, we want to scale a process, we assume that the original process was good. When we say, we want to scale scrum, we assume that dynamics of a single scrum team are good. If we don’t have goodness to begin with, and we attempt to scale it, how can we have goodness at scale?

Enterprise – it does not automatically mean huge. A relatively small organization (e.g. 50-100 people) is an enterprise, if it includes multiple organizational dimensions, such as HR, legal, finance, vendor management, technology, operations, sales/marketing, etc. At the same time, a 500-person IT department alone is not an enterprise. It is just an organization silo.
We frequently hear people say “we need enterprise-level transformation/operating model/methodology changes”, while focusing mainly on technology and leaving behind many of the above mentioned dimensions.  It creates an illusion of enterprise-wide impact because such efforts are very siloed, limited and locally optimized.

Now, imagine if all three of the above mentioned words were used together, in the same sentence or phrase: “Enterprise Agile Scaling“:
If the individual words were misused, imagine the magnitude of a negative impact  the whole phrase  :(.