Agile and the Best Management Practice Framework Within the Public Sector

Agile and the Best Management Practice framewor fr amework k within the public sector sector Peter Measey Measey,, RADT ADTAC AC Limited

White Paper June 2013

© The Stationery Office 2013

2

Agile and the Best Management Practice framework within the public sector

Contents 1

Introduction

3

2

What is Best Management Practice?

4

3

What is Agile?

4

4

Agile – why now in the public sector?

5

5

Agile and the Best Management Practice framework

6

6

Agile transformation

8

7

Dynamic Systems Development Method

9

8

Agile and ITIL

10

9

Agile and PRINCE2

10

10 Agile and Managing Successful Programmes

11

11 Agile and Management of Risk

12

12 Agile and Management of Value

12

13 Agile and Portfolio, Programme and Project Offices

13

14 Agile and Management of Portfolios

14

15 Conclusion

14

References

15

About the author

16

Acknowledgements

16

Trade marks and statements

16



1 Introduction Within the world of method frameworks it is very easy to get attached to one specific framework and become a ‘fundamentalist’ on that single method. Method fundamentalism causes people to focus on why their method framework is right and all others are wrong, rather than on how integrated method frameworks can enable excellent delivery (which is the whole point of having them). Most method frameworks have something to offer and, once inspected and adapted, they can normally coexist. This White Paper discusses the implementation of Agile frameworks within organizations where the complexity of the delivery and management environment means that inspecting and adapting guidance from the UK government’s Best Management Practice frameworks is recommended.

3

Best Management Practice provides a detailed knowledge centre of learned best practice which Agile practitioners can inspect and adapt for their own purposes. The Best Management Practice framework website (see section 2) defines its publications as ‘flexible, practical and effective guidance, drawn from a range of the most successful global business experiences.’ Sadly, what happens all too often is that the Best Management Practice frameworks are used far too strictly and the focus shifts from delivering the product to delivering the framework. This is missing the point about Best Management Practice’s ‘flexible, practical and effective guidance’ which should be inspected and adapted as appropriate. People tend to miss this key point; instead they unthinkingly and robotically follow the Best Management Practice framework.

What is Agile? There are a number of Agile frameworks that in essence aim to deliver fit-for-purpose products and outcomes on time and cost (or in best time and cost) in complex environments that are constantly changing.

Agile encourages people to think about what they’re doing and provides a simple baseline framework from which to start. It advocates inspecting elements of the Best Management Practice framework and adapting them for use only when they demonstrably add value to the customer.

What are the Best Management Practice frameworks? They are a family of management and delivery frameworks that have been built from learned best practice covering complementary topics such as portfolio, programme and project management.

Using Agile and Best Management Practice combines the best of both worlds. It enables Agile thinking (essential for delivery) and provides a set of learned best practice frameworks that Agile thinkers can use as appropriate.

The Agile frameworks align with an Agile manifesto (Beck et al ., 2001) that defines Agile values and core principles. These values and principles must be adhered to for the framework to be considered Agile. The Agile values stated in the Agile manifesto are as follows:

Another very common obstacle to Agile people using the Best Management Practice framework is that they confuse Best Management Practice with the Waterfall approach and think, wrongly, that Best Management Practice cannot work with Agile frameworks.

■

Individuals and interactions over processes and tools

■

Working products over comprehensive documentation

■

Customer collaboration over contract negotiation

■

Responding to change over following a plan.

Agile recognizes that while there is value in the items after the word ‘over’ (for example, process and tools), it values the items on the left more (for example, individuals and interactions). Along with other delivery and management frameworks, Agile does not expect everyone to be an expert on everything. Therefore, depending on the complexity of a delivery environment, it is essential that people have reference to a body of knowledge; this can be either another person who can coach them, or a set of reference documents from other people’s experiences and best practice. The Best Management Practice family of frameworks can provide this.

Waterfall is designed for use in simple delivery environments that don’t undergo constant change, and therefore all the analysis and design is performed upfront. Agile is designed to be as its name suggests; in other words it is designed to provide the delivery and management agility to stay in line with changing environments. Agile is designed for use in complicated, complex or anarchic situations that change unpredictably (see section 3). This is one reason why Agile has become so dominant within the software industry.

Best Management Practice is not the same as the Waterfall approach. Best Management Practice and Waterfall are fundamentally different things. Waterfall is a delivery approach; Best Management Practice provides frameworks that can be used with any delivery approach, whether that approach is inherently Waterfall or Agile.

Not all delivery environments require standards and guidance. The Agile world starts with the basic Agile framework, then inspects other processes and documents as required, adapting them to suit its delivery approach, but only if they clearly demonstrate value to the customer.


4

2


What is Best Management Practice?

Best Management Practice is a collection of best-practice frameworks from the UK government. The Best Management Practice website (www.best-management-practice.com) describes them as follows: ■

■

ITIL ® offers guidance to service providers on the provision of quality IT services, and on the processes, functions and other capabilities needed to support them. ®

PRojects IN Controlled Environments (PRINCE2 ) navigates users through all the essentials for running a successful project.

■

Managing Successful Programmes (MSP® ) offers best-practice guidance to all organizations – large or small, public or private sector – to help them achieve successful outcomes from programme management.

■

Management of Risk (M_o_R® ) is a robust yet flexible framework that allows organizations to assess risk accurately.

■

Management of Portfolios (MoP® ) is about managing programmes and projects to deliver change, and investing in the right change initiatives to maximize return on investment.

■

Management of Value (MoV® ) is all about maximizing value in line with the programme and project objectives and key stakeholder requirements.

■

3

