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 !

 

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.

 

 

 

Kano Model - Scrum

 

 

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.

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

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.

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

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

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

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.

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

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

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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