Enterprise Agile

Applying Agile principles to enterprise development

The interest in agile development practices in recent years has been a reaction to the need to make
software development projects more focused on early and regular delivery of business value. In
many ways this has been a healthy shift, with a spotlight being placed on certain corners of the
development process and the challenge put: “how does this task or deliverable help with the creation
of business value?”

However, as is often the case with new approaches, the pendulum can swing too far, and the
inherent value in some current best practices can be lost along the way. This paper briefly examines
the principles and benefits of agile approaches, then highlights the problems such approaches face
when placed in an enterprise context and how these problems can be resolved, while adhering to
agile principles, by introducing enterprise best practice to create an Enterprise Agile approach.

June 2006

by John Cheesman, Strata Software Ltd

Project Management processes Why Agile?

IT projects frequently fail to deliver, either on time, on While iterative approaches are generally
budget or at all. Occasionally this may be due to the acknowledged as being an improvement, their overall
software development itself or the technology being efficiency depends on the type of “mini-waterfall”
problematic. But it is much more likely to be due to process being applied per iteration. Some iterative
problems with project scoping and the match between approaches identify a mass of development artefacts,
the delivered software and the actual business documents, models, designs, tests and so on, that
requirement. must be produced. These non-software artefacts can
easily gain a life of their own, using up resources and
Traditional waterfall approaches have attempted to
causing confusion when inconsistencies arise.
solve this problem by “pinning down the requirements”
and carefully scoping projects early on. This suffers Agile processes attempt to cut through the red tape
from a number of major problems – (i) requirements and get everyone in the project, regardless of role,
and priorities change with time, so by the time the focused on the common objective of delivering
project delivers it is unlikely to meet the requirement, software that provides business value as quickly and
(ii) “paralysis by analysis” – the requirements are so efficiently as possible.
extensive that they change during (and often because
Agile takes an iterative approach but forces the pace,
of) analysis itself, which means that analysis goes on
shortening iterations to two or even one week, and
and on (iii) technical risks to the project (e.g.
paring down the
technology problems, performance issues,
deliverables and artefacts
security) may only become apparent very late in
produced during the
the project and consequently be very expensive
to change. “ Agile processes iterations. Each artefact is
examined and its value
Iterative approaches try to address these cut through red challenged:
problems by breaking a project into a number of tape” Do we need this document?
iterations, with each iteration being a mini-
Do we need this model? Do
waterfall project. Rather than getting everything
we need this tool? Can we
pinned down up front, the first iteration can start
write the software without it? Many activities and
with a subset of the requirements, while the details of
artefacts produced on iterative projects fail these tests
the requirements for the next iteration are fleshed out
and get pruned. The effect is to create a development
in parallel. Further, areas anticipated as being
process that looks something like Figure 1.
technical risks can be addressed in early iterations
reducing risk for the project. Certain iterations are From an artefacts point of view it is highly software-
designated as releases, delivering software back to centric. Business Analysts (BAs) communicate
the business for review and acceptance. informally with the Business (Biz) to understand the
business rules. They then communicate informally with
Problem solved. Or is it?

Copyright © 2006, Strata Software Limited Page 1 of 6

 Business
Biz Business Biz
Rules
Rules

Acceptance
BA QA
Tests

Iteration Release
Iteration
Dev System

PM
System
Design
Iteration
Iteration
Iteration

Figure 1 – Agile Process

the development team (Dev) to define the functionality projects. We can categorise the problem areas broadly
of the system in terms of “stories” – small packets of as:
functionality that can be developed in a single iteration.
The software is periodically released back to the • Requirements definition
business for validation and this forms the main • Scalability
feedback loop.
• Enterprise context
Within the iteration Dev write acceptance tests for the
quality assurance (QA) team to validate the software Let’s look at each of these in turn and summarise
against. Dev will also write their own internal unit tests where enterprise best practice can usefully be applied.
to ensure consistency of the code base across re- Complementing Agile Approaches
factorings.
Dev may also document certain elements of the
Requirements definition
Agile approaches rely on informal communication of
system design, if this is deemed necessary, but due to
requirements, often using story cards or just a
constant communication and potential re-factoring the
whiteboard. The idea is that by creating a rapid
design necessarily remains a dynamic construct.
feedback loop and showing working software to the
The project manager (PM) is responsible for the business at the end of each iteration, the need for any
iteration and release planning, as normal, and more formal requirements definition can be avoided.
progress is measured in terms of stories completed,
and rate of completion. Precision – informal communication is the life-blood of
any project, but important business rule details must
This goal-driven and delivery-focused approach is fast be documented to avoid miscommunication. Capturing
and lightweight, and aims to establish a highly- these in a simple model ensures all the stakeholders
responsive, customer-focused project, ensuring steady are communicating, and that the rules are precise –
delivery of small increments providing business value. prior to the software being developed. It is highly
Does it work? inefficient to wait for the end of an iteration to discover
that there has been a basic misunderstanding of the
Agile was designed for small projects with co-located
rules. A symptom of lack of precision is the need for
teams and UI-oriented systems (where functionality
repeated analysis workshops.
can be assessed readily through the user interface)
and in this context it works very well. However, a Stakeholder availability – relying on regular business
number of problems can arise when applying it to acceptance as a mechanism for validating
projects that don’t have the required characteristics, requirements is risky. Business stakeholders are busy
and particularly when scaling up to medium or large people and their availability is often limited. Further,

