AgileOrganizations

How Agile a group of people want to be, or can be, is not static and should not have to be. When buyng a service using Agile practices it is important to make sure everybody speak the same language to set expectations and govern collaboration. That, however, does not mean pure Agile practices is always best when outsourcing service rather finding a level of using Agile practices that is more or less equal to all involved.

Therefore I recommend a Trust score to be used. The trust score identifies differences in perspections/expectations which needs to be adressed.

How do you size an engagement when you do not know exactly what is going to be delivered?
Very often companies wanting to outsource something wants to specify exactly what is going to be delivered and how, simply because they think that is the best way to make sure they do not get fooled or tricked by a vendor. This behavior works when you can specify exactly what is going to be delivered and how, like in traditional Waterfall projects. In an Agile engagement it is different, so instead focus should be on making a functional capacity available to the customer which can be specified and controlled. The output can not be controlled in the same way, but the assumption, based on mutual trust, is that utilizing the right capacity will produce the optimal output i.e. working code.

So, when buying Agile services focus should be on sizing the relevant capacity to adress the business problem, NOT sizing the estimated effort to create a predefined solution.

Being Agile does not mean following a specific framework to the letter. It is more about how to adress problems, how to collaborate and how to implement change.
In another post I have written about agile vs. Agile, in this post I want to highlight the Agile mindset.

* Problems are adressed with curiousity and as opportunities to make change. Change is positive and continous. Solving problems is a stepwise exercise where you size workload in each iteration depending on the capacity you have. After each iteration the output is evaluated and based on result the next step is planned. This means that you probably never come to a fixed solution …
* Collaboration is impled. Not if, but when issues appear they should be brought to the attention of all in a transparent way. This is not to put blame on indivuduals/groups but to drive learning and gaining experience. It is ok to fail, you should fail occasionally to learn and progress. Youd should not make the same mistake twice though…
* Implementation of change is a continous exercise with a regular cadence. Stakeholders and implementors are in the same team, there is nowhere to hide. Stakeholders work on detailing the problem at hand by clarifying the problem statement, iteration by iteration by evaluating the output, comparing to objectives and updating problem statement. Implementors update the working code adding their expertise and experience iteration by iteration and work together with stakeholders on what is possible.

Traditional outsourcing is covered by SLA’s to make sure the buyer can control everything the supplier do. The reason is to make sure the supplier delivers what is promised at the cost that is committed. If the SLA’s are very tight and detailed it leaves little room for experimentation/innovation/learning. If the service requested is easy to define and measure it may be a good approach, but as the service gets more and more complex and more and more demanding specialist skills outside the remit of the customer it gets problematic. If only lower cost is important, the service will be optimized for lower cost. If the customer wants learning/advise/innovation there must be trust enough in the vendor providing it and results that proves it.

So, therefore I have defined 4 categories of partnerships
A – Competitors ( no trust, lowest cost, buying a product)
B – Master/Slave Partners ( no trust, lowest cost, buying a service)
C – Master/Servant Partners ( increasing trust, reasonable cost, building a relationship)
D – Equal Partners ( complete trust, value sharing, monetize the relationship both ways)

Depending on what partnership is requested there are different types of contracting approaches.
A – Traditional contract buying a product with negotiations on cost/penalty
B – Traditional contract buying a service with negotiations on cost/penalty
C – Team-as-a-Service / Factory-as-a-Service buying a capacity with negotiations on available skillsets
D – Relational contracts aligning interests with negotiations on successful ways of working together

According to Agile practices and way-of-working there are no projects. Instead Agile is based on the assumption of a regular, steady cadence of work being applied to a product. The work intended is outlined on a backlog and after each Sprint the output is validated and considered while planning the next Sprint. This is very similar to old-school maintenance approaches given that the execution of work is different.
A traditional project sets out what to build in a specification and resources are allocated according to estimations of what is needed. In Agile it is the other way around where the resources are fixed and the specification is ever changing reflect what the team(s) accomplish in each Sprint. Hence the traditional Project concept is not relevant, instead it is more appropriate to talk about an Engagement where available resources are utilized under a set period of time.
Using the same word with multiple meanings are never a good thing!
Therefore, I suggest using the term Project when offering to build a solution with a fixed specification and moving capacity. When you have a situation where you offer a fixed capacity and a moving specification it should be called an Engagement.

To validate the team delivery of working code meets expected standards there are several concepts that can be used.
* Engagement Objective – Defines the EXPECTATIONS on the full delivery after the Engagement is done. These Objectives should be measurable.
* Sprint Objective – Defines the EXPECTATIONS on team delivery at the end of each Sprint/Iteration. These Objectives should be measurable.
* Definition of Done – describes WHAT ACTIONS needs to be done before an Item can be considered done, i.e. ready for evaluation.
* Acceptance Criteria – defines the EXPECTED RESULT for each Item/User Story. This must be measurable through the Definition of Done and clearly stated comparable with criteria set.
* Working code – this term is aimed at what is delivered at the end of a Sprint/Iteration. It does not have to be code, but rather that Quality of output does not conflict with what is already delivery in a working format. So, with that definition a document that meets acceptance criteria and does not contradict previous versions of that document (or what it is aimed for) is within the concept of working code.

According to the Agile alliance glossary the definition of Velocity is
// At the end of each iteration, the team adds up effort estimates associated with user stories that were completed during that iteration. This total is called velocity. //

This means that velocity is a way to capture historical capacity of delivering user stories when the sprint/iteration is completed.
There are many unknowns here like:
– how big is a user story
– what was the actual skill level in the team for the specific type of stories delivered
– what activities were actually involved in Definition of done
– was the stories well defined
– was the initial effort estimation correct or not
– where there practical things like vacations affecting the teams capacity
– …

Over time the team will be better at estimating effort needed to accomplish something, but because of the unknowns and the lack of possibility to look into the future estimations will be wrong.

A common approach for traditional management is to use velocity as a way to plan capacity of a team going forward, and make commercial comittments based on the assumption that the velocity is a constant. This, to me, is wrong since it comes too close to traditional project planning and resource allocation. All velocity should be used as, is input to the planning process (PO/team) defining the items on the backlogs.

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.