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

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.


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.

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


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…


Lean lifts Muda drags

Lean lifts Muda drags

Logic for lean appears magic for mediocre

not only weed out wastes, sets fire on them

path is unfurled, value flows without wait

conduit unconfined, elevating through upscale

continuously glued to innovation

where’s the work, its living spirit

embodying people, where product

stages disappear as if to reflect

oneness of sea, without plurality phenomenon

whether it’s the sea or waves or water or all one

so does product made of lean stature

not being different in concept, construct,

test and release. Product, people

and the consumers revel in reverence.

Lean lifts and Muda drags.

Lenify Flow

Lenify flow – Optimize the flow through bottleneck

Group review of software work products is one of the effective ways in reducing the work flow of Product through various gates of software life cycle. Typically the time taken using Group review methods to review software work products  like Software requirements, Design work products, Code, Testing documents is reduced up to one third of effort, it would otherwise take if these are reviewed by individual people.

For example the if the software development team after receiving business requirements from customer, review the requirements as team consisting of Project Manager, Project members, Architects, Quality group, Business Analysts and support functions they might take together say 3-5 hours for a requirements review. All these stakeholders will come out with their queries that can be consolidated and sent to customer on the same day for clarifications. On the other hand, If the project team reviews individually they might take say 2-3 days and then send to others for their inputs. This might involve more than 3 days since it not only involves review effort but also the waiting time from each of the stakeholders plus additional communication overheads.

The group review method is one of good technique that can be put reduce the waiting time, reduce the total effort and to increase the speed and the increase the product flow during the software development process. Group review of software work products is one of the effective ways in reducing bottleneck and accelerates the flow of work products.

SIPOC for Ideas Launch

SIPOC for Ideas Launch

Supplier Inputs Process Outputs Customer
Employees( trigger) Innovative suggestions Brainstorming the suggestions Output pointers Senior Management
Senior Management Ideas considered Preliminary validations Prioritized backlogs of ideas Department heads
Department Heads Share their project viability and plans  on prioritized ideas Weighing the cost vs benefit Benefits expectations on the prioritized backlogs All department heads,


Management Listing of top five ideas Launching top three Business plans for the launched ideas All employees

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.

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


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


Unreasonable, helps innovation

Unreasonable customer is the reason that the organization runs. For if it were reasonable users, there expectation are known and follow logic, there will be a huge set of vendors who could offer normal products or services and its very hard out there to sustain in the long run.

A sustainable business can leverage and PULL the unreasoning from the customer and use those logic defying requirements to build futuristic products or services. The actions that the companies need to take for converting unrealistic requirements should be equally ‘unreasonable’ by putting all efforts to ensure word class products are built without compromise.

When Chester Carlson invented photocopier even bigger companies were not sure about the photocopiers market and use. The success is now very well known and it kind of revolutionized the way the business were conducted for more than three decades.

Twitter is another contemporary example of Superlative success of micro blogging giant with just 140 characters. When the current digital age is obsessed with High resolution GUIs, pictures, video based contents, this simple 140 characters text giant is making sweeping trend all over the world.

The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man.

— George Bernard Shaw

Quality principles and Agile

Customer Focus:

Internal and external customer focus. Pulling of values by customer. High level of customer transparency


Servant leadership  – everyone owns the product

Involvement of People

Full stakeholder collaboration including developers, end users, QA, Management, etc

Process approach

Elimination of non value added steps and ensuring focus remain closely with respect to current priorities

System approach to management

Keeping in mind the bigger picture of product vision each sprint is developing a theme towards the making of final  product. Automated testing and continuous integration form system approach

Continual improvement

Learning from the previous deliveries of iterations of scrum, incorporating the customer / stakeholder feedback and striving for elimination of NVAs(non value added wastes) from the processes demonstrate continual improvement.

Factual approach to decision making

Decisions are taken through real data obtained through direct stakeholder like customer and end users. All iterations / releases can be directly consumed by users. User feedback gets incorporated into subsequent sprints. Great way of factual approach.

Mutually beneficial supplier relationships

Supply chain efficiency is at its best in Agile / Lean development since customers, vendors and all stake holders are in continuous contact with each other monitoring the product development. Software vendor delivers product to immediate customer, gets the billing done, customer releases products to end customers through various sales channels and monetize the product releases. End users get their requirements fulfilled

Preferable over Pleasurable III – Minimizing Cost of poor Quality

If the delivery schedule is very tight, process has to be tighter. Process here does not mean the extent of the work products/documents rather the right thinking and synergistic actions that excites all the stakeholders in getting the results they want.

Many projects world over have repeatedly experienced higher Cost of poor  Quality  in their projects due to fire fighting activities like fixing production bugs and issues.  Right mix of planning in terms of dealing with preventive, appraisal and failure costs would have saved lots of dollars in many cases. Getting on the same page with regard to product prioritization, in the context of current sprint theme could be main key in avoiding failure costs in Agile projects. Having good average of right experienced team resources will reduce the training costs that contribute to prevention costs.

Using the automated reviews and just enough measurements systems normalizes the appraisal costs effectively.

Similarly focusing on Just enough features in the sprint context will lessen if not eliminate failure costs.

Can’t stop wondering genius of great poet Henry Wadsworth Longfellow  on this great management wisdom, delivered two centuries ago.

It takes less time to do a thing right, than it does to explain why you did it wrong.

Right metrics or (getting the) metrics right – Use systemic thinking

Makes one wonders why there are many differences in measurement systems between many projects.  Automatically goes to prove that a good input and standard way of using measures to derive metrics is essential.  Best results can be achieved by making all the projects and team understand the agree on what should be unit time and effort consist of.  For example an ideal use case in case of Agile projects can be made as 6 hours excluding break and lunch times, assuming average experience of all team members does not vary beyond +/- 10%. Similar approach can be followed for all metrics.