Copyright © 2006, Strata Software Limited Page 2 of 6

iterations may slip meaning that functionality to be • Reliance on the user interface – many systems
reviewed is not available on the planned day. These integration projects have little or no user interface.
factors mean that business acceptance may occur For example, a data cleansing system may
much less frequently than the development iterations process data and remove duplicates. The
deliver increments. Augmenting software business user can hardly check the database
demonstrations with formalised models of business contents. What they can do is define the required
rules is a good way to mitigate this problem. Business rules and check representative examples.
rule models can be emailed around and reviewed in
parallel by multiple stakeholders, catching problems • Rules can be complex – the verification of some
before software gets built. business rules can difficult and best done against
documented rule definitions rather than the
Single source of truth – identifying a single individual working system. For example, distribution
who can finalise the definition of a business rule can companies may use complex routing rules when
be difficult. Business rules may emerge during the scheduling deliveries. It is difficult for those rules
analysis process and need reviewing by other to be validated by looking at the resulting
stakeholders before they are finalised. As before, this schedules produced by a routing and scheduling
definition and review process can be usefully system. Again, a small number of examples can
supported by a small number of formalised and be checked, but examples do not define the rule.
precise models.
Scaling agile projects
Joined-up stories Agile approaches were originally intended for small co-
– agile development located teams working closely with the business
iterations are based stakeholder. Once we try to scale the approach things
on the selection of a “…but scalability can start to break down.
certain set of
stories. These are
is a key issue” Communication – probably the most important
then implemented difference between small projects and larger ones is
during the iteration the ease and form of communication. Ten people in a
and the functionality single room can rely on informal communication and a
delivered. The goal of the delivery is to provide couple of shared whiteboards. The daily stand-up
incremental business value, but this value can often be keeps everyone is synch. All the developers
missing because stories don’t join up properly. It is understand all of the code. Life is good.
important that the collective set of stories selected for Once projects grow to even a modest size this idyllic
a given iteration supports a number of specific picture unfortunately breaks down. Larger projects
business scenarios. In order to do this, the stories necessarily get broken into separate teams with
must be based on a clear business process context. different responsibilities. Having teams on different
Project scope definition and tracking – while joined- floors, even different rooms, can significantly affect
up stories based on business process scenarios are shared understanding. Further, people take holidays,
needed for iteration scope planning, similarly the are off sick, leave the company, take another contract,
project as a whole needs a clear functional scope and so on.
definition mapped back to the business process. Agile Relying on knowledge in people’s heads, and
developments tend to work with simple story lists and communication via pair programming, while important,
as development proceeds, stories get implemented, is not a viable enterprise approach. The solution is to
and progress is tracked against stories. This measures get the key things written down and shared
development progress. independently. The trick to remaining agile is being
But, as before, stories alone do not capture business clear about what these key things are, and keeping
benefit or provide a link to the business process their representation simple. We’ll discuss this later as
supported. Project scope and progress tracking needs part of the Enterprise Agile approach.
to be based on business value delivered. Projects can Distributed development and off-shoring – the
often be perceived to be progressing well by ability to partition system responsibilities and allocate
development measures (good velocity, large number ownership to different groups in different locations,
of stories completed), but actually be failing to deliver including off-shore development, is an important
on key business scenarios. strategic requirement for large organisations. This can
Acceptance – showing working software to the be achieved by solving the communication challenges
business is a good discipline, but using it as the discussed above, but also by having well-defined and
mechanism for ensuring requirements and business relatively stable architectures and development
rules have been successfully understood and standards. These allow software dependencies to be
implemented can be problematic. Apart from the clearly defined and understood and hence properly
availability problems mentioned earlier there are other managed.
issues:

Copyright © 2006, Strata Software Limited www.stratasoftware.com Page 3 of 6

Collective ownership – a related topic to defining Enterprise Architecture – enterprise architecture
clear responsibilities is the agile principle of collective concerns the definition, roll-out and maintenance of
ownership. The idea is that anyone on the project can architectural principles and standards across the
work on any piece of code. The principle is to ensure business process and system portfolio. All projects
that everyone understands how the whole system need to conform to these wider standards to support
works, to create less dependence on individuals, and the wider IT strategy, even where, for that specific
to develop an ego-less attitude towards the code. project, such standards may not provide a direct
benefit. By taking too project-focused a view, agile
On large projects this is just not practical. With
projects can tend to exacerbate portfolio-level
increased complexity and a greater number of
problems such as functional
technologies comes the need for increased
duplication, lack of reuse,
specialisation. User interface developers have
“Enterprise Agile differing artefact standards,
different skills from database designers. Security
information integration,
specialists are different to package experts. incorporates the process misalignment and
Further, large projects often cross organisational portfolio context” so on.
boundaries and responsibilities. Changes
portfolio context”
The solution to this is to
therefore need to be managed in terms of well-
ensure that portfolio-level
defined software interfaces and organisational
goals and project-level
boundaries, with managed releases and deployments
goals are properly aligned and that organisational
respecting those boundaries.
responsibilities are clear. This means each project has
Application Architecture – agile approaches promote a pre-defined set of portfolio-level requirements it has
the concept of an emergent and evolving application to meet.
architecture that is minimally sufficient for the
Green field assumption – while many small projects
functionality required to date. The idea is explicitly not
may involve a high degree of new code development,
to look ahead (at least not too far). Should subsequent
most significant enterprise developments concern the
iterations require an architectural change then it can
integration, rationalisation or migration of existing
be handled through re-factoring.
systems and packages. Here, the vast majority of the
This approach generally code already exists, may be written in many different
does not scale. The languages, or may not be available at all. In this
larger the code base, context, architectural constraints and functional
and the greater the boundaries need to be based on a portfolio-level view
number of development of the problem, not just a project-level view (see also
teams, the more the portfolio re-factoring next).
need for standards.
Portfolio re-factoring – the agile technique of re-
Introducing a major
factoring is aimed at the individual code of an
architectural re-factoring
application, but at the enterprise level the idea needs
mid-flight on a large
to be applied to system portfolios not individual
project is to be avoided
systems alone. The current best practice – service-
at all costs.
oriented architecture (SOA) – is just such a portfolio-
For this reason, it is best level re-factoring approach, looking at the system
practice in most iterative portfolio as a whole and re-factoring systems into
processes to address services over time.
the major architectural
Total cost of ownership – when looking at the costs
qualities of a system early on and incrementally add
involved with managing a system across its lifetime the
functionality in subsequent iterations. Re-factoring can
maintenance and upgrade costs typically far outweigh
then be localised with less impact on other parts of the
the cost of initial development. It is therefore important
system. Focusing on functionality at the expense of
that sufficient attention is paid to the maintainability of
architecture too early invariably costs more time and
systems, not just how quickly you can get to first base.
effort over the lifetime of the project. This does not
There are two aspects to this (i) system agility and (ii)
mean that the architecture does not evolve, but that
system documentation.
the evolution is managed on a sound base.
Agile projects generally do not produce agile systems.
Enterprise Context System agility refers to the ability to make changes to
Notwithstanding the project-specific issues, there is the system readily, replace pieces, re-write pieces and
also the wider enterprise context to consider. Few so on. This system property derives from good internal
projects are islands. Most developments will need to structuring and dependency management using
dovetail with systems that implement overlapping layering standards together with component- and
business processes. service-based principles. Maintainability concerns are
generally not uppermost in the agile designers mind

Copyright © 2006, Strata Software Limited www.stratasoftware.com Page 4 of 6

