Coaching Tool/Technique: System Modelling (w/ Causal Loop Diagram – CLD)

 

System Model (high level)
System Model (zoom in)

 

Additional Assets:

Note: System Thinking is used in LeSS training & coaching (team & enterprise).

OKR: Narrowing The Gap Between “O” and “KR”

(Draft)

OKRs (Objectives & Key Results) – they could be your best friend or your worst enemy.

Albert Einstein once wrote on a blackboard: “Not everything that counts can be counted, and not everything that can be counted counts. [source]” This usually applies to things that people like to measure. But what does this have to do with OKRs?

OKR – is a way to measure how your initially set [strategic] objectives translate into results, at various organizational levels.  With OKRs, there also come numbers, metrics, calculations, RAGs, etc.

What would OKRs look like for a traditional organization (complex structure, many reporting layers)? – this is not the scope of this writing.  Frankly, there is a plenty written on this topic.  Though, one thing is worth mentioning is that, as “Os” roll down from top (executive level) to bottom (individuals), and as “KRs” roll back up, through multiple organizational layers (managers, teams, departments), accuracy and relevance decrease, whereas variability/variance/inaccuracy and system gaming risks increase.

But what would OKRs look like for an organization that was trying to get away from a traditional structure and wanted to become more agile (adaptive)?

First, we need to define what it means, to be ‘more agile‘?  What is the most important factor that defines organizational agility? That is right!!! – organizational design/structure (culture, norms, values etc, come much later). When an organization becomes more agile, what we typically see, is reduction in a volume of processes, artifacts and single-specialist roles – people that are responsible for single, asynchronous tasks. This is sometimes referred to as organizational ‘de-scaling’ (flattening).

By the way, and just to correct frequent misunderstanding of the word means: agile – does not mean ‘faster’, ‘cheaper’, ‘more efficient’ etc.  Of course, the ladder may come, as a secondary or even tertiary result of becoming more agile and responsive (e.g. a company, responds to market/clients needs than its competitors –> this leads to increased sales –> increased profits –> better economics) but this should not be the main set goal of agile transformation efforts.

Even at a large investment bank, with its traditional complex structure: multiple reporting levels, many applications (with application owners), many departments (with department managers), many sites (with sites coordinators) – in order to improve agility in e.g. product development, we need to de-scale organizational layers and bring closer together: real customers (or internal users) with development teams (GEMBA).  Why?
Because, in a flatter organization, where customers and executive management set objectives, and development teams are expected to produce initial (low-level) key results, there would be fewer errors and omissions, due to a lower number of translation layers.

For example, a good business objective could be to increase an annual revenue by 5 million dollars. This could translate into a requirement of having an X-number of new customer-centric features that, if delivered by a certain date, would help generating more revenue for a company (as per forecasting by its market analysts). These X-number of features could now be entered into a product backlog (owned by a single product owner and multiple teams), refined and delivered incrementally, over time, sprint by sprint. The lowest level key-result, in this case, could be meeting teams’ definition of done (DoD) and delivering a potentially shippable product increment (PSPI) at the end of every sprint. (Please note that ALL teams responsible in product development would be sharing the same objective.  By the same token, results would be measured for ALL teams – working together.) The next level key-result,  for example, could be delivering some large feature (or a percentage of an initially requested feature), by some arbitrary interim date.
The intention here would be to have as few translation layers as possible, while cascading up results from-low-to-high, to avoid errors and omissions that could be introduced during translation.  Of course, this would only be possible if an organizational design inside, around and beyond teams, was simple (de-scaled).

Word of caution:

These days, ‘agile’ is one of the mostly overloaded and misused terms.
Agile has become one of the most popular areas, where transaction takes place and business is generated (recruiting firms, consultancies, tooling companies). The are many, commercially successful, complex frameworks and tooling solutions (with the word “agile” in them) that are marketed, as “unified & comprehensive solutions”. This constitutes, what is sometimes referred to, as a ‘Triple Taxation‘  – and organizations become a victim of it.  This is also a part of a bigger, industry wide “agile” framework-tooling problem.  Essentially, these approaches, redefine the “old world” with new terminology: projects / programs / portfolios become agile  projects / programs / portfolios, PMO becomes agile PMO,  BAs become agile BAs, and so on…

