Agile, People, Project Management, Requirements

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

Re-posted from http://bornagainagilist.wordpress.com

About Terry Bunio

Terry Bunio is passionate about his work as the Manager of the Project Management Office at the University of Manitoba. Terry oversees the governance on Information Technology projects to make sure the most important projects are being worked on in a consistent and effective way. Terry also provides leadership on the customized Project Methodology that is followed. The Project Methodology is a equal mix of Prince2, Agile, Traditional, and Business Value. Terry strives to bring Brutal Visibility, Eliminating Information islands, Right Sizing Documentation, Promoting Collaboration and Role-Based Non-Consensus, and short Feedback Loops to Minimize Inventory to the Agile Project Management Office. As a fan of pragmatic Agile, Terry always tries to determine if we can deliver value as soon as possible through iterations. As a practical Project Manager, Terry is known to challenge assumptions and strive to strike the balance between the theoretical and real world approaches for both Traditional and Agile approaches. Terry is a fan of AWE (Agile With Estimates), the Green Bay Packers, Winnipeg Jets, and asking why?

Discussion

One thought on “Solution Driven Development

  1. I fully agree — and I would like to see the Agile Manifesto replaced by the following two definitions 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.

    Posted by Gebhard | September 6, 2011, 6:50 am

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

%d bloggers like this: