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.

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

VOC the WOC

Organizations involve in many upstream engagement activities like great product demo, road shows, white papers, catch lines, attractive ads and trade shows et all. After the contract is signed with prospective customer many small and medium enterprises organization that do not live up to the promises made cannot sustain for long in the business. Reasons are many. Ineffective communication between Presales, marketing teams with delivery teams is the major factor in failing to meet customer expectations. There are other reasons like inability to capture customer undefined expectations, non functional, performance, domain specific and safety requirements et all.

Customers particularly the end customers are interested on how the product / service will satisfy his expected and intended requirements rather than any white papers / case studies. We can take lessons from giants like Toyota and other BIG players like Ford, GM and Chrysler on how they implemented the TPS and continuous improvements in their plants by considering the entire Supply chain elements from vendors to end customers. Their checkpoints, rigorous inspection before delivery, feedback surveys and focus group analysis target the real time user experience and incorporate the feedbacks on continuous basis into the product design and evolution. The feel that the customer has on his experience of using the products of these great companies is converted into quantifiable requirements by Business group. These requirements get transformed into user design and finally product is rolled out. Rigorous inspection and testing takes place to validate multiple parameters of all customers and stakeholders. In spite of working on the upstream activities before production, on few occasions there will be some defects after the products reach end customer. Their extensive networks of after sales service takes care of even the few impacted customers and ensures that these companies really are seen as partners in progress for their customers. Customer remains loyal to companies who serve them with real intent of meeting and exceeding their needs and wants.

The IT industries particularly SMEs (Small and Medium enterprises) can learn from these invaluable customer experience patterns of Manufacturing practices particularly from Auto Industries and should develop a systems that focus on Upstream activities like Solid Architecture and a great design and evolutionary feedback systems that continuously take  inputs from the downstream activities to become better on a constant basis. Customer experience from various segments and domains should be captured and senior management should commit to remove the woes of customer by designing the initial phases of the product development in a thought out manner. If we want VOC (Voice of Customer) to be positive and delight to us we should consider eliminating the WOC (woes of customer) in the upstream activities itself.

Preferable over Pleasurable

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

Pareto Analysis using Pareto charts are one of the powerful 7 QC tools used by all industries to find out the root causes of an issue / problem. 

It is also known as 80-20 rule. It provides the trend called Critical few and trivial many. Let us say if we have totally 24 findings after an internal audit has been performed. We might observe that out of 24 finding around 19 findings are attributed to project management , configuration and metrics areas. Balance 6 are distributed among balance other  areas like risk, training, vendor management, testing etc.

Though it is called 80-20 it need not necessarily be exactly 80%. We mean here that we do not have to have few critical areas contributing to 80 % effect. It can be even around 70%. the focus is to find out which are the few real pain areas that causes for non conformities and findings impacting 80%.  In the following table we find that CMP1,QPM1and PMP1 contribute closer to 80% of the total findings reported after Internal Audit. These are all just cause codes. Like QPM1 can be metric not meeting the objective, CPM1 – configuration audit has not benn done and PMP1 no proper planning and so on.

Once we know these critical factors, we can initiate Corrective action and ensure these do not occur again in future audits. These Critical few causes can further be drilled down to arrive at Pareto trends for each of the process areas so that we can actually reach out for the exact cause or sub cause and eliminate them from the root.

The pareto table and chart to represent the table findings are given below.

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

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

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

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

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

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

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

Cheers

Audit  a cup or coffee?

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

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

If   Y = Success of project

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

Y = F (Budget, Quality, Schedule)

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

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

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

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

Role of External QMS Auditors 

There are number of Auditing agencies and firms that are engaged in performing third party audits on various objectives like certification audit, system readiness audit and Gap Audit etc.

Whatever be the name of the audit process, the objective should always be a value addition to the QMS system being audited. While it is great to have auditing in the lines of standards and clauses, it is equally important on the part of the auditors to have some good grasp of the domain / company’s business that they are going to audit.  The classic question of how do the external audits help the companies to meet their business objective has much to do with audit process and understanding of the company’s business by the auditors. It is never easy to get the domain knowledge of all industrial segments ranging from Manufacturing, Health, Power, Energy, Information technology and education for the auditors. That said Auditors can do some good home work from the time the audit schedule is announced till the audit is actually performed with regard to understanding the nature and type business of the company they are going to audit.

During the Lead Auditor training the basics of auditing lesson teaches auditors to talk the language of the auditee in auditee’s terms and vocabularies. This will not only make the auditees happy about the auditing process it will also induce confidence in the eyes of the companies on the audit’s worthiness.

There are major categories of manufacturing and services companies. Manufacturing is very distinct and the QMS manual, procedures and work instructions will be direct and leading to effective audit. However in case of Information Technology companies the QMS may be less direct and it requires a good interpretation on the part of auditor to understand and report the audit findings in a manner useful to the auditee’s way of working.

Though ISO 9001:2000/2008 has applicability across various sectors including services, the auditors can play a change agent that can make the auditee firms to develop confidence. Once the Audits are taken in the right spirit by the auditee firms then they will start implementing QMS process in line with ISO. This might lead to TQM all the way if Continual improvement prcatices are adhered correctly.

This will create an impression that Auditors can also be a change agent and a partner in progress for the companies and not mere reporters of noncompliances.

Happy Auditing!

• Have the Internal Auditors trained preferably by external training agencies
• Prepare a schedule of Internal Audit not exceeding 5 days Duration
• Circulate the schedule to All the Auditors, Auditees and respective managers
• Have an opening meeting between Auditors and Auditees
• Explain the Audit scope, Criteria and Objective
• Discuss the Audit report template and method of completing the report
• Insist on mentioning the sampled artifact / document / record of the audit
• Start the Audit with a request to brief about the project
• Understand the present phase / state of project and observe a live product sample with full cycle
• Summarize the Audit findings to the auditee
• Prepare Audit report and send it to auditee
• Get into agreement on findings, nature and agreed time frame of resolution of findings
• State the observation ( as observed) , Categorization (Non conformance / Opportunity for Improvement / Good Practice)  and Attribution (to the Standard clause reference like ISO 9001:2000).
• Present objective evidence for any category of finding.
• Send the audit report with good detail that helps the auditee to take effective Correction, Corrective and Preventive actions.
• Verify the Corrective and Preventive action, record the status of the findings as resolved, open etc.
• Help the auditee in the interpretation of clauses and process requirements
• While auditing be positive and share the finding in a proactive manner
• Do not forget to record good practices if any observed
• Do not nitpick on trivial issues
• Be focused on objective and scope of the audit
• Summarize all findings of all projects and functions
• Perform Pareto evaluation on the summary to see if there few critical issues that are responsible for majority of the findings
• Hold Closing meeting between Auditors and Auditees
• Discuss the root causes of non conformities in the closing meeting
• Identify a plan of action for eliminating the root causes and spreading the good practices