Introduction

A Brave New World

Agile is now considered the standard approach to software development.  Many Businesses are experiencing quality issues and are in a state of chaos after rapid introduction of agile methodologies such as Scrum.  Many are in transition towards ‘being Agile’ without having a clear roadmap as to how to get there or even knowing what they are hoping to achieve.  They get the theory, but need a pragmatic approach to adopting agile techniques and achieving the true business benefits without compromising quality.  They need to bring the Business closer to product development.  They need to collaborate.

Background

Agile became popular in response to challenges faced by development teams to respond to business needs quicker and with more agility, to accommodate changing requirements and deliver return on investment at the earliest opportunity.

This is achieved through improving communication between technical and business teams, understanding very clearly which requirements deliver the business value and delivering that business value as early as possible and in line with business expectations (having avoided defects through close collaboration).

Some of the 12 Principles of Agile Software as stated in the 2001 Agile Manifesto;

• Our highest priority is to satisfy the customer
  through early and continuous delivery
  of valuable software
• Business people and developers must work
  together daily throughout the project.
• Continuous attention to technical excellence
  and good design enhances agility

Examining the Problem

What we often see however, is a focus on the mechanics of Agile frameworks such as Scrum, and the technical tools and development environments that support them rather than on the underlying principles for success i.e. collaboration.

It’s not just about the technical stuff

Agile has often been advocated by technical teams excited by the shiny new stuff but not necessarily naturally good at working collaboratively.  Business Stakeholders may have half the message, they may have heard Agile jargon and have expectations of some cost–savings or time to market improvement, but have not made the mental switch from cost to investment that underpins the benefits of delivering software in business value increments.

We see project teams thinking they have ‘gone Agile’ because they have thrown their documentation away and are having a 10-minute stand up meeting every morning.

Collaboration is the key to success

After having received technical training for Scrum, team members are generally quick to understand the methodology and principles, but the training can stop short of telling teams how to collaborate.  Team members know they should be having a close dialogue with developers and business users, but don’t have tools or guidance for doing so, and often don’t have predictable access to the Product Owner.

The following problems can occur;

• Teams fall into ‘mini waterfall’ patterns within each iteration.  This is very expensive as testers sit around doing nothing until enough has been developed for them to test.
• Defects get raised at the end of an iteration and are progressively pushed to the next, resulting in a final (maybe extended) defect fix iteration to sort everything out.
• Testers complain that there is not enough information in the user story to test from and feel uncomfortable and under-valued within the agile team.
• The Product Owner is frequently unavailable and there is no business representation within the iteration.
• There is a lack of shared understanding of the goal of the iteration, the high level architecture, or how the smaller components fit within the higher level vision
• There is a total lack of documentation after the project has finished
• Automation lags behind with high maintenance overhead.
• Business stakeholders are unable to prioritise requirements and want everything delivered to a fixed deadline.
• Business stakeholders want detailed estimations and fixed-price costs up front for the whole project.

All of which lead to inevitable delays, rework, quality issues and a very disappointed customer.

Continuous delivery is hard

There are a number of Agile principles focused on regularity of delivery;

• Our highest priority is to satisfy the customer
  through early and continuous delivery
  of valuable software
• Deliver working software frequently, from a
  couple of weeks to a couple of months, with a
  preference to the shorter timescale.

There is often more focus on achieving the capability to deliver software continuously, (very challenging) rather than on delivering value early, which is where the true business benefit lies.  Whilst it is a good aspiration in a mature Agile team to have a very short iteration, if you try to get there too quickly without recognising the technical constraints, or without having understood which features deliver the most value, it can be disastrous.

There are several factors that impact the regularity with which a software development initiative can deliver to production, and achieve true continuous delivery.  For each development project we should ask these questions;

• How many 3^rd parties are involved in this development?
• What is their ability to iterate? Do they have a long acceptance test schedule and infrequent releases?
• How big is this thing?  Are there many applications, which need to be integrated together, and which require end-to-end integration testing?
• How easy is it to introduce change to a particular functional area without needing to regression test the whole system?
• Are there legacy systems involved?
• Is this green field development?

The Solution

Pragmatism please

We need to recognise that it is not always easy to achieve very regular releases, especially on enterprise projects and in large organisations with lots of legacy systems and points of integration.

If we agree however, that the biggest business benefits lie in delivering value early rather than continuously we are left with a business challenge rather than a technical challenge.

The challenge is to understand which features have the greatest impact on ROI and deliver them first.

We can do this by applying the agile principles around communication, collaboration and prioritisation without necessarily having overcome all of the technical challenges around automation, tools and continuous delivery.

In fact we can use a structure for collaboration and prioritisation for all projects and decide how regularly we can iterate on a project-by-project basis.  We can tackle the continuous delivery challenges in parallel

From Cost to Investment

Agile is a mind-set change for the whole organisation, not just development teams.  Some more Agile Principles;

• Agile processes promote sustainable development.
  The sponsors, developers, and users should be able
  to maintain a constant pace indefinitely.
• Simplicity–the art of maximising the amount
  of work not done–is essential.

Users want everything they have asked for.  Business Stakeholders want detailed estimates up front.  Projects often run over on budget and schedule.

Business Stakeholders see development projects as costs (sometimes out of control) rather than as an investment against a Business goal.

This is a particularly painful truth for an organisation trying to adopt agile delivery methods.  With incremental delivery, the whole premise is that you don’t dive into the detail of a requirement until you need to.   That means you might not know how big and complicated a requirement is (and how much it might cost) until you get to it. The cost is fixed and the scope can vary

In most organisations there is some work to do to convince Stakeholders that this is a good idea.

Getting Business Stakeholders comfortable with the idea of flexible scope requires them to fully embrace the idea that the features with the highest business value, contributing most significantly to the ROI will be delivered first and at the earliest possible opportunity.

More so, if there is very clear understanding of the business goals and how features contribute to the ROI, they can make decisions with regard to how much they would like to invest towards the achievement of that goal.  Furthermore they can consider how they would like to distribute that investment across the scope of features, and finally how that translates towards achievement of short term, mid term and long term business goals.

If we collaborated effectively with the Business to get their buy in and agree on all this stuff up front we’d be half way there.

Summary

The Right Product

Too often we get wrapped up in delivering to a certain set of listed requirements rather than achieving the underlying business case.  Through closer collaboration with the Business, a clear vision of the product roadmap and a very clear identification of the highest priority requirements, project teams can get on with delivering the Right Product.

If we are able to give development teams a structure and tools that help them collaborate with Business users more effectively and tackle highest priority requirements first (regardless of how regularly we can deliver to production) then we can be assured we are focusing our efforts in the right direction.

If we focus on collaborative development techniques that reduce misunderstandings around requirements and maximise efficiency, we can reduce defects, reduce costs and get to market quickly.

If we can bridge the gap between technical and business teams, communicate using the same language and plan for collaboration in a predictable and structured way, we get more useful input from the Business.  Development teams with a closer proximity to the Business Domain have higher productivity.

Through collaboration we can allow Business priorities, business language and real world examples to inform the design, resulting in a lean and highly maintainable product.

We can do all this regardless of how well we follow the mechanics of Agile and how well we are doing with our continuous delivery capability.

And when we get good at this stuff, we can start worrying about tackling the harder stuff.