Preferable over Pleasurable

Preferable over Pleasurable

It is easy for the start ups and small organizations to choose the delectable (no process) 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

Twenty20 and the Art of Agile Scrum

 

A casual attempt to compare Agile and Cricket. I took Scrum Project Management and T20 for comparison.

 

A T20 championship consisting of many different matches has striking similarities to a Scrum based Agile project with a Product Vision (T20 Chanmpionship).

 

Individual T20 matches can be thought of a Sprint each with 20 overs frequency (doesn’t it sound like a 2 week sprint of an iteration).

 

When all the sprints get executed the actual product vision is realized. In the T20 counterpart it means winning the league, quarter finals, semifinals and finals matches (sprints) to realize the product – the championship CUP.

 

Now we try to look at lower levels of execution within a sprint (T20 match).

 

Presprint activities like defining product backlog(target score), prioritizing them (planning like hitting during filed restrictions, taking singles and doubles during regular filed set up etc) selecting sprint themes (sub score targets with diffrerent batting orders like top order, middle order etc) have matches in their counterpart of T20 in preteam meeting, prioritizing the batting / bowling order as the case may be, fixing the target to beat the opposition etc.

 

If you take up a batting team it will have story points for each over like go for fours and sixes in new bowler / restricted filed set ups, free hits (each sprint day equivalent of T20) scheming, designing the strokes w.r.t bowler variations (like spin, pace etc). Shot selections could be the low level design and going after the bowlers when filed restrictions are on could be like quickly rolling out low complexity module. The best one is Asking rate vs. Strike rate – there cannot be any better equivalent to Burn Down chart of Sprint than a asking rate (ideal burn down) and required rate (actual burndown) . Cricket’s Asking rate curve is more accurate to be precise. Because it doesn’t change unless there is a truncated match beacuse rains / any other exception.

 

The stand-up meetings of Sprint can be thought of mid pitch meeting between striker and non striker to analyze what did they do last ball/over, what they should in the coming balls/overs, and what were the hurdles that they had faced from bowling team and how to counter them.

 

The losing team can push the victories to next T20 match (postponing the stories to next sprints). The spectators are one of the stake holders and probably users in the sense that they take pride in their country getting the championship – this is the service that was provided by the cricketers to fellow country men / customers.

 

The user feedback in terms of reviews in cricketing columns by subject matter experts (ex-cricketers ) help them to adapt cricketers’ future game plan. strategy and tune them in the future games (sprints). A tip here while selecting the suggestion points please avoid taking reviews of non prfessionals like models, comperes, as it may prove to be counter productive. Post match sessions with coach, manager, captain and the team are nothing but reviews and retrospectives.

 

The winning team through its quarter, semis and finals realize their dream product that is the Championship.

 

Welcome views on this 

 

 Krsna

An AGILE ISO

An AGILE ISO

ISO 9001:2000 addresses almost any possible situations as for Quality improvement goes. Though there is some thought in the IT industry that ISO relates less than its counterpart CMMI in terms of model adaptation for IT Quality Management System.

I would not think so.

 

Four significant recommendations of ISO 9001:2000 are:

• Measurement of Customer Satisfaction
• Continual Improvement
• Independent Internal Audits
• Corrective and Preventive Action

If we try to interpret the values of above recommendations for IT industries, it will do lot of good for benefits of the Customers and the ISO organization.

 

Customer Satisfaction Measurement –  As per ISO, it can be done using surveys, regular interactions at project, delivery and engagement levels. The methods of collection of data and analysis are left to the specific type of organizations and their specific customers. This is the beauty of ISO it stops with requirement definition and leaves the implementation to the owners of the processes. In these days of Agile development with flexible frame works ISO suits the best in terms of customization of clauses w.r.t each process area. In Agile since the focus is on collaborative approach, the sprint backlog items are tracked almost on daily basis and as a product owner customer knows the updated status of the project at any given point in time. Hence Burndown chart, Sprint tracking, White boarding all are means of customer satisfaction measurement. This is direct and best way to address the requirement of ISO’s Customer measurement clause. Sprints that are delivered are workable iterations and the feedback given on those deliveries will be direct from user’s perspective. This is a great proof that ISO and AGILE are indeed partners in Quality improvements.

 

 Continual Improvement – as compared to Breakthrough Improvement can be considered as gradual incremental improvements achieved by any system. This being the case in AGILE implementations Sprint deliveries, burning of stories, backlog updates and velocity measurements are best evidences for continual improvements involving all the stakeholders as required by ISO. Again great partnership of ISO and AGILE

 

