• Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 25 other followers

  • Archives

Form (ever) Follows Function

Ice, Water and Steam- Three forms of the same source serve different purposes. Each form serves multiple unique purposes. Force fitting these forms for functions not meant for them, don’t help and fails miserably.sample

This is a great natural example of “Form Follows Function” theory expounded by great architect Louis Henry Sullivan through his favorite design phrase, “form (ever) follows function,”

All great concepts like SAFe, LeSS, Lean,etc do insist on achieving the Goal collectively as an engaged organization. TOC nicely summarizes and advocates to Increase the throughput to maximum using leverage points / constraints.  Choosing a or a combination of any concepts before applying to any program should be judged by the function it should deliver rather than fitting the function into the templates of pre-determined concepts.

Common causes of failures of new initiatives in my experience are attributed to predetermined “Management flavor of the season” initiatives rather than focusing the function that need to be served.

What is your experience? please share your thoughts.

Release the Air, let the Value Flow

An engineer (Tech Arch) in a car manufacturing company designs a world class car.

While trying to bring out the car from the plant area, they realized car is few inches taller than the entrance. (Root Cause – Not factored all non functional requirements – Test and user environment set ups incomplete)

Engineer felt bad as he has not factored this requirement.

Painter (UX engineer) suggested they can bring out the car and there will be few scratches that can be touched up later on. (Applying patch after retrospective = extra cost)

Engineer suggested breaking the entrance (More cost, schedule delay), taking the car out, and later redoing the entrance.

A Gate Keeper was observing and remarked “Sir, the car is only few inches taller than the entrance, so simply release the air from the tyres, which will reduce the height and then you can easily take out the car”.

slide1

In TOC, this is an example of Inherent Simplicity and Never say I know – two key pillars of TOC.

Lean stresses this in its Lean Principle Respect People

In Agile parlance, it is involving all stakeholders during design retrospective (apart from Tech , DEV team include support teams as relevant) and be open minded and good listener.

Don’t look problems always from expert points of view.

There’s always a layman’s outlook that might provide an alternate solution.

Inherent Simplicity – A Key Pillar of TOC

 

Organizations have been finding it difficult to gather metrics data and trends that are directly impacting the business objectives. This pain is more pronounced in software organizations.

Dr Eliyahu Goldratt advocates that if we map causes, effects and opportunities, then reality turns out to be very simple. He calls this great concept as Inherent Simplicity – the home ground for TOC.

InSimple

The Metric Y can have many input parameters Xᵢ to Xn.

Business Objective  -> Program/Project Metrics   Y = F (X)

There are many  metrics(Y) we derive like Productivity, Velocity, Effort deviation, Schedule deviation, Defect slippage, Turn around time for resolving bugs / defects, Rework and more. While there are different categories of Y,  in most of the metrics that business needs to monitor and achieve is just two input parameters(X) Size (number units )and effort (time. Days) to arrive any metrics. Since we know for sure input variables (X) are just two i.e size and effort, it is important for the organizations to ensure capturing these inputs data accurately while the tasks are carried out in the system. From these accurate simple data organizations can derive metrics that are relevant to them.

Do you have any examples that used simple solutions to address large points. Please share.

One of the four Pillars of TOC – All conflicts can be resolved

All conflicts can be resolved.

One of the four pillars of Theory of Constraints is that “All conflicts can be resolved”.

Let us look take an example of  pole vaulting example in the sports.

The Pole Vaulter has roughly four  stages :

1.Approach . Run-up from the start of till vaulter reaches the vaulting-pit.

2.Planting the pole in the vault box.

3.Take off using the speed of the run by planting of the pole .

4.Swing up  to reach the top of the bar and  Fly away by pushing the  pole.

In Step 1 the Pole is used as the Tool.

In Step 2 & 3 – Pole is used as process work flow to reach the Goal.

Step – 4, After reaching the near top of the Bar, vaulter will identify the timing and drops the pole at right time as the pole is the

Conflicts resolution

Conflicts resolution

constraint to reach the Goal. Goal – Successful landing is achieved.

It shows that both opportunities and challenges (constraints and yields) need not be always separate from each other. Depending upon the positioning and timing in the life cycle of a product same entity can serve as a tool as well as constraint.

Let me know you have any experience / inputs in identifying the constraint and tool in a similar manner.

 



		

	

TOC – 3,4 and 5. Putting all together

TOC  Framework  – Three key points

What to change:  The system pains points that are needed to be changed.
To what to change to:  To be state.
How to cause the change:  Mechanism to be adopted.

TOC  – Four Pillars

Inherent Simplicity.
All Conflicts can be resolved.
People are Good.
Never Say I Know.

Five Focusing steps.

Identify the Constraint
Exploit the Constraint
Subordinate to the constraint
Elevate the constraint
Go to step 1