Agile software development and feature-driven development (FDD) have much in common. Many agile stories encompass features requested by the software stakeholders and end-users. Yet, staying focused on features and not system architecture can be hard to do.
Let’s discuss a simple example. Say your development team is asked to build a simple software application that enables a customer to select a PDF file from a predetermined list of available files and download the selection. In the future, the list may grow, more file types may be added, and we may want to restrict download privileges, but none of that matters right now.
How should you approach this challenge?
Most software developers would want to plan ahead. They might want to build a database to hold the PDF collection (or links to the PDFs). They’d want to implement a search function, capture and save user information, include links to PDF file viewers, add a front end for uploading new content, etc.
All of that may be needed in the future but the current request is much simpler — As a customer, I want to pick a PDF from a static list and download the file. Someone might argue that the software application is too simple to be realistic — that it has little, if any, practical value.
Consider these possibilities:
- The business may want to test the viability of offering customers electronic documentation in place of paper.
- The PDF files may be massive, over 20MB each, and customer acceptance needs to be tested.
- Demand for the files is forecasted to be high and the infrastructure capacity needs to be assessed.
- A large customer is demanding electronic documentation and it needs to be made available fast.
- The company is moving to a new software environment but can’t wait for it to be deployed. The download capability is needed now.
You get the idea. There are many valid reasons for wanting to offer a simple solution now while retaining the option to offer a much different solution later. The challenge is to keep the software team focused on the current target not future possibilities. That’s what feature-driven development is all about.
Clearly, if the initial idea proves viable, the simple solution depicted above will be largely tossed out and replaced with a database, a search function and some form of user identification. The business stakeholders and Product Owner need to recognize that the initial solution will need major refactoring to achieve enterprise scale.
This may seem wasteful but the alternative is to invest lots of time and effort building a robust solution that may not be needed by the business or wanted by the customers. An open dialog and close collaboration between development and the business are necessary to make this work effectively.
Here’s the bottom line.
If the business knows what they want and can justify it, take the time to lay a strong foundation and build on it incrementally. But if they aren’t certain and need time to evaluate and refine their ideas, build the simplest solution that delivers the features they specify and refactor as needed. That’s agile FDD!