Portfolio, Programme and Project Offices (P3O® ) brings together a set of principles, processes and techniques to facilitate effective portfolio, programme and project management offices (PMOs).

What is Agile?

Figure 1 shows that if requirements are not yet agreed or are likely to change, or if the delivery technology is unknown, then the delivery environment is likely to be complicated, complex or even anarchic. Professor Ralph Stacey of the University of Hertfordshire made the point that the simpler the delivery environment, the more defined and detailed the delivery approach could be because of the lack of required change. In other words, all the analysis of the problem and design of the solution could be done upfront as change would not be experienced. Taking the software industry as an example, the first delivery framework to be used within the software industry was the Waterfall, an approach proposed in 1970 by Dr Winston Royce in his paper ‘Managing the development of large software systems’ (see Figure 2).


Far from agreement

Anarchy s t n e m e r i u q e R

Complex Complicated

Simple Close to agreement Close to certainty

Far from certainty

Technology

Figure 1 Defined or empirical delivery – a version of the Stacey matrix

Waterfall is a delivery approach that is suited to delivery environments that are ‘simple’ under Stacey’s definition. The Waterfall style of delivery served the software industry well in its early years. Most software assets that were being delivered in the 1970s and early 1980s were fairly straightforward; requirements that didn’t change much could be defined at the beginning and the technology at that time was relatively simple. However, in the late 1980s this changed. The software industry started to be asked to deliver products that were far more complex; no-one could define upfront exactly what was wanted; any requirements definition that was made would change, sometimes significantly; and the available technology became far more complex.

System reqs Software reqs Analysis Program designs Coding

Testing

Operations

Figure 2 The Waterfall approach, as proposed by Dr Winston Royce (1970)


The Waterfall delivery approach no longer worked for numerous software deliveries in the late 1980s as it was not designed for complicated, complex or anarchic environments. Meanwhile, the Agile family of delivery and management frameworks had been evolving since the mid-1980s to enable delivery in constantly changing environments. In the late 1990s, as these frameworks evolved further, they became subject to increasing public attention. Each had a different combination of old, new, and transmuted ideas. But they all emphasized the following: close collaboration between the team and stakeholders; face-to-face communication (more efficient than written documentation); frequent delivery of new deployable business value; tight, self-organizing teams; and ways to ensure that the inevitable requirements churn was not a major problem. These frameworks were named collectively as ‘Agile’ in 2000 at a gathering of the leading gurus where the Agile manifesto (Beck et al ., 2001), consisting of four values and 12 principles, was created.

The four Agile manifesto values 1

We value individuals and interactions over process and tools. However, we should still use best practice to provide the Agile teams with sources of guidance (such as Best Management Practice) that can be inspected and adapted.

2

We value working product over comprehensive documentation . However, we should still provide documentation where it adds value to the customer. Best Management Practice provides an adaptable set of documents which we may or may not apply, depending on the situation.

3

We value customer collaboration over contract negotiation . This means that teams consist of both ‘customers’ and ‘suppliers’ working together and there is no traditional ‘command and control’ management in the middle acting as an obstacle to communication and delivery. Agile managers who act as facilitators and removers of obstacles are still required (but not within the Agile selforganizing teams).

4

We value responding to change over following a plan. Within Agile we create plans; however, the plans we create have the ability to be Agile and to change in line with the delivery environment.

The twelve Agile manifesto principles 1

Our highest priority is to satisfy the customer through early and continuous delivery of valuable product.

2

We welcome changing requirements, even late in development. Agile processes harness change to the customer’s competitive advantage.

3

We aim to deliver working product frequently, from within a couple of weeks to a couple of months, with a preference for shorter timescales.

5

4

We believe that business people and developers must work together throughout the project.

5

We build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6

We believe that the most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7

Our primary measure of progress is the working product.

8

We promote sustainable development through Agile processes. The sponsors, developers and users should be able to maintain a constant pace indefinitely.

9

We enhance agility by paying continuous attention to technical excellence and good design.

10 We believe in simplicity – the art of maximizing the amount of work not done. 11 We believe that the best architectures, requirements and designs emerge from self-organizing teams. 12 At regular intervals, we reflect on how to become more effective, then tune and adjust our behaviour accordingly. For an Agile environment to be created, people and the organization must have the courage to implement the Agile values and principles in a disciplined way. These values and principles drive agility and the ability to gain the very significant benefits of being Agile. Pretending that Agile is in place while still doing the same as before (always the main risk when combining Agile with any other framework) is pointless as the Agile behaviours and thought processes will not be implemented and delivery will continue to fail. The major Agile frameworks are as follows: ■

Dynamic Systems Development Method (DSDM ®) (www.dsdm.org)

■

Lean Software Development (www.poppendieck.com)

■

