Complexity kills speed. In classical systems we often need to manage variants and versions of components. The combination of both could be called a configuration. 

• Variant means “coexistence of two solutions at the same time”. 
• Version means “temporal succession of implementations”. 

In a cyber-physical system with embedded components, both aspects have to be managed in the classical world. If I want to manage the problem, I need to know all possible implementations beforehand, that is I need to know all configurations of the system and need to validate each of them. At least the ones I want to “allow”. Or limit the number of possible configurations to those that “make sense” (for me) and show the desired functionality and at least validate this subset. I think we can all agree that configuration management is a complex task with a lot of dependencies. 

If managing something is complex and tedious, maybe there is a different solution. (This is a reference to my old atomic physics professor, observing us calculating quantum theory wave functions for an exercise on end-less printer paper. “Are you sure you are on the right path? There must be a simple solution. This is not elegant.” He was right. There was a simple one. I learned later.) Remember: There is always an elegant version of a brute force solution. 

What is the solution when classical management is becoming too slow and complex? Bingo. 

Selfmanagement. Trust the experts/developers/worker a.k.a. value creators. Provide the right objective and guidance, then they are going to figure out the rest. Objective and guidance, a.k.a. a reference frame requires commitment and boldness.

What if we reverse the problem of configuration management and stop managing? Instead of pushing solutions to a cyber-physical system, we let the system PULL the valid configuration? Not used configurations do not need to be validated and tested. The system knows how it is built and can do the job of the “system integrator”. This is simple and fast. It comes at a price tag, but suddenly a new configuration does not add to the bill. Where is break-even?

Not possible and all phantasy? I do not think so. I believe it can be done and I am convinced it is implemented somewhere already. In the automotive world. All you need is an automatic test and release system built into your cyber-physical whatever and a suitable description of the components and their relations. Heard of a digital twin before? I used to think of it as a digital simulation of the system of interest. Possible, but more powerful is “just” a description file, describing your system of interest possibly as a graph.
No guarantee though that is really exists. I am just reading tea leaves here and there. Correlating random information. I would bet on it.

Oh, and one more thing: in mathematics, elegant proofs sometimes are visible when you watch the system from the outside. 

Cheers.

The post Changing Paradigms … Pull Principle for the Product? appeared first on Grado.

The post Resource Fluidity vs. Resource Balancing appeared first on Grado.

In a second it struck me that there is something dreadfully wrong in this statement. I just could not nail it down.

Some years ago around the same time. Enter podium discussion at a tiny conference close to Detroit. Some agile “what-ever”. I was on stage with two big names. No idea why I was asked to participate on stage. The topic was agile scaling or rather how to run big projects in agile. At the time, I was very much into micro services and reversing Conway’s law and architecture centricity and topics around it. We were discussing the standards like big room planning, program boards, minimum viable products, walking skeletons, whatever… At one point I had an idea. “We need to manage the work such that there are as few as possible dependencies on the board. Best case scenario is NO dependencies.” That one touched a nerve and I was disqualified as not understanding systems at all. Easy bait. Lesson learned: Do not be creative on stage. Does not work.

But: Still, the idea was attractive to me. It leads to simple solutions with very little dependencies and dependencies is where I get a headache.

Fast forward to some project management conference. Quite a few system engineers were presenting. I have seen a few people proudly showing off their skills in management of complex dependencies.

My mantra became a lot clearer: “Keep it simple, stupid.” There are many variants to the idea and it dates back a couple of hundred years. Just search the web for some trivia. Anyhow, the recommendation to the executives by the consulting company should have been:

“You need to reduce complexity.”

How to reduce complexity? Make it complicated for few and simple for many. This involves

• Unterstanding that architects are in a leadership role. They shape business and products. Cannot be separated. Both go hand in hand.
• Understanding that organizations that develop systems are systems themselves and that these are social systems of people, developing for people. (In the end there most of the time there is still a human interacting with your product. The product should be there to serve a purpose.)
• Understanding that the world is changing at a certain pace. To manage solutions, you need to be faster than the changing environment. Elements of self-management might be a good idea to maintain speed.
• Understanding that “divide and conquer” does not necessarily mean micro-management.

Why should we reduce complexity at all?

• Simple solutions are easy to build.
• Simple solutions are easy to adapt and to modify.
• Simple solutions are cheap.
• Simple solution can be delivered very fast.

Complexity kills speed. I want to move

The post Dealing With Complexity appeared first on Grado.

However beautiful a strategy is, you should occasionally look at the results.

Strategy begins with finding yourself as an organization.

This includes

• identity: who we are, what we want, what we stand for
• perception of the situation: what our environment is like
• Building on this, you can develop a strategy: what our mission is, our goals, our direction

Then: Refine and substantiate the three blocks. At this point, the orientation is still very abstract and not well suited for a resilient implementation. In the course of refinement, prioritization questions arise, as they are typical for budget discussions. We distinguish three types (or three budget dimensions):

• Products / product families (“what do we sell”)
• Architecture / technologies (“what can we do”)
• Strategic personnel development (“who produces it”)

And: execute. Strategy implementation is just as important as strategy development to achieve the desired clarity and alignment.

• Creating the climate in which everyone can participate
• Defining the target operating model(s)
• Roll-out and alignment

The context is not as linear as it appears in this diagram: in reality, these steps are interwoven and are iteratively passed through. They are partly fractal and also not exclusively the tasks of (top) management. A cooperative management model connects the strategy with management and day-to-day tasks and involves all employees.

The post From Identity to Strategy appeared first on Grado.

• Focusing on value – the first priority is pursuing a global optimum
• Organizing a continuous flow – delivering in small batches and short cycles
• Optimizing, reducing waste and striving for perfection

Main outcome: efficiency

The post Operational Excellence appeared first on Grado.

However, money is not a goal in itself – it is more the effect of running the business properly.

A word about startups: in this sense, a startup is not (yet) a company, but rather an experiment to see if an idea can develop into a business.

Recommended Resources

1. Businesses Do NOT Exist to Make Money Simon Sinek on Youtube

The post Economic Goal appeared first on Grado.

A just cause must be:

• for something – affirmative and optimistic –
• inclusive – open to all who want to contribute –
• service-oriented – for the primary benefit of others – thereby building a loyal base of employees and customers (and investors) who will stick with the organization through thick and thin.
• resilient – can withstand political, technological and cultural changes –
• idealistic – big, bold and ultimately unachievable – achievable is a vision that also plays an important role.

What does not qualify as a good thing is

• Moon shots, i.e. difficult to achieve goals
• “be the best”, i.e. measure yourself against the competition
• Growth in itself
• Social responsibility, i.e. things that the company pursues in addition to its actual goal

Recommended Resources

1. Infinite Games An overview of Simon Sinek’s ideas, developed from “Start with Why”
2. Introduction by Simon Sinek in 5 min on Youtube

The post The Common Cause appeared first on Grado.

Resilience is the ability of a social or ecological system to absorb or withstand disturbances so that the system essentially maintains its structure and functions. It describes the degree to which the system is capable of self-organization, learning and adaptation (Holling 1973, Gunderson & Holling 2002, Walker et al. 2004).

Recommended Resources

1. Resilience Alliance 

The post Organizational Resilience appeared first on Grado.

The post Guiding Principles appeared first on Grado.

The post Augmented Learning appeared first on Grado.