Planning for the unknown: how agile
outsourcing leads to increased business & IT collaboration

Life can be unpredictable, strange even.
With so much out of our control how can we predict what will happen next in
life, never mind in business, technology or government?

Even if you know enough to make a plan,
keeping it on track is almost impossible. Especially given the number of
outside forces that can interfere. So how do you make a success of a business
experiment?

The answer is simple: take a lean start-up
approach to your development work and rethink how you approach your contracts.
Don’t be bound by your plans because, if there’s one thing in life that’s
certain, it’s that plans change.

Why transactional contracts are bad
for agile outsourcing

Transactional contracts are rigid
agreements. They focus on inflexible specifications, predefined delivery
expectations and risk mitigation. Once signed, the contract forces both parties
to proceed as it dictates, lest they face a fine. These contracts focus on
risk avoidance, which in turn leads to distrust and blame.

In short, because you
can’t define unknown outcomes up front, transactional contracts stop you
working together towards the common goal of delivering value, no matter what it
looks like. In an age of rapid transformation and
business disruption, there must be a better way.

In the real world, nothing is certain. So
why base contracts on arbitrary specifications rather than value? Why not have
an agreement that is more relational
rather than transactional?

Instead of looking at the pre-defined
project in front of you – delivering a product (good or bad) on time and within
budget – why not think longer term? Remember, planning is essential but
following a plan is not.

In a relational contract, the definition of
success changes. Success becomes about increasing business value, even if that
means changing your end goal. Collaboration and trust will help you understand
and deliver this.

Agile is not an unknown quantity

None of this means you can’t have a goal in
mind when you create a relational contract, just don’t let it confine you. Agile
helps you build a minimum viable product to manage expectations rather than
letting project definition paralyse you. For example, you could use DXC
Business and IT collaboration workshops to outline user needs and include
findings on the proper backlogs and continuously evolve the minimum viable
product towards a suitable consumer product.

You
can then continue improving this alpha version in steps, basing your iterations on a direct dialogue with stakeholders. Business
stakeholders can share what innovation the organisation wants to bring to
market and customer stakeholders can share how the product should be used
and what customers ask for. The Agile approach gets all
stakeholders involved and keeps them informed.

This agile approach to
developing long-term benefits isn’t new. For example, when a business
builds a factory, it’s for continuous production. The factory doesn’t become
redundant when the product evolves. Instead,

·
The
factory’s capabilities evolve with changing business needs.

·
The
company learns new skills as the product evolves, contributing to
future innovation.

·
Continuous
improvement makes production increasingly efficient over time.

This is how it should be for software
development as well.

How changing your planning and
contracts can benefit your development work

The Agile
software development manifesto focuses on collaboration and flexibility,
which makes for a better final
product. This approach is equally vital for creating contracts to
support such development.

In Agile contracting
you take part in every stage of development. This reduces the risk of a sub-par
product. You don’t just write a brief and absolve yourself of all
responsibility. You work together with IT and third-party vendors. You
build trust and, in the process, improve your organisation as a
whole.

Think ‘we’ instead of ‘me’ to reduce unhelpful handovers. Approach
contracts as a partnership between business stakeholders and IT. This
will keep the focus on problem solving rather than ‘handing
over’ risk of failure to another party. Transparency around progress is
key to building trust and success.

Everyone should take
an equal share of the blame and rewards. This means it’s in everyone’s
interests to address problems before they fester into failures.

With Agile, the more
you put in, the more insight and value you get out of the process. The
transparency and ability to accommodate change that comes with Agile increases
your chances of success. Plus, you get more of the credit for the extra
business value you deliver.

Agile practices and
contracts also lead to more innovation. Developers can edit and alter
in response to business needs and feedback. And, in turn, the business can see
what’s possible due to quick turnarounds of minimum viable products and agile
iterations.

There is no miracle cure. You need to work for it.

Let’s be clear: Agile isn’t a ‘silver bullet’. There have been notable failures using Agile
due to a lack of oversight and involvement. But when you engage with agile
development, you want the occasional failure. Failure can be a good thing; in
fact it’s a prerequisite for a learning organisation. Focus too hard on
avoiding failure and you’ll lose sight of business development.

An increased tolerance for failure, however, doesn’t negate the need to take special care
and attention when working with developers. You need involvement from senior
business stakeholders who can keep an eye on progress. This shouldn’t be overbearing.
Rather they should ‘trust but verify’
that the contractor is making the right product in the right way based on
business feedback.

Plan for unpredictability and work together to reach your
objectives

Life is unpredictable, but you don’t have to let it take you by
surprise. Forget trying to control change by sticking to a rigid plan – that’s
only going to lead to failure. Instead focus on benefits and outcomes and
remain open to change in how you achieve them.

Think about an employee contract: it’s flexible. There is a broad
outline of what the employer expects you to achieve and a set of tools for you
to work with. But you’re not told exactly how to conduct every step of
everything you do. In employment, like in agile outsourcing, you have a common
goal, but there are many paths to get there.

Appraisals, based on set feedback loops, keep you on the right track.
They ensure you’re delivering what the business needs and gives employees a
chance to tell management what they need to do a better job. In just the same
way, agile contracts rely on continuous feedback and communication.

With agile outsourcing,
you have gradual development and deployment. It’s an amalgamation of shared
expertise and continuous feedback. You stop ‘passing the buck’. Trust and
collaboration increases both within the organisation and with partners. And
everyone involved in the development work takes a share of the work and the
risk.


docx