A while ago I was sent a job spec for a Scrum Master role that took my interest. Mainly due to the fact that the author had apparently regurgitated a full thesaurus of agile acronyms. The classics were listed such a CI, BDD, TDD, CSM. But some were less obvious. So I asked the online answer to everything.. Google…

…What is ‘FDD’?

To my surprise I found an approach that was documented, taught and discussed, that pretty much outlined an approach I myself had used on previous projects and one that I have seen countless times with other ‘scrum’ teams.

So genuinely… WHAT IS ‘FDD’?

FDD stands for Feature Driven Development. This is the approach of taking a product and breaking it down into releasable features. It was initially devised by Jeff De Luca in 1997.

In FDD the product is looked at as a whole and a modal is created as the first step. Then this is broken down into features so that each feature can be delivered independently. The project then runs iterations, to deliver each feature.

FDD does not have to be self-organising and you don’t have to have a single PO and a servant-leader type Scrum Master. Team members could be specialised and could even have an architect overseeing how each feature is produced.

The definition of done is also not as prescriptive as scrum. At the end of the sprint the feature may not be released to live but might be pushed to QA or UAT.

The Scrum Compromise…

When you first start using scrum you come across a lot of practical problems that you and your team slowly get to grips with.

When you are taught scrum in the classroom it is generally taught from the perspective of a greenfield project – you don’t have the final product in mind, but should iteratively release high value functionality and watch your product evolve, gaining oodles of great user data and business insights along the way. This all sounds great, but what  if you are re-platforming a product that already exists?

In this scenario you often end up with the grey area at the beginning of the project that we may call initiation, where the team goes through the whole product and then – you know whats coming – the team then breaks it down into features. But we want to use scrum right! So we don’t want to prescribe it all up front. So, after breaking down the product into it’s features and creating a general plan, we then aim to scope up the features in more detail as we go along. Most teams following this approach will try to scope up the features a sprint ahead of the developers.

Then there is the problem of team structure. Introducing full on Scrum into an organisation is difficult. It demands fundamental changes in team structure and ways of thinking across the business. There is no getting away from it – this is hard to do. So most organisations try for a compromise – the Scrum Master might be the developer’s manager, the scrum team is often isolated to the development team, with testers and designers working separately. You might even find architects sat outside the scrum team.

So now we have a QA team that is sat outside of the development team. How can we deliver a product to live without testing being done within a sprint? Again, lots of people have come up with a similar solution for this – move the aim of the sprint end to get everything passed to QA, not to live.

So now we have done all of our adjustments we are happy we have a way of organising our project into sprints, and the business is happy that we are using scrum. Right?

Is it Scrum or FDD?

To some extent it is still scrum. Scrum defines an ideal scenario, and if this is what you have to do as a first step to get the organisation moving in the right direction, then great. Make these changes and then move on from there. But in a lot of cases, this is the end of the change.

There are also a lot of people who at this point would be shouting angry vents of ‘where’s the cross functional team?’, ‘it doesn’t follow the agile manifesto’. And I completely understand why. This is far from the ideal and if you have seen the benefits of scrum being used to it’s full potential, seeing a project like this can be excessively frustrating.

But here’s the thing. If you are running a project in a similar way to the process above it is a long way from being a full scrum project. It is however using a lot of Feature Driven Development principles, and FDD has a lot of benefits in itself. It allows you to reliably see project progress, minimise project risks, creates shorter feedback loops from the PO, allows for project reporting and planning in a manner that executives find useful. It is still agile, it’s just not scrum.

We all say we are doing scrum because scrum is the word that we all want to use. And I love scrum, it’s definitely in my top ten list of things I can rant about for hours with avid enthusiasm. But if you’re not quite there with getting the scrum methodology in place, and frankly, not planning to be, then Feature Driven Development is a great over-arching, less prescriptive framework that can deliver you a great project.

And to be honest, you may well already be running a project that can more easily be described as FDD rather than scrum. There is nothing wrong with this. There are benefits and pitfalls to all methods and each organisation has to do what works for them.

So if you are running something similar FDD why not label it as such! You will certainly make a few scrum purists a little happier and you might gain some new insights by digging a little deeper into the FDD method.

Extra reading and references:

Check out this pro voices video for a great in depth seminar on FDD : https://www.youtube.com/watch?v=9U1bXV-jtyI