Download Agile Control - Agile Business Consortium

Agile Control
– two terms in conflict
or in harmony?
by Andrew Craddock DSDM Director and Founder of nlighten training
On one hand, project and regulatory
governance
become
(project
increasingly
control)
important
has
in
recent years. On the other hand, many
Agile evangelists consider control to
be an intrinsically anti-Agile concept.
So is this a paradox or just a case of
mistaken understanding of both terms?
The problem with control is that if it is applied in a
traditional command and control way, it is anti-Agile.
In most project scenarios the mode of operation where
a manager of a team tells individuals what they need
to do, when they must do it and, in worst cases, even
how to go about it, is now and probably always has
been misguided. Equally misguided is the mode of
operation where individuals and teams must adhere
rigidly to pre-defined detailed process standards and
practices where ‘they’, the people who define and
police compliance, exert control over everybody – team
member and manager alike. Quality Management
practices over the last 30 years have been increasingly
focussed on tighter and tighter control over process,
with compliance being demonstrated primarily by
bureaucratic means. This has led to thousands of man
years of wasted time and effort attributable to:
lThe generation of documentation that has little or
no business value and sometimes is not even read
by those approving its content
22 www.pmtoday.co.uk | APRIL 2015
lA mistaken premise that, for projects, the best
‘plan b’ is to try and do ‘plan a’ better – through
better adherence to and, in best cases, constant
tweaking of the approach.
Fortunately all of the above misrepresent what control
really is – or at least could be – in an Agile environment.
Before looking at this in detail it is equally important
to debunk some of the misrepresentation of Agile too.
As a consultant and trainer in the Agile arena since the
late 1990’s it has been my dubious privilege to hear
words of wisdom such as “we don’t do documentation
because we are Agile” and “we don’t make plans
because we are Agile” and, even though I have never
heard the words exactly, I have certainly witnessed
behaviour that states “we do exactly what we like,
when we like and how we like because we are Agile
and if you aren’t happy with that then it’s because you
are ignorant or stupid or both”. These statements
badly misrepresent Agile and certainly appear to
disregard the notion of any form of control.
The truth here, is that the 17 thought leaders who
authored the manifesto for Agile software development
in 2001, and kick-started the whole Agile movement,
all agreed that defined process, documentation, plans
and contracts had value; it is just that other aspects
of projects such as people, teams, collaboration,
responding to change and, above all delivering
real business value early and frequently should
take precedence over these more formal aspects.
(see www.agilemanifesto.org)
Human beings maintain a dominant position on our
planet as a result of two main advantages over most
of the other species. The first is having hands with
opposable thumbs – allowing us to create and make
extensive use of sophisticated tools. The second is the
sophistication of our brain – giving us the ability to
solve problems based on experience and creativity and
the ability to do this collaboratively by exploiting our
preeminent skills in communication.
Interestingly, these characteristics actually describe
the essence of Agility – the ability to build solutions
in a collaborative way using the knowledge, skills and
resources and tools available to us.
DSDM is the longest established whole project Agile
approach. It has been tried, tested and proven over
the last 20 years to reliably deliver projects on-time,
on-budget and on-quality. To achieve this level of
success requires both Agility and control. In recent
versions of the method the emphasis on control has
become more explicit whilst every care was been taken
to maintain optimum Agility. In DSDM Atern (launched
in 2007), the principles were redefined as:
Once Evolutionary Development of the solution
begins, governance in a DSDM environment is much
more about roles and responsibilities than it is about
process and documents. The project relies on properly
qualified individuals to engage in the project and to
collaborate to ensure that the right solution is built
in the right way and is appropriately documented for
support, maintenance and regulatory purposes. The
use of Structured Timeboxes (or structured Sprints to
use Scrum terminology) with pre-defined touch-points
provides the individuals with such responsibilities
(Business and Technical Advisors – to use DSDM titles)
with an ever-timely forum to monitor and influence the
evolution of the solution.
lFocus on the business need
lDeliver on time
lCollaborate
lNever compromise quality
lBuild incrementally from firm foundations
lDevelop iteratively
lCommunicate continuously and clearly
lDemonstrate control
To make the first seven of the Principles a reality DSDM
describes a framework of empowerment within which
sensible, disciplined people demonstrate control over
the work they do. Control stems from the self-discipline
of every individual participating in a project and every
individual with the authority to direct or have influence
over it.
In the DSDM Agile Project Framework – launched
in summer 2014 – and the new DSDM-based Agile
Project Management – launching this month – some
of the products identified by DSDM (and only created
where they add value to the project) have been
identified as governance relevant. These products
are often analogous to products in PRINCE2® such
as the Project Mandate and the Project Initiation
Document (the PID) but are intended to be much
lighter than their distant cousin’s and always directly
relevant and useful to the members of the project –
not just the Project Manager and those responsible
for ‘signing off on projects’. This is an example of
the demonstrate control principle in action as it simply
makes visible to the project governors (project boards,
steering committees, programme managers etc.) the
information that is relevant and valuable to the project
and the organisation not just ‘stuff’ that is provided for
generic and often obscure reasons related to comfort
rather than real value.
At the touch-points identified above, Advisors:
1. Understand at the Timebox Kick-Off meeting
whether they need to be involved in the work
of the timebox
2.
Help the Solution Development Team
understand the requirements related to
e.g. supportability, maintainability, security,
compliance
3.Review the teams plans for fulfilling those
requirements
4. Review whether the requirements have been
properly addressed and advise on any remedial
action that may be required
5. Accept (or if necessary reject) that the solution
meets the agreed requirements
Capturing pertinent information at each touch-point in
Timebox Review Records (another governance-relevant
product) provides all that is needed as an audit trail
for all but the worst-formed legislation. Be aware
that in most cases, the legislation itself requires an
impacted organisation to define how it will ensure and
demonstrate compliance it doesn’t dictate how the
organisation should do this.
In summary, a DSDM-based approach provides a project
with an Agile framework for the development and
delivery of a solution in which disciplined professionals
demonstrate control over the work they do. Agile
Control – two concepts in complete harmony.
For further information and the latest developments
from DSDM Consortium, please visit www.dsdm.org
www.pmtoday.co.uk | APRIL 2015 23