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

Advertisement

Agile Experience Reports – The Agile Dozen

My main purpose for this BLOG was to try and share some personal Agile Experience Reports and get discussions going with others on what worked and what didn’t work. My first challenge was to create a framework where some sense could be made of my personal project results.

When I compiled the list of Agile practices that I feel are important to projects, I was worried about how any patterns could emerge with that many factors. And I was right. I had compiled a list of 42 characteristics and practices that covered the Project Team, Project Planning, Execution, Requirement Gathering, and Development activities on the project.

What I did next was look at those 42 characteristics and practices and whittle it down to 5-10 Agile practices that I believe are really key to project success. Unfortunately, I could not get it below 12. So I was stuck with the Agile Dozen.

Next was the step to validate that those practices were indeed a true indication of project success. And through the projects reviewed so far, they have held.

For my upcoming Agile Experience Reports I’ll share how well we followed all 42 characteristics and practices on a rating scale of 1-5. But I want to caution that I am not viewing this rating as:

  • An Agile scorecard
  • An Agile Maturity
  • An Agile report card

I think those constructs cause teams to focus on the wrong things. Namely, getting a good grade rather than project success, client success, and continuous improvement. I created this framework to help myself understand what practices really contributed most to project and client success and help me to improve and focus on the right practices.

In the next BLOG post I’ll discuss in details the Agile Dozen and my rationale for including them. For now, here is the list of the Agile Dozen..

  • Team Experience (Technical & Domain)
  • Developer to Designer Ratio
  • Embedded Engaged Client
  • Team Continuity
  • Team Estimating
  • Automated Tests
  • Team meeting estimates
  • Daily stand ups
  • Retrospectives
  • Iterative Delivery
  • Epics, User Stories and Product Backlog
  • Continuous Integration

Then I’ll provide some context on where these characteristics existed and practices actually worked on projects and share lessons learned.

I hope you will find this interesting. I tried to find information like this when I was starting out and I could not find it very easily.

A Testing Phase – I just can’t quit you!

Finally I’m going to write about the problems I have had moving away from a sequential testing phase. I got side-tracked with some Monster analogies, but before I move on to discuss any other topics I need to fulfill my promise about writing about this.

To summarize, no other concept is personally easier to state and harder to do than a sequential testing phase. Even when I am coding or creating, my mind always thinks about creating sufficient inventory to then make the context switch to then test. Even though I know this is incorrect and I am losing quality and building inventory by doing this, I seemingly can not help myself. I was thinking about why this is and I may have a theory.

I wonder if this default behaviour on our projects is due to how we were educated? All through out our years we had the pattern of building up a sufficient inventory of knowledge in classes and then having a large test or two to validate that the knowledge was indeed mastered. I think back to university and my Mathematics exams worth 90% of the grade, the ultimate big bang approach. No concept of failing fast in those courses. Sure there was some assignments to practice, but even that was not consistent across all the courses. Ultimately most of my courses after Junior High had an exam of at least 60%. And of course the problems that caused were very similar to project issues:

  1. By the time you know there is an integration issue it is too late to do anything about it.
  2. You cannot correct mistakes early so if something is misunderstood the number of mistakes is huge.
  3. These large tests, don’t provide opportunities to learn. They only provide judgement.

This last sentiment has stuck with me the most and I remind myself of this fact to ensure I test as early as possible. I remind myself that the noble purpose of testing is learning, not judgement. With most traditional projects, the testing phase is almost viewed as a judgement being pronounced on the project declaring  whether it is successful or not. Almost like we are grading the project and determining if it has to go to summer school. We need to fundamentally shift our focus in testing to be that it is an opportunity to learn and not an opportunity to judge.

When you do this shift, something very interesting happens. The value of a Quality Assurance Departments and Testing groups lessens greatly. Those structures are all about judgement. If testing is about learning, then the people conducting it only naturally should be the ones that will learn the most! And that would be the developers and clients. (Hopefully together!)

I believe our educational system has now moved to more frequent, smaller tests to ensure that the tests are about learning, not judgement. It seems only now has our Information Technology projects also understood that it isn’t about judgement.

I would propose that rule #1.a of Software Development should be:

‘Thou shalt test the deliverables before each and every status report is given and status meeting is held’ (this would be daily but weekly at the latest’)

This would ensure that testing is not a separate phase and that testing really is a learning activity by being integrated in the entire lifecycles of the project.

And really, how can we report on status if we haven’t tested????

Any guess to what Rule #1 is? Share your thoughts and I’ll tell you mine on my next post.