Kanban (http://limitedwipsociety.ning.com)

■

Scrum (www.scrumalliance.org)

■

eXtreme Programming (www.threeriversinstitute.org)

■

Agile Project Management (www.dsdm.org).

4

Agile – why now in the public sector?

Agile has been implemented within the private sector software industry since the early 1990s. It is now the standard for software delivery and management in the private sector. On 2 March 2011 the Institute for Government (IfG) published a paper entitled ‘System error: fixing the flaws in government IT’. This paper proposed a two-pronged solution to the problems with government ICT and the well-publicized failures to address those problems over recent years, and made recommendations © The Stationery Office 2013

6


for ‘a common platform’ and the implementation of Agile solutions. Figure 3 compares the Agile approach with traditional tools and methods. Almost one month later, the Cabinet Office, incorporating many of the IfG’s recommendations, published the Government ICT Strategy (Cabinet Office, 2011) which included a commitment to a variety of actions associated with the adoption of Agile ICT practices over the following 24 months. To quote from the IfG report:

‘Numerous reports and articles have pointed to a long list of problems: chronic project delays; suppliers failing to deliver on their contractual commitments; not designing with the user in mind; divergent costs for simple commodity items; incompatible systems; the high cost of making even basic changes; ‘gold plating’ IT solutions; and failing to reuse existing investments. Moreover, there is a critical dependence on legacy systems, and the need to deal with interoperability between these systems increases cost and complexity. ‘These problems have been widely rehearsed but proved stubbornly resistant to change. This is because government’s approach to IT is fundamentally flawed for our times. ‘Traditional linear IT project approaches, like the V-model and Waterfall, assume that the world works in a rational and predictable fashion. Specifications are drawn up in advance, ‘solutions’ are procured, and then delivery is managed against a pre-determined timetable. In reality, priorities change rapidly and technological development is increasingly unpredictable and non-linear. Most government IT therefore remains trapped in an outdated model, which attempts to lock project requirements up-front and then proceeds at a glacial pace. The result is repeated system-wide failure.’

Traditional approach

Agile approach

Complete solutions

Functional modules

Linear development process

Short iterations

Lock down change

Experimentation, improvement and reprioritization

Users specify all requirements at start

Users embedded throughout the process

Figure 3 Traditional vs Agile approaches Source: Institute for Government ( 2011)

It is this document from the IfG that has initiated a drive for agility across the public sector (note that though the IfG report is directly criticizing the Waterfall model, the Best Management Practice frameworks do not mandate Waterfall). © The Stationery Office 2013

The OGC Gateway™ may be problematic in an Agile environment, but it doesn’t need to be. It is part of the integrated assurance framework in the UK public sector and, together with project assurance reviews, it provides repeatable checkpoints that ask, ‘Are we doing the right things in the right way?’ Hence the Gateway can be used to ensure that the project is implementing Agile effectively. Programmes and projects are being delivered in a changing world; this is especially true of IT projects where we cannot tie everything down in documents at the outset. The solution therefore needs to evolve to take account of the changing environment around that delivery. There are now numerous examples of Agile within the public sector and these are increasing all the time.

5

Agile and the Best Management Practice framework

The UK government has recognized the need for fundamental change within its delivery and management practices. This is great news and long overdue. If Agile is implemented robustly and correctly it will make a huge contribution to delivery success with the UK government. That is a big ‘if’, as there are many examples of failed so-called Agile implementations. These include ‘Fragile Agile’ (Agile without discipline, which leads to fragile implementations that may work for a little while but soon fail; this is known in the IT world as ‘hacking’), and ‘WAgile’; this is Waterfall masquerading as Agile by changing the terminology while retaining all the existing bad practices. Agile itself is a collection of highly disciplined management and delivery frameworks involving the ruthless removal of process and documentation that do not demonstrably add value to the customer. Another misconception is that Best Management Practice mandates old-style management behaviour, such as command and control, and document-driven communication. It doesn’t. However, Best Management Practice is often implemented by old-style command-and-control managers who think that documents must be created either to enable communication or to ensure that when things go wrong they cannot be blamed as they have produced ‘their documents’. Individual Agile teams (one team is around 3–9 people), on the other hand, are multidisciplinary, communicate face to face, and succeed or fail together. It is also a danger in the Agile world that commandand-control managers just implement WAgile as described above. We have the opportunity within Agile to break this traditional management and delivery mindset and enable people to use the Best Management Practice frameworks as they were designed, with flexibility and an ‘inspect and adapt’ approach. It is a huge mistake to just throw away the wealth of experience that resides within Best Management Practice, thinking that it forces Waterfall or command-and-control thinking.


Agile values and principles

Best Management Practice knowledge cube

Agile management frameworks Agile delivery frameworks

7

ITIL Inspect and adapt

M_o_R MSP PRINCE2 Etc...

Figure 4 Agile frameworks and the Best Management Practice knowledge cube Source: Peter Measey, RADTAC

Figure 4 shows how within complicated, complex or anarchic environments Agile frameworks must be at the core of management and the delivery of outcomes, all wrapped within Agile values and principles. The Agile values, principles, management and delivery frameworks must be implemented courageously and with discipline to be effective. Courage is required because human beings do not like or welcome change. Our reaction to change is typically either anger or derision; therefore the people who drive Agile transformational change must have the courage to do it correctly. Discipline is required because Agile frameworks do not provide a plethora of processes and documents but a disciplined core framework within which inspection and adaptation occur. Agile teams must have the discipline to follow Agile even though it may be difficult for them to do so. The Agile frameworks should be kept apart from other frameworks and be as simple as possible to understand. There is a direct relationship between the complexity of a method framework and how much people use it. The more complex the method framework, the less people will use it as they haven’t enough time or motivation to understand it in order to use it effectively. The definition of Agile must be kept as simple as possible. The Agile mindset is mandated across all management and delivery teams and is at the core of how the organization operates. However, Agile teams still need to do a professional job within their area of expertise. This is where the ‘knowledge cube’ is essential. The knowledge cube could be a coach who transfers skills and experience to the team, or a set of written-down, learned best practices as expressed within the Best Management Practice framework.

For example, if it is assumed that no team worker is perfect within their area of working (for example, service management) then it would seem reasonable to support the team with some guidance that they can then inspect, adapt and utilize as appropriate (for example, ITIL). If there is no knowledge cube, then teams must develop their own approach, which can be extremely slow and involve a huge duplication of effort. Ideally, teams should include intelligent, motivated human beings with access to learning from others which they can inspect and adapt appropriately. Not to trust people to do this demonstrates a lack of faith in the competence of those working in delivery and management. Managers must show confidence in their workforce, and trust them to use the frameworks effectively. Within the knowledge cube there is a difference between standards (which are audited and typically legally mandated) and guidelines. Agile is suspicious of standards, as they lead to non-Agile thinking, but welcomes guidelines, which help and support the delivery teams. Too many standards that are not legal or regulatory can stifle ingenuity and innovation. They can also indicate a lack of trust in the team’s professional capabilities. However, standards are needed to enable future-proofing and maintainability, and therefore they must be applied with care. On the other hand, having more guidelines means that more reference material is made available to the teams, to inspect and adapt to their approach. In this way the teams will be best able to meet the needs of the environment within the Agile values, principles and frameworks.


8

6


Agile transformation

Any organization transforming to Agile must implement Agile values, principles and practices at the heart of its delivery and management philosophy, then inspect and adapt from bestpractice guidance where required. Agile thinking is not a ‘quick fix’. Transforming any organization to an Agile way of working is not about just ‘doing’ Agile, it is about changing the culture of the delivery and management people to ‘being’ Agile. Implementing the significant Agile mindset change required within organizations with an ingrained Waterfall and command-and-control mentality is not easy, but it is attainable and indeed essential in order to deal with the problems experienced when delivering in the public sector. It is tempting to think of Agile transformation as a revolution. However, revolutions are a very high-risk way of transforming anything. Evolutionary change is far safer for any organization and creates a much more sustainable transformation. This is why we see evolutionary change demonstrated across nature, which naturally organizes itself to the most effective delivery and management structures based on the environment. Evolutionary change ensures the continuation of a sustainable, strong business, whereas infrequent revolutionary change puts the whole business at significant risk and can be hugely disruptive. There are many ‘method fundamentalists’ who will espouse revolution as the only way to change to their method. However, there are far fewer who will say how to manage the revolution in a way that protects the business or who will still be around after the revolution they have initiated falters.

Evolution can be revolutionary (for example, the dinosaurs were removed from the earth almost immediately); however, it is rare for such a strong business case (for example, an asteroid) to exist to enable that type of revolutionary transformation. In most organizations transformation must be evolutionary to ensure that business continuity is protected. It is easy for some experts to identify what is wrong with Agile, or for others to identify what is wrong with Best Management Practice, as anyone can identify the negatives. But to create evolutionary transformational change we need to identify the following: ■

Where are we now?

■

Where do we want to be, at what points in time, and for what reasons?

■

How are we going to get there? – What needs to coexist during the continuous

transformational journey? – What will remain at this time on the evolutionary

transformational journey? – What can safely be replaced by something that

demonstrably adds more value? Transformational change within the public sector can only be evolutionary; this is especially true when considering essential public services that are paid for with public money and the size and complexity of the public sector. The only way the public sector could be transformed in a revolutionary way is if a business case existed to do so, like the asteroid that killed off the dinosaurs. However, not only would the creation of this business case be extremely unlikely; initiating revolutionary change in an organization of the complexity of the public sector would also be extremely risky.

Transition management Vision; objectives; benefits; plan; transition team; measures; stakeholders; culture

Support Initial pilot/s and beyond; coaching; assurance; reviews; interim PM and delivery resources

Training and education Training needs analysis; training organization and portfolio; tailor and deliver training

Processes and standards Tailor and integrate selected methods/practices; develop; deliver; communicate; refine

Related capability building Identify and develop, e.g. portfolio; governance; suppliers; HR; infrastructure; skills etc. Figure 5 Iterative and incremental: evolutionary transformation Source: Peter Measey, RADTAC



9

Evolutionary change can be triggered by five drivers of change implemented in an iterative and evolutionary way, as Figure 5 shows. Agile transformations are implemented using Agile frameworks as transformations are inherently complex. Evolutionary change must not be used as an excuse for no change or little change; it means striving for added-value change, rather than striving to keep the status quo.

7

Dynamic Systems Development Method

Up to this point Agile has been discussed generically. To be more specific it is necessary to pick one Agile framework at a time when considering specific parts of Best Management Practice. The remainder of this White Paper will discuss Agile in the context of the Dynamic Systems Development Method (DSDM ®) as this has been used successfully numerous times with the Best Management Practice framework within the public sector. This paper does not intend to describe DSDM or any other specific Agile framework in detail; however, it does need to ‘pen sketch’ the basics. DSDM aligns with the Agile manifesto values and principles described in section 3. It builds on them by providing an overall delivery and management philosophy, supported by principles which in turn are supported by process, people, products and practices, as shown in Figure 6. The DSDM philosophy is: ■

Projects must be aligned to clearly defined goals

■

Focus must be on early delivery of real benefits to the business

■

To be successful, there must be:

Figure 6 The structure of DSDM Atern Source: ©2007 Dynamic Systems Development Method Limited. All rights reserved.

DSDM is not the only answer for government Agile or for integration with the Best Management Practice frameworks; there is no single Agile framework that provides all the answers. However, DSDM does have some very attractive qualities for public sector Agile and Best Management Practice alignment: ■

It was developed by a not-for-profit consortium.

■

The DSDM consortium is not controlled by any single body; it is a group of people and organizations who drive DSDM forward because they believe in it.

■

More work has already been performed within DSDM to align with Best Management Practice than any other Agile framework (DSDM was one of the major contributors to the IfG report).

■

It is evolving along a path that supports stronger alignment with the evolving Best Management Practice.

■

It provides a ‘corporate Agile’ framework that is more suited to large, complex, project-driven environments (such as the public sector).

■

It is designed to be non-method fundamentalist; to be implemented as a full framework, or integrated with other Agile frameworks (such as Scrum, XP, Kanban or any other Agile framework).

– Key stakeholder understanding of business objectives – Empowerment to the appropriate level – Collaboration to deliver the right solution – Delivery on time, according to business priorities – Stakeholders willing to deliver a fit-for-purpose solution – Acceptance that change is inevitable.

The DSDM principles (DSDM Consortium, 2008) are as follows: ■

Focus on the business need

■

Deliver on time

■

Collaborate

■

Never compromise quality

■

Build incrementally from firm foundations

■

Develop iteratively

■

Communicate continuously and clearly

■

Demonstrate control.

Sections 8 to 14 of this White Paper will give a high-level overview of Agile and the contents of the Best Management Practice portfolio. Each section will start with a definition of what the Best Management Practice element actually is. Sections 8 to 14 do not aim to describe exactly how to customize each element of the Best Management Practice framework to work within an Agile environment; that would be prescriptive and against the principle of enabling professional teams to inspect and adapt. Rather, they aim to demonstrate that the


10


Best Management Practice frameworks can be used as an excellent knowledge cube of learned best practice to support Agile delivery and management where required.

ITIL is very suited to Agile and vice versa. The evolution of ITIL can be delivered with an Agile mindset and can engender a very Agile service organization using ITIL as the knowledge cube for service management.

8

One of the key skills to cultivate within an Agile ITIL organization is the ability to deliver ‘vertical slices’ of working software frequently rather than waiting long periods for largescale service delivery. It is also essential, as with any Agile organization, to ensure the other Agile values and principles are enabled within the ITIL-driven service organization. This is not easy (appropriate tooling is essential), but attainable.

Agile and ITIL

First, a quote from ITIL Service Strategy (Cabinet Office, 2011):

‘ITIL is used by many hundreds of organizations around the world and offers best-practice guidance to all types of organization that provide services. ITIL is not a standard that has to be followed; it is guidance that should be read and understood, and used to create value for the service provider and its customers. Organizations are encouraged to adopt ITIL best practices and to adapt them to work in their specific environments in ways that meet their needs.’ ITIL is a very detailed framework that provides beginning-to-end guidance on how requirements are received from customers and then delivered as services back to customers. It deals with the whole value chain of how to shape a service delivery organization from definition of a service strategy through to service design, service transition and service operation. ITIL expects evolutionary change of the service via continual service improvement. Service design, service transition and service operation continually evolve around the service strategy (see Figure 7).

9

Agile and PRINCE2

PRINCE2 is a project management approach that can wrap around various delivery approaches. Waterfall is just one such approach, PRINCE2 providing the necessary project governance. Although people typically criticize PRINCE2 in an Agile context by using arguments that are based on a Waterfall delivery style, PRINCE2 does not mandate this delivery style. Agile can coexist with PRINCE2 as long as PRINCE2 is tailored; in fact tailoring is one of PRINCE2’s seven guiding principles. To quote Managing Successful Projects with PRINCE2 (Office of Government Commerce, 2009):

‘The purpose of PRINCE2 is to provide a project management method that can be applied regardless of project scale, type, organization, geography or culture. This is possible because PRINCE2 is principles-based. The seven PRINCE2 principles can be summarized as:

Continual service improvement

Service transition

Service strategy

Service design

Service operation

1

Continued business justification

2

Learn from experience

3

Defined roles and responsibilities

4

Manage by stages

5

Manage by exception

6

Focus on products

7

Tailor to suit the project environment.

It is the adoption of these principles that characterizes whether a project is using PRINCE2, not the adoption of processes and documents alone.’ There is nothing in these principles that forces a Waterfall, and nothing that breaks Agile. DSDM and PRINCE2 can fit together well because DSDM is the Agile project delivery framework – the only major Agile framework that specifically operates at the project management level.

Figure 7 The ITIL service lifecycle © Crown copyright 2011. Reproduced under licence from the Cabinet Office – ITIL Service Strategy , Figure 1.1



Wherever PRINCE2 is mandated, PRINCE2 and DSDM should be integrated. Sadly PRINCE2 is often implemented with an ‘oldstyle’ management mindset even though it does not recommend this. When using PRINCE2 within an Agile environment the following traditional behaviours must be disabled: ■

A ‘contract’ being created by a Waterfall-driven specification and then delivered through a ‘project manager’ who becomes a contract negotiator between customer and supplier. The Agile team consists of customers (for example, the business ambassador) and suppliers (for example, solution developers) working together to achieve clearly defined goals.

■

Agile project managers do not ‘command and control’; they facilitate, enable and protect delivery teams.

■

Agile project boards do not command and control project managers; they facilitate, enable and protect them.

■

Estimates are forecast guesses based on the best information available at the time (i.e. baseline plans). Forcing delivery against a fixed contract defined early in the project will achieve a significantly incorrect outcome if the delivery environment is changing.

■

Delivery is made in the form of short vertical slices of working software (or product), not in long stages.

The Agile manifesto and principles plus DSDM philosophy and principles must also be enabled. The list above is not meant to be exhaustive; however, it does indicate where behaviours in the usage of PRINCE2 need to be inspected and adapted to enable Agile.

11

Where PRINCE2 is not mandated, Agile project management or AgilePM should be considered. This is a project management method based on DSDM Atern and a certification process owned by the DSDM Consortium and APMG (Richards, 2007; DSDM Consortium, 2010); it is therefore already customized for Agile projects.

10 Agile and Managing Successful Programmes According to Managing Successful Programmes (MSP) (Cabinet Office, 2011):

‘MSP is highly suitable for business transformation and political/ societal change, being an approach designed to accommodate high levels of complexity, ambiguity and risk. Adopting a programme approach is not necessary where something new is delivered within the existing business model. Incremental improvements to an existing product or service would not normally warrant a programme approach, nor is a programme relevant in organizing all the projects within an enterprise solely for prioritizing and allocating resources. Organizations have successfully used MSP, or elements of it, in such situations; however, the programme management framework of MSP is primarily designed to cater for leading and managing transformational change.’

Remaining aligned with corporate strategy c e n e i r c e e a n p r x e s u a s n t m d m e o n r a e f t y a g n g a l i a n i u m n r Q a L e

D e s i c g o n h i n e g r e a n n t d c d a p e a l v b i e i l r i i t y n g a

e t su n is e d e m n a a g s k n i a R m

Programme organization V i s i o n

Identifying a Programme

Defining a Programme

i s h b l a t E s Delivering the Capability Realizing the

T h e b u s i n e s s c a s e

Closing a Programme

P la n n in c o n g a nd tr o l A d d i n g v a l u e

L e a d i n g c h a n g e

e r Benefits a w d p e n e i v a r e p R

t h M e T a n r a a n g c i h n e g s

L e e st a n a d g k e a e r g h s h e o ip m ld e e a n n r d t

t t s n i f m e e e n e g B n a a m

g n t i a i c n u e m r m tu o fu c d e r n t a t g e in a b n i o is v n E

s i g n t d e r y n i r p v e B l u e d d e l i a n

a n d i t s f e b e n m e h e n t t o t h o in g r e a t s s u t h F o c

Figure 8 MSP framework and concepts © Crown copyright 2011. Reproduced under licence from the Cabinet Office – Managing Successful Programmes , Figure 1.1


12


It is not realistic to expect Agile frameworks on their own to provide adequate guidance to deliver within the scope that MSP operates. There is no Agile programme framework that is widely in use at the moment so this is an area where the Agile mode of operation must be supported by a suitable framework, such as MSP.

R princ ip l es M o_ _

M _o _R a pp r R is k oa ch r e gi s t er

b ed E m

and r ev i ew

a c h p p r o _ R a M_ o I s s u e t e r r e g i s

Implement Identify

Figure 8 shows that MSP is based on the following: Communicate

■

The MSP principles (outer ring)

■

The MSP governance themes (second ring)

■

The MSP transformational flow (inner circle).

Plan

Figure 8 looks very complicated, and it is. Delivery of transformational business change is a complicated subject; there are very few individuals who have delivered true transformational change throughout organizations. MSP must be inspected and adapted as appropriate to support Agilebased programme delivery. MSP states clearly that it can be fully tailored, like other Best Management Practice frameworks. The important point to emphasize within MSP is that all parts of the framework need to be used to ensure success. Within an Agile-driven programme the core Agile values are adhered to, and MSP is inspected and adapted ruthlessly based on added value. So an Agile manager or team would remove any parts of MSP that do not add value in the specific environment in which the programme is running. This could be interpreted as counter to the values of MSP; however, in the Agile world it is up to the professionals using knowledge cubes (such as MSP) to do an excellent job. MSP can also be very useful when running large organizational transformations to Agile ways of working. The largest, most complex Agile transformations could utilize Lean (ww w.lean.org) to optimize the business value to an Agile value chain; the Lean optimization would be delivered by an Agile expression of MSP.

11 Agile and Management of Risk Starting with a quote from Management of Risk (M_o_R) (Office of Government Commerce, 2010):

‘The purpose of the Management of Risk (M_o_ R) guide is to provide a framework for risk management that can be applied to any organization regardless of its size, complexity, location, or the sector within which it operates. This is possible because M_o_R is principles-based. The M_o_R principles are informed by corporate governance principles and the international standard for risk management ISO 31000: 2009. They are intended to guide rather than dictate so that organizations can develop their own policies, process, strategies and plans to meet their specific needs.’


Assess

h o a c p p r m e n t a _ a g e o R M_ m a n l i c y k s i p o R h c a or p p a R _ o _ M

t n e m e g a n a m s k i R

M _ R i s o _R k m a p p a n r o s t r a g e a c h at e m e g y n t

e id u g ss e c ro p

Figure 9 M_o_ R framework © Crown copyright 2010. Reproduced under licence from the Cabinet Office – Management of Risk: Guidance for Practitioners , Figure 1.1

From this description, it is possible to tell that M_o_R expects to be inspected and adapted based on the reality of the environment. Figure 9 provides a synopsis of M_o_R. Within any Agile delivery or management team there is a need to continually assess risk. The robustness of the approach used depends on the complexity of the risks to be treated, terminated, tolerated or transferred. M_o_R provides a solid risk management framework for Agile deliveries. It can be added to, or certain aspects of it can be removed, dependent on need. The main risk for any Agile team is that the Agile values and principles are not adhered to. This could be because either the team or the organization doesn’t have the courage to completely make the change to Agile, resulting in WAgile or Fragile Agile. M_o_R provides the organization with a mechanism within an Agile transformation to manage those risks.

12 Agile and Management of Value Quoting from the Best Management Practice guidance Management of Value (MoV) (Office of Government Commerce, 2010):

‘[There are] seven fundamental principles underpinning MoV: 1

Align with organizational objectives

2

Focus on functions and required outcomes

3

Balance the variables to maximize value

4

Apply throughout the investment decision


5

Tailor to suit the subject

6

Learn from experience and improve

7

Assign clear roles and responsibilities and build a supportive culture.

13 Agile and Portfolio, Programme and Project Offices

For MoV to be effective, it is essential to apply the principles introduced. If these principles are not followed, MoV is not being properly used. They are intended to provide clear and concise guidance to senior management and users alike. They are not intended to be prescriptive but to provide a clear framework for individuals and organizations to evolve their own policies, processes and plans to suit their particular needs.’ In line with the other frameworks within Best Management Practice, MoV has a set of principles that should be aligned with and then inspected and adapted based on the environment. MoV focuses on what is being delivered and the cost of delivering, not on how it is being delivered. Thus it keeps the focus on what of value is being delivered. MoV helps define ‘value’; a word that is difficult to define because everyone judges value very differently. A risk in Agile when implemented incorrectly is that the teams end up delivering products that are not aligned with the overall value required by the whole business. MoV provides a body of knowledge to help teams to constantly focus on value across the business and not just related to the products of one single team. MoV is clear that it should be scaled according to the size, complexity and strategic importance of the environment or project to be delivered, and indeed it states this repeatedly. It provides a knowledge cube from which to inspect and adapt guidance for value management within Agile.

Business change strategy Are we doing the right things?

13

How does Best Management Practice define the portfolio, programme and project offices that facilitate effective project management? The guidance is encapsulated in Portfolio, Programme and Project Offices (P3O) (Office of Government Commerce, 2008), which states:

‘The purpose of the Portfolio, Programme and Project Offices (P3O) guidance is to provide universally applicable guidance, including principles, process and techniques, that will enable individuals and organizations to successfully establish, develop and maintain (or in some cases re-energize) appropriate support structures that will facilitate: • Informing senior management’s decision-making on prioritization, risk management, and deployment of resources across the organization to successfully deliver their business objectives (portfolio management) • Identification and realization of outcomes and benefits via programmes and projects • Delivery of programmes and projects within time, cost, quality and other organizational constraints’ Figure 10 describes the focus of implementing portfolio, programme and project support offices. The P3O teams can be very helpful when transforming to an Agile way of working. However, they can also be a huge barrier to implementation of Agile.

Validation

Business change value Are we getting the business benefits?

Business change governance Business change design Are we doing things the right way?

Verification

Business change delivery Are we getting things done well?

Figure 10 O verview of P3O Source: DSDM Consortium (2010)


14


In an Agile organization it is perfectly acceptable to have people or teams that support delivery and management (advisers, users or specialists) as long as they act as enablers and do not block change by insisting that numerous documents be created that deliver no value to the customer.

Senior management commitment

Energized change culture

When implementing P3O within an Agile environment it is essential that the P3O structures are designed with Agile management and delivery in mind and that the people within the P3O have the courage and discipline to be Agile.

Energy

If there is a combination of an Agile organization and a Waterfall or command-and-control P3O the cultures will clash significantly and the P3O will be a significant obstacle to Agile transformation. However, if P3O is driving Agile behaviours throughout the business at the portfolio, programme and project level then P3O should be a huge enabler of Agile. The P3O guidance within Best Management Practice acts as a useful knowledge cube for Agile P3O if required (DSDM Working Group led by Julia Godwin); however, Agile people must be put into the P3O to ensure the values and principles are adhered to.

Portfolio definition

Governance alignment

Portfolio office

Portfolio delivery

Strategy alignment

Figure 11 The portfolio management model © Crown copyright 2011. Reproduced under licence from the Cabinet Office – Management of Portfolios , Figure 2.1

14 Agile and Management of Portfolios

15 Conclusion

Best Management Practice describes Management of Portfolios (MoP) (Office of Government Commerce, 2011) as follows:

■

Agile is a set of management and delivery frameworks that enable products to be delivered within complicated, complex or anarchic environments (such as the public sector).

■

To be Agile, organizations and the people within them must have the necessary courage and discipline.

■

Agile does not expect team members to be perfect or have a complete level of knowledge. Therefore they need support from ‘knowledge cubes’, i.e. sources of best practice. These can be provided by either human coaches or best-practice frameworks (implementation of both is most effective).

■

The Best Management Practice frameworks provide an excellent knowledge cube, built up by many very experienced people who have worked in some of the most complex environments in the world.

■

Best Management Practice is largely designed to be inspected and adapted. Therefore it is possible to implement Agile thinking (values and principles) at the heart of delivery management within any organization and use Best Management Practice as a knowledge cube.

■

Any Waterfall legacy found within Best Management Practice should be either removed or highlighted to show that it is only suitable for simple environments within which change won’t be experienced.

‘Portfolio management is a coordinated collection of strategic processes and decisions that together enable the most effective balance of organizational change and BAU [business as usual]. The portfolio management model below highlights how the portfolio management principles provide the context within which the portfolio definition and portfolio delivery cycles, and their constituent practices, operate.’ ‘The portfolio management principles represent the foundations upon which effective portfolio management is built; they provide the organizational environment in which the portfolio definition and delivery practices can operate effectively. These are generic principles – the way in which they are applied must be tailored to suit the organizational circumstances whilst ensuring that the underlying rationale is maintained.’ As is standard within Best Management Practice, MoP is designed to be inspected and adapted to the environment. There is nothing within MoP that is anti-Agile if it is used appropriately. MoP acts as a valuable knowledge cube within Agile environments. Like Agile, MoP recognizes that it is about people and their interactions. This concept is enshrined in the energized change culture (one of the five principles of the portfolio management model shown in Figure 11) where success is realized only if the people working for the organization are engaged, focused on the appropriate goals and feel a sense of working together as one team.


This White Paper has made the following key points:

Agile encourages the creative implementation of Best Management Practice in the way it was designed to be used. It enables focused delivery of the right outcomes, on time and


cost, even when the environment is complicated, complex or anarchic. A good summary is provided in the Institute for Government (2011) repor t:

‘Like any management innovation, there are plenty of challenges in adopting an Agile approach. We have identified three in particular: changing organisational cultures to support Agile techniques; governance issues, including approval processes and Gateway reviews; and commercial complications, particularly in relation to procurement.’ Implementing Agile within the public sector will not be easy. However, if an evolutionary approach is taken in order to continually improve over time, Agile within the public sector is definitely attainable. Given the size, diversity and complexity of the public sector it is not realistic that it will change in a revolutionary way. Some elements of governmental working – those which promote Waterfall or old-style command-andcontrol management – should be removed. Learned best practice, such as Best Management Practice, should remain and be used, but it needs to be tailored to the specific context, nature of the organization, industry sector, and nature of the project or programme in an ‘inspect and adapt’ way. The Best Management Practice frameworks continually evolve in the same way as the Agile frameworks. One final quote from the Institute for Government (2011) report:

‘Implementing Agile will require support from senior level leaders as well as the IT communities in each department to be successful. It will also require training, tools and a clear demonstration that it works.’ This is absolutely true; Agile will be implemented only if the public sector has the courage and discipline to do it correctly. This will require significant training, support and retooling. The main risk is that public sector ‘Agile’ deliveries will be initiated but that people will not have the courage to make the change. All this will do is add another layer of bureaucracy, and failure will still occur. However, change must be implemented with public sector delivery and management to enable success.

15

References Beck, K., Beedle, M., Bennekum, Arie van et al . (2001). Manifesto for Agile software development. www. agilemanifesto.org Cabinet Of fice (2011). Government IT Strategy . www. cabinetoffice.gov.uk/content/government-ict-strategy Cabinet Of fice (2011). ITIL Service Strategy . The Stationery Office, London. Cabinet Of fice (2011). Managing Successful Programmes. The Stationery Office, London. DSDM Consortium (2008). DSDM Atern: the Handbook . DSDM Consortium, Ashford, UK. DSDM Consortium (2010). Agile Project Management Handbook . APMG, High Wycombe, UK. Institute for Government (2011). System error: fixing the flaws in government IT. http://www.instituteforgovernment.org.uk/publications/systemerror Office of Government Commerce (2009). Managing Successful Projects with PRINCE2. The Stationery Office, London. Office of Government Commerce (2010). Management of Risk: Guidance for Practitioners. The Stationery Office, London. Office of Government Commerce (2010). Management of Value. The Stationery Office, London. Office of Government Commerce (2011). Management of Portfolios. The Stationery Office, London. Richards, K. (2007). Agile Project Management: running PRINCE2 projects with DSDM Atern. The Stationery Office, London. Royce, W. (1970). Managing the development of large software systems. Proceedings of IEEE WESCON 26 (August): 1–9.

Whether the public sector decides to implement true Agile and not just WAgile or Fragile Agile remains to be seen.

‘The definition of insanity is doing the same thing over and over again and expecting different results.’ Albert Einstein (attributed)

Note: In the Agile manifesto values and principles listed in section 3 the word ‘software’ from the original definition has been changed to ‘product’ throughout as Agile is now used in diverse delivery environments, not just in software.


16


About the author Peter Measey, chief executive officer of RADTAC Limited, has over 30 years’ experience as a project and programme manager, consultant, facilitator, trainer and coach. Peter has specialized in the Agile market since 1994. Peter works with numerous global organizations, has written many White Papers and has presented at numerous conferences on the subject of Agile. Peter is a certified DSDM trainer, DSDM board director, member of the BCS Agile Committee, Project Management Institute Agile certified practitioner, certified Scrum trainer, certified PRINCE2 practitioner and is certified within the Lean IT Foundation.

Acknowledgements Sourced by TSO and published on www.best-managementpractice.com Our White Paper series should not be taken as constituting advice of any sort and no liability is accepted for any loss resulting from use of or reliance on its content. While every effort is made to ensure the accuracy and reliability of the information, TSO cannot accept responsibility for errors, omissions or inaccuracies. Content, diagrams, logos and jackets are correct at time of going to press but may be subject to change without notice. © Copyright TSO. Reuse of this White Paper is permitted solely in accordance with the permission terms at http://www. best-management-practice.com/Knowledge-Centre/White-Papers/ A copy of these terms can be provided on application to Best Management Practice White Paper Permissions, TSO, St Crispins, Duke St, Norwich, Norfolk, NR3 1PD, United Kingdom.


Trade marks and statements OGC Gateway™ is a registered trade mark of the Cabinet Office. The OGC Gateway Process examines programmes and projects at key decision points in their lifecycle to provide assurance that they can progress successfully to the next stage. The OGC Gateway Reviews deliver ‘peer reviews’ in which independent practitioners from outside the programme/project use their experience and expertise to examine the progress and likelihood of successful delivery of the programme or project. For more information see http://webarchive.nationalarchives.gov. uk/20100503135839/http:/ww w.ogc.gov.uk/what_is_ogc_ gateway_review.asp The Swirl logo™ is a trade mark of the Cabinet Office. ITIL® is a registered trade mark of the Cabinet Office. PRINCE2® is a registered trade mark of the Cabinet Office. MSP® is a registered trade mark of the Cabinet Office. M_o_R® is a registered trade mark of the Cabinet Office. MoP ® is a registered trade mark of the Cabinet Office. MoV® is a registered trade mark of the Cabinet Office. P3O® is a registered trade mark of the Cabinet Office. DSDM® and Atern® are registered trade marks of Dynamic Systems Development Method Limited. Best Management Practice is the overarching brand that umbrellas multiple Cabinet Office best practice products. The internationally renowned portfolio is adopted as best practice through high quality training, publications, software tools and consultancy for portfolio, programme, project, risk, value and service management disciplines.

Agile and the Best Management Practice Framework Within the Public Sector

Recommend Documents