emphasize | deemphasize |
deep and narrow (meaningful, systemic improvements) | broad & shallow (big-bang, “check the box”, superficial, fake changes) |
system/global optimization (organizational level) | local optimization (at expense of system optimization) |
flat, lean, adaptive organizations | complex, multi-layered, cumbersome organizations |
light (very) tooling solutions and quality of human communication | focus on heavy tooling and PMO management style |
importance of working software (product), as success indicator | metrics and reporting, as indicator of progress |
feature teams (focused on products & customers) | component teams (focused on applications & platforms) |
component mentorship/teaching | component ownership |
simple, elegant, dynamic frameworks | heavy, prescriptive, rigid frameworks & “operating models” |
historical and market evidence, proof by experts | “best practices”, cook books and unrealistic hypos |
communities, as media for functional learning | power towers of “special people” (e.g. center of excellence, PMO) |
participation by volunteering and commitment | participation by mandate and enforcement |
dynamic, rolling-wave, product centric budgeting | hard-fixed, fiscal year-end budgeting |
creating and owning ideas | renting ‘best practices’ from others |
team performance, profit sharing | individual performance and bonuses |
job & salary security | role security |
simplicity of job descriptions | complex titles and management roles |
shared ownership, successes & failures | outperformers and individual heroics |
personal development goals, consistent with available career path | manager-imposed, unrealistic individual goals (“legal trail for a rainy day”) |
importance of hiring the best and growing the best | pressure to hire/recruit low quality experts (including agile) |
Category Archives: Uncategorized
DeveloperWeek2021: What is “UNDONE” Department And How To Eradicate It?
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.
12/06-LeSS Talks: Using Product Canvas in LeSS Product Definition
Relevant Assets:
- Getting Started with LeSS Adoption
- LeSS Adoption Journey Map
- Product Definition & Exploration Workshop Template
- EBG Consulting, INC: Product Canvas (pages 1 & 2 )
- LeSS Training Experience Report: Product Definition, DoD & Team ‘Blueprint’ Exercise
- “What is Your Product?”
- Using the Product Canvas to Define Your Product: Getting Started
- Using the Product Canvas to Define Your Product’s Core Requirements
- Lessons Learned in Becoming a Product-Centric Organization
- Ellen’s conversation w Dave West CEO of Scrum.org on “What is Your Product” dec 8th 2020
- Discover to Deliver book pdf: (deep coverage of the 7 Product Dimensions which are on Part 2 of the Product Canvas
Additional recommended 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
Should Teams Use Kanban, Instead of Scrum or LeSS?
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.
Dec 3 – LeSS Talks: How To Identify Agile Masquerades: Errors and Omissions with Scaling @ LeSSDays
This page is TBD.
The materials can be downloaded here: 12-03-2020_ Agile_Masquerades_Errors_Omissions_with_Scaling_LeSS_Days.ppt
LeSS Review
General Overview
- LeSS History
- What is LeSS? What is NOT LeSS?
- What LeSS is NOT (certainly!)
- Informed Consent: Inverted Organization
- LeSS Adoption: Principles 1 and 2
- LeSS Adoption: Principle 3
- One LeSS Sprint. Same “Rowing” Cadence
- Scrum Master in LeSS
- Product Owner in LeSS (deep dive)
- Avoiding “Double Blind” Dates
- Avoiding “Bad SQL”
- Typical LeSS Organizational Chart
- Typical LeSS Huge Organization
- Avoid: “Agile Layered Cakes”
- Avoid: “Agile” Framework: Version 348.54345345435…
- “Triple Taxation” to companies
Scrum Master in LeSS
- Classic Omissions with SM role in Basic Scrum (1-team)
- SM in LeSS
Primary Learning Resources
- LeSS Structure
- Getting Started
- What is System Modelling in LeSS class? (video)
- Debriefing Systems Modeling (video)
- Lean Thinking – what is it?
- Proper Scaling of Scrum and Dynamic Financial Forecasting
- Preparing for First Call
- Preparing for LeSS Adoption
- LeSS Story
- The Scrum Guide, by Jeff Sutherland and Ken Scwaber
- Scrum Checklist by Henrik Kniberg
- The Scrum Master Checklist, by Michael James
- Scrum Primer
HR Implications of LeSS Adoption
- Deep & Narrow Adoption: HR focus
- Product Owner | Product Owner Relationship
- Scrum Master | Scrum Master Focus over time
- Feature Teams | Feature Team characteristics
- Managers
- Responsibilities of the LeSS roles
- LeSS Organization (inverted structure)
- LeSS Organizational Overview (org chart)
- HR-Related LeSS Experiments – Deciphered
- System Modelling of HR-Related “Nuances”
Additional Learning Resources
- The LeSS Blog
- Other LeSS Blogs
- Articles
- Books and Chapters
- Videos
- Newsletters Archive
- LeSS Onion (the complete picture)
Class Self-Preparation:
- Introduction to LeSS (Large-Scale Scrum)
- “The Contract Game” (22-44min), by Craig Larman (video)
- Why “Scrum” Isn’t Making Your Organization Agile: Harmful Misconceptions About Product Owner Role (video)
- Why LeSS?
- Introduction to LeSS
- System Thinking – what is it?
- Pre-Course Scrum Assessment
- Pre-Course LeSS Assessment
09/07– LESS TALKS: The Six Enablers of Business Agility, with Karim Harbott
Synopsis:
“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 Learning Assets:
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
09/01– LESS TALKS: Resilience of Organizational Design to Help You Through Tough Times & Beyond
Upcoming LeSS Training:
Additional recommended 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
Clarification Of Top-3 Misused [Frequently] Words
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 :(.
Exposing Uncomfortable Topics: Errors and Omissions with Scaling @ Smarter Enterprise Lean Agile – LeSS Toronto/Montreal/Ottawa Toronto, ON
Upcoming LeSS Training:
- August 19-21 (group discount: group_disc)
- All other
Additional assets recommended:
- 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