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

    Join 24 other followers

  • Archives

  • Advertisements

Key factor – compliance or outlier

Data Points in trends like normal distribution determine the compliance vs outliers.  In Agile product development it is interesting to see and analyze the compliance vs outliers.

Estimation : Planning poker method – all scrum team members take their call based on their experience and judgement. So the Scrum master / PO decides the estimate value by consensus not by majority. Here outliers have more weight and will be important factor.

Sprint Planning : Prioritizing of stories is a collaborative effort between PO and DEV team/ Here the factor deciding the call is a common shared goal. Not outliers.

Skill / role matrix : Whether DEV and TEST teams will do their DEV and TEST tasks only or involve themselves in multiple areas if they have free time. Again in this case,  it is a new habit, may be. It’s a combination of compliance and outliers.

Product acceptance criteria and Definition of done – Clearly compliance

Review and retrospective – mix of compliance and outliers.


CTQ (Six Sigma) and features (Agile)

Product vision sequence could be built just as Product tree is developed in SIx Sigma project.

While in Six Sigma project A product is sub divided into sub-products, in a similar fashion  scrum themes could form a sub division of product vision in Agile product development.

CTQs are derived from sub products in Sigma project, and in the Agile parlance scrum themes will have drilled down entities as prioritized features.

Six SIgma offers help in granularity by way of CTQs development. Agile has matching equivalents like features of sprint drilled down to smallest level of chunks. Only difference Six Sigma has is that it also specifies what is not included in project as different from Agile that just focuses on current feature requirements.

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.

Thirukkural – FMEA, Elimination of MUDA

A great Management and Productive thought of Thirukkural

Verse :

EthirathAk  kAkkum Arivinaarku Illai

Athira Varuvuthor Noy

Direct meaning:

Those people of capable intellect who can feel the imminent pains and have plans to tackle them,  know not of any fear from sufferings.

Lean Six Sigma inference

A Six Sigma methodology foresees and expects pain points and adresses them with fall back plans. This when combined with lean practices makes perfect formula in eliminating wastes and mitigating the unfavourable impact. 

Six Sigma uses FMEA, Risk Planning, Forecasting – Hence expects and reduces pains and preapres the solution. Lean eliminates waste increase productivity and beautifully compliments Six Sigma.

Agile follows Ohm’s Law

Lean follow 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 / R


Usable Product = Value Added Inputs / Wastes


Any usable software or hard ware =


(Clear Requirements, inputs, understanding)


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



Lesser the resistance more the current. Current follows the path of least resistance. This classical law has amazing similarity when applied to PULL system of Lean Production. The Pull system ensures that the value stream of any product life cycle flows in a path of stream. When the upstream activities of this product life cycle are facing resistance in the form of impediments like wait time for approval, review and multiple hand-offs it tends the lower the Value (current) of the Usable product.


We can adapt the Ohm’s law in Lean Scenario as Value(defect free product release) of the product is directly proportional to the Value added Inputs (like coding, release) and inversely proportional to the resistance (like waiting time for approval, review and rework, bug fixing etc).


To achieve the maximum current that is the Value proposition for the customer, the important task of Project head is to remove the resistance, the wastes in the words of Lean. The process should also ensure that direct value added inputs are taken for converting them into valuable outputs


If we consider requirements as valuable inputs, and released product as valuable output then the wastes are unnecessary waiting time for approval, review, documentation, rework, bug fixing time, defect injection for not following standards and best practices, etc.


The output i.e the usable product release will have to be streamed out by pulling the flow naturally without having resistance / wastes discussed above.

Agile maps to Lean – Muda, Mura and Muri


Dr. Shigeo Shingo and Mr. Taichi Ohno have contributed immensely towards improving production processes at Toyota through concepts Muda, Mura and Muri. They enriched the Toyota Production system now became to be called as famous Lean Production system.


Let us try to understand the meaning w.r.t Industry in general and software development in particular.


Muda : Non value added activity or waste.

Mura : Unevenness or inconsistency

Muri : Overloaded or excessive strain


Reworks, multiple compilations and check-ins after code is developed due to inadequate design are some of the classical points of wastes in software development. In Scrum management, project team delivers sprint in prefixed duration called sprints, during which different types of Muda elements are need to be avoided, so that maximum number of prioritized stories can be burnt during the current release. If upstream activities like Architecture, Design and Planning have been carried out effectively then during the sprints there will be less abnormal variations leaving the teams with little rework to be done. Since Agile adapts to the changes from stakeholders requirements that means true to the Lean Management it wonderfully implements pull system from product owner and makes changes in the upstream activities like backlog management and priority settings. Hence optimized upstream Pull systems along with adequate upstream activities like good design and test activities will ensure that Muda in the system is eliminated to minimum.


