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

Leadership

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

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 conveyance	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 Movement	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

Be AGILE

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.
Remarks,
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)

VOC the WOC

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.

Preferable over Pleasurable

Preferable over Pleasurable

It is easy for the start ups and small organizations to choose the delectable (no process) over the electable (disciplined process).

These delectable ways like skipping the upstream activities of development like Architecture, good design, non commitment to testing-early and committing downstream mistakes like avoiding unit testing, not doing enough test coverage, poor regression testing all these leads to failure of project deliveries. New start-ups and small organizations that do not have long term vision and trying to skip these best practices may pick up few wins initially from small customers but suffer in the long run.

The big problem that they will eventually face is Scalability and not able to even sustain the present growth either owing to the so called “path of least resistance” ways chosen and cultivated them deep into DNA’s of their organizations. Having been used to delectable ways of cow boy coding, ‘code and test as you like’ methods suddenly the organizations realize that they could no longer hold to present level of  raw processes.

Then the organizations will start to use some kind of “silver bullet” that would never work. They seek the help of external consultants and fix the process problems temporarily. Finally maintaining the ‘made up’ process becomes more painful than ‘no process’ state. This is the point delectable organizations will feel maximum disappointment. From no process to “forced quick fix processes” . Then they engage into activities like training, mentoring and motivating the staff and the self (Management themselves). All these come with huge cost and time expense.

Have a fairly long vision and deep insight in this competitive world of web 2.0, elect best practices and desist from delectable short cuts.

Choose the Preferable (Best Practice Process) over the pleasurable (skipping process).

MUDA 7 – Defects

Defects. Production of defective parts or firefighting to correct the defects. Rework, scrap, replacement, and inspection mean wasteful handling, time, and effort.

Defects in software development costs heavily to the vendors and customers alike.  Detecting the defects early by using Agile approaches likes TDD, Pair programming, Extreme programming, having defect prevention plan in place are critical for producing high quality software. Finding and fixing a software problem after delivery is often many times more expensive than finding and fixing it during the requirements and design phase.

Agile helps to minimize the defect age of software by typically reducing the presence of defects age by (maximum) a day or two. As customer and all stakeholders are continuously collaborated in making decisions Agile suits best for faster and better quality software development.

Better to prevent defects by identifying causes and systematically eliminating is the key to sustainable software development. Having solid reviews also benefits the projects in defect reduction. Using automated test suits and code integration tools are best solutions in preventing defects.

Peer reviews catch 60 % of the defects. Objective based reviews catch 35% more defects than non-directed reviews. Toyota puts it beautifully about removal of MUDAs as WAR on WASTE.

MUDA 6 – Motion

Motion (Unnecessary movement). Spending extra time and wasted motion of employees during the course of their work to find relevant information about the tasks and projects, such as looking for, reaching for, or stacking parts, tools, etc.

In software development projects spread-out-teams in different locations within the organization should be avoided. If Dev, Testing and support teams are available in same location, easy to schedule stand-of meetings and less movements that leads to increased productivity.

Wastage of time and energy to find information is called Motion in seven types of MUDA. Teams not maintaining proper libraries for components, tables and process assets. This means every project has to reinvent the wheel all the times to start from fresh for building all components. Best way to address this to have intranets that has collaborative platforms marinating various technical and process assets of the company. Holding regular knowledge sharing sessions, lessons learnt meeting will help to minimize the Motion Muda.

MUDA 5 – Over processing

Over processing. Taking more steps than necessary to accomplish tasks. Using poor Quality Tools, incompatible software and hardware result in poor product design, producing defective product outcomes.

In software development Over processing normally results in requirements gold plating, design gold plating, etc. This means taking extra steps and sequences when the task /activity in hand can be completed with minimal steps.

Too much documentation, trying to cater more than what is required for the application / product. Developers not adhering with best code practices by avoiding comments in the code. This introduces lots of person dependency leading to costly maintenance for the code. Improper planning by project heads and inefficient task assignments in random manner all contribute to poor code quality. This loads the reviewers’ and testers’ time and again result in reworking the code for the developer. Good project management practices as per PMO could address these issues

MUDA-4 Excess inventory

MUDA-4 Excess inventory

Excessive storage of raw material, assembly line work products, finished goods waiting for shipments and the associated storage costs for all these situations form the MUDA 4 – Excess inventory. It can include defects and downtime issues also.

Excess Inventory in Software development

Code is waiting for review and testing for long – typical waterfall model habits

Product / Application – Waiting for cross platforms, multi OS testing because the testing and user environments are not yet ready.

Depending upon third parties or vendors supply for getting tools.

Too many resources on buffer waiting for the tasks to arrive

