Delivering business value is certainly a major goal when you adopt an Agile approach like Scrum. If determining business value is already difficult inside an organization, the topic is even more complex when the project is performed by an external Agile provider. This article lists some of the important questions that should be answered about delivering value when you are contracting Agile projects to a consulting company.
Author: Chris O’Brien, Datacom Systems Limited, https://datacom.com/
This article is an extract of the playbook “Preparing for agile success”. This playbook answers questions that are likely to arise while navigating the acquisition, execution, and transition to support of agile-delivered solutions. It is hoped this guide will assist buyers and suppliers to reduce cost, time, and friction while helping them to build effective collaborative relationships and deliver greater value.
What sort of people should the buyer provide?
Arguably, the key person the buyer can expect to provide is the product owner. This role should be filled by one person, capable of guiding the solution direction on a day- to-day basis and maximising the value of the product resulting from the work of the supplier’s development team(s).
The product owner will often need to be supported by the buyer’s business and technical subject matter experts (business analysts, architects, security specialists), endcustomers and users to assist co-design and validate the solution, and any independent testing the buyer requires for the product (such as for acceptance, performance, or security). Wherever possible, all these functions should work with the product owner and agile development teams in a highly collaborative and integrated way.
The buyer should also expect to provide people to prepare the organisation for the solution. Readiness could include things like training (although this may also be provided by the supplier), communication and marketing, process design, policy, legal, and other aspects of organisational change management.
Who makes a good product owner?
The best product owners typically have a deep understanding of what the business requires, are well-connected and respected within their organisation, collaborative, open-minded, can confidently make sound decisions, and are available to engage with the project on a daily or near-daily basis (ideally at the same geographical location).
The product owner must also be trusted by the buyer’s project sponsor to own and guide the delivery of the vision. These qualities are often found in experienced, senior staff who are very close to the business and how it works. Where a product owner lacks deep knowledge of specific business processes and technical systems, they can be supported by specialists. However, it can be harmful to assign the responsibilities of this key role to a programme or project manager (who have
other delivery functions outside the agile method and are not empowered to own the vision), or to a committee (who are unlikely to be able to engage with the solution teams every day and make rapid decisions).
Where a project is entirely technical in nature, for example, moving a digital platform from on-premise to the cloud, it may be appropriate for the product owner role to be filled by a senior architect who has the necessary attributes.
How will we know the velocity of the project is okay?
Velocity is the rate at which development teams produce completed work.
In estimating when the project may deliver and how much it may cost, it is important to consider the things that may affect velocity and the possible range of delivery rates that could be achieved. By frequently tracking actual velocity against these estimates during the delivery, the project can
determine if predicted or unforeseen risks are being realised, and whether action is needed to address these issues.
Progress through the backlog items should be visible at any time, and teams will usually report their velocity at the end of each sprint (and this requirement can be described in the contract).
There are some important points to note about velocity:
- The velocities of early sprints are likely to be lower, as team members adapt to working with each other (and potentially to the new agile way of working)
- Velocities may be higher or lower in any given sprint due to normal variation — it’s the velocity trend that matters
- Due to the differences that exist between teams and the nature of their work, the velocities achieved by different groups should not be compared.
How can the buyer get the assurance they need?
Buyers can be assured of better outcomes from agile delivery by setting realistic expectations and plan, by engaging closely with the market to find a capable and well-matched supplier, and by investing in authentic participation in the agile process.
Agile methods include various safeguards to monitor progress and enable reporting of the costs incurred compared to scope and value delivered over the relevant time frame. Monitoring, reporting, and early engagement on concerns by all parties can help ensure that agile delivery occurs as intended.
For formal assurance during agile delivery, New Zealand’s office of the Government Chief Digital Officer has provided guidelines both private and public sector organisations may find useful.
How will we know when the work is done to the right level of quality?
Different acceptance criteria for each item in the backlog and common criteria that apply to all items (called the definition of done) are important elements that help define the agreed level of quality for the work.
Manual and/or automated testing can verify that functional and non-functional requirements have been achieved for the backlog items completed in each iteration. However, in a sound agile delivery, there should also be frequent opportunities for the product owner, supporting technical specialists, and wider stakeholders to observe the quality of working solutions through interaction with the development team and in regular review sessions.
How will we deal with defects and quality issues?
It is important to remember that defects are a normal part of development activity, whether in agile or traditional delivery projects, and their existence does not necessarily imply poor quality.
Agile aims to identify and correct defects during their related development activities with the minimum of overhead, so many defects may not be subject to formal defect management. Defects that can’t be repaired immediately, or those that are found outside of the current development iteration, should be tracked as part of the backlog and be subject to product owner prioritisation for remediation. These may be software defects, but could also be issues with requirements, architecture, or testing itself.
If the number of defects or general quality issues (including the quality of the agile process) are adversely affecting velocity and the delivery of features, these problems should be dealt with using collaboration and the agile feedback mechanisms in the first instance (for example, reviews and retrospectives). If underlying causes or solutions are outside the influence of the delivery teams, or are proving intractable, then support can be sought from project governance.
How will the delivery be accepted?
Ideally backlog items will be fully accepted within each of the development iterations, but this can be hard to achieve and it is not uncommon for some acceptance to occur after the related development has taken place.
Considerable risk can be created for the buyer and supplier depending on the size and nature of this offset and any misalignment between criteria used for solution development and those used for acceptance. These risks can be mitigated by creating high levels of early and ongoing engagement between the product owner, those responsible for any offset acceptance activities, and the development teams.
When should rework be done at the supplier’s cost?
Some degree of rework is unavoidable on any software project and is expected as a natural consequence of discovery and learning on an agile delivery. Where a project involves greater uncertainty or discovery, more rework can be expected. However, rework does not always contribute positively, and poor performance by the buyer or supplier can cause waste in the form of avoidable rework.
It can be difficult to define exactly when the amount of rework has become excessive, and because agile requires parties to work more collaboratively, it is sometimes not easy to say who is responsible for rework (or if one party is solely responsible). Buyers and suppliers should use the many opportunities for visibility and feedback in an agile project to understand if rework is causing problems, and to collaborate in quickly addressing any causes of avoidable rework.
Where rework issues clearly lie within the supplier’s sole control, and are not able to be promptly remedied, it may be reasonable for a buyer to expect that the rework is done at the supplier’s cost. In keeping with sound agile principles and behaviours, issues of this nature should be raised early and openly, escalated through project governance (if necessary), and not appear as a surprise to either party at the end of the project.
About the Author
Chris O’Brien is Principal Advisor at Datacom. He is passionate about making a difference – both as an individual and as part of powerful teams. After more than 25 years working across all aspects of technology concept, creation and support, he brings this passion to helping people and organisations achieve the benefits of successful digital development and services.
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International Licence.