Internal Audits though not directly relevant in AGILE parlance, we can think of Continuous integration testing and unit testing, and peer reviews as system checks to ensure quality deliveries

 

Corrective Preventive Action – this is taken care by the self adjusting nature of AGILE. Daily stand up meetings and removal of hurdles by the Sprint owner, using tools to review the code and testing continuously take care of correcting defects. When each sprint gets executed, after four cycles or so, one will have good learning from the review and retrospective phases of earlier sprints. If this hindsight is used prudently the team will prevent lots of errors / bugs by avoiding them.

 

 

Please feel free to offer comments

Agile ISO – Lean and Effective QMS

Since QA is the lynchpin of an organization, they need to be armed with detailed understanding of how project actually gets executed considering customer specifications, resource competency level, schedule and budget constraints in addition to being expert in QA models and QMS standards. We will try to figure out mapping one model viz., Agile to QA processes and together with ISO standard.

 

Entire QMS needs to be devised keeping in mind to build a foundation for repeatable and continual improvement in the organization. Hence while designing the processes QA need to work in collaboration with actual users of the processes.  After collecting the important activities done by each process owners in their process areas QA should sequence them and arrive at approximate SIPOC (Supplier-Input-Process-Output-Customer) framework. The model chosen be it Agile or Structured should then be compared with the designed SIPOC frame work. Finally these can be again mapped to the standard models like ISO or CMMI to further enhance the compliance. Here is an attempt to map the QA process with Agile and ISO clauses as mentioned below.

 

The matrix below tries to analyze how Agile model complies with most of the ISO clauses and hence leaves little work on compliance issues for the already pressurized project people. I would like to add here that certain areas (part or full) like clause 4, 5 and 6 and may be parts of other clauses are not mapped here. This matrix just signifies that to a significant extent few artifacts of Agile comply with ISO’s many requirements.

 

Any thoughts welcome.

 

Process Areas Mapped to Agile Model and ISO

 

Process Area              Agile activity                  ISO clause

 

Process Definition, Development	Selection of appropriate Project Management and engineering procedures for Agile model	4.1, 4.2.1, 5.4.2, 7.1.
Reviews	Collaborative Hub dashboards	5.6.1, 5.6.2, 5.6.3, 8.2.3, 8.2.4
Measurement & Analysis of data	Sprint Backlog Tracking	8.1, 8.2.1, 8.2.2, 8.2.3, 8.2.4, 8.4
Continual Improvement	Retrospective and reviews learning and using them in subsequent sprints	8.5.1, 8.5.2, 8.5.3, 7.5.2
Planning and Management of Project	Planning, Assigning tasks, Tracking through Burn down charts and collaborative hubs	7.1, 7.2.1, 7.2.2, 7.2.3, 7.3.1, 8.2.3, 8.2.4, 7.3.1
Configuration Management	Sprint backlog is the updated product spec at any time and is always current – no separate configuration  management is required for work products	7.3.7, 7.5.3, 7.6
Risk Plan and Management	Best addresses by product and sprint backlogs collaboratively with stakeholders. Statuses of backlogs updated reflecting the risks.	7.1, 7.3.1, 7.3.4
Requirements Management	Pre sprint activity	7.2.1, 7.2.2, 7.2.3
Design activities	Pre sprint activity	7.3.1, 7.3.2, 7.3.3
Coding and Development	Sprint tasks burning (development)	7.3.1, 7.3.2, 7.3.3, 7.3.4, 7.3.5, 7.3.6,7.5.1
Testing activities	Unit and Continuous integration testing	7.3.5, 7.3.6, 8.3,8.2.4,8.2.3
Release Management	Sprint Themes deliveries	7.1, 7.5.1, 7.5.5,8.2.3
Implementation	Sprint Themes deliveries	7.1, 7.5.1, 7.5.5
Technical Review	Peer reviews and Test driven development	7.3.4, 7.3.5, 7.3.6, 8.3,8.2.4
Maintenance	Pushing / debugging of sprint issues within or in next sprints	7.2.1, 7.2.2, 7.2.3, 7.5.1,  8.2.1
Customer related processes	Collaboratively addressing the issues and resolution	7.2.1, 7.2.2, 7.2.3, 7.5.1, 5.2, 8.2.1

Scrum a perfect fit for Kano model

Scrum model of Agile Project Management best addresses the excellent Kano model of Customer Satisfaction.

 

Types of Customer perception given by Kano model will be discussed here. There are features that will create varied perceptions on customers mind. Kano model serves as great guidance in understanding and figuring out how to delight the customer. Let us analyze the Kano model below and try to understand how Agile Scrum project management best aligns with the Kano model naturally.

 