As it is obvious that with just two inputs like time and counts literally all metrics like effort /schedule variance, productivity, defect density, turnaround time etc can be measured, it will a world of good for the project teams to agree upon the standard definitions on various units used in the projects. A slight tuning and agreement will sure do the trick in getting project measurements right.

A tool is just as good as the user. Whereas systemic thinking and applications equalises most of the fluctuations.

Whats in a name – ceremony or practices

Agile ceremonies like sprint planning, stand-ups, visual boarding, refactoring have been sounding like very formal customs that must be practised by all teams. Hence some people/teams prefer using the words practice instead of ceremony.

IMHO it is contextual, and can be used interchangeably. For instance a team that’s new to Scrum project management it should consider the activities like scrum planning, estimation, stand-ups, collaboration, review, refactoring et al, as ceremonies as these need to be minimum steps in ensuring project deliveries.  For a team that has matured through many sprints these activities become practices, implying that customs/ceremonies put into regular routines and become practices.

Also evolution means accommodating and modifying new elements into project management practices, that might involve replacing few practises. This is the essential spirit of Agile – embracing the changes.

As far as teams, learn, practise and perfect – sprint of Agile – What’s in a name?

A rose by any other name would smell as sweet.

Muda Agility Mapping

Over Production  Heavy Code Base, extra  WPS, more buffer resources contributing to non required features, obsolete WPs
Waiting  Unnecessary Hand-offs,  Excessive change request approvals,  in efficient Server set up time, unwanted tools installation, unplanned leaves
Unnecessary Transport or
Unnecessary movement of work products at different levels within the project, as against Kanban and collaborative Hub
Excess Inventory  Product / Application – Waiting for cross platforms, multi OS testing because the testing and user environments are not yet ready.
Over processing  requirements gold plating, design gold plating, etc., poor tools selection
Motion / Unnecessary
Wastage of time and energy. Spread out teams of same product, too much to and fro , no knowledge sharing
Defects  costs heavily to the vendors and customers alike.  Detecting the defects early by using Agile approaches likes TDD, Pair programming, Extreme programming

Right First Time (TQM) Vs Fail early (Agile)

As one who believes both in the solid principles of TQM as well as agility of Agile, wanted to share my perceptions about Right First Time, Every Time principle of TQM along side of fail early view Agile methodologies of software development

In order to get it right first time, there need to be lots of wrongs that should have happened early in the evolution of product development. This is true everywhere, be it in industry, theatre, art, paint  or sports, et all. Any aspiring champion will have to put in enormous effort to be aware, learn, practice and perfect his own endeavour. So may be the intent by saying Right First Time can be taken as applying the mindset to the current priorities, it may be practice, rehearsal or any work in progress to remain focused on the present. It will help them to achieve the ‘future Right’ whenever that will come.  Any activity be it product development, theatre play, music or sports will involve series of preparatory steps and each of the steps will be important to get the final desired outcome. Each of these steps individually has sub goals and those need to be ‘got right’. A step’s objective may also involve learning, as far as the learning is obtained  by the pursuer, she got it right. When all the individual steps got what they wanted as outcomes, end outcome is it Right, and indeed Right first time, because for that nth step, what has been achieved is first time event.

While Agile focussing on adaptability and quicker ROI for all stakeholders understands and is flexible in admitting that first 2/3 sprints there will be missed deliveries of few features. Also there might me lessons learnt from review and retrospective phase of sprints. These lessons learnt are indeed one of the sub goal of the sprint that meets the criteria ‘Right first time and every time’ too. Ultimately during the last sprint if all the lessons of the earlier sprints are effectively applied along the way Product delivered will be right first time. Individual sprints looked at the perspective of each sprint goal accomplished their objectives Right. As well they have contributed to ‘fail early’ part of Agile, due to the evolving nature of Product backlog and in the same time helped the overall Product Development Vision by solid lessons learnt practices.

True to ‘embracing the change’ nature of Agile, It will good to consider Right First Time and fail early as truly complimentary principles.

Agile TQM!

Seed Lean, Weed Muda and Yield Revenues

In general context Waste will be something that is not adding value to a system or process or output. Specifically in industrial applications whatever is extra to the present current activity is considered as waste. In  Agile parlance non required activity / feature is waste for the sprint in context. Hence we can interpret wastes in Agile as over documentation, lengthy meetings, too much steps for any activity, maintenance of documents in too many places are some examples.

One solution to help curb wastes will be to follow MSCW methodology –  for feature prioritization for the current sprint, which indeed will help in eliminating wastes effectively.

M – Must be requirements

S – Should be requirements

C – Can be requirements

W – Won’t be requirements

In addition to prioritization, waiting times like sign-offs, document approvals, too many reports / records for the same artefact in multiple machines, including non stakeholders in stand-ups all these can be contributing to Wastes.

Seed Lean, Weed (out) Muda and Yield Revenues

Preferable over Pleasurable II – experience over perception

Breakthrough improvements – Prefer experience over perception

It is very easy to breach than honour processes for the sake of meeting delivery schedules, more so in Agile context.  However solid standardization practices will help any team to get to the basic project  control mode quickly while giving project teams a way to think and innovate beyond.

The path of least resistance (PoLT)syndrome affects almost all teams taking shade under the Agile cloud. Even agile advocates refactoring and review phases during sprint ends. Then we have automatic unit testing tools, continuous integration tools, code checkers etc that are used in Agile projects generate good enough data for the organisation to better their performances in future sprints.

Skipping processes for the sake of Agility is like saying that the Sun is hidden by the cloud.

The irony is that

  • Sun creates cloud,
  • cloud is nowhere near Sun on distance front and
  • to sight the cloud itself Sun is required.

