Solution Driven Development

I’ve been reading and searching through the many different types of Agile methodologies for one approach that describes the Agile approach I believe to be the best. Although I found components in each methodology that I use, I could not find one approach that succinctly defined the approach I prefer.

I was encouraged recently when I was re-reading information on Feature Driven Development, but I found that there was much there that I did not believe in. The concept of creating an overall model in Feature Driven Development is one that I do not see referenced in many other methodologies. I believe this concept of creating an overall model before starting iterations is absolutely mandatory. But I do believe that the additional practices of creating detailed domain object models in Feature Driven Development is excessive and not required at the start of the project. It seemed to me that Feature Driven Development still required considerable big design and requirements up front.

Solution Driven Development

I believe in what I like to term Solution Driven Development. If you can’t or haven’t envisioned the solution, how can you start executing the project? Some people would say that not having to envision the total solution is Agile. I believe it is unprofessional and lazy. Some would say that the solution will change anyway so why spend the effort envisioning and planning when it is likely to change? I believe that we can’t proceed unless we have a shared vision on what we are creating. 

Let’s start with the definition of Agile Software Development:

“Agile development is a style of software development that emphasizes customer satisfaction through continuous delivery of functional software. Based on a variety of iterative development disciplines including extreme programming (XP), agile methods put developers to work in small teams to tight budgets and short timescales. In contrast to traditional software development methods, agile developers liaise continuously with business clients, aiming to deliver working software as frequently as every two weeks during a project, and welcome changes to the requirements in response to evolving business needs.”

I believe the key is this phrase: “welcome changes to the requirements in response to evolving business needs”. This sentence has the following two assumptions:

  1. “Changes are welcome to the requirements” – This means we know what the baseline of the requirements are. Otherwise, how could we know what a change is?
  2. “Respond to evolving business needs” – We are responding to evolving business needs. This assumes that we have a baseline of current business needs.

What I consider Solution Driven Development satisfies these assumptions.

Solution Driven Development

  1. Creation of an overall model of the solution via consultation and collaboration with all of the stakeholders
  2. Creation of a high level features list that are then scheduled in Iterations
  3. Creation of User Stories that define the features. The creation of these User Stories are only done for the next 1-2 Iterations.
  4. Iterations then refine the design, development, construction, and implementation of the solution.
  5. The solution is tested using the practices of Test Driven Development and Behaviour Driven Development.

If an Agile Project lacks an overall model for the solution, I would propose you are doing Ad-Hoc Software Development not Agile Software Development