How is Value Driven Delivery achieved in Agile Scrum Projects? Traditional Projects’ are Delivered according to a Plan. For the Development of something that is predictable, there may be a few unknowns but the outcome is generally predictable. The project can be based upon previous Projects. However, when it comes to Software Development there is often a lack of predictability. The uncertainty as to what needs to be Developed, combined with the need to Change Requirements throughout the Project brings a high-level of Risk. With this risk there is an elevated risk of Project failure.
The need to reduce Risk and Deliver what was needed was the focus of the seventeen Agile Manifesto signatories. Some of the declarations in the Manifesto were nearly heretical from a Project Managerial perspective, especially these Values:-.
” Working Software Over Comprehensive Documentation”.
and
” Responding To Change Over Following A Plan”.
Plan Driven Delivery
If the existing practices of Project Management, which were based upon Plan-Driven Delivery, were to be revised to fit Agile Development, a different Approach would need to be adopted. This is what is known 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”.
The Customer no longer needs to wait for months or years to see the result of a Software Development Project. Incremental outputs are Delivered quickly and in brief Cycles (or “Sprints”). That is not to say there is no Plan in Value-Driven Delivery, it just has a different focus.
Planning for Value in Delivery.
What Value-Driven Delivery guarantees is a Quality output that satisfies the Product Requirements of the Customer in the fastest time possible. The low BMI of this Product is the first action on the roadway to Delivering Value; the Team understand that everything they will Develop is relevant.
The Scrum Framework does this extremely well. The Product Owner, uses their understanding of the Company and Product to Prioritise the Product Backlog. If they run out of time on the Project, the Scrum Team (Scrum Master, Product Owner and Development Team) can take comfort in knowing that any outstanding Items were the least critical to ensuring the Product’s viability. The Quality and completeness of Delivery is defined by the Customers in a set of Acceptance Criteria for each component.
Driving Value in 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 are addressed in isolation from the stakeholders. The product is eventually Delivered once the Product has been fully developed. The Agile Values and Principles guarantee that the Customer is kept in the loop. As each Product increment is created, it is offered for Review by all Stakeholders and interested Parties. This is where Changes are typically requested. Changes are requested by the Customers when they realise that they are getting what they desired and not what they required (a typical challenge when specifying Requirements, even with something as standard as a User Story).
All Changes are assessed and if accepted incorporated into the next tranche of Work. The Agile Manifesto stated that Change is Welcomed. The capability to accept Changes midstream is what defines the “Agility” of Agile Development.
Assessing Value in Delivery.
A comprehensive set of Acceptance Criteria are defined for the Product and its components. These are utilized to evaluate whether shipment is “Done”, that is, does the Product, or this part of the Product adhere to the Quality and Functionality Required? Because Deliverables are addressed by their urgency to the Product, the Maximum Value is being Delivered in the quickest time. The Lower-Value Items are held over till later on.
There is constantly the Risk of Project failure, even with the most Agile Delivery. What Agile supplies is the capability to “Fail Fast”. If it is discovered throughout Development that the Product is not Viable, the Project can be stopped or cancelled. This is likewise a Value-Driven action – the financial impact and its result on the Company’s bottom line is much lower than with a Traditional Project, where it takes a lot longer to understand that the plug must be pulled.
The Benefits of Value Driven Delivery.
By concentrating on Value, instead of Timelines, the Development Team can produce an end Product in an extremely short time. This product meets the expectations of the Customer. Frequent Interaction with the Customer, plus clear Criteria on what the Product should do, guarantee that the Delivered Product is of Value to, and Valued by, the Customer. The ROI is alike greater, and as mentioned above, the Risk of Failure is mitigated by the ability to stop or cancel a Project immediately where needed.
Another Spin-Off is that the Development Team are buoyed by a successful delivery, and their self-esteem is increased. Their Value to the Company is improved and identified by the Project Stakeholders.