The agile holistic approach for improved software delivery

To optimise IT services delivery the approach must be holistic. What actually counts is to produce business value for the customer as early as possible while mitigating the risks in the process and that is difficult to achieve if the efforts are isolated to single-point improvements.

As distributed development becomes more common due to reasons such as cost, availability and scalability, organisations must learn to cope with it and more importantly to turn it in to an advantage. I have written a few articles on the importance of having the entire organisation in on-board to benefit from the positive effects of using agile methodologies. Read more here or here! In-house is by far the most expensive form of development but it also have the lowest risk.

An holistic approach is essential to improve your delivery. Working with the development team or your service supplier alone, will not create the desired effects or at least not give the full potential result.

Desired state

Let's define what the desired state is with for example a user story: "As a management team we need effective processes so that our software investments deliver the required business value and financial return".

Acceptance criteria can for example be:

• All software projects shall deliver 70% of the desired business value within 50% of the projects scheduled time.
• 90% of all software projects shall be completed on time within budget.

What you choose to use here is depending on your situation and ability to change. I recommend to start with something achievable and to adapt the criteria as you learn and improve.

The agile holistic approach incorporates four main elements:

Business alignment

The first element is business alignment. This is an important part of the preparation for any software project but often cut short.

• The customer's (the business) expectations on the value to be created need to be realistic in terms of budget and schedule.
• Risk identification and mitigation
• The business case that underpins the investment in the project need to supply metrics that can be used to measure business value.
• The metrics need to be documented and made transparent along with progress. All team members and stakeholders need to understand the implications.

In too many cases organisations fail to provide this alignment, which increases the risk and can potentially cause a team that develops good software to to develop the wrong software. It's especially important that the alignment based on business metrics is clear when working in a distributed environment. If the team is provided by a service supplier, the metrics should be used to align the supplier to have the same business goals as the customer.

Resource alignment

The roles of an agile team need to be understood and the stakeholders need to align and allocate the resources needed.

• The role of the product owner is critical but often feel as not being a part of the team. Many organisations struggle with the role and do not allocate enough time to it. For a full Scrum team a PO role is a full time job.

In distributed development, the product owner is often on the customer or business side and the other roles placed in another or location supplied by a service provider. Even if business alignment is good, there are easily conflicts of interest growing that are hard to cope with, when not sitting in the same place and working for different entities. There are a couple of options to mitigate this:

• Let the outsourcing supplier provide a Product Owner - a problem could be domain experience but will improve over time if the outsourcing has a long term approach
• Appoint a Project Manager to support the Product Owner - this will help to confine the conflicts of interest between budget, schedule and scope to the customer side.

The own ability and openness to work in a foreign language and over boarders with cultural differences should guide the selection of teams and providers. The farther away, the more difficult this will be.

Agility

The ability to run agile in distributed development is considered as a must for many, but I think we can safely conclude that it will help. The actual techniques that are in use must be determined by the combined experience and knowledge. Again, it is important the the organisation beyond the development team supports the agile principles.

• Team members need to be able to work together, a quality that is not so easy to find in a CV.
• Traditional outsourcing contracts can be counter-productive to agile.

The supporting functions such as finance, procurement and HR needs to understand how to contract and remunerate suppliers to pave the way for agile execution. HR needs to understand how to recruit people who are contributing to the continuous improvement of the teams.

Project governance

As the aim is to get as much business value as early as possible in each project and in effect also to avoid developing code that will not be used, the management team needs to set and declare the principles for how projects are planned and governed.

• The planning onion - It is not good enough to have sprint planning and retrospectives. Product and portfolio planning along with release planning are equally important to reach the desired state.
• Prioritisation - The metrics that are set by the project's business case should be used to govern the prioritisation on product and release level.

This planning is in my mind a de facto business plan that is adaptive and used iteratively, along with a changing business landscape and learning from the teams.

Preparation

To be able to optimise software delivery using agile principles there is a strong need to apply a holistic view. Excluding one or more of the main elements above will not enable you to get the right results. The preparation for each step is critical and could be helped by training and expert coaching.

If you succeed, you can enjoy the benefits of working with the expertise of distributed teams, where cost and availability will come to your advantage.