Similar note, Agile is created by good process and team work, till the sprint zero we have to have good software engineering processes like BRM, SRS ,Architecture, Design, Planning etc. To recognize good agile projects we need to have tracking process like Velocity, average velocity, defects reduction while scaling up the sprints. Good Unit testing and integration methodologies should also be implemented to ensure great agile deliveries.

Many real time project managers experienced that Agile is great with just enough processes.  In the same note it s just a (PoLT) perception that Agile needs little or no processes.

Choose the Preferable over Pleasurable

If Agile Sprint is fastest – process should be disciplined

Jenson Button’s pitcrew set a new world record for the fastest-ever pitstop in Formula 1 history: 2.31s at Santander German Grand Prix.

While appreciating this unbelievable performance of Jenson pitcrew in F1, a thought came on the Agile sprint deliveries.

For achieving this kind of superlative service performance, surely  an enormous amount of practice, planning and execution would have gone behind.

Assuming a normal agile sprint of 2 weeks service delivery, project teams and stake holders  are many times reluctant in following disciplined process of project management and tend to skipping reviews, not tracing the requirements effectively, poor estimation or nil estimation etc.

May this great clinical performance by McLaren’s team will help Agile Project Managers in believing to deliver fastest sprint delivery and still following required processes and indeed use those processes effectively for achieving greatest performances.

Just enough process accelerates breakthrough performance. Happy 2013!

2012 in review

The WordPress.com stats helper monkeys prepared a 2012 annual report for this blog.

Here’s an excerpt:

600 people reached the top of Mt. Everest in 2012. This blog got about 3,500 views in 2012. If every person who reached the top of Mt. Everest viewed this blog, it would have taken 6 years to get that many views.

Click here to see the complete report.

Compliance, Management and Excellence

Thinking from own experience, it is very interesting to compare and contrast Compliance, Management and Excellence in projects.

With millions of articles and deliberations around the world insisting that standardisation (Management) and Innovation (excellence) have to be two sides of the same coin, gated by compliance (standards and processes), here’s an attempt to understand the relative importance of Compliance, Management and Excellence in projects.

While Management takes major chunk of the project pie, other two factors Compliance and Excellence have their significant roles in ensuring an organisation’s overall current and future goals are met and tracked.  While Excellence and compliance are intended to be globally applied across the projects, locations and organisations, there are many challenges in implementing them in any organisation. This means that Management factor is given more focus and less focus is given to Compliance and excellence.

Does the survival and sustenance method looks like this?

Comply to just enough processes for just enough areas, Excel is in pockets of areas, and Manage most of the areas.

If that be so, it can be a good starting point to ensure synergy by moving away from compliance mindset to managing the projects effectively for maximum projects and functions and then improve by consistent innovations to scale up on excellence.

Even best of the big companies have been affected by compliance standards and few times fail to meet excellence levels that they have set forth.  However they manage to stay top by ensuring Management of projects effectively.

can there be a ratio of compliance, management and excellence model to be set across to different sizes of organisation?

Fellow professional, please share your thoughts

Innovation happens on comparing apples with oranges

Why not compare apple with Oranges. In fact innovation comes from non conforming concepts only.  Non conventional wisdoms considered to be taboo have been proven solid facts like Earth is ellipsoid and not flat as it was thought for centuries.

Waterfall and sequential model was challenged and emerged Agility models.

Education based on theories have been replaced by application and work shop models.

If we try to analyse how breakthrough innovation happens, it is  by comparing apple with oranges like in the above quoted examples and not by comparing  small sized to big sized apples.

Reasons for innovations are many.  Gurus who impart knowledge for creating breakthrough innovations are two kind. One is knowledge (reason) guru and other one is causal (trigger) guru. Knowledge imparting Guru helps in upgrading popular knowledge of the followers and make them expert in the same field. Whereas non traditional Causal Guru help the students themselves evolve to reach breakthrough innovation.

In the recent times we have best example of innovation – that is TWITTER. .  140 characters  of super communication shared between millions of users. Awesome. This example of causal guru led innovation. Here Guru can me a person or an idea or an inspiration or even revelation if one may call it

Any thoughts!

2011 in review

The WordPress.com stats helper monkeys prepared a 2011 annual report for this blog.

Here’s an excerpt:

A New York City subway train holds 1,200 people. This blog was viewed about 4,200 times in 2011. If it were a NYC subway train, it would take about 4 trips to carry that many people.

Click here to see the complete report.

Kanban and Risk Management

A great thought from Tirukkural – Tamil saint Thiruvalluvar couplet on Risk Planning and management.


Anjuvadhu Anjaamai Pedhamai: Anjuvadhu

Anjal Arivaar Thozhil


Not preparing for the unprepared is ignorance. Preparing for the unprepared is wise’s way.


Risky unplanned fails. Risks

planned leaders ways.


Risks are for sure to exist in any project regardless of domains. If not planned to consider the impacts and cause elimination and control, will lead to long term failures. Kanban is an excellent way to keep track of project progress and risk control. Agile effectively uses this Lean concept in reducing wastes and improving effectiveness of the product deliveries. Collaboration Hub can synchronize with Product backlog and ensure that all the stakeholders have visibility to all activities of sprints and product development. Upstream misunderstanding in architecture and design phases prior to sprints can become very minimal and risks are majorly contained by use of Kanban boards.  Unlike the detailed project management  activities carried out in waterfall model project managers cannot afford to have bandwidth in sprint based Agile models. In these cases Kanban is great way to monitor development and contain risk.

Feature development and Bug effacement – The other way round TRIZ 13

Personality development and defect effacement…..Product Development and Product Testing

Development is focussed on giving personal experience to the product user. Improving customer perception about product is the objective of all vendors. Many of the products / services / tools experience are decided by the first few looks and thoughts of customers when it comes to web.

