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

Nallthorum Nadi Muraiseyya  Mannavan

Nallthorum Nadu Kedum.

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

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

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

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.

Principle 1: Customer focus

Principle 2: Leadership

Principle 3: Involvement of people

Principle 4: Process approach

Principle 5: System approach to management

Principle 6: Continual improvement

Principle 7: Factual approach to decision making

Principle 8: Mutually beneficial supplier relationships

Customer Focus:

Lean focuses on bringing out the best Value of a product to customers. In Agile projects Lean aspects are taken care through Customers collaboration with vendors on consistent basis to ensure that the product under development meets near perfect expectations of all stake holders.  Here the prioritization of product and sprint backlogs continuously ensure that the market demands are considered and high quality products with best Value are delivered.

Leadership

Shared leadership is fundamental in planning and executing Agile Scrum projects. In fact the Scrum leader leads from the front by being hands on into the product development apart from leading the team by removing hurdles encountered by resources and stake holders. Lean allows kind of flexibility to all resources to suggest the improvements in technical and process steps.

Involvement of People

Full stakeholder collaboration including developers in scrum iterations, giving suggestions to teams during stand-up meetings and working with customers to redefine backlogs are some of the direct cases of Involvement of people. The resources take complete control of product development. It means that the resources are mature enough to understand the domains, technology and end user requirements.

Process approach

Though the term process approach in Lean / Agile scenario looks slightly out of place, if we see process approach is equally or more relevant in Lean projects. Process here is looked as method of effectively planning and executing tasks. Like Pull Systems, removing MUDA,MURA and MURIs , establishing SIPOCs are some of the great examples of process approach in Lean.

System approach to management

Here the synergy of interacting elements is the focus. System here can be thought of product development system consisting of customer, vendor and all stakeholders along with associated paraphernalia like technology, tool and specifications. Continuous review and collaboration are the best examples of this Quality Principle.

Continual improvement

Learning from the previous deliveries of iterations of scrum, incorporating the customer / stakeholder feedback and striving for elimination of NVAs(non value added wastes) from the processes demonstrate continual improvement in Lean technique. Best Value product of highest Quality is built and delivered to users.

Factual approach to decision making

Decisions are taken through real data obtained through direct stakeholder like customer and end users. Burn down charts display the status of the product development during any point of time. Burn down chart provides real time data that drives the product development ensuring only facts determine the decisions related to product development.

Mutually beneficial supplier relationships

Supply chain efficiency is at its best in Agile / Lean development since customers, vendors and all stake holders are in continuous contact with each other monitoring the product development. Vendors learn the product requirements quickly and get the grip of domain early. Users and customers start getting their value of money during initial stages of product development itself.

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.

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.

Lean follow 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 / R

Usable Product = Value Added Inputs / Wastes

Any usable software or hard ware =

(Clear Requirements, inputs, understanding)

—————————————————————————————

Waiting time for approval, Review, rework, Bugs and defects injected

Lesser the resistance more the current. Current follows the path of least resistance. This classical law has amazing similarity when applied to PULL system of Lean Production. The Pull system ensures that the value stream of any product life cycle flows in a path of stream. When the upstream activities of this product life cycle are facing resistance in the form of impediments like wait time for approval, review and multiple hand-offs it tends the lower the Value (current) of the Usable product.

We can adapt the Ohm’s law in Lean Scenario as Value(defect free product release) of the product is directly proportional to the Value added Inputs (like coding, release) and inversely proportional to the resistance (like waiting time for approval, review and rework, bug fixing etc).

To achieve the maximum current that is the Value proposition for the customer, the important task of Project head is to remove the resistance, the wastes in the words of Lean. The process should also ensure that direct value added inputs are taken for converting them into valuable outputs

If we consider requirements as valuable inputs, and released product as valuable output then the wastes are unnecessary waiting time for approval, review, documentation, rework, bug fixing time, defect injection for not following standards and best practices, etc.

The output i.e the usable product release will have to be streamed out by pulling the flow naturally without having resistance / wastes discussed above.