The Agile Approach to Planning

‘Adaptive Planning’ in Agile Projects is very different to Traditional Planning since it Accepts and Expects Uncertainty. However, there is still one very important resemblance, the Project Constraints. These Constraints are depicted as a triangle, known as the Triple Constraints or the “Iron Triangle”. These constraints are:-.

• ‘Time’.
• ‘Cost’.
• ‘Scope’.

In Traditional Projects planning operates within the triangle, with Scope is the Constraint that is the least likely to Change. The Specification of the Scope is included in the Project (Requirements and Analysis). What is specified in the scope is what will be Delivered. There is a problem with this approach. What is defined at the Time the requirements are written might not reflect what is required when the Product is Delivered. This is especially the case when it pertains to Software Development. The steady adoption of the Agile Values and Principles to build Software includes an extremely different approach to Planning. This approach provides a better chance of Delivering according to Customer expectations.

A Flexible Alternative: Agile Planning.

In an Agile Project, Planning is an interesting mix of Rigidity and Flexibility. As discussed above, Agile Planning is still based on the Triple Constraints, however the Focus has Changed. Time and Cost are rigid and Scope is Flexible.

It is anticipated that any Product Specification defined at the start of a Project will Change as the Product is Developed. Changes will be easily applied during the Project. In order to attain this flexibility, two sides of the triangle are Fixed: these are Time and Costs. The Project is Time-Boxed, as are the numerous activities occurring throughout the Project. The Team selected to complete the Project remains the same from start to finish. Extra resources can not be drawn in if the Project is behind schedule. The objective is to produce a Minimum Viable Product (MVP) in the quickest Time-Frame possible. What is not completed in the available time is left. This can be Done since the focus is on Developing Product Features, concentrating on the most valuable Features first.

Feature-Driven Development to Create Value.

In Traditional Planning, as soon as the Requirements have been gathered, the Customer or Stakeholder is excluded from the Project. They only get to see the product once the Development is completed. This develops lots of Opportunity for the Project to derail. There in an increased risk that what was developed is not what the Customer expects. It is tough to specify and envisage an intangible Product like Software. There may be other circumstances that have actually resulted in the original spec being out-dated. For instance, a legislative Change, or a contending Product.

Agile Development neutralizes the Risk of Delivering the “incorrect” Product. It does this by keeping the Customer both informed and committed to the Project. The Product starts by breaking down the requirements into “Epics”. Epics are outlines of major features. These Epics are then Prioritised, with the most Critical Features being offered the Highest Priority. They are Critical, either because of their importance as a Product Component, or because there is a high level of Risk and uncertainty connected to Developing them. These Features are Developed and demonstrated to the Customers and other Stakeholders as early as possible, Value is being Delivered. The Stakeholders’ confidence levels in the Project are raised because there is a part of the Product Delivered for their Inspection.

Adaptive Planning: Inspecting and Adapting.

‘Inspection and Adaptation’ are crucial activities in an Agile Project and contribute to Project success. While ‘Inspecting and Adapting’ is utilized throughout the Project from Code Development to Process Improvement, the Opportunity for Customers to check the Deliverables also offers them the Opportunity to Adapt the Product Design. The Change request is subject to Evaluation, but if it is decided that the Change is vital to Delivering the MVP, it is added to the Product Backlog (the Repository for the Product Requirements, arranged by Priority). The Ability to make Changes midstream is what separates Agile Planning from Traditional Planning most of all. Because Changes are expected, the next tranche of Work (or Iteration) is not Planned in detail until the previous Iteration is complete.

We found these books great for finding out more information on Agile Scrum:

A Step at a Time.

Unlike Traditional Planning, which anticipates what will happen when and who will execute it for every single Task in the Project, Agile only has firm Plans for the present Iteration. What Work will be Done in the next Iteration is only decided at the Planning Meeting prior to that Iteration (or Sprint). The Project Risk slowly decreases up until the last Sprint takes place and the end product is Delivered. The Completion date of the Project was chosen up front, as is the number of Iterations, so the Project is under Control, even if we do not understand in advance what Work will be designated to and completed throughout future Sprints.

Agile Planning is Democratic.

The responsibility for Planning is a Team effort in Agile projects. There is no Project Manager. Team members are responsible for Estimating Work. The Development Team select their own Work to be Done, it is not assigned to them. Every day in the Stand-up Meeting, each Team member informs the Team what he or she has Planned for the next 24 hours,. They also disclose whether they accomplished what they had Planned the previous day.

The Estimation of Work to be Done during the Sprint is calculated and agreed during the Sprint Planning Meeting. Each Team member Estimates the complexity of a piece of Work (i.e. a User Story) using the preferred Estimation Technique for the Project. This is discussed until a consensus is reached. The “Command-and-Control” Model of Traditional Planning, where a Project Manager is responsible for Estimating Effort and allocating Work has no place in Agile Planning.

Adaptive Planning: Continuous Improvement.

A part of Agile Planning for Change that is often overlooked is the Planning to Improve the Processes. At the end of each Iteration, Process Improvements are discussed and taken into account for the next Sprint. Such enhancements are expected and adopted both at Project and at Programme level. In the Scrum Framework, they are owned by the Scrum Master, who is also responsible for their Implementation.

Adaptive Planning:Planning as a Way of Life.

Adaptive Planning is completely Integrated into the Project and occurs frequently and naturally. Every Scrum Team member (Scrum Master, Product Owner and Development Team) assumes Responsibility for what they have Planned to do and keeps everybody else informed. Utilizing the lens of Features to be Delivered instead of Tasks to be completed keeps the Plan in sync with Customer Expectations and offers a clearer view of the Product as it develops throughout each Iteration.

Utilizing a Features-Driven approach also gives an early heads-up if the Project seems likely to fail. In this case the Project can be cancelled there and then if the decision is made. While this is disappointing, the early recognition of failure is part of development and stopping a Project early minimises expense. This is unlike a Traditional Project where only the End-Product is visible and the entire Budget has already been spent.