Category Archives: Uncategorized

Transformations Gone Wrong: Erin Perry, JP White and Gene Gendel

My good-old friends Erin Perry and JP White have invited me to their regular Vlog session. The topic was  Transformations [Agile], Gone Wrong.  Both, Erin and JP have a lot of experience on the subject. So, the three of us had a nice discussion.  We discussed mocked-up transformations, copy-paste frameworks (and their market share capturing success), credibility/reliability of home-grown-my-own “operating models” … and more.  The whole recording is about 30 minutes.

DevRel Live – Transformations Gone Wrong with Gene Gendel from Erin Perry on Vimeo.

References & Assets To Share



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)

DeveloperWeek2021: What is “UNDONE” Department And How To Eradicate It?



Synopsis:
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.

12/06-LeSS Talks: Using Product Canvas in LeSS Product Definition

Relevant Assets:

Additional recommended assets:

Should Teams Use Kanban, Instead of Scrum or LeSS?

Register: Sunday, September 5, 2021. 12:00 PM EST: Can Kanban be used with/instead of LeSS or Scrum? WHO is asking and WHY?

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:

  • Increased transparency of workflow (“vacuum bubbles” and congestions)
  • Explicitness of WIP limits and one-piece workflow management
  • Throughput-based forecasting
  • 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 vs. capacity utilization

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.

LeSS Review

General Overview


Scrum Master in LeSS


Primary Learning Resources


HR Implications of LeSS Adoption

Additional Learning Resources


Class Self-Preparation:

09/07– LESS TALKS: The Six Enablers of Business Agility, with Karim Harbott

Materials used

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:

09/01– LESS TALKS: Resilience of Organizational Design to Help You Through Tough Times & Beyond

 

Upcoming LeSS Training:

Additional recommended assets:

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  :(.