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

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


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.

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

Handling is good, Awareness is better – of Muda

Being aware of process and project MUDAs is more important than handling them. As it is rightly considered in software engineering that defects are injected into the work products at various stages and not inherent in the system. (Though in Six Sigma parlance we have 1.5 sigma shift caused due to passage of time, is in different context altogether)

At the beginning of any project inconsistencies in understanding between customer/end-user requirement and software vendor understanding of the requirement, there is waste called MURA that is created. This is not created by the system rather caused unintentionally between the stakeholders viz, software vendor development team and customers. This is where awareness of MUDA or any types of wastes is really going to benefit the teams. Tools are deployed, Business analysts are employed , still there will be some inconsistencies  May be, it is impossible to get the same and right understanding between development team and customer on round one of the discussion on requirements. However all parties involved should be just aware that the wastes of different nature like MUDA,MURA and MURI can get introduced into system in spite of the best skills displayed by the team. Experienced teams should keep a list of assumptions on the possible wastes that they feel at each stage. Over a period of time and project progress, the assumptions can be validated by the reviews of work products along the common goals shared by all stake holders.

This is true for all phased of software development. Wherever there is an input, process and output sequence involving multiple interfaces of people, there will be wastes injection. Just the awareness and recording of these wastes assumptions will help the team to review and progress gradually towards a great product vision.

The Lean coach therefore drives the awareness of MUDA,MURI and MURA more than handling them. Because as it is said in PM circles one size does not fill all, much the same way  there is no common list of wastes that can serve as check-list for different product development working with different vision and stakeholders.

Being aware of the Waste is more important than handling them


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

Handling Service MURA and MURI

Service MURAs:–

is understanding terms differently within the same organization. One common situation is that Agility is interpreted with multiple meanings from different sections of the organization depending upon the size of the project, engagement model, offshore-onsite structure, delivery criteria, experienced levels of resources etc It is suggested to have knowledge sharing sessions on the common contexts of the company policies including processes, models and procedures. This will clear our inconsistencies in meanings of concepts and models within the organization. Although project level inconsistencies need to be removed, this might be little easier when compared to removing organizational inconsistencies. Trainings and awareness sessions, quizzes and book reading sessions will help to spread the consistencies of concepts quickly and effectively within the organization.

Service MURIs

could be duplication of procedures and non value added activities that strains the  flow of the development / delivery processes. When the lean tools are applied to effectively eliminate non value added activities, there will be less strain on the work flows that will quicken the product outflows. Multiple reviews in excess for a same stage process, passing same information to multiple locations at different times, gold plating of work products that are not required are some of the MURIs in service industries. Some thoughtful actions like group reviews (as against multiple reviews), conference collaboration with all stakeholders in different locations at same time, developing and focusing on just enough requirements could do well in eliminating service MURIs


Gemba Walks in Scrum

In Service industries like software development, we can use Gemba walk in Scrum stand up meetings and Collaborative Hub reviews and also during reviews and retrospective.

Though in manufacturing industries, actual shop floor is the place Gemba walks mostly happen, in software development with the right stakeholders around, we can leverage Gemba walks to great benefit.

At the Standup meeting just sticking to chosen standard questions like, what happened, what is planned and what were the hurdles, A scrum leader can Gemba walk through by understanding the perspectives of each stakeholder contributing the stand-up meeting. Key is not to overdo as stand-ups are limited to 15 minutes or so.

During product dashboard reviews using burn down charts, excellent opportunity is in front of scrum master and product owner to Gemba walk, ask questions by showing respect to all stakeholders involved. This will create a great deal of confidence and also enable the team to open up their minds to achieve a common product vision.

Finally during reviews and retrospectives, scrum leader can Gemba walk along with team and ask right “why” questions and see an opportunity to introduce lean tools like PULL, Kaizen, MUDA elimination as they best fit for the current situations