Kano talks about following categories of customer requirements:

• Attractive        - when present make customers delighted
• Performance  - when fulfilled more the better
• Must-Be         - Basic requirements – absence of these make customers unhappy

Scrum management being collaborative model with continuous customer involvements, no wonder Scrum management embraces Kano model of customer satisfaction. The best part is conversion of lower levels of satisfaction(or dissatisfaction) types (reverse, indifferent types) will be progressed into higher levels of customer delight by delivering attractive requirements to customer.

 

 

 

Must-be characteristics. (If not fulfilled lead to extreme dissatisfaction) Very easy to guess. Some estimation technique use – MSCW technique, M stand stands for Must-be features. These must be features that appear right at the top on product backlog.  Not only do they burn first but there is a significant focus on executing these stories with very good quality. These requirements are priority for current sprint theme, hence the scrum team should be more focused on these and should not miss any of these requirements. In MSCW, S corresponds to “Should be”, C to “Could be” and W to “wont be” features respectively. If these basic requirements are not fulfilled customer becomes dissatisfied. If they are met there is no satisfaction, the absence of these create dissatisfaction. Therefore these are very critical features any Scrum team as the entire business depends on these characteristics.

 

Performance characteristics. These factors relate to performance of the product or service. These requirements when fulfilled, increase customer satisfaction. If requirements are not met and features don’t perform as per the expectations of customers, customers get dissatisfied. In scrum prioritization of features, burning down stories on time with less defects,  and good burning down velocities correspond to performance requirements.

 

Attractive (implied requirement) characteristics– these are features / qualities that customers don’t expect and are delighted on the their presence. On Agile Scrum we can consider activities  like delivering best possible product / service quality. Some examples could be Better sprint velocities, delivering less products defects than expected, reduction in deployment issues, reduced field complaints of the released iterations / module. Matured Scrum team just achieves this after few initial sprints. Since they will learn lessons from the reviews and retrospective stages of scrum.

 

We can also consider other characteristics like :

 

Indifferent – Well some of the documentation of reviews, unit testing records and release notes etc may not be required by customer and customer do not seem to focus on these artifacts. They are more interested in getting the sprint iterations into the market quicker. However the Project team can use these artifacts  for their own purpose in improving the productivity and predictability of their future sprints.

 

Reverse – Customer wants exactly the opposite. Could not be more relevant than the errors / defects that get introduced in the first few sprints especially when the project team is new to Scrum.

 

When all the sprints are executed and the product is realized as per the vision of the product owner and scrum master the “reverse” category is supposed to become nil and there should be more attractive features that got introduced on the way.

 

The beauty of the KANO is that even this can be used as internal customer satisfaction model by the QA team towards its internal customer viz., projects, management and other functions.

Six Sigma in Software Development

In principle Six Sigma applies to all industries when looking at reducing variations and achieving Critical to Quality Objectives.

Many Six Sigma professionals agree with one point that Cost savings / Return on investment is definitely a major element when drawing the project charter.

In IT industries since the requirements are continuously changing and Agile methods are applied for development, it might be difficult to follow a rigorous DMAIC approach. However just with basic Seven QC tools and problem solving methods we can reduce the variations in the selected process be it on time delivery or lesser defects levels in the end product DMAIC will take the performance levels higher for the processes involved.

If we look at the defects, we need to quality them by defining defects as customer would look them. If we are able to keep customers happy by meeting basic requirements and building exciting requirements into the product we will achieve six sigma objectives. The delighted customer will increase business with his vendor and that leads to improved revenues. The customer may also refer to other companies about his vendor. If Service industries have these kind of long term perspective then six sigma can prove as beneficial as it is for manufacturing companies.

However if one looks at defect perspective of six sigma (3.4 DPMO) it is very difficult to achieve this Critical To Quality attribute in IT industries. When a software application / product is tested, and is ready to ship to the customer, the software vendor sometimes might feel it is better to leave few minor defects into the system. Because beyond a stage leaving a defect is less costly than testing it. In this case Cost is considered as CTQ and not the defect.

IT organizations can greatly benefit Six Sigma as a tool to improve their sigma levels of the processes and reduce variation rather than worrying about 3.4 DPMO.

Any thoughts are welcome.

Krshna

Six Sigma in Software organizations – benefits

When organizations want to reduce cost and improve productivity Six Sigma initiatives are mainly considered by organizations that have firm belief in Quality.

 

However a careful analysis should be made to ensure that the benefits obtained are much higher than the actual investment. Incorrect project candidates without proper tools and skilled resources will result in loss of expected returns on investment.

 

