The 35th meeting CITI’s centres of excellence club (CofEe) held on 23rd October 2014 was hosted at the Home Office in London.

The topic for the day was – Agile in the P3 environment: reviewing the key features of Agile development and examining whether they can be usefully extended, applied or find parallels in project, programme and portfolio management

The topic for the 35th meeting of CITI’s centres of excellence club (CofEe) was – Agile in the P3 environment: reviewing the key features of Agile development and examining whether they can be usefully extended, applied or find parallels in project, programme and portfolio management.

The day began with an introduction from our host Ian Santry, Head of programme management, best practice and capability at the Home Office. This was followed by some questions from Nick Dobson to stimulate thinking and discussion around whether Agile has real merit in project, programme or portfolio management.

Our first presentation was delivered by Derek Homer, Agile Delivery Manager from Bookatable.Com. Derek has drawn from his extensive experience in Agile product development at Workshare, Nokia and BBC. The main message from Derek’s presentation was that we should not confuse Agile with a project management methodology; it is rather a product development methodology. Whereas Agile provides a mindset that may be suitable for delivering products in some contexts, it does not work well as an approach for managing a project.

The second presentation was from Natalie Jones, Head of Projects at the Home Office. Natalie outlined how Agile was used successfully as a new methodology for software development within the Immigration Platform Technologies Programme. Natalie highlighted the particular challenges of changing the mindsets not only of management but equally of the product managers and software developers. Natalie concluded that although Agile does not come free of challenges, she sees no turning back to other methodologies for product development.

The third presentation was from Phil Bradbury from Transport for London (TfL). Phil outlined how Agile is used within the project management environment at TfL. An important message that emerged from Phil’s experience with agile is that governance in the product development environment should mirror the philosophy underpinning Agile. Phil also emphasised the critical need for changing the mindsets of people working in Agile environments.

Members then were invited to participate in a workshop where they discussed one of four themes:

• Agile experiences in the workplace
• When is it appropriate to use Agile in a project?
• What are the costs and risks of Agile?
• Guidelines for running Agile projects within portfolios and programmes.

During lunch, members were also invited to participate in two surveys. The results of these surveys together with all presentation slides and workshop out puts are available to members at the usual web-site.

Please note: membership of the club is only gained once you have attended a meeting.

Thank you to our guest speakers, all members and a special thank you to our host Ian Santry who helped ensure the day was a great success.

Survey results

Survey one – Measuring progress

Survey one attempted to establish the differences in reporting metrics between Agile and conventional projects. Members were invited to identify which metrics they used to monitor progress in both Agile and non-Agile project environments. The response was equivocal; both types of project make a practically identical use of metrics. The only exception was where metrics were specific to, and could therefore only be used in, an Agile environment (e.g. ‘business value assigned to stories’ and ‘sprint backlog completion rates’).

This seems to imply that there is little differentiation of reporting of progress between different techniques and traditional metrics can be applied to Agile product development.

Survey two – How have organisational frameworks been adapted to accommodate Agile?

This survey was aimed at assessing what proportion of change delivery projects were being run through Agile and, as the same time, the extent to which the governance and structuring mechanisms were altered to accommodate Agile approaches.

A minority of all the projects represented were delivered with the application of Agile approaches and in the majority of instances where projects were being delivered through Agile approaches no changes had been made in project governance structures or monitoring to accommodate this. This is somewhat interesting in that it could either suggest low-levels of maturity in the thinking about the roles of governance structures and monitoring in project delivery; alternatively it could point out an implicit recognition that we don’t need to change project governance structures to accommodate the subordinate Agile product development lifecycles.

Workshop sessions

Four workshops were set to frame discussions between club members. Groups were self directed and generated flipchart output which was summarised in plenary session. The themes and outputs generated are summarised below.

Workshop 1: Agile experiences in the workplace
The first workshop asked members to draw on their Agile experiences in the workplace identifying success stories and cautionary tales on the levels of: (i) product development; (ii) projects; (iii) programmes; and (iv) portfolios.

Most of the success stories arose within the product development and projects environments whilst the cautionary tales surfaced in the attempts to apply Agile approaches in portfolios and programmes.

Success stories in using agile revolved around:

• Incremental product development: Agile allows product managers to start small and incrementally build on success (success brings success)
• Engagement: Agile helps in engaging users and in setting expectations early

Cautionary tales highlighted challenges around:

• Value: Agile is not a panacea for all type of projects and for all type of change
• Skills shortages: difficulties in finding contract resources, while training of existing resources is not easy
• Governance: difficulties in establishing governance structures appropriate to the challenges of applying Agile approaches in complex management environments.

Workshop 2: When is it appropriate to use Agile in a project?

The second workshop asked members to identify when it is appropriate to use Agile in a project.

Emerging concepts from this workshop included:

• Clarity of requirements; members identified that Agile may be useful when projects are building new products or when requirements are ambiguous or fluid
• Type of project: while Agile can be particularly suitable in IT projects, members found the usefulness of Agile in, for example, transformation of people’s behaviour is highly dubious
• Team location: members emphasised that co-location of Agile team is preferable, although not essential. The observation being that it was less effective with geographically dispersed teams
• Project constraints: members emphasised that Agile is not appropriate in fixed cost projects for instance. Although it is possible to cost constrain Agile approaches by pre-determining and establishing the funding of a given number of sprints.

Workshop 3: What are the costs and risks of Agile?

The third workshop challenged members to discuss what costs and risks are associated with Agile.

Emerging concepts from this workshop covered:

Concepts around cost of Agile:

• Agile is perceived to be quicker and cheaper.
• Whereas, conventional methodologies (e.g. waterfall) can have hidden costs (e.g. user engagement), Agile makes this explicit. The need to back-fill users’ roles whilst they are engaged in scrum activities can be significant

• Becoming too obsessed with the methodology (madness of methodology) as some organisations now go Agile as the ‘default setting’
• Fragility: members emphasised that some organisations claim to be doing Agile but not really doing it!
• Product owner: there was also recognition among members of the additional risk associated with the quality of the ‘product owner’, who is key in Agile development
• Co-location: members also highlighted difficulties with running off-shore or remote working Agile development
• Business context: the predominant risk identified was that the technologists and users may take control of the deliverables and their development in isolation of the business context, purposes and objectives; that is to say they could usurp the role of governance and project management

Members stressed additional points around the value from Agile, which are discussed below as part of ‘interesting observations and questions’.

Workshop 4: Guidelines for running Agile projects within portfolios & programmes

The fourth workshop asked members to discuss guidelines for running Agile projects within portfolios and programmes.

An interesting observation is that both teams who participated in this workshop went back to basics by questioning ‘what is Agile’ in the first place? Members stressed that even now ‘we are not clear on what Agile means’; there was clearly an apprehension that Agile as a formalised product development lifecycle is often confused with a more general management ambition to be agile (i.e. flexible and quick) in performance. In short that Agile is very close to being a ‘buzz-word’.

Some members suggested that Agile is ‘a way to manage uncertainty’ at the level of projects and programmes and that it might be applicable for use in prioritising projects within a portfolio; however concrete examples or a clear explanation of how this might occur were not forthcoming.

Emerging guidelines for running Agile projects from this workshop:

• Choose the right people (best people!)
• Communication within teams and with the business is key
• Define clear roles and responsibilities (determine RACI up front)
• Be clear on what you want, then measure it!

The energy and participation in all the work groups was high with individuals freely exchanging views and opinions.

Some ‘interesting observations and questions’ emerged from the deliberations of the afternoon which can be summarised as:

1. Culturally Agile is ‘mandating’ user involvement, but shouldn’t this be the case in all well-run projects as Pinto and Slevin have been telling us since the 1980s?
2. Culturally Agile accommodates the mindset that some products may ‘not succeed’ and it structures for ‘fail fast’, but shouldn’t this be the mindset in all projects? Projects are, after all, speculative investments.
3. Isn’t it essential for project managers and sponsors to ask the question: what problems Agile (in contrast to other approaches) are supposed to solve?
4. Are all the ‘good’ things that come with the Agile methodology (e.g. user engagement, collaboration, multi-disciplinary teams, clear communication, well-defined roles, focus on the project goal) not possible with other project management methodologies?
5. Does agile have to be the only approach or can projects have a hybrid approach where it can start with agile then switch to waterfall for instance?

Indeed this last question underlies the overall conclusion of the day which is that Agile is a product development lifecycle and approach for the iterative development of products (e.g. software) in collaboration with the users and, in the correct circumstances, can prove exceptionally effective. However it is not a project management approach and attempting to apply it as one demonstrates a profound misunderstanding of the differences between project management and product development management – they are not the same.