Configuration of the Agile process

The Codeworks DEV Programme was conceived as a vehicle for getting innovative IT ideas to market. Funded from a mix of both public and private sources, the programme has gone on to encompass hundreds of projects, each of which can be at a different stage of development. Such projects tend to be characterised by an emergent scope – exactly the sort of thing that Agile Methods are known to handle well. Yet there was also a narrative (and somewhat linear) flavour to this work. Project stakeholders are guided from problem discovery to problem definition, and from there through solution development to solution delivery (the “4 D’s”).

Our hope was that the new version of PRINCE2 released in 2009 would be scalable enough to accommodate this simple narrative model. We also hoped that we could further the headway that others had made with DSDM previously [Richards, 2007], [Barron, 2003]. The scope of method configuration therefore included a number of considerations. We needed a programme-level approach to PRINCE2-Agile configuration, and not just as a project-specific one. Also we sought a more orthogonal and standards based solution than can be remedied by “mixing and matching” from parts of an assumed methodological continuum.

We decided to handle Agile-PRINCE2 process configuration in three stages:

1) Firstly, the “4 D’s” would have to be fleshed out with the details of the business process. For example, the “Discovery” stage includes discrete steps for identifying any new IP behind a candidate project, the likely economic benefits, the business case (with repeated checks for project viability), desk based market research, and other such details of project inception. We decided to use a simple flowchart grammar to model these flows.

Also, the business process model would need to be rationalised along broadly Agile lines. We decided to keep the Delivery Stage free of DEV specific business flows until we had enough information to make a firm decision on the operational characteristics of this phase. We therefore constrained its immediate scope to a dialogue between client, project manager, and supplier based on iterative-incremental delivery.

2) It was already established that PRINCE2 was going to be a key process component, representing as it does a defensible and widely accepted standard for project management. We therefore arranged PRINCE2 Practitioner training for all DEV team members. This gave us the vocabulary needed to define DEV’s roles and responsibilities in PRINCE2 terms, as well as management and work products (see Figure 1), and to map each of the “4 D’s” to the PRINCE2 process.

Figure 1

3) Thirdly, we needed a process management tool that would support DEV stakeholders – not just project managers, but also clients and suppliers – throughout the prototyping of each project. A variant of MoSCoW analysis [Clegg, 2004] would synchronise expectations across a common acknowledgement of scope. The initial requirements were:

a. This tool would have to support Agile Methods and be PRINCE2 compliant

b. It should be configurable in the sense that DEV’s own business process flows should not be hard coded.

c. It should be possible to customise process flows as necessary on a per-project basis

d. It should be possible to embed timeboxes and MoSCoWing activities at any point in a flow.

e. Requirements should be definable for each project

f. MoSCoWing of requirements and allocation to timeboxes would have to be fully supported. This would clearly be important during the Engineering Phase (DEV Delivery). There might also be opportunities for MoSCoW analysis when negotiating with market research companies in the Feasibility Phase (DEV Discovery).

No satisfactory tool was available as a COTS package. Although potential commercial solutions did exist, they would have required such extensive customisation that it really made more sense to develop a system from scratch. The application, which is now nearing completion, has been internally named “DEV Folio” since it encompasses a portfolio of multiple projects. Codeworks DEV holds the I.P. of the application and we hope to open-source it at a future point.

We evolved an XML schema for defining workflows. Each step in a workflow may consist of sub-workflows, or (if a leaf node) will contain various data entry fields. Requirements capture, timeboxing, MoSCoWing, and document-generation features were architected as plug-ins to the basic workflow tool.

DEV Folio: a first look

Logging in to the application shows which projects in the program the user is currently participating in (see Figure 2). Note that we have applied MoSCoWing at even this high level. Candidate projects are inducted in batches over the course of the DEV Programme. We cannot handle all at once; we must have a means of prioritising them by importance and by their own inherent timescales. Each project on the DEV Programme is therefore given a MoSCoW rating. The “Musts” are those projects that we identify as making definitive contributions to the success of the programme and for which deferral to a later batch cannot be risked.

Figure 2

Clicking on the workflow of any particular project shows the high level process model defined for that project. Although the technical details are beyond the scope of this document, the Agile-PRINCE2 flows are customisable for each project if necessary.

Clicking on a project workflow shows the top level flow for that project (see Figure 4). This flow maps to the DSDM Phases of Feasibility, Foundations, Exploration, and Engineering as described earlier and summarised in Figure 3.

Figure 3

Figure 4

DSDM Phases are thereby represented by process boxes in a workflow. A key feature of DEV’s Agile approach is that these workflows can be nested. This allows configurability of each phase, since all workflows are defined as XML. The precise workflow that should be followed in each phase can therefore be adjusted to be project-specific.

Figure 5 shows a standard sub-workflow for the Feasibility (Discovery) Phase of a DEV Project. As each step is completed, it is annotated with a check. Decision points enable progress to appropriate branches. For decision points that have not yet been reached, the ensuing branches are greyed out.

Figures 5 and 6

 

Figure 6 shows the content of a leaf process. In this case “Invention Summary” does not contain any sub workflows. At this finest level of granularity, data must be entered.

A detailed description of each sub workflow, and the leaf nodes for data entry, is beyond the scope of this discussion. However it is worth examining the flow of the Engineering (Delivery) Phase in some detail. During Engineering, project velocity is maintained via a brisk and focused dialogue between stakeholders. The tools which are brought to bear are those of requirements elicitation, timeboxing, and the MoSCoWing of requirements. All of these are critical components of our approach.

In the default process configuration used for DEV projects, we include a precursory stage for preparation of the solution development team infrastructure. This is followed by a Delivery stage which is defined in terms of requirements capture, timeboxing, and MoSCoW dialogues. Then there is a project closing stage (see Figure 7).

Figure 7

Typically requirements entry, timeboxing, and MoSCoWing for a particular project are all done as part of a “Deliver” stage within Engineering. Clicking on the appropriate link will bring up appropriate screens for entering requirements (Figure 8), defining timeboxes (Figures 9 and 10), and MoSCoWing the requirements across timeboxes (Figure 11). Note that we consider timeboxes and iterations to be synonymous. This is a result of our experience in managing client and supplier expectations with escrow and billing cycles, and it represents a significant departure from DSDM.

Figures 8 and 9

Requirements are held in a flat list format, although it is possible (when editing a requirement) to upload a supporting document. This allows Use Cases to be supported.

Timeboxes (or iterations) are defined by start date and end date. Overlapping is permissible since work may be allocated to groups operating in parallel. We have included a separate date for reviewing the products of the iteration (i.e. the incremental release). This may not necessarily be the same day as the final day of the iteration, but it would normally be close to it.

Figures 10 and 11

The MoSCoWing of requirements is done on a timebox-by-timebox basis. All requirements are initially MoSCoWed as “Won’t”, which makes them available for inclusion in any timebox. Once a requirement has been included as a “Must”, “Should”, or “Could” for a particular timebox, then it will no longer be available for inclusion in other timeboxes.

It should be noted that a “Should” at timebox level is not necessarily a “Must” at the project level. We have found that project level “Musts” are fluid, and that higher level classifications are (in practice) driven by what happens at timebox level. As such, DEV Folio does not support the direct linking of timebox level MoSCoW classifications with project level ones. This has proven to be expedient, but it is also a departure from the usual approach to MoSCoW analysis, and we may revisit this issue in future publications.

MoSCoWing is a 3 way conversation between supplier, client, and project manager. The client will provide input on what should be done and when, and how important each item is. The project manager will then negotiate the spread across the available timeboxes with the supplier. Note that the difficulty and effort are entered for each requirement in the timebox during this discussion.

All “Musts” have to be delivered in order for the iteration to be considered a success. Any “Shoulds” or “Coulds” which have not been delivered can be amended to “Won’t” which frees them up for re-allocation to other timeboxes.

It can therefore be seen that the DEV implementation of the Delivery Stage represents a fairly canonical (albeit tool supported) realisation of the DSDM Engineering Phase. However, there was one supplementary modification which we made. This was the inclusion of a graph (a “Highlight Chart”) which tracks the implementation of requirements as they are dealt with (see Figure 12).

Figure 12

The Highlight Chart is risk driven, and leverages the product of difficulty and effort recorded during MoSCoWing to elicit a graph of project risk reduction. The sum of products represents 100% of the project risk; when the project is 100% complete, all risks will have been mitigated. Also, when the project has mitigated 50% of the total risks (expressed as difficulty x effort), then the project will be more likely to succeed than to fail.

We consider this risk-driven approach to more useful than Burndown Charts, which can mislead due to the varying granularity of requirements.

 

Management of Products

Our PRINCE2 configuration specifies of the roles, management, and work products we usually need (see Figure 1). As can be seen, this is somewhat more than the absolute minimum required for PRINCE2 compliance. This is because we have suppliers from outside organisations. These suppliers fulfil DSDM Team Lead and Solution Developer roles and are engaged and paid in fortnightly timeboxes. It is therefore beneficial to retain discrete work packages and not to conflate them with the plan.

The complete list of products are shown in Table 1, along with the DSDM Atern mappings we have identified.

 

PRINCE2 Product	DSDM Product(s) represented
Management Strategies (Communication, Configuration, Quality, Risk)	Delivery Approach, Delivery Control Pack, System Testing Strategies, Management Foundations
Outline Business Case	Outline Business Case, Feasibility Assessment, Business Vision, Business Foundations, Business Area Definition
Business Case	Business Case
Risk Register	Risk Assessment
(Project) Product Description	Outline Solution, Solution Foundations, System Architecture Definition, Models
Project Plan	Outline Plan, Delivery Plan Deployment Plan, Business Deployment Plan, System Deployment Plan, Benefits Realisation Plan, Timebox Plan
Work Package	Solution Review Records, Timebox Review Record, Increment Review

Table 1

The content of these products is entered into DEV Folio, which supports automatic PDF generation of the relevant documents. For example, in Figures 10 and 11 it can be seen that the Outline Business Case, Business Case, Project Plan, and Project Product Description are ready for generation. Clicking on the links results in the appropriate PDF being generated (see Figure 13)

Figures 13 and 14

The Risk Register and Daily Log are handled differently. As can be seen from the Home screen in Figure 2, there is a direct link to these products. The Risks link, when clicked, opens up the Risk Register. It then shows the risk, dates, description, and actionee (See Figures 15 and 16). All of the risks for a particular project are rendered as a Probability Impact Grid (Figure 15). The Daily Log allows date stamped, signed entries to be appended (Figure 14).

Figures 15 and 16

Solution, Feasibility, and Capability/Technique prototypes are, of course, the key deliverables of the process. The final documents produced are the Project Review Report, Lessons Report, and the Benefits Enablement Summary.

 

People and their roles

Without recourse to any particular terminology, these roles on our projects describe at least 5 different types of person. We have the client, the supplier(s), the project manager, the programme director, and the corporate board member. In PRINCE2 terms these represent the roles of Senior Responsible Owner, Supplier Team Manager, the Project Manager, the Executive, and Corporate.

A further 4 roles can be added from the PRINCE2 framework. There is the Senior User, Project Assurance, Quality Assurance and Senior Supplier. These 9 roles, and their mappings to DSDM Atern roles, are shown in Table 2.

One further role must be added, for which there is no PRINCE2 equivalent. This is the Administrator of the DEV Folio workflow engine.

PRINCE2 Role	DSDM Atern Role(s)	Key Responsibilities
Senior Responsible Owner	Business Sponsor, Business Visionary	Owns Project Business Case, defines project business vision, approves changes to high level project requirements
Supplier Team Manager	Team Leader, Solution Developer	Concentrates the team to ensure on-time delivery. Manages risk at timebox level. Reports to Project Manager. Undertakes iterative development of the solution. Tests own output prior to independent testing.
Project Manager	Project Manager, Business Analyst, Atern Coach	Communicates with senior management, high level planning amp; scheduling, monitors progress, manages risk. Liaises between business and technical stakeholders. Manages documentation and products. Tailors Atern to suit projects and explains it to team members.
Executive	Business Sponsor, Business Visionary	Owns Programme Business Case, defines programme business vision
Corporate	Business Visionary	Approves changes to high level programme business requirements
Senior User	Business Ambassador, Solution Tester	Contributes to requirements, design and review sessions. Provides a business perspective. Describes business scenarios. Helps define test scenarios. Assists in execution of important tests.
Project Assurance	Technical Co-ordinator	Ensures adherence to best practices
Quality Assurance	Technical Co-ordinator	Makes sure non-functional requirements are met
Senior Supplier	Team Leader	Oversees and co-ordinates supplier work.

Table 2

 

Conclusion, and the future

Agile Methods are often considered to be incompatible with high levels of process rigor. This perception has been encouraged in part by a misunderstanding of the terms of the Agile Manifesto, and partly by the assumption that Agility and rigor exist at opposite ends of a methodological spectrum. Such views are commonly held by Agile supporters and detractors alike.

In the past it has proven difficult to accommodate both approaches simultaneously, and technical and cultural obstacles to progress have been encountered. However, Codeworks DEV have shown that by adopting a standards-based approach with clear process mappings, and by leveraging tool support along with clear roles and responsibilities, it is possible to obtain a balance between prescriptive and emergent development approaches.

At a technical level, our next steps are to re-skin DEV Folio’s UI layer to accommodate early results from usability testing. We are also exploring integration points with Basecamp and with third party scheduling tools. We also plan to extend the coverage of DEV Folio and the supporting methodology across the public sector, and to make the transition into larger corporate in the near future. We expect that “brownfield projects”, where transfer is complicated by existing processes that are neither highly prescriptive nor particularly Agile, will present new challenges. However we are quite confident that the DEV Methodology - and the configurability of DEV Folio - will prove fit for purpose and allow us to master these situations.

References

[Barron, 2003]. Barron, Kevin, et. al. “White Paper: Using DSDM and PRINCE2”. The DSDM Consortium, 2003.

[Clegg, 2004]. Clegg, Dai; Barker, Richard. “Case Method Fast-Track: A RAD Approach”. Addison-Wesley, 2004.

[Richards, 2007]. Richards, Keith. “Agile Project Management: Running PRINCE2 projects with DSDM Atern”. The Stationery Office, London, 2007.