In manufacturing companies where the dimensions of a product are very clear and not varying too much within given time period will have easier choice compared to Software organizations in identifying Six Sigma projects. Software organizations on the other hand have change as the only constant in terms of requirement, resources and budgets cannot afford to make wrong selection of projects. There is still hope. That is, Six Sigma has the flexibility to be used as an operational strategy to reduce the number of defects or as a business strategy to improve business processes and evolve new business models. Agile and Test Driven Development are few examples that maximizes the profit since Agile focuses on reduced to Time to Market through its frequent deliveries. Many proponents of Six Sigma stress that the power of Six Sigma lies in the fact that it can be used as a business strategy to improve market share and profitability. Agile stresses the usage of automated tools for testing and code integration. Proper investment and good training in Agile and adoption of this collaborative model is a good business decision. Six Sigma tools  like Analytic Hierarchy Process, Pugh Matrix etc to be used in selecting tools on Software development. This makes it clear that instead of looking at Six Sigma as only a statistical technique to improve the sigma level towards Six, organizations can use parts of Six sigma approaches suitable to them.

 

In large developmental projects productivity, defect rates and acceptance criteria can be considered as Critical To Quality (CTQ) factors. If the development team has a strong customer focus, uses data analysis tools like DMAIC, DFSS, controls project management the Six Sigma project will have very high customer satisfaction. Here the return on investment will be a combination of customer delight, reduced defects, on time delivery and increased business from existing customer. This is the one of the practical ways of looking at ROI of a Six Sigma project from a software organization’s perception.

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.

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.

MURA

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.

MURI.

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.

Remaining stories Vs Remaining Hours

Some of backlog management tools use remaining hours as the measure to calculate the backlog items pending for the sprints.

While it is easy for any resource / team to think in terms of remaining hours rather than quantum of work pending, we will try and analyze few points here.

If the development team / Scrum master needs to update the Product owner / customer about the status of particular iteration scrum master has to update how many stories have been burnt and how many are pending. As Scrum requires a workable release / iteration during completion of every sprint, it will not make much use to express the on going status of sprint in terms of how many hours pending to the Product owner.

For example if the Sprint frequency is 10 working days (2 weeks), 10 resources are involved the budgeted effort for the team is 10 * 10 * 8 = 800 hours. Let us say after the end of the day 6, the team would have consumed 10 * 6 * 8 = 480 hours, the balance hours remaining will be 320 hours. But does this give an indication of how many features / stories are required to be burnt still. Not directly at least. It is always better to express the completed as well as pending efforts in terms of stories.

Also 800 hours of effort need not equal 800 hours “worth” of work. 800 hours may just have produced 600 hours of worth work done. In other words earned value is what is important and not the plain hours. This is the reason velocity is expressed in terms of number of stories brunt / sprint / team and not in hours utilized.

Overall this stories based thinking helps team to deliver only value added product / services leading to effective Lean ways of production. During retrospective meetings the teams should preferably consider what are the wastes (MUDA)in the system and finding out the ways to eliminate them in future sprints. This will ensure stories based thinking and improve the value stream mapping of the product / service.

Agile rules

Let us see some of the merits of Agile:

Embracing change

Agile does not just manage the changes. Changes are way of development in Agile. Downstream activities like releasing product to the product owner and further rolling it to the end user means the product is used immediately without much wait time. The product owner gets the feedback from the end user and onward transmits the same to software development vendor. The software team suitably incorporates the feedback into the next releases / sprints. This ensures all the stake holders in the supply chain are benefited. Software vendors realize money quickly, so do the product owner and user. The user has a chance to participate in development of future product and has an opportunity to receive what he wants in future.

The software development vendor can learn from feedbacks, retrospectives and other inputs and make his team evolving better and better with quality coding, design and release of products.

Embracing changes means WIN-WIN situation all the in the supply chain.

Frequent delivery

Frequent delivery of software products / iterations enable continuous learning for development team and quicker time to market for product owner . The user starts using the product quickly and participates in the development of the product as per his needs.

Fixed time boxed releases and variable scope

Focus on workable product without compromising quality. Scope can be varied to a little extent that allows evolution of product through stake holders’ collaboration. This is just opposite of waterfall development where scope remains fairly constant and many change requests are raised during different stages of software development and delays the deployment of the final product. This does not just stop with this delay. Customer may get last minute surprises in the form of critical defects that have originated during requirements / design phases. This will lead to enormous cost of rework. Agile tenet of fixed delivery and variable scope guards effectively against these.

Prioritization features by product owner

Customer decides what he wants and frequently updates his decision to Software team. This avoids multiple hands off like approval time, waiting time for customer review and rebaselining of artifacts, etc. Saves time which means cost reduction

Customer Collaboration

Confidence to development team. The risk is limited (if at all present) to few days of work only. Indirectly empowers the development team to increase expertise in not only relating to software development but also in product domains.

Test Driven Development

This gives opportunity for defect prevention. Hence the notion of certain people that in AGILE the product quality is compromised owing to less reviews / walkthroughs gets defeated by adapting TDD. TDD provides opportunities for testing team to improve the quality of the product by suggesting test cases before development, and for development team it reduces rework related to bug fixes, reviews etc. This also improves development team ability to write Quality codes.

Peer Review

Two people see the code through four eyes. Cost of effort in terms of time is reduced. Waiting time for review and approval can be saved.

Defect prevention

All tenets of Agile help preventing defects. Defects here we can mean any thing that leads to customer dissatisfaction and not just product defects. Customer gets transparent about the status of the product development, software teams ensures they meet the schedule, product less defects and manage cost and work efficiently. Usage of code integration and automated tools are helpful in defect prevention too.

Automated unit testing

Saves lots of time for developer. Also the test coverage and efficiency will be more in case of automated testing. This is for any kind of testing.

Code Integration

Avoid manual integration and ensures more accurate code integration

Carry forwarding incomplete features to future sprints

Flexible development and evolving product

Ability to add delete and modify

Customer can modify the features delete and add features any time he/she wants.

Changes and Bug-fixes cost less

If the development team works on say sprints 1, 2 the customer can change features required for sprints 4.5 and 6 for free of cost. This is major advantage over waterfall development.

Risk containment

Agile adapts “better fail early” approach (if at all failure is unavoidable). Since high risk and priority features are planned for first iterations risk is mitigated early in the product development cycle.

Release at any time and in working condition

If customer wants to stop developing the product any further for any reasons he can ask the development team to stop the development and get the product in working condition till last day of development. Agile provides this kind of comprehensive ability for the product development.

Audit a cup or coffee?

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.

Apply Parkinson’s Law, Remove MUDA

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

MUDA1 – Overproduction

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.

Leader by Nature or Nurture

A legend goes in Indian history. Great King Janaka in his dream perceived himself as a beggar. After waking up he started questioning his very identity whether he was a king dreaming himself as a beggar or a beggar dreaming himself to be a king. Which state was his true state?

He decided to clear his identity confusion with his Guru and great sage Ashtavakra. Guru whispered into the ear of Janaka, neither this nor that is real. Neither meaning he was neither a king (The LEADER) nor a beggar (the led). But the Atman – The God Principle. Simply it means the self realization is the state of every aspiring human. In the contemporary world we should consider everyone as a leader. Only few manifest themselves by removing their ignorance (a feeling that they are not leaders) as leaders and others still clouded by their “subordinates” feeling remain to be led by others.

I was greatly inspired by this story that has sort of cleared confusion over my mind with regard to leadership, Quality and all positives attributes of Business. The debate as to whether leaders are born or made has almost become a non-issue. Leader is one who realizes the leadership ability in oneself. People who realize their potential (and remove the feeling that they lack leadership) become leaders, those who are clouded themselves with numbers and statistics (on the qualifications, social and educational backgrounds) as to who makes the leader, will not make leaders on their own or take a very long time to become leaders.

No statistics can be a pointer in determining whether Leaders have school background, university backgrounds, business education or wealth. Though education is a great aid in becoming a leader. What sort of education are we talking about? Is it about degree certificates / internships / on the job training in curriculum / Web based training? / class room / Web 2.0 kind of training? Yes all these can again be aiding the leader in grooming himself / herself. Great Leaders get motivation from common people and in turn motivate others. Great leaders did not require other people to make them, they realize at one point of time they have their inner abilities and go about working on it and finally realize thier leadership ability

A leader is one who identifies his potential and produces his best in the interest of the society. All mothers are leaders for they are selfless. All social workers, community workers, soldiers and serving people are leaders indeed.

A leader is neither born nor made but identified himself / herself and performs to the fullest potential of oneself.

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.

Seek and analyze data

Nallthorum Nadi Muraiseyya  Mannavan

Nallthorum Nadu Kedum.

 King who daily seeks to Analyze not, will lead his nation gradually perish

 A Leader who does not seek and analyze data will come to see his nation / corporation leading to attrition.

 In Agile analogy the product owner who is not collaboratively involved with his scrum master and the team on the status of backlogs daily,  will have difficulty in reaching his goal or will have to compromise on his project / iteration success.