MUDA 3 – Unnecessary Transport or conveyance

 

MUDA – 3  Transportation

Moving parts, components and other materials between location to location often with less planning leading to wastage of time and effort on the part of the workers and the task being done.

In software development  sending artifacts between different people and getting this reviewed, approved and commented and implementing the feedbacks are considered Transportation waste. Again Peer review, pair programming and Test Driven Development approaches of Agile help to a larger extent in avoiding to and fro movements of the work products between different resources at different levels within the project.

Since the Product and Sprint Backlogs represent the exact status of the Sprint / iteration in Agile projects it greatly reduces transportation of various artifacts between stakeholders.

Right from Project Planning, prioritization, tracking, review and retrospective everything happens within the sprint development with focused and self empowered scrum team, Transportation wastes are almost fully eliminated in Agile development methodologies

MUDA 2 – Waiting

 

Waiting  :

Agile is based on Lean Principles and best addresses this MUDA – Waiting .

In manufacturing environment a worker waiting to get other parts ready before he can go ahead with his component machining. Waiting for tools, material supply or simply waiting for any resources before the worker could start or continue working on his present task.

In software development following could be MUDA – waiting time

1. Unnecessary Hand-offs , waiting for approval for artifacts like Design Document, Requirements document, Code base for review etc.

2. Excessive change request approvals (developed habits from waterfall models)

3. Server set up time, tools installation

4. Uninformed absence of team member waiting for a replacement resource et all.

Agile best addresses this by recommending customer collaboration, shared source code, daily reviews through white boards and backlogs status reviews, empowered team working on self managed basis etc.

While I do not know of exact  data on how much idle time (non productive time) is spent in waiting time in software projects. In manufacturing industries they have been able to identify and eliminate significant percentage of this type of waste leading to very high levels of productivity and improved product Quality

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  Participants
Departments and functions	Course proceedings and effectiveness	Evaluation of training effectiveness	Feedback on training	All departments, functions and training function

Knowledge and Endurance

Knowledge and Endurance

For the emerging product companies, a great lesson from Quality Guru, Dr Deming – Cease dependence on mass inspection. Loosely translated, don’t let many defects get to the testing phases.  There should be solid mechanisms like good requirements management combined with short term and long term product objectives and vision. In Agile development, requirement management is based on adaptability and collaboration, it also has embedded the notion of fail early indicating that it is okay to have few defects in the initial stages of sprints that can be managed to almost nil defects during the final sprints.

Endurance means conviction for the long term vision. 

Is the process – Part time pass time or Full time Agile?

Is the process – Part time pass time or Full time Agile?

for Small and Medium enterprises that are consolidating their models of project executions, Lean principles and Agile methodologies are best suited. Quicker  time to market , faster feedbacks and collaborative approaches do the trick in minimising initial risks and saving good dollars for all stake holders involved. While in Bigger enterprises it might take lots of time to migrate to Lean approaches from non Lean methods, best way to get started will be to try in pockets and slowly and gradually adapt towards global approaches.

Big or small in either cases the mission is to eliminate Muda and create Values. For this to happen, process should not be a pass time part time, rather it should be full time Agile. Value creation at all levels should be continuous focus with right deployment of tools. The Lean approaches like 5S, MUDA elimination, Gemba, Kaizen, Kanban should not be used as just another Management flavour of the month or quarter. This is what I mean by pass time part time approach. Rather the  the management should be take couple of lean tools Kaizen,5S for example and achieve continuous improvements towards longer periods. This way the organizations will get long term benefits like perpetual value creation from Management, employees and all associated stake holders.

In long term approach may be Q on Q results may not show up immediately, however Lean can not go wrong if applied with full fervour and spirit in the long run. It is best to follow the Quality Guru Dr Deming’s principle of creating a constancy of purpose towards long term improvement.  Replace part time process be full time Agile.

Process – a night time Moon

Process should not be like a day light moon. It Should be like Sun and like night time moon.

If the process is built around compliance focus only, it will loose the confidence of the practitioners.  There will be instances that people will complete the artefacts just for the sake of evidences rather than as learning tools.

Best way is to LEAN forward. Use tools and visuals just as necessary and nothing more to create value and remove MUDA. Let the dashboards are created along the process steps. The burn down chart in Agile development uses great visual chart (Burn Down Chart) that helps the team to correct their gaps in achieving their goals and objectives along the way instead of waiting till the development is over and fire fight.

During day light some times, moon does show up but there’s no use of that moon light. In the dark nights though Moon light, is very beneficial and a treat to watch. Process should help the organisations during darker periods of problem and conflicts rather than just display the charts(light) during good times (light).  Process should help the organisations like night time Moon and Sun.

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