This augurs well with the fact that product should give a feel of personal experience(development) to its user. However from the testing point of view all the critical paths need to be tested so that the product does not fail in the customer’s expectation. We can say that defect effacement is the tester’s manifesto. Other words, try to break the requirements from all needs and expectations of customer.  Requirements related to Performance, user, functional and non functional testing covering optimum scenarios must be tested if products need to be successful.

A product should be evolved by using quite opposite perceptions and contradictions at the same time. Personality development (developing customer personal experience – the product) and defects effacement (impersonal testing, testing to break all developed features) are great examples that fulfill the criteria of  TRIZ Principle 13. The other way round.

Turn Lemons into Lemonade

Just my thoughts on TRIZ principle 22 “Blessing in disguise” or “Turn Lemons into Lemonade”.

Use harmful factors to achieve a positive effect

– Using Heat wasted for generating electricity

Bugs arrival rate can be increased by Agile deliveries during the initial few sprint with more review effort using many resources. Early sprints produces more defects, because of many reviews and less product acquaintances. This increase of upstream product bugs will mean there will be less bugs in the later part of the product sprints(as initial sprint bugs are carried forward as features in subsequent sprints) , increasing their software Quality. Also during the mature stage of the product iterations, less resources will be working (because of less bugs ). This will give leeway for the project team as they can release extra testing/ review resources to another project during later product sprints. just my thoughts on TRIZ principle 22 “Blessing in disguise” or “Turn Lemons into Lemonade”.

Recycle waste  material from one process as raw materials for another.

Using defects as tickets for helpdesk system. The root causes of the defects with their cause eliminations can become lessons learnt and best practices for future project management

Eliminate the primary harmful action by adding it to another harmful action to resolve the problem.

Turn the waterfall development overheads by eliminating them through use of Agile Management practices

Amplify a harmful factor to such a degree that it is no longer harmful.

excess waiting time or  unnecessary sign-offs of work products are impediments to Agile product deliveries. These sign-offs from stake holders should be amplified to such an extent through visual KANBAN and collaboration hubs, that all stake holders literally have online visibility to the product development and can approve(“sign off”) or comment whenever there is a delay or defect of any kind in the product life cycle


Intuition and not tuition – way to manage risk

Plan, control and Manage Risk – through experience and not by books and tools .

Y = F [Risk Manage (Quality Cost and Delivery)]

Risk optimization = (minimize cost, maximize Quality and meet Delivery Schedule)

In the services scenario Risk should be planned from Contract stage and initiation itself.

There are many methods like TRIZ, FMEA, KAIZEN, Lean Six Sigma, Quality function deployment(QFD) for efficiently managing risks.

Since knowledge management is more subtler than material management Risk has to be defined in the right context of the organization, customer and other stake holders involved.

There’s a tendency of Project managers to stick to PMI or any other tools for managing risks. Though tools are really great source and improve the productivity of the projects, over depending on tools and standards may limit the project deliverable in the long run. If a project manager is interested in long term satisfaction of all stakeholders, he can think in new paradigm. Understanding the dynamics of various risks specific to each customer is the key.

Risk is best managed by intuition rather than tuition. A candle  is lit by another candle  and not by reading about the candle or by looking at  the pictures of it.

Likewise Risk and Project Management is best carried out not by reading PMI or understanding various tools, but by Risk and project management experience.

Passion over reason

TRIZ ideality states that it is directly proportional to useful function and inversely proportional to System Resistance.

Ideality =  (Useful function) / (Harm(resistance) + resources(systemized))

Resistance itself is a great bottleneck in any useful work flow and here we refer to system resistance that is to say more organized resistance that follows logic and reason and ensure total resistance.

A simple story that comes to mind here is about two frogs that had accidentally fell into a  small pot of curd.

They were struggling to to get out of the Pot and got jammed at the bottom of the pot.

One frog was a rational thinking web 2.0 frog and used his logical skills and told the other frog “we got fixed and there’s no way out, really”, “why waste energy and just remain as they were”

The other frog replied “I see your point well, there’s no use in our effort to get out of here”, “however I will keep hopping and jumping”, “may be something might happen”.

The second frog not- so- rational, after few hours by continuous hopping churned the curd into butter under its limbs . From the solid butter that was formed,  the frog came up to the brim of pot by using the solid butter  and jumped out of the pot eventually.

There will be Resistance to processes and standardization initially. QA team with passion and conviction can churn out traps (of resistances) into values (butter) and see the way out for their organization.

Lessons Learnt  : Passion beyond perceived reason make impossible things possible.

Unto you, offering thine own…… oh my customer

unto you, offering  thine own,

Oh my customer, non existing will I be,

devoid of your demands exigent.

Kano’s must-be’s my business rationale

while performance begets continuance

Attractive demands trigger  fortune hopes

best of design and product experience

caused by your demands,

commerce and transactions that you set

roll the world, guarantee and support

support business because you support

in a way understanding support service

makes you the provider and well wisher

unto you, I offer thine own.

Quality not the weakest link in strongest chain

Quality – need not be – the – Weakest Link in the strongest chain

If  Quality in its attribute form is weaker then we have many issues with Reliability, Usability, Efficiency, maintainability taking major hit. On the other hand Quality function is weaker either because of lack of expertise, less control on the delivery processes or resistance from the development team, customer satisfaction will get hit.

Quality in its all form should become preferred culture rather than pleasured lecture. For this root causes instead of symptoms need to be strongly analyzed and eliminated. Setting up of CTQs(Critical to Quality) is essential for the continual improvements of the products / organization. CTQs are specification limits that are defined as quantifiable parameters as small as possible needed to ensure customer delight. Functional, Non functional, Safety and user friendly requirements for a product are not just enough to be identified. These requirements have to be broken down into small manageable measurement attributes that demonstrate customer needs.

