What is Safe Inspect and Adapt and how does it apply within Agile Project Planning? ‘Agile Planning’ is very different to Traditional Planning because it Accepts and Expects Uncertainty. However, there is still one very important similarity, 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. 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 was defined in the requirements documentation is what will be Delivered. There is a problem with this approach. What was specified at the Time may no longer be relevant by the Time the Product is Delivered. This is especially the case when it comes to Software Development. The steady adoption of the Agile Values and Principles to develop Software includes a very different approach to Planning. It has a much better chance of Delivering according to Customer expectations.

Safe Inspect and Adapt: A Flexible Alternative

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

A Product Specification defined at the start of a Project is expected to Change as the Product is Developed. These Changes will be simple to apply throughout the Project. In order to achieve this flexibility, two sides of the triangle are Fixed. These are Time and Costs. The Project is Time-Boxed, and so are a number of the activities taking place during the Project. The Scrum Team (Scrum Master, Product Owner – the Voice of the Customer, and Development Team) selected to finish the Project stays the same size from start to complete. Additional resources can not be drawn in if the Project is dragging.

The intention is to produce a Minimum Viable Product (MVP) in the quickest Time-Frame possible. What is not finished in the set time is left. This can be Done because the focus is on Developing Product Features, concentrating on the most critical Features first.

Safe Inspect and Adapt: Feature-Driven Development.

In Traditional Planning, once the Requirements have been collected, the Customer or Stakeholder is excluded from the Project. They only get sight of the Product once the Development is finished. This creates plenty of Opportunity for the Project to derail. This could habben because what was initially specified is not necessarily what the Customer expected. To start with, it is challenging to specify and envisage a intangible Product like Software. Secondly, there might be other factors that have led to the initial spec being outdated. This may occur as a legislative Change, or a competing Product for example.

Agile Development counteracts the Risk of Delivering the “wrong” Product. This is done by keeping the Customer both informed and committed to the Project. The Product is first broken down into major Requirements referred to as “Epics”. These Epics are Prioritised with the most Critical Features being provided 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 attached to Developing them. These Features are Developed and demonstrated to the Customers and other Stakeholders as early as possible. Value is being Delivered. Stakeholders confidence levels in the Project are raised by the Product Delivered for their Inspection.

Examining and Adapting.

‘Inspection and Adaptation’ are key activities in an Agile Project and add to Project success. ‘Inspecting and Adapting’ is utilized throughout the Project. There is the Opportunity for Customers to examine the Deliverables and provide feedback to Adapt the Product Design. The Change request is subject to Evaluation. If it is decided that the Change is necessary to Delivering the MVP, it is added to the Product Backlog. The Product Backlog is the Repository for the Product Requirements and is organized by Priority. The Ability to make Changes midstream distinguishes Agile Planning from Traditional Planning. In Agile projects, Changes are anticipated. The next tranche of Work (or Iteration) is not Planned in detail until the previous Iteration is complete.

Safe Inspect and Adapt: A Step at a Time.

Unlike Traditional Planning, which predicts what will occur when and who will execute it for every single Task in the Project, Agile only has firm Plans for the current Iteration. What Work will be Done in the next Iteration is only selected at the Planning Meeting prior to that Iteration (or Sprint). The Project Risk gradually decreases until the last Sprint takes place and the final Product is Delivered. The end date of the Project was decided up front, as is the number of Iterations, so the Project is very much under Control, even if we do not know what Work will be assigned to and completed during the next Sprint.

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

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, and select their own Work to be Done. Work is not assigned to them. Every day in the Standup Meeting, each Team member informs the Team what they Planned for the next 24 hours. They also discuss whether they accomplished what they had Planned the previous day. The Estimation on Work to be Done during the Sprint was determined and agreed during the Sprint Planning Meeting. Each Scrum Team member Estimates the complexity of a piece of Work (a User Story) using the preferred Estimation Technique for the Scrum Project. Estimations are discussed until a consensus is reached. The “Command-and-Control” Model of Traditional Planning, where a Project Manager is accountable for Estimating Effort and assigning Work has no place in Agile Planning.

Continuous Improvement.

A Part of Agile Planning for Change that is often ignored 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. Improvements are expected and adopted both at Project and at Programme level. They are owned by the Scrum Master, who is likewise accountable for their Implementation.

Planning as a Way of Life.

Planning is completely Integrated into the Project and takes place frequently and naturally. Every Team member assumes Responsibility for what they Planned to do and keep everybody else notified. Using the lens of Features to be Delivered rather than Tasks to be finished keeps the Plan in sync with Customer Expectations and supplies a clearer view of the Product as it progresses. Utilizing a Features-Driven approach offers an early heads-up if the Project promises to fail. The Project can then be cancelled there and then if the decision is made. The Project is transparent and the Product elements are Visible to the Stakeholders. While this is disappointing, the early acknowledgement of failure becomes part of innovation and stopping a Project early minimises expense, unlike a Traditional Project where only the End-Product is Visible and the entire Budget has already been spent.