From Chaos to Control - Optimised lean services

Product / Service accountability

When the product service is what it is about, the CPO (Chief Product Officer) has a pivotal role. A CPO is more then than the COO (Chief Operations Officer) it is including innovation (Chief Innovation Officer), technology alignment, involving empowered people. An other important role is the CRO (Chief Risk Officer) accountable for what and how risks are managed .

Issues in this are:

• The role of a CPO is not in place, it is new proposed combination.
• The CRO is a know role but not seen as a major key player.

Suppose these roles would be in place, what is additional missing?

• A supporting role Chief Analytics & intelligence officer (CAIO).

Using this C-role newbies in a 3*3 plane is changing the Command & Control mindset. Presenting it by a visual is helpful in understanding accountabilities and the alignment in communications. The Fancy 3*3 plane:

Notes for interactions communications:

• For setting and managing visions and missions the diagonals are important.
• for getting the advisory details in visions and missions the vertical & horizontal are important
• The line to the floor is not shown, there are many more concept and context dimensions

The Product / Service quantum

When the product / service covered by a vision mission of the organisation a quantum exist with many lines of several types. See the figure in the header.

The Product / Service flow, operational plane (horizontal):

• RTL Green: Product / Service Pull request
• LTR Green: Product / Service Push delivery result
• RTL-LTR Yellow: Operational Changes for the Product / Service
• RTL Blue: Planned design changes innovation Product / Service

There are several closed loops for different stakeholders doing a balancing act. This is applied analytics, intelligence with the goal of understanding the performance. The connection lines are in the analytical plane (vertical):

• Green: The level of functioning of the operational plant for the Product / Service
• Blue: The level of functionality of the design for the Product / Service
• Red: The level of purpose for what Product/Service is designed
• Black: external events that can be helpful and disruptive

This would help a lot in simplification of where data, analytics intelligence are important so how you do the information provision is simplified by more clear understanding of the goals to achieve. This would be simple when all was just internal and there would be no external dependencies for a Product / Service. The reality is different multiple products / services are combined into what is the product / service for the (external) customer, consumer.

In a figure:

Lean, agile, optimizing

Everyone is wanting this, seeing the advantages but at the same time most attempts are failing dramatically. What is going on, why is this happening? When asking what lean is, agile is there a good generic applicable answer is not found. Trying to understand how to recognize lean, agile no good generic applicable answer is not found. There is a famous commercial example trying to be copied by similarities, it is the Toyota Production System (TPS). This famous example however was not the only one moving in that direction. The Theory of Constraints (TOC) 1984 was build on top of that. Looking from a far distance it is a natural evolutionair evolvement in the "Information Age".

Trying to understand lean agile and trying to categorize a complicated list of requirements with definitions, technical requirements, behaviour requirements resulted in something that could be helpful in recognizing lean agile. In a visualisation:

The areas in this 3*3 plane are not at random places, they positioned for:

• A clockwise PDCA cycle starting with the P bottom left
• The pull request RTL line at the bottom
• The push result - delivery LTR line at the top

The pillars are interesting in understanding lean and what has happened.

1. The left vertical pillar is about mindset. The famous TPS example had his place in a culture that did not have many conflicts for that. The Toyoda family had an important role for this
2. The middle pillar is about methodology and practices. In the famous TPS example the dissonant Taiichai Ohno was the master for this.
3. The right pillar is about measuring, understanding, insight adjust in closed loops. Deming had an important role in this one.
4. In the middle there are threats obstacles. When not getting managed they will rip down the others. For the TPS system Eiji Toyoda was the master.

If we accept this as what has happend and accept the why it is happening at least there is way to recognize that big lean elephant. Not being lost anymore in details of the blind trying to understand the elephant.

Reference

Thinking about this all started with an idea to do better Software Engineering Intelligence better enterprise engineering intelligence, better support for products / services.

More at: https://metier.jakarman.nl/devops_bianl/devops_bianl.html#inntdss_04