Root causes of errors / non conformances from previous audits, peer / customer reviews, walk-throughs  are a great source of understating the gaps and converting them to CTQs. Group reviews of  customer contracts/requirements before and during the course of project will further refine the CTQs and in fact will serve as the future Best Practices. Quality can be strongest by converting the weakest gaps into CTQs.

Skip process – blinding darkness, Follow it – darkening blindness

Skip process…. enter into blinding darkness

Follow process…………. embrace darkening blindness (greater darkness).

Skipping processes will never be good for the long term stability of the organization. Chaos will prevail and products and services will be delivered based on few Heroics rather than disciplined methods. Since it depends on few heroics of extremely talented resources, if those talented resources move out there will be major pains faced by the organization. This will involve more costs; dip in the bottom-line leading to losses.

On the other hand “following” ill defined or yesterday’s process without regard to today’s field realities of customer, market, technology or trends of future will lead to a greater failure. Because projects / people who are ignorant about process can at least be trained to understand and map their processes to efficiency. However not accepting innovation, sticking to older principles without concern for dynamics of customer, market will only help the system to fail in methodical manner. It will be counter productive to use older processes for current or future problems. Less process compliance at least will save some time and overheads.

Don’t skip (good) process, or blindly follow (old) process. Rather keep modifying the work flow to suit the market and technology demand. Innovation is they key here.

Set process or workflow based on current demands of the market; continuously attune the processes to address current and future dynamics of the market. INNOVATE.

Some methods:

  • TRIZ helps in reducing costs resulting in productivity improvements.
  • TOC advocates identifying bottle necks and handling them rightly to maintain work flow leading to higher throughputs
  • Lean propounds WASTE elimination
  • SIX SIGMA helps in getting the RIGHT product or service to meet customer delight with very minimal or NIL defects.
  • KAIZEN instills disciplined improvements on continuous basis.

By following any or combination of the above methodologies any organization would do well to improve their positions in terms of revenues, market share and sustenance.

Walk the TOC – Goldratt way

Throughput: The rate at which the system generates money through sales.

How soon  Delivery team liquidates account receivables? How fast customer pays the invoice? depends on customer acceptance of the delivery Quality.  Delivery Quality is determined by the strong upstream control in Requirements management, great design, less defects through construction and testing. These all dependent upon the understanding of the customer requirements by resources in development. These are preceded by Sales in its ability ability to judge how the customer requirements can be met by their delivery team. In order to reduce the gap of sales’ understanding the customer needs, it pays to have Sales people with previous experience in development.  This is how (development and sales) system generate money through sales need to be looked at, if  Throughput is to be maximum.  Thanks Goldratt for giving direction.

Inventory: All the money the system invests in things it intends to sell.

Maximum percentage of total investment goes to resources. Followed by software, systems,hardware, infrastructure etc.

As per TOC the money invested means Human resources invested and how their skills are intended to be sold. Technical skills, soft skills, domain skills, customer interaction skills become THE investment that can be sold. These are the skills that organisation should consider as Inventory. Have  great resources, excellent training, develop passion in serving customer needs. That could be a way to create Inventory the Goldratt’s TOC way.

Operating Expense: All the money the system spends in turning Inventory into Throughput.

Training the resources, providing them right tools and systems are the Operating expenses that will ensure Inventory(Resources) to turn their expertise into Throughput(Money)

Current practice of useless time sheets data, incorrect entries, guess estimations are really the pains that need to be treated the TOC way.

WALK the TOC !


Green IT Rationale and Actions

Greatest Problem is Cost

Greatest Solution is Savings (Revenues)

Measures Stakeholder Involvement

Purchase of equipments from energy minded suppliers

Looking out for best practices from Industry for reducing emissions     both in IT, support activities

Leadership in Energy &     Environmental Design (LEED), etc

Energy meters installation to monitor energy consumption

Virtual offices, Videoconferencing instead of travel

Power management software – Automated demand response system

Server virtualization   Data center designed for reduced power demand

Alternative energy supplies (solar, wind)

Mapping  Green Measures with Organizational Strategy

Green IT measures tied to financial reporting system

Cognitive Contradiction

Contradictions Matrix for Car On Slope and Quick Quality Product Release

Cognitive Contradiction

Brakes and Accelerator are both desirable Features of the any Vehicle. Though they are capable and many a time function mutually exclusively, I  have considered a specific situation i.e Trying to move a stationery Car from a slope, where these two features contradict each other.

Since Brakes and Accelerator are contradictory in their functions, a driver can obtain the objective of the system (driving forward) by handling both brakes and accelerator features in meticulous balance.

Similarly in Agile based delivery cycles (particularly SCRUM) the objective is to have a Quicker delivery and Quality product releases.

Here the contradicting components are Quick Release and Quality product. When the Life cycle duration of the product release is faster there is a tendency among the development team to skip upstream activities like Design review, Architecture Analysis, not bothering about requirement completeness etc. Just code and release.

At the same time if the Development team is just bothered only on managing, developing and tracing complete requirements by repeated reviews and walk thorough, they may not be able to deliver the product release to customer within timelines.

Solution :

Automate the reviews, unit testing, code integration, code reviews, testing etc.

Educate the resources on product requirements.

Collaborate with Customers in developing the product.

Involve Developer

Make team self adjusting


Simply Co create.

Be TRIZ until next press.

TRIZ Ideality and Ohm’s Law

Back after attending a great and wonderful TRIZ India Summit at Bangalore. Special thanks to Navneet Bhushan of Crafitti for referring me to this inspiring summit.

One of the central concept of TRIZ called Ideality was discussed. There was a session by Ido Lapidot from Intel. Naveent has written about this here .

During his great session on his experience of TRIZ implementation he mentioned about law of Ideality :

Ideality =  (Useful function) / (Harm + resources)

With my very limited understanding of TRIZ, I was curious and keen to understand the Ideality definition by comparing with Ohm’s Law.