With electronic tools that are in close partnership with heavy, RUP-like frameworks (e.g. JIRA + SAFe), neither one of which are focused on improving organizational design, OKRs become just another illusionary improvement.

Companies should avoid falling into the trap described above. Aligning low-level OKRs (e.g. team project) to higher-level OKRs (e.g. portfolio), by merely, “mapping” numbers that are generated at single-team level (e.g. velocity or number of items delivered per sprint) through an “agile tool”, and processing them through multiple layers of projects, programs, portfolios, epics, themes, etc – this approach is prone to *unintentional errors and intentional system gaming*, and will ultimately lead undesirable outcomes, because fundamental problems, such as an organizational structure and its internal communication channels, are not being addressed.  Such “cascading” of OKRs may look nicely on reports but because it represents a system that is flawed, it would not be valuable.

Conclusion:

OKRs could be a great communication tool and means of providing transparency and managing expectations. But OKRs are only as good as processes and dynamics they represent, with the ladder being fully dependent on an organizational (system) design.

In order for OKRs to be reliable and omissions-resistant, they need to be as simple as possible, and have very few translation layers between the highest-level “O” and lowest-level “KR”.   This is an organizational design question.

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:

Agile Poetry In Motion

Lyrics written by: Gene GendelMusical/voice performance by: Erin Perry

LinkedIn feed

-1-

It is time to get serious about agility:
It is best to be viewed as PMO utility.
Scrum and Kanban are agile “methodologies”,
Agile Manifesto – is purists’ ideology.

-2-

Agile KPIs, metrics and RAGs,
PMs – proudly wearing “Agile Coach” name tags.
BAs – are pretending to be “Product Owners”,
Tech Leads – are deciding on a year-end bonus.

-3-

Agile’s the way to advance for promotion!
Don’t miss opportunities: strive with devotion!
Scrum Master – is merely a junior role,
An Enterprise Coach’s your ultimate goal!

-4-

Chief Architects – want a piece of this action,
Lets clearly define their main interaction:
“Dont waste their time, by expecting to code,
Power point creation – is their main working load”.

-5-

“Fixed everything” plans and forecasts to stakeholders,
Lets put all Scrum work in portfolio folders.
Make sure: estimations are very precise,
Our organization can handle all lies.

-6-

BAs – “PO Proxies” – Team Output Owners,
Borrowed resources – capacity donors.
Scrum, Scrum of Scrums and Scrum’s fractal design,
Oh God!, someone get me a bottle of wine!

-7-

Our Enterprise Scaling’s  – a serious matter!
Big, scaling solutions will make things just better.
Lets pay extra fees for every new version,
And be in denial of this brutal extortion!

-8-

Projects and programs. Trains, Streams, Epic Owners,
Shared workers, Brook’s Law and  developers-loaners.
Vertical structures get flipped on their side,
They’re now called Chapters – lets go for a ride!!!

-9-

Those Chapters too big??? – No worries, at all!
With Chapters of Chapters – we’ll all get a role!
But what if that thing got tremendously big?
No worries at all – will add Guild in a gig!

-10-

Portfolio Managers paid a big bribe –
To be guaranteed a sweet spot in a Tribe.
Of course, Tribal Lead is their main aspiration,
They’re now in charge of org. structure creation.

-11-

For staffing, rely on “sweat shops” and recruiters,
They are most ferocious industry looters.
They’ll find and “deliver” the cheapest resources,
While “riding” developers, like smelly horses.

-12-

Don’t do this alone: lets invite “expertise”!,
Expensive consultancies run this striptease!
They lead us through “theater” and masquerade,
And work extra hard for the millions they’ve made.

-13-

If you recognize what’s described in these rhymes,
If you get annoyed with these problems (sometimes),
Don’t remain silent and voice your frustration –
Earn tons of respect and your peers’ admiration.

For graphic irony and satire please visit this page.

SEPTEMBER 02-04: CERTIFIED LESS BASICS (CLB) COURSES | VIRTUAL

Reviewing Before Class
Additional Relevant Assets
Upcoming Virtual LeSS Training: