From Buzzword Agile to Real-World Agile

• March 15, 2017
• By Paul Newton

Let’s have a game of Buzzword Bingo: Agile Edition.

Kanbans at the ready… ok, let’s go!

Sprint.
Waterfall.
Scrum.
Lean.
Extreme Programming (XP).
Stand-up.
Burn-down.

FULL HOUSE!

“There’s a new buzzword in the boardroom: Agile” reports the BBC. And that’s a challenge, with multiple methods falling under the ‘Agile’ umbrella the use of the word in isolation can be interpreted in different ways, despite all being characterised as using incremental work packages. For example, ‘lighter’ methods of Agile involving ‘Scrum’ or ‘XP’ are more product-centric methods and are different to methods such as the Dynamic Systems Development Method (DSDM), which is project-centred in a fast-paced, flexible and collaborative way.

Following my completion of the APMG-International AgilePM® certification last week, this blog aims to highlights some of DSDM approaches I personally found most useful and will be taking back into the workplace, both in terms of project management and business as usual (as DSDM is as equally effective on small straightforward solutions as it is for large complex corporate projects). This blog, however, won’t list the DSDM principles or describe the whole approach; there are plenty of blogs out there that already do that!

Start off with a DSDM mindset

The DSDM philosophy states that ‘best business values emerge when projects are aligned to clear business goals, deliver frequently and involve the collaboration of motivated and empowered people’ — I think that’s something we can all agree on!

Is what we’re delivering ‘good enough’?

What tends to happen in traditional project management is that requirements are fixed (or they keep expanding i.e. ‘scope creep’), and the time taken and costs increase. Scope creep isn’t just frustrating, it means that other work which may be more important isn’t being done.

The DSDM approach reverses that with the flexibility being in the features, and time and cost being fixed. We get more benefits from a project that delivers something ‘adequate’ on time which can then be improved, than from a project delivering something ‘splendid’ two years late when things might have changed. Ultimately, DSDM states that a solution has to be ‘good enough’.

The digital team already stand back at the start of a project and assess what the real needs and benefits are, rather than jumping straight to building a system. The DSDM approach strengthens this, and defines requirements as ‘user stories’ so the whole project is shaped by what we are trying to achieve and the real benefits.

A quick tour of MoSCoW

When we look at requirements, we will prioritise them as ‘Must have’, ‘Should have’, ‘Could have’ or ‘Won’t have this time’ (MoSCoW).

• ‘Must have’ means absolutely essential. There’s no point carrying on if this isn’t done.
• ‘Should have’ means it’s necessary for a decent result.
• ‘Could have’ means it’s useful, but you could live without it
• ‘Won’t have’ means it’s relevant and might be a good idea, but it’s out of scope for this project.

For a good project, it is recommended that you have a maximum of 60% of the estimated time on the ‘Must have’ requirements, and the remaining 40% of time on ‘Should haves’ and ‘Could haves’. ‘Should haves’ and ‘Could haves’ then act as project contingency, and can be dropped from specific timeboxes if necessary to meet fixed deadlines.

Build incrementally from firm foundations

Once firm foundations for development have been established (through the DSDM ‘feasibility’ and ‘foundation’ stages), DSDM advocates incremental delivery of the solution in order to deliver real business benefit as early as is practical. Incremental delivery encourages stakeholder confidence, offering a source of feedback and may lead to the early realisation of business benefit.

A project ‘increment’ delivers a coherent set of requirements. That means developing and testing the solution, with technical and customer staff working closely together. The results should, if possible, be deployed at the end of the increment, so the organisation is getting benefits as soon as possible. Also the experience of deploying the partial system in the real world often helps clarify the rest of the project, perhaps changing the priority of the remaining requirements.

Collaboration and communication

DSDM state that ‘teams that work in a spirit of active cooperation and commitment will always outperform groups of individuals working only in loose association’. I couldn’t agree more!

Improved collaboration encourages increased understanding, greater speed and shared ownership of projects, which in turn enables teams to perform at a level that ‘exceeds the sum of their parts’.

DSDM practices are also specifically designed to improve communication effectiveness for both teams and individuals. Poor communication is often cited as the biggest single cause of project failure. In order to fulfil the ‘communicate continuously and clearly’ principle, DSDM teams need to encourage informal, face-to-face communication at all levels. This can be done through daily standouts (two minutes per person, for a maximum of 15 minutes), or through workshops. Using visual communication practices such as Modelling and Prototyping helps to demonstrate the ‘Evolving Solution’ early and often, and manage the expectations of the stakeholder at all levels throughout the project.

And my favourite principle of all DSDM principles: keep documentation lean and timely. Ask yourself the question, is somebody going to actually read this 15-page report? And if not, is it worth writing as a report at all — would a short blog update be sufficient?

And in conclusion

The DSDM methodology focuses on getting something decent out the door on time rather than something marvellous in the ever disappearing future.

For more information, read more about the APMG-International AgilePM® certification or find out more about the DSDM Agile Project Framework.

Tagged in : Communications