John Muncaster, Goldratt UK
John is an experienced TOC and Lean practitioner who, with more than 25 years of experience, has occupied several positions in manufacturing companies in the UK.
What is Agile?
Agile is a software development philosophy that is best summed up in the Agile Manifesto (http://www.Agilemanifesto.org/):
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
There is an assumption in the Agile world that, in software, when starting development there is no need to fully understand the specification of the end product. In many cases this may be continually evolving. The Agile world also assumes that what is being delivered can be broken down into smaller chunks. These chunks provide useful functionality and can be released as soon as they are tested. This works particularly well when developing software for Web services. It is very common when visiting a favourite website to see some of the pages transformed into a new version, whilst others remain in the current format. Over time all pages will be transformed to the new style as the software to support these pages is developed and tested.
In Agile the intent is to simplify by breaking a big project into small chunks, with a clear definition of done, and build autonomous teams to deliver the chunk. The team should be self-sufficient and self-managing. The team retains focus by further breaking down the chunk into short duration discreet tasks. These tasks are distributed amongst the team for delivery. Cadence is maintained by the team keeping WIP low and regularly reporting progress. This reporting of progress ensures that team members are focused on delivering what they have committed to. This allows the power of the team to become engaged when any task becomes stuck.
Organisations have built processes to support these Agile philosophies and this document does not intend to define them, rate them, or discuss them in detail. It is enough to say they all have merits, supporters and documentary evidence to show they work. Some follow all the guiding principles of Agile well and others focus on a smaller subset.
Can Agile Work in All Software Development
In environments where the software itself is the end product, and the product is expected to continuously evolve, Agile has an excellent track record. The question raised here is, can this flexible approach work in an environment where the software is integral to a physical product that is being developed? Can the true, flexible, Agile approach that offers so much in continuously evolving software products be as useful for delivery of a full set of functionality to a deadline? Particularly when, the software supports the hard launch of a physical product. For example; all car drivers want all of the software to be working and fully tested when they buy their new vehicle. It is not possible to launch a vehicle requiring a future upgrade to make the braking system work effectively all the time.
However, as with all things, it is important not to throw away valuable principles and techniques just because the full philosophy is not applicable in some circumstances. This document will identify how core elements of Agile can be used seamlessly with the successful deadline focused project management tool – Critical Chain.
Critical chain is a Gantt based project management tool that uses the rate of consumption of a protective buffer compared with the rate of completion of the longest chain of tasks to understand the health of the project.
- Logical network created
- Longest chain of tasks identified
- % of time taken from each task to provide a buffer to protect the end date – sharing task safety
As tasks are completed the remaining duration of the tasks are likely to extend and buffer is consumed.
Progress is measured by comparing the percentage of longest chain complete to the amount of buffer consumed.
If, this metric demonstrates good health, the project team can be left alone to continue the good work. If, it demonstrates that the health is poor and therefore the delivery date is in jeopardy, it highlights to the team and management that action is required to bring it back on track.
Creating the Plan
When building traditional Gantt charts, there is a temptation to focus on creating plans with infinite detail, and to micromanage resources with the plan. Assigning the role of building the project solely to the project manager is common, as is developing detailed plans for projects of months or even years. This approach is in direct conflict with the principles laid out in the Agile manifesto. This approach is also in conflict with good critical chain plans which are:
- Built at a higher level of detail, the tasks are described as clear deliverables. The detail of how this deliverable is achieved is left to the owner of the task and the team working on delivering it. This supports the Agile principle: “Individuals and interactions over processes and tools”
- Built collaboratively, a team is assembled containing those who will be working on the project and customer representation supporting the Agile principle: “Customer collaboration over contract negotiation”
- Built with tasks focused on tangible deliverables, only doing what is required to deliver the required functionality supporting the Agile principle “Working software over comprehensive documentation”
- Built in detail only for the short horizon, detail for the longer horizon is only planned as that horizon approaches supporting the Agile principle “Responding to change over following a plan”
It is clear that building a good Critical Chain plan has no conflict with the Agile Manifesto. It should be noted that some of the process developed by organisations, consulting bodies and academics to support the Agile community may in themselves conflict with Critical Chain planning. Using the core principles of Agile will definitely assist in developing a good Critical Chain plan ready for Execution. Truly Agile organisations will be prepared to flex the tools being employed to support their principles if this gives them an advantage.
In execution of traditionally built project plans, it is common that focus remains on items that were deemed critical or time limiting at the start of a project, even if in execution this proves not to be the case. There is also a temptation to follow the old adage “the sooner we start the sooner we will finish” and work is released to individuals and teams faster than they can complete it. This causes significant problems with priority setting and losses due to multitasking and context switching. Good Critical chain execution focuses on:
- The current critical and time limiting activities supporting the Agile principle “Responding to change over following a plan”
- Choke the release of work to individual teams emphasising focus and rapid completion of the tasks released for execution. Although this is not directly part of the Agile manifesto it is common in most Agile tools that resources are forced to focus on small chunks of work and maintain a high cadence of completing these chunks of work.
In most project environments there is a high level of uncertainty in the tasks being carried out. With any tool being deployed there is a reasonable chance that what has been agreed with the customer in terms of cost, scope and delivery date will require modification. Critical Chain is no different and successful Critical Chain implementations require good channels of communication between the project team and the customer to obtain the optimal outcome for the customer.
There are no direct conflicts between Agile and Critical Chain and the two philosophies can be used quite comfortably with each other. In fact, if project teams building Critical Chain projects have the Agile manifesto in mind, they will certainly develop much better quality project plans. There are some direct conflicts between some of the tools developed for applying the two philosophies. In many cases this can be resolved by the organisation ensuring they have selected the right tools for their environment. Projects delivering software as a service will need a slightly different set of tools than those delivering physical product with a software element.
All materials available on the TOCPA site are the intellectual property of their authors and cannot be reproduced in any other media and used for any purposes without the prior permission in writing of the authors.