How can we ensure Continuous Delivery Of Valuable Software. ‘Traditional Projects’ are Delivered according to a Plan. In Software Development there is a combination of unpredictability and the constant need to Change Requirements. These changes to requirements can occur throughout the Project. Each of these changes bring a high level of Risk as well as a chance of Project failure. The need to mitigate Risks and Deliver what is needed was top of the agenda for the Agile Manifesto. Some of the declarations in the Manifesto were practically heretical from a Project Managerial perspective, especially these Values:-.

“Working Software Over Comprehensive Documentation”.

and

“Responding To Change Over Following A Plan”.

The existing practices of Project Management, which were based upon Plan-Driven Delivery needed to be revised to fit Agile Development. A different Approach would need to be adopted. This is what is referred to as “Value-Driven Delivery” and is revealed in the first Principle of the Agile Manifesto:-.

“Our Highest Priority Is To Satisfy The Customer Through Early And Continuous Delivery Of Valuable Software”.

No longer would the Customer have to await months or years to see the result of a Software Development Project. Incremental outputs would be Delivered quickly and in short Cycles (or “Sprints”). The Stakeholders could see right away if what was Developed was what they were expecting. If the Product was not as they envisaged, a request for Change could be issued. The Development Team address the most important elements first, maximizing Value to the Customer. That is not to say there is no Plan in Value-Driven Delivery, it just has a different baseline.

Continuous Delivery: Planning for Value-Driven Delivery.

What Value-Driven Delivery promises is a Quality output that fulfils the Product Requirements of the Customer. This is achieved in the fastest time possible. The low BMI of this Product is the very first action on the roadway to Delivering Value. The Scrum Team (Agile Scrum Master, Scrum Product Owner and Scrum Development Team) understand that whatever they will Develop is relevant.

The next step in the Planning stage is deciding the order of Work. The focus is on the most critical and Riskiest components. The Scrum Framework does this effectively, by having a Scrum Product Owner. The Product Owner utilizes their knowledge of the Company and understanding of the Product. They use tis knowledge to Prioritise the Workload in the Product Backlog. The Development Team will select the highest priority Work to be Done during the Sprint Planning Meeting. If they run out of time, the Team can take comfort in knowing that the important Items were addressed. The Quality and completeness of Delivery is defined by the Customers in a set of Acceptance Criteria for each component.

Continuous Delivery: Driving the Delivery.

In Traditional Development, Stakeholders and Customers do not have a good line of sight into what is being Developed. The Requirements are Documented and Signed Off and descend into a dark tunnel. The product ultimately popping up again as the final Delivered Product. The Agile Values and Principles ensure that the Customer is kept in the loop. As each Product increment is provided, it is made available for Review by all Stakeholders. All interested Parties can view a product demonstration during the Sprint Review Meeting.

Where a change is requested, they are assessed and included into the next tranche of Work. That is if they are necessary to delivering a Product that is aligned to Customer expectations. The Agile Manifesto specified that Change is Welcomed. The capability to accept Changes midstream is what defines the “Agility” of Agile Development.

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

Continuous Delivery: Examining the Delivery.

As mentioned above, a thorough set of Acceptance Criteria are defined for the Product and its components. These are used to assess whether delivery is “Done”. That is, does the Product, or this part of the Product conform to the Quality and Functionality Required? The Criteria needs to be met to ensure that Value has been Delivered. Due to the fact that Deliverables are ordered by their criticality to the Product, the Maximum Value is being Delivered in the fastest time. Lower-Value Items are left over until later in the project. If the Project runs out of time, the Low-Value Items that have not yet been Developed may be disposed of.

There is always the Risk of Project failure, even with the most Agile Delivery. What Agile offers is the capability to “Fail Fast”. If it is discovered during Development that the Product is not Viable, the Project can be stopped or cancelled. This is also a Value-Driven action – the financial impact and its effect on the Company’s bottom line is much lower than with a Traditional Project, where it takes much longer to realise that the plug must be pulled.

The Benefits of Value-Driven Delivery.

By focussing on Value, rather than Timelines, the Development Team can produce a completed Product in an extremely brief time that meets the expectations of the Customer. Frequent Interactions with the Customer, plus clear Criteria on what the Product needs to do, ensure that the Delivered Product is of Value to, and Valued by, the Customer. The ROI is similarly greater. The Risk of Failure is mitigated by the ability to halt or cancel a Project immediately where needed.

Another Spin-Off is that the Scrum Development Team are buoyed by a successful delivery, and their self-confidence is enhanced. Their Value to the Company is boosted and recognised by the Project Stakeholders.