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.

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.

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.

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

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

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

Unstated and not needed items in manufacturing parlance. Manufacturing Goods or products that are not required currently are never would be.

When applied to software parlance unnecessary features that are gold plated and never were part of customer requirement. Also some of the features that are not required currently and developed by the project team to be kept as library as artifacts and never used ever.

Examples

Heavy code base (as against lean code base)

Too much documents and work products

Trying to reach maximum normalization of the database systems creating performance issues

Many buffer resources present in the team contributing to non-required features and creating more dependencies for the core system.

Looking at the many of the commercial desktop software products most of the users hardly makes use of 50% of full features. It applies to even mobile phones. Not every user makes use of all the features of a mobile phone.

Over production some times complicates the maintenance because the extra features may create dependency with main required features making the whole product difficult to maintain and leading to under productivity issues.

Work expands to fill the time available for its completion – Parkinson’s Law.

Parkinson’s Law stated as early as 1950’s had a great flavor of Removing MUDA. The demand for completing a work by a resource will try to occupy total time available (supply) for the resource making the work inefficient. It means if 100 hours are planned for a task for a resource, the resource will ensure to utilize all the 100 hours of time for completing the work, even though it would have been possible to complete the work much before 100 hours. This is also called student’s syndrome. Student’s syndrome means postponing the exam preparation till near the exams.

Many of the non Agile projects in IT industries and non Lean projects in manufacturing industries are best examples of these.

Even in pure service Industries like Banking, Insurance, Public sector services have been introducing many forms of wastes particularly related to time. In fact banks take more time than the available time also for performing services. Many banks display their SLA objectives for issue of demand drafts, disbursement of  cash, opening and closing accounts with targets as part of a probably ISO 9001: 2000 requirements. Not only they take all the SLA time for delivery of respective services but also exceed the targets most of the times.

These examples automatically goes to prove that why Parkinson’s observation was called a LAW and not a theory. Proper elimination MUDA by managing the loads of processes as per peak, non peak times will help to complete works and services better by the service industries.

In software development most of the resources never complete projects on time, leave alone taking all the time available to complete their task (as per Parkinson’s Law). They overrun the schedule. Best way to understand Parkinson’s Law and not fall prey to student’s syndrome of pushing the tasks to the end of the schedule is to adopt Agile methodology. It focuses on tasks as story point functionalities rather than code pieces. Great tools for Project Management, Development and reviews will help them to automate repeat processes and reduce MUDA. The evidences for work accomplishment can be in the form of snap shots of white boards, simple work flow diagrams etc. No need to have baselined artifacts and change requests that unnecessarily brings lots of overheads. Since customer is also continuously monitoring the development activities most of the work products can be eliminated and real Working product in the form of iteration and releases can be achieved.

Let’s understand Parkinson’s Law and eliminate MUDA.  

Cheers

Audit  a cup or coffee?

Fundamental drivers of a project success like Budget, Schedule and Quality should be kept in mind during auditing a project.

While Budget is not a direct audit element, Schedule and Quality are.  

If   Y = Success of project

X = combination of   ‘x’s like Budget, Quality and Schedule

Y = F (Budget, Quality, Schedule)

While it is important that Process should take care of leading the project without depending upon individuals it should not be designed in such a manner that holds productivity. Like overly focusing on structure of documents like font sizes, styles, formatting menus and other trivial areas. It is great to have documents in consistent and uniform manner and still greater to have products rolled out to customers / end customers on schedule with right quality and budget. A working product is more important than a work product.

This is becoming increasingly significant in project success related to Agile and Lean Development. In typical Scrum based Agile projects artifacts can include just snapshots of white board messages and post it notes. Here the central principle is people orientation rather than document based. There should be solid pre scrum work products like Concept document, Design and Architecture documents that are correctly done. If these foundations are strong then the project execution need not worry about producing too many records and artifacts. Since all stakeholders are involved on daily basis in monitoring product backlog project teams can do away with unnecessary excessive documentation. Stakeholders participate in product evolution continuously leading to quicker working products that fetches early ROIs for all stakeholders.

Process should be designed on the basis of customer satisfaction and end user satisfaction rather than documentation.

Auditors can concentrate on the Products (coffee) rather than work products (cup).  Otherwise Audits on Lean and Agile projects will impede the innovation and creation of new products and concepts.