Care to share?

Business is strongly addicted to changes. This is the one of common truths behind software development and one of the reasons why agile methods like SCRUM are adopted which such success.

The problem with agile – its fragility– comes to voice when it comes to strict constraints, like budgeting or time framing. Of course, using SCRUM you have a clear view of team speed and budget-burning. But from my perspective as a CTO, business owners too often have too little time and/or experience to use control tools efficiently.

If you have to develop a working MVP in 3 months and in about 40K EUR – you probably would think about trying different approach. A Safer one.

You cannot have everything when it comes to constraints, but certainly you also shouldn’t dismiss the benefits you can get from agile methods. One of the solutions is to take a quick look at the constraints triangle. This classic picture shows how software engineering works. Let’s simply check what you can adjust during the process and what is not changeable.

 constraints triangle

Picture under CC licence from: https://en.m.wikipedia.org/wiki/Project_management_triangle

If time and budget are constant then you can adjust the project scope. Sounds easy enough? But the question is, how to implement?

One of agile methods called DSDM (https://pl.wikipedia.org/wiki/Dynamic_Systems_Development_Method) suggests the answer. It’s based on MoSCoW analysis (https://en.m.wikipedia.org/wiki/MoSCoW_method). Using this method it’s extremely important to perform analysis/design stage at the very beginning of the project, before development (or at least at a preliminary level).

MoSCoW is about priorities. When you gather all requirements (for example describing user stories) you should set the following priorities in the next step:

Must have

Requirements labeled as MUST are critical to the current delivery timebox in order for it to be a success. If even one MUST requirement is not included, the project delivery should be considered a failure (note: requirements can be downgraded from MUST, by agreement with all relevant stakeholders; for example, when new requirements are deemed more important). MUST can also be considered a acronym for the Minimum Usable SubseT.

Should have
Requirements labeled as SHOULD are important but not necessary for delivery in the current delivery timebox. While SHOULD requirements can be as important as MUST, they are often not as time-critical or there may be another way to satisfy the requirement, so that it can be held back until a future delivery timebox.

Could have
Requirements labeled as COULD are desirable but not necessary, and could improve user experience or customer satisfaction for little development cost. These will typically be included if time and resources permit.

Won’t have
Requirements labeled as WON’T have been agreed by stakeholders as the least-critical, lowest-payback items, or not appropriate at that time. As a result, WON’T requirements are not planned into the schedule for the delivery timebox. WON’T requirements are either dropped or reconsidered for inclusion in later timeboxes. (Note: occasionally the term Would like is substituted, to give a clearer understanding of this choice).

Afterwards, when it comes to time estimation (done by developers / analysts) you have to attach budgets with req. categories. In Divante, we use the following budgeting plan:

  • 60% of overall resources must be attached to MUST features,
  • 20% to SHOULD,
  • 20% to WOULD.

Why is this? In optimistic circumstances project budget will be sufficient to cover the overall scope. But in case of – for instance – underestimations, random-issues, req. changes – you have a place to cut off the scope. Simply by not implementing some of the WOULD then SHOULD features.

In other words – in budget you have up to 40% of buffer. But – to be honest – it’s buffer intended to be used for development, not a kind of insurance (like in standard fixed-price budgeting).

Using this technique you can still work in the agile model, pay in time&materials – still having possibility of changes, possibility of working in sprints and release quickly.

It’s up to discussion which other features of DSDM to use. In Divante, we tend to use feasibility study, analysis, design in sprints (overall preparation to development – where we have all UI ready and accepted takes usually 3-4 weeks). Development is done in sprints like in SCRUM, during sprint retrospect/planning clients can actively choose which user stories to implement next. We give our clients continuous information about team pace, budget burned out – and necessity of cutting from the scope.

It works really well, I can recommend it personally. Let’s do some minimal effort, test the idea, decide how much to spend further!

Published February 6, 2016