Ohm’s law can be stated as the current in a resistive circuit is directly proportional to its applied voltage and inversely proportional to its resistance.

In equation I = V (Useful function) / R (Harm)

Usable Product = Value Added Inputs / Wastes As per Lean

Any usable software or hard ware =

(Clear Requirements, inputs, understanding)


Waiting time for approval, Review, rework, Bugs and defects injected

To achieve the maximum current (I) that is the Value proposition for the customer, the important task of Project head is to remove the resistance (R), the wastes in the words of Lean.

This is my first understanding on Ideality and applied in limited context. After a while with more exposure to TRIZ, I may be able to come out with improved mappings later. Let us use TRIZ and move closer to Ideality.

Agile Pit-stop and Agile Pit-Strategy

It is fun to compare Agile and Formula I Racing or for that matter any car race.

The pit stop is very critical aspect in car racing. The players and teams sketch out very carefully though out pit strategy plans with respect to number of stops, how many miles the car should have been driven before pit stop, tyre specs, corner speed wear outs, pit stop space and speed, tyre pressure etc.

Much the same we adapt in Agile development. Agile team should have proper reviews, design, retrospective, backlog management. Here is a casual attempt to compare Agile and Car Racing through Pit stop.

Let me know your thoughts.

Agile Pit Stop

Agile Pit Strategy

Agile,CTQ and CTC

Agile,Critical to Quality (CTQ) and Critical to Customer (CTC)

Critical to Quality(CTQ) factors are meeting functional requirements,  catering to non functional requirements, complying to statutory and safety requirements, employee productivity, schedule, defects etc.

Critical to Customer (CTC) factors are on time release, defect free product, SLA adherence, service availability, communication, consistent service and delivery quality etc.

Agile being collaborative development concept, CTC and CTQ will be matching closely with each other. The visual signals like Collaborative Hub (a software Kanban equivalent), burn down charts provide excellent tools for reducing the gap between CTQ and CTC. Additional benefits like ensuring waste reduction, eliminating unnecessary reviews and unwanted sign-offs come us bonus along with Agile adaptation.

On the limitations (or should we say initial investment), the Agile team should have prior experience in disciplined software engineering approaches before attempting to Agile. It helps a great deal. It is like having net practice in a tennis match before the real match.  Do not underestimate the development team software engineering experience.

Truly when CTQ = CTC, Co-Creation happens in Agile.

Lean not Leaner (Simple not Simpler)

Lean (eliminate heaviness) but not leaner (Lacking fuel).

Use Tools to reduce waste (effort) and don’t eliminate unit testing, good estimation and effective reviews.

Agile ways of development means ensuring light weight and efficient velocity for the project engine to take off to iteration destination.

However in the name of simplicity we should not make things too simpler by avoiding necessary fuels (reviews, unit tests), air (tools), lubricants (stand up meetings) to the Agile engine.

Over simplification results in lack of values to stakeholders.

Lean Leaner
Think Product Vision by prioritizing Product Backlog through Sprint Backlogs Don’t forget Product backlog, theme and vision while detailing in Sprints
Agility means thinking in story points and ensuring values to all stakeholders. Customers are not interested in tasks status but stories status that adds value to them Don’t skip stories planning, estimation, mapping  with tasks as subsets. Tasks based planning will be useful for developers if they cant think through stories.
Eliminate Manual efforts in : unit testing, reviews, code integration. Use Tools Don’t skip Unit testing, adequate reviews by being “Agile” that is not
Have short stand up meetings Don’t overlook stand up meetings as a way of saving time. Skipping stand ups results in teams sitting down on the sprint.
Have planning poker estimation or any other rational and simple estimation. Don’t skip formal estimation and allow guess estimates. This over simplification will lead to confusion and missed features for the sprint planned.
Have product vision in back of the mind and focus on the current sprint. Set and leave the integration and regression testing to the tools . Don’t dilute code review without thinking about the dependencies and the impact of the present features into future iterations.
Use test early and test often tenet for both functional and non functional requirements. Never avoid non functional / alternate paths for testing in the name of agility
Clear the impediments by ensuring right resources, training, clarity, tooling and understanding Does not mean compromise on technical Quality of the features by concession to developer’s lack of skill. Train resources.
Collaborate with stakeholders Not to include over participation from people not directly involved
Make it simple Not Simpler

Everything should be as simple as it is, but not simpler – Albert Einstein.

Perfection of means and confusion of aims

Typical Projects with the paraphernalia of sequences and steps are PUSHed into waterfall development methodologies. Project managers and stakeholders insist so much on process frame works, documentation and client sign-offs at every phase like Business Requirements, Software requirements, LLD, HLDs, Code check-ins, testing etc leading to heavy overheads. Not only does this create wastes in the system, it causes potential defects waiting to be discovered during the downstream stages of product releases. This is the way to “how to make projects fail and increase cost”.

Instead if project stakeholders commit to Agile Development, build products collaboratively and value people who matter most like developer, user and other key stakeholders and have trust in the system being built, the aim – the goal of successful products release will be achieved in the end. Means are important for sure, not to the extent of impeding the aim – “building products quicker and better”.

Product owner and scrum master jointly can decide on priorities based on drive the product development towards success.

  • Have Product Vision.
  • Collaborate with Customers.
  • Believe in people who build products.
  • Use optimum process as a means.
  • PULL the Value through customer driven development.
  • Eliminate Waste.
  • Make Great Products.

Wisdom of Albert Einstein:

“A perfection of means, and confusion of aims, seems to be our main problem”.

SCRUM – Stories and Estimation – Part II

Planning Poker Estimation for Scrum:

Can use Planning Poker method to get consensus and arrive the stories value for estimating story points. Use athletic sprint notation for categorizing the complexities of story points.

Sprint stages and estimation


Attribute categories like L (League), Q (Quarters), S ( Semis) and F (Finals) for complexity of the stories.