Muda examples in software development :


Multiple check-ins and compilations of code : This will happen because of inefficient resources or not understanding the requirements of the customer specs. This is most critical factor in making the software defect prone. If we can ensure that right resources with right skills prudently understand, define, design and develop the system, we can avoid maximum rework.


Delaying testing to the end of the life cycle. Not testing the application till the end of the life cycle means that undiscovered defects, risks are carried till the end of the product development. This will create huge rework and heavy costs to the organization. These reworks can be identified and corrected by being iterative in development and use tests early in the life cycle. The test suites should be automated and the integration of code also should be automated. This will ensure less waste in the system.


Waiting time due to many handoffs in the product life cycle. In typical waterfall development models every phase artifacts should be approved by next in process stakeholders and if the stakeholders are occupied the work products simply get stagnated leaving some people in the system to remain without productive work. If we follow the peer reviews, group reviews and tester-developer collaboration from early on the wastes arising out of wait time can be overcome.




Not following standards / tools / best practices :

If a particular application is tested by five different people it produces 5 completely different results. Even different developer develops a particular module in different Ways. The best way to bring about consistency in development and testing is to make everyone follow the standards, conventions and policies of particular organization based on their own best practices. Using tools like FxCop, Cruise Control and other development / testing tools will reduce inconsistencies in outputs of resources. When inconsistency (MURA) is removed from the system the predictability towards estimation, cost will be better. This will lead help the product owner with high degree of certainty in bringing the product to the market on time. For the software organization it will results in more business.


Not understanding requirements, ambiguity in requirements, not capturing implicit and no functional requirements. Avoid these MURAs


Multiple contacts from software organization as well as customer side without taking a common view on the product evolution. Avoid these using transparent stakeholders’ collaboration by white boarding and sharing.




Excessive strains put on the development teams and expecting unrealistic outcomes with less time available. This can be the result of under estimation / poor planning w.r.t scope, schedule and skills. Prioritization of product backlogs by understanding the variables like resource, time and ability should be done properly to avoid these kinds of strains. It is better to negotiate with customer either on increasing the sprint duration or team size as it may be feasible, instead of over committing. This will help us avoid customer dissatisfaction as well as increase the team morale. In Agile scenarios even the customer is not always sure about what the market wants and hence the software vendors should not just act as mere vendor catering to the needs of the customers but also work consultatively to help customer get his product rolled to the market in reasonable time and high quality. This will increase customer confidence on the software vendor and therefore better business.


Other MURIs could be understaffed teams and less or almost nil tools and making teams work longer hours due to poor planning. All these MURIs should be avoided by following Good Project Management principles.


This is just a thought on mapping the great Toyota Gurus concepts to software development scenarios. Suggestions welcome here.

Lean Agile

Lean management approach advises:


Waste Elimination.

Speedier flow of information and work, and faster time to market.

Doing only what is required for customer currently.

Reducing life cycle and cost.


Most of the Software development organizations have multiple hand-offs right from Sales to Business Analysts through Requirement, Design, Development, testing and Deployment teams before a product or service is delivered to customer. More the communication channels more the information distortion and longer the time it takes to get the value of the work accomplished. The suggestion here does not mean to skip upstream activities like requirements analysis, architecture and design activities. Rather just to use approaches that are flexible and has the ability to adopt to continuous changes from the stakeholders.


Agile with its test early approach is really the saving grace for software development organizations wanting to become customer centric organizations. Shorter cycle times for deliveries ranging from 1 week to 1 month and delivering workable iterations each cycle has been possible with Test early and Test Driven Development approach. If the test suite is automated for each iteration the testing will become more efficient and will lead to almost defect free working iterations.


Lean management advises on waste elimination, cutting unnecessary steps in software life cycle, reducing the documentation to minimum, making waiting time almost nil for reviews, by using techniques like  automated unit testing and code integration. This way maximum wastes are eliminated. Since the sprints have the choice of postponing certain features to the future iterations, this allows customer to delay his commitment to software vendors by giving him more opportunities to learn from the market about his product evolution. The cost is also under control from both customer and software vendor as they mutually collaborate in product vision on continuous basis by embracing the change.


Effective Software development organizations do not need a silver bullet approach nor do they get carried away by Do it Right First approaches. Successful Project teams should understand that flexibility, changing requirements, learning from retrospectives, stakeholders’ collaboration and shorter life cycles are inevitable factors for effective and efficient software product development. More and more with less and less effort is what both Agile and Lean mutually propound. Lean Agile will be a great approach for software organizations in managing their projects.