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

6 thoughts on “Solution Driven Development

  1. I fully agree – being agile (in a positive sense) should be defined as: „Have a development process in place that will allow and urge you to welcome changes to the requirements in response to evolving business needs”.

    Many people however, when trying to be agile, do not see the difference be-tween agility and hacking: Far too many Agilists seem to think that the most important principles of Agility were the principles of Extreme Programming. To think so is a big mistake.

    See also: Principles of Agility 2011 and follow there the link “What Gartner found”.

    A process model keeping you away from XP but allowing you to be agile (in the positive sense) is SST defined here:

    Avoid XP – be Agile with SST

    • Thanks for the comment and information. I need to read through the references but I believe this may be the content of my next blog post. 🙂

  2. Pingback: Is #agile #sub-optimal? | bornagainagilist

  3. Pingback: Is #agile #sub-optimal? « Protegra

  4. I would like to see the Agile Manifesto replaced by the following two defi-nitions of Agility:

    Software Developer’s Definition of Agile:

    Agility means to have a process in place that will allow us (and urge us)
    to react on changing business requirements as soon as possible
    — long before the complete product is ready for delivery —

    Project Manager’s Definition of Agile:

    Agile Project Management means to have a process in place
    that is to maximize team efficiency.

    The best way to become agile in this sense is something more subtle than what is suggested by the authors of the Agile Manifesto.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s