L being the lowest complexity
F is highest complexity four times complex than the L.
Q is 2 times L and
S is 3 times L.

SCRUM – Stories and Estimation – Part I

Story is a useful perceivable Value to a stakeholder.

Customer or Scrum master can define stories for the prioritized backlog items in the running sprint. It should be done in user pitch and to developer understanding. There is no firm requirement in defining stories.

We can use the SCRUM acronym for defining and estimating stories.

S – Specific to functionality being developed
If the story is “Dashboard Report “(of a Project management Tools in development) – it can be something like this:

“As a Project Manager, I want Status Graphs of running project so that I can know about completed and pending functionalities of my project.”

C – Criteria of acceptance– clear and independent as much as possible
Dashboard report should have
Status graphs for indicating completed functionalities,
Remaining functionalities,
Status on all functionalities with respect to delay/on time/
deferred / closed.
Escalation for delays.

R – Realistic – can be executed in the current sprint
Have the ability to complete in present sprint and is independent functionality

U – User valuable – valuable for stakeholders
Stake holder – Project manager and other users can view the
status of project any time

M – Measurable – can estimate them and test them
Can measure the effort for the Story called “Dash Board” and can be further subdivided into tasks and they also can be estimated.

Lean : Value,postion,people

Position the people or people the position. Neither.

Positioning people -flaws::

Positioning people for the “experience” may not be all time good, especially in the future growth perspective. It is the disposition as the attribute should drive the position. Every one irrespective of the position should have objective and goals set. Not only the dynamism and action at the top help the senior management but also really motivate the bottom of the hierarchy.

How? If the Top management constantly updates and committed to continual innovation , then there’s a chance that they might try to understand the innovation triggered in the middle and bottom tiers of the organization. Senior management will appreciate the extra work put in by the bottom tier people in addition to catering to the standard roles they perform. In other words Lean and flat thinking sets into the organization leading to world class.

People the position : challenges ::

Though not seemingly as flawed as the former choice, it puts in some sort of constant pressure for the management and HR function to seek and fill the hierarchical roles whether useful or not. Instead if the flat organization approach is followed in spirit and philosophy. HR and Management functions need not worry about people labeling. The organization will itself adapt and mature into flat organization and will take care of itself to fit people with suitable positions. This will too lead to Lean thinking organization where core is focused and wastes are discarded.

Be Lean.
Be Value centric.
Eliminate Waste.
Respect People.
Disposition position.

Value Stream Mapping in Agile

 Visually documenting a process for information flow and process flow.

 Identifies the existing state and defines future state.

 Helps in finding root causes for weak process areas. Data is obtained from different sources like technical reviews, project management reviews, code walkthroughs, Fagan inspections, internal audits and assessments.

 Overall the data assimilated through above reviews should be codified and informed to all team members on a regular basis. Possible fixes for the root causes should also be available along with each cause.

 Project teams should use these data and try to prevent same kind of issues recurring. This is the first step towards standardization.

 Once the process is matured and similar kinds of projects tried to avoid repeat errors then the team should innovate towards future goals.

 In Agile development environment the Scrum master acts as impediment remover that can be considered as part of waste elimination.

 White boarding or collaboration Hub is the best visual flow depiction in Agile development.

Since Agile is people driven it encourages developers to find the problems themselves and eliminate at earliest opportunity. It is what “be the change you want to see”. Agile lessens process entropy by making more value adds available to team. After three or four consequent sprints teams mature and delivers a good release that meets the prioritized functionalities in working state

Scrum leader facilitates the team in Agile manner, identifies issues, find and fix the root causes and finally spread the learning across the organization.

Also empower people by making them not waste their time and effort in overheads (wastes) , letting them fix their work and help them solve their own problems.

Customer drives the development as product owner and ensures only product priorities are executed in the current sprint and ensures leaving less priority backlogs for future sprints. Value stream is processed in a reverse manner by PULL from customer. Customers are main drivers in waste elimination in Agile and hence Agile is in perfect synergy with Lean.

Imperfect Quality Vs Perfect Defect

An imperfect quality is better than a perfect defect.

trying to measure software metrics like Plan effectiveness, project tracking parameters right from requirements through design to release attributes will be better than non measurement and “trying to save time”.

Irrespective of project size or duration always have plan. In fact the shorter the life of project stricter the planning required. It goes without saying that in the long duration projects one can have some chances to correct some errors and in Agile projects it is not possible. Hence planning activity should be performed and measured as a minimum for the effectiveness. Plan and actuals exist for all activities and the project should measure this attribute as minimum metric.

Even maintenance and bug fixing projects should measure few important attributes for better control of project. Over a period of time better measurement system will evolve out of such projects on its own that will help other projects also.

Lack of data has proved to be real handicap for many software projects that could have otherwise become more successful.

In the beginning let the metric system be erroneous with little data and no trends. Never mind. Actually it should be less accurate in the initial stages reflecting the early stage of maturity of the project. As the project carries on more data points will be available and the metric system will get consistently approximate. Then put back the plan in such a way as to follow the actual. Once the planning tries to catch up with actual,then start measuring planning vs actual that will be the threshold point for good metric system.

Measure Quality and it will pay back riches in the long run.

Start with imperfect Quality than “save” time by not measuring and leaving defects consistently in the system.

An imperfect quality is better than a perfect defect.

Excellence élan

There is no defeat in having a goal as excellence.

Success may not be immediate outcome of excellence.

Nevertheless if the efforts are noble and consistent towards excellence the work becomes fragrance itself. The reward for effort to excellence will come at appropriate time and in bounty. Resist the path to short lived success and Lean towards sustaining achievement by attuning with Excellence.

Few thoughts:

Excellence élan :

