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

    Join 24 other followers

  • Archives

You before I, TOC vibes

In my earlier post UB4I, I briefly touched upon how Agile development is pro-people and has ingrained team spirit in its working methods.

As I have also gained over few years experience in Theory of Constraints (TOC), I see there is a greater synergy of this UB4I (You before I) spirit.

In its Four pillars of ‘Inherent Simplicity’, ‘Every conflict can be resolved’, ‘People are good’, ‘Never Say I know’  TOC is replete with the great team / organizational phenomenon of working as a whole and for the whole.

Estimation is one area that is posing great challenges for large teams particularly in software  development. Many factors can be sources for incorrect and inaccurate efficiencies.  Complex requirements, too many scope creeps, market conditions influence  accuracy of estimates.  TOC helps here by focusing on only three basic metrics like Turn around time, Operating expense and Inventory costs.  Operating expense is defined as the money system spends to convert inventory into Through put.  Here the focus is only on the system throughput and not on individuals / project level.  Team will be highly motivated and will have solid clarity of the role and expectations from them to align to the system’s Goal. IMHO, I see this as inherent simplicity.

Agile and Lean software development focus on collaborative development and working. Greater visibility for all stakeholders, involving vendors right from requirement stage / product design stage, create a super positive environment for great product development and innovative solutions. Daily sharing of the progress of the release and sprints with customer and solving any issues / conflicts by shared understanding lead to quality products to customer and confidence to vendors. I see this as ‘Every conflict can be resolved’ principle of TOC.

Self organized teams, feeling of ownership and common goals in terms of stories to be burnt by team and its members, truly vibe with ‘People are Good’ pillar of TOC.

Systems thinking is one of key component of Scaled Agile Framework (SAFe). Typically many groups (some times called tribes) like Technical Architect, Domain experts, Compliance team and other types of subject matter experts work in harmony to produce innovative products and solutions. Here the matching principle of TOC is   ‘Never Say I know’, implying many teams and teams of teams work in cadence.







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”.


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.

DOD for Agile rationale – UB4I

UB4I  – DOD for Agile rationale 

Value delivered is the most effective metrics in Agile. Prioritization by Product owners  and relevant stakeholders make the user stories for first few sprints.

‘Don’t measure people but product’ paradigm is best  represented by Agile model.

You before I mindset is the greatest skills for an Agile team member. Like we have definitions of done for various  stages of Agile product development, an attempt at DOD for successful Agile practitioner is UB4I.  

Some traits for UB4I

  • teams share their work expertise
  • caring for other issues
  • Committed to common Sprint and product goals
  • pitching in whenever team requires help
  • Collaborative
  • co-creative
  • Be a product developer as against coder
  • wearing multiple hats in the projects

please add on…


Pythagoras values for Agile delivery

Value delivered (Working Features) = Product Backlog + Non value added features (incomplete

Lesser the non value added features, more value delivered.

Though defects cannot be made zero, hence incomplete features and non priority functions (contextual defects) are pushed to the next sprint cycles. Ensuring effective prioritization will help teams to deliver more values

Practice Pythagoras for a perfect value delivery using Agile

When fix is painful than defect (Medicine pains more than illness) – Get to theory- 3.4 couplet

When fix is painful than defect (Medicine pains more than illness)

Get to Theory

~3.4 couplet

A small half cup (like that of cough syrup bottle) will contain 1 KG of water vis-a-vis around 74 mL of water. This is the practical way of informing the density concept to children, instead defining in formal physical terms like ratio of unit mass to unit volume expresses in kg/cu.m etc.

However as the child grows perception of density becomes a concept and understand the definition formally. When the child was not able to visualize concept, a direct visual demo was required as the child could not apply the density with just basic perception. However when the child becomes grown up, it will need to understand and extend the concept to broader areas and will be able to derive the density of various substance on its own use the property of density in the relevant application.

The point am trying to suggest is that quick and hot fixes in the name of Agile, will impair the long term solution/product rather than strengthen it.  Here we need the help of theory and concepts. Addressing the root causes and systematically eliminating them will make the model more solid and ensure that product / service is evolving in consistent and effective manner. There are cases where the fix is taking so much effort and cost than the leaving the actual defect in the system, resulting in more CoPQ.  Looking at this way also predictive capabilities if remain the focus and applied in true manner, then will ensure meeting long term objectives of all customers.

Solid grounding on basic concepts will help, in the words of great Toyota way provide the customers with what they want when they want and in the amount they want.

MUDA- Agile-combination – long term as well as short term benefits

Agile can be used to build a great product that can use best of both worlds like long term vision – building a good  overall product as well as quicker return of investment – by delivering working iterations in quicker sprints.

Awareness of MUDA  is more important at the mental level than the measurement level. Just to expand this,  the team need not have checklists of do’s and don’ts rather focus on what is really important to customer in the current project and eliminating everything that customer does not want. During the initial two to three sprints there will be mutual learning between the customer and vendor and then once the PULL mechanism is established , the MUDAs can be identified from all perspectives, the value and product will flow in smoother manner by eliminating the MUDAs

Identifying objectives for the common good of all stakeholders and customers in particular will help define the MUDAs that need to be eliminated from the system.  This will make to faster deliveries, better products and cheaper costs for all the stake holders