This article is not strictly about Web Application development and will not be entirely packed full of my own opinion. Rather, it’s about an aspect of modern software engineering in general and a subject about which I feel very strongly – Engineering Discipline.
I first became aware of DSDM shortly after its release in the mid 90’s. It was created to bring some control to the hacking fad of the time called RAD (Rapid Application Development). Its latest edition “Atern” has regained interest as a method of employing the Agile approach of product development without the project becoming, in the word of a client of mine, “a hack-fest”.
I am only going to pick up on a couple of aspects in this article and suggest you refer to the official site for the full details. The online handbook is also very informative. When I was first introduced to DSDM I was convinced of its efficacy but most of our clients disliked RAD and there were very few opportunities to apply the method. Nowadays, convinced by the perceived benefits, it seems every project we bid for asks for an Agile approach to development. However, there is a problem when the commercial people come to approve the contract.
DSDM may not be recognised by many technical people as Agile because there are no specific tools, automated or otherwise, and the approach is more about managing systems development than the Software Development Life-Cycle (SDLC). At a systems-level approach it slots in nicely between project management methodologies such as PRINCE2 and the tools and techniques supporting the SDLC through either Waterfall, Agile or any other development approach.
The bad only days
Traditional system development projects are often contracted with fixed costs, schedule and scope as outlined in the Statement/Schedule of Work (SoW), or similar document. This usually leaves the quality of the product as the only factor remaining with any flexibility for a contractor, which is the one thing no responsible engineer should compromise. This approach keeps the commercial people off the project manager’s back, at least initially. As the project nears delivery the customer project manager often recognises the lack of quality (or similar sort-comings) and rejects the product on the grounds that the product is not “fit for purpose”.
From an engineering perspective, the contracting approach forces development down the waterfall method because it works – doesn’t it? In reality it is more the fact that the step-by-step approach is easily comprehensible to the commercial staff. Agile on the other hand gives them the shivers.
No matter how experienced your are (arguably) in software development projects, effort estimates are always just that “estimates” because every project is different. If you are fortunate your sales people will have managed to negotiate a project with sufficient contingency in time and/or budget to address the slip and slide of effort estimates and unforeseen circumstances. If not, when push comes to shove there are usually only three ways to go; none of them ideal.
- Upset management by exceeding the budget to bring the contracted features in on time; also upsetting the team in the process by asking the to work excessive hours.
- Upset the customer by not delivering all the features and possibly rendering to product useless, compromising quality (and potentially creating a dangerous product), or worse, both.
- Upset both management and the customer by over running on the schedule, usually at the supplier’s expense, to deliver all the features to the agreed quality. However, the engineering team will consider the project a job well done, until management express their view.
So what is the answer?
Not all Agile projects are a “hack-fests” but the majority of those that work best are typically run within an organisation, albeit with support from external contractors. Seldom do they work when they are entirely contracted out and access to the user community becomes constrained by either the customer or management of the supplier.
Commercial staff are charged with trying to fix Time, Cost, Scope and, to a degree, Quality from the outset. They are intolerant of the approximate nature of effort estimates and the inclusion of risk contingency to resolve the unforeseen. So you might think adopting an approach were unused contingency would result in additional functionality would be appealing. No, many commercial staff seem to be transfixed on the fact that DSDM means there is no guarantee the entire scope will be delivered. Indeed, 80% and as little as 60% of the scope cannot be deemed a failure as long as the Minimum Viable Product (MVP) is delivered. As a “rough rule of thumb” DSDM performs best with an estimated effort distribution of 60:20:20 for “Must have”, “Should have” and “Could have” priorities respectively (using the MoSCoW scheme). But it is the 60% maximum of “Must have” requirements that is critical, but a minimum of 20% “Could haves” is important as well.
MoSCoW Prioritisation of Requirements
- “Must haves” (MH) are essential for the viability of the project and are no-negotiable.
- “Should haves” (SH) supply the ‘added value’ for the project and so they can only be excluded with the customer’s agreement.
- “Could haves” (CH) provide the risk contingency trade-off so their inclusion cannot be assumed by the customer.
- “Won’t haves” (or as I like to call them “Would have next time” (WH)) are excluded from the current scope of work but are important nonetheless. It is vital that avenues for future development are not closed by requirements in scope by keeping long-term aspirations in mind.
Experienced Project Managers have a tough time adjusting to Agile too. Even using DSDM the problem is the unpredictable nature of the Agile schedule, or the complete lack there of. Using sprints or DSDM timeboxes, it is only the scope of the current task that can be planned and completion anticipated. Yet this is a useful aspect of Agile because it accommodated late inclusion of new requirements. Once complete it is important to review the effort applied against the original estimates in order to re-calibrate future tasks. There is also a temptation to front-load the high priority requirements in an attempt to a) achieve the MVP as early as possible and b) ensure their delivery over lower priority requirements. This is a mistake, it is only through including a blend of all the requirements (60:20:20) can the flexibility in the approach be maintained.
Customer’s say they want to run projects in an Agile manner without fully understanding the concept or accepting the implications. It is also a difficult sell due to the lack of a clearly defined schedule at the outset and the (intentional) flexibility of scope. However, the adaptability of the scope, the trade-off of risk contingency for additional features and the re-calibration of effort during development, ensures the final product will be delivered within time, budget, with (at least) the essential (MH), probably most of the value-add (SH) and possibly some of the wish-list (CH) requirements, most most importantly to the agreed quality.
Introduction to Agile
I can highly recommend a series of YouTube videos by Crowd Interactive CEO, Adil Wali. He explains:
- Part 1 – Why we use the Waterfall methodology and highlights some of its failings.
- Part 2 – How Agile compares to Waterfall.
- Part 3 – What benefits Agile has over Waterfall as well as some of its considerations apply.