Manifestos are great defining. Greater if implemented
Visions and missions are fine year wise. Wonderful if they are a decade wise.
Lean is more . Lesser the MUDAs (wastes) more the Value.
Quicker the iterations delivered, better the products usability
Lighter the documentation overheads more the benefits for stakeholders

Talk Folks

More the conversation between stakeholders, lesser the defects in iterations / deliveries
Increased code integration means decreased defects injected
Earlier the testing begins clearer(of bugs) the product
Talk (interaction) more bug (overheads) less

Agile Delivery – Hindsight or Hunch

Neither. It is a Hybrid approach of many essentials.

For the Hunch:

Experienced team knows what are the priorities for the current sprint release.
Experienced team that knows why they are skipping few processes explicitly.
Experienced team has ability to help customer in driving the Agile projects.
Experienced team ensures that requirements are PULLed from stakeholders,
Experienced team minimize wait times for development and test phase activities.

Once the sprint team starts working on burning their stories thing like estimation, explicit configuration management, documented reviews will become less pronounced. In this way this follows the Hunch of the Agile professionals involved.

For the Hindsight:

Hunch comes from hindsight
Competence on pair programming
Consult the customers
Expertise in understating the product owner’s and stakeholder’s requirement,
Fitting the most wanted in the current release,
Collaborating with customers daily, continuous integration,
Ability to create test cases that would drive development

all these form part of experience by hindsight.

Though review and refactor are some of the powerful agile concepts in ensuring quality deliverables in Agile delivery, still in complex mission critical projects structured programming will always tick. Some projects take few months to develop even a prototype, these projects should be grounded on solid software engineering principles. The prototypes are continuously refined and customized with the feedback from the stakeholders involved.

Hybrid model approach suits best for software development in general and Agile in particular.

VOC (Voice of Customer) the WOC (Woes of Customer)


Organizations involve in many upstream engagement activities like great product demo, road shows, white papers, catch lines, attractive ads and trade shows et all. After the contract is signed with prospective customer many small and medium enterprises organization that do not live up to the promises made cannot sustain for long in the business. Reasons are many. Ineffective communication between Presales, marketing teams with delivery teams is the major factor in failing to meet customer expectations. There are other reasons like inability to capture customer undefined expectations, non functional, performance, domain specific and safety requirements et all.

Customers particularly the end customers are interested on how the product / service will satisfy his expected and intended requirements rather than any white papers / case studies. We can take lessons from giants like Toyota and other BIG players like Ford, GM and Chrysler on how they implemented the TPS and continuous improvements in their plants by considering the entire Supply chain elements from vendors to end customers. Their checkpoints, rigorous inspection before delivery, feedback surveys and focus group analysis target the real time user experience and incorporate the feedbacks on continuous basis into the product design and evolution. The feel that the customer has on his experience of using the products of these great companies is converted into quantifiable requirements by Business group. These requirements get transformed into user design and finally product is rolled out. Rigorous inspection and testing takes place to validate multiple parameters of all customers and stakeholders. In spite of working on the upstream activities before production, on few occasions there will be some defects after the products reach end customer. Their extensive networks of after sales service takes care of even the few impacted customers and ensures that these companies really are seen as partners in progress for their customers. Customer remains loyal to companies who serve them with real intent of meeting and exceeding their needs and wants.

The IT industries particularly SMEs (Small and Medium enterprises) can learn from these invaluable customer experience patterns of Manufacturing practices particularly from Auto Industries and should develop a systems that focus on Upstream activities like Solid Architecture and a great design and evolutionary feedback systems that continuously take  inputs from the downstream activities to become better on a constant basis. Customer experience from various segments and domains should be captured and senior management should commit to remove the woes of customer by designing the initial phases of the product development in a thought out manner. If we want VOC (Voice of Customer) to be positive and delight to us we should consider eliminating the WOC (woes of customer) in the upstream activities itself.

SIPOC – simple example – training

Supplier Inputs Process Outputs Customer
Indenting function Request form Specialized training request Request sent Training department
Respective Functional Head Names of the resources Nomination of the participants for training. Mail confirmation Training department
Training department Names of people received as requests from all functions Short listing  the nominated participants 


List of attendees for the training Respective departments and functions
Training and functions List of training vendors Choosing/ approval of trainers Approved trainer details Training dept. and functions
Functions and departmental heads Suggested training topics and course notes Approval of the training material content Training content Functions and departments
Training function Training course, venue, material and others Perform training as per the schedule and content for fulfillment of training needs. Training course being conducted Approved 


Departments and functions Course proceedings and effectiveness Evaluation of training effectiveness Feedback on training All departments, functions and training function

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.




Subordinate other decision to bottleneck

One of the key focus in Theory of constraints is “Subordinate every other decision to bottleneck”. This one focus is a great beneficial differentiation when compared any other innovation / productivity technique.

It can be applied to software projects and program alike with great potential improvements.  Finding out the key steps in any work flow / life cycle / program and identifying the critical bottleneck is half the problem solved. Next step is to work together as a team brainstorm how  all the processes and people can collaboratively work together to weave the innovation magic. All processes should be synchronized and subordinated to help smooth-en the critical bottle neck so as to achieve maximum efficiency of the whole system..

Random example for presence of mind

Not sure whether this makes for presence of mind, just sharing..

In one of my earlier organisation many years back, one customer has included a penalty clause (deducting some percentage of payments) for delayed shipments of products to him. The product was a combination of some outsourced parts from different regions of the country. Hence we had lesser controls on few parts. However the contract was important strategically.  The delivery schedule of the products was planned in phases to customer’s sites.  A smart sales person agreed to the penalty clause knowing the risk involved. However he proposed the customer a bonus clause that involved some bonus (customer had to pay additional costs) should be paid to us by customer, in case of advance shipments of products with almost equal condition to that of penalty. Overall the shipments were mix of delayed schedules in the beginning and advanced schedules towards the end. Both customer and we were happy.