because there is usually no explicit “maintainability” process best practice. It addresses some of the
story defined. This means that systems developed by shortcomings discussed above by formalising some of
agile projects tend to be more difficult to change later. the key communication boundaries and scalability
By factoring in early on a number of standardised concerns with specific process artefacts or contracts
quality requirements for maintainability, the (see Figure 2) – the business contract, the system
architecture and flexibility of an agile project can be contract, and the portfolio contract.
greatly improved. This not only reduces the longer-
Business contract – communication between the
term cost of ownership, it also assists with immediate
project and the business does not rely solely on
changes of functional direction and content by
software releases. Specific business models are
providing a flexible systems framework to support such
created which capture and formalise business rules
change.
and business processes. Verification with the business
Documentation is a classic issue. Everyone expects can then happen rapidly before software gets built,
documentation to exist, but no-one wants to write it. and is scalable, allowing multiple participants to see
Agile principles stress “working software over how all the rules fit together at different times and in
comprehensive documentation” and it is hard to argue different locations. Further, it can be relatively system
against that, but some agilists treat this as an excuse independent, allowing multiple system development
to produce no documentation at all. As ever, a balance and integration projects to be based on a common
needs to be struck. In general, high-level summary business contract.
documentation tends to be more useful than detailed
System contract – communication between the BA,
documentation because a) it gets read, and b) it is
Dev team and PM, relies on there being a clear
much more likely to be maintained and up-to-date.
definition of the system requirements and its functional
Detailed design documentation is generally best
definition. These elements are known as the system
produced by reverse-engineering models from the
contract and are formalised using use case models
code as required. Business rules are generally much
combined with system information models and
more stable than source code and hence business rule
operation contract definitions.
documentation should be more stable and maintained.
This clarity allows iteration plans to be linked to the
Enterprise Agile broader release plans, and development
Agility by Contract dependencies to be managed.
An enterprise agile process retains the principles of an
agile approach without discarding enterprise-scale

Business
Biz Business Biz
Rules
Rules

Business Acceptance
BA QA
Contract Tests

Iteration Release
Iteration
System
Dev System
Contract

PM
Portfolio System
Arch
Contract Design
Iteration
Iteration
Iteration

Figure 2 – Enterprise Agile Process

Copyright © 2006, Strata Software Limited www.stratasoftware.com Page 5 of 6

Further, by formalising the communication boundary remains test-driven and iterative, it uses continuous
between the business analyst and the development integration to maintain quality, and it creates regular
team, distributed development and off-shoring is better releases to validate requirements and priorities.
supported.
The main difference for the development workflow is
Portfolio contract – in an enterprise context system that the boundaries and remit of certain practices are
designs cannot be developed and managed in much clearer – releases are
isolation. By establishing a clear link between an focused on analysis and
individual system design and the broader enterprise design validation rather than
architecture, the role of architecture is enhanced business rule discovery;
allowing for portfolio-level re-factoring to be requirements are more
accommodated within projects focused on business precise so acceptance tests
functionality. The portfolio contract also further can be written more quickly;
supports the construction of agile systems, distributed and the architectural
development and systems integration. boundaries are better-defined
allowing re-factoring to occur
Incremental Contract Development with more confidence in a controlled environment.
Formalisation of communication boundaries as
contracts does not imply “big up front” contract Summary
development. By separating the business analysis and
architecture workflow definitions from the iterative and Agile principles have caused everyone to look carefully
incremental project management process, these at their current development practices. But agile
contracts can be built up gradually as the project methods were designed for small teams and small
proceeds. projects. This has meant that many organisations have
attempted to run agile projects and failed because,
Each iteration establishes that subset of each contract although the principles are sound, current agile
as is necessary practices are not suited for enterprise-scale
for software to developments.
“Contracts are be delivered.
Of course, as Enterprise Agile builds on existing agile principles but
established some aspects applies additional discipline, rigour and standards to
of the contracts allow agile practices to scale. It also acknowledges
incrementally” have a broader that projects do not exist in a vacuum, providing
scope than an support for managing the business process context
individual and system portfolio context on the project, without
project, it may well be the case that the contracts losing the delivery focus.
already exist in full or partial form. The aim then is Enterprise agile combines the best of both worlds –
simply to standardise the form in which that the delivery focus of agile practices with a process
information is captured. framework that allows those practices to scale in an
enterprise environment.
Agile Development in a Box
In an enterprise context, design and implementation †
works very much as in the standard agile approach. It

For further information please contact [email protected]

or visit our website: www.stratasoftware.com

Copyright © 2006, Strata Software Limited Page 6 of 6