Wednesday, 20 July 2016

Hidden Assumption of Agile

Agile cures common problems that we experience in software development, however, there are limitations to Agile.  It may seem like a silver bullet, but there are circumstances under which Agile is not the best choice for development, or at a minimum, not to develop the entire project.

The problems with the waterfall model are well known and understood by most by now.  The waterfall methodology at a high level appeals to executives because it provides a clean way of thinking about a problem.

After all:
  • you can't design something before you have the requirements
  • you can't code something before you have the design
  • you can't test something before you do the coding
These facts are true in Agile as well.  The only difference is that you don't try to do all of any phase as a big bang.  We understand that unless we use some kind of iterative process we can't return to a previous phase and fix anything.  So the Agile process looks as follows:

That is, instead of doing all of one phase as a big bang, we do a bit at a time.  Some methodologies call the code that results from each sprint as a 'brick', and through building bricks, we eventually complete the wall.  So Agile is essentially slicing up the waterfall methodology, but all of the work that needs to be done is still done.
So why on earth would we use a waterfall process for ANYTHING?

Well one of the hidden assumptions of Agile is that you can build all software projects one brick at a time.  But, when was the last time that you saw contractors show up and just start building a skyscraper without a plan?

I mean, isn't it just a matter of building the skyscraper one layer at a time, why bother with planning?

Even though a skyscraper will be built one floor at a time from the bottom up, there still needs to be some architectural planning that happens first.  The materials in the support structure of the building together with the common components that provide common services to each floor (plumbing, electricity, air conditioning) need to be planned out in advance. 

If insufficient planning is put into the architecture, then insufficient plumbing is put in place to drive water to the top of the building, insufficient breakers are purchased to support the electrical needs, insufficiently strong materials might be put in place to hold the weight of the building.

To some degree software is malleable and you can add things after the fact.  But there is often a cost to add things after the fact which is much higher than if the element was designed up front.  For example, you could add add a parking garage to the Empire State building, but it would be cost prohibitive. If they had wanted a garage, it should have been built when the building was constructed.

So any project that will require serious architecture should pause and plan for the structural and connective elements that will be required by the project.  The requirements that are tied to the architecture should be developed first so that the architecture of the project is developed first.  Of course, the architecture can be developed using Agile or the traditional waterfall approach.

Once the architecture is in place, then the rest of development can be done using Agile knowing that all the structures and connective elements are in place.  This is akin to building the skyscraper one floor at a time once the architecture is planned.

The alternative to building out the architecture first is that you find yourself in the position of having architected a building of 10 floors and then realize that you need to have 30 floors. The initial architecture which came together quickly will be snowed under by the work arounds that you need to as you get above 10 floors.  You might get to 15 or 20 floors, but you will never finish the project.

Things that would be expensive to add after you have built a few floors:

  • Needing an extra elevator
  • Needing an extra floor in the parking garage
  • Needing the entire building cabled with fiber optics
Most projects do not require advanced architectures, just like most 2 story houses don't need to have architects.  But if your project is large and has serious architectural considerations then you are best suited to plan for the architecture up front.

Make sure to plan the architecture before doing Agile development

Friday, 8 July 2016

User stories or use cases?

Alistair Cockburn says "A user story is to a use case as a gazelle is to a gazebo".

If you are extremely familiar with both techniques then this makes sense.  If you are not familiar with both then suffice it to say that you can put a gazelle in a gazebo but not vice versa.

A user story is of the form As a <type of user>, I want <some goal> so that <some reason> (see here).  

A use case for withdraw money has many more components to it, and a skeleton of such a use case can be found here.  I develop this skeleton use case in a four part tutorial:
  • Part 1: Use case as a dialog
  • Part 2: What is an actor?
  • Part 3: Adding interface details
  • Part 4: Adding application context
The above user story is only a part of the entire use case.  For an ATM, a user story might be As a user, I want to withdraw money so that I can have physical cash.  This user story is only the summary of the withdraw money use case without the details.

User stories come from the Extreme Programming methodology. The assumption was that there will be a high degree of interaction between the developers, and the end customer and that QA will largely be done through test driven development.  It is important to realize that Extreme Programming does not scale.

Once your development team gets large, i.e. you have 3+ agile teams and your code base gets large enough to warrant a formal testing environment, then you will outgrow user stories as your only method of capturing requirements.

You can still use user stories for new modules developed with an end customer to take advantage of the light weight and rapid nature of user stories, but at some point those user stories should transition to use cases.

Unfortunately, there are quite a few ways to build use cases and not all of them are effective.  Alistair Cockburn's method (found here) is an excellent way to capture use cases for more sophisticated systems.  There is no doubt that use cases are heavier weight than user stories, but consider this:
  • Use cases can more easily be turned into test cases by QA
  • With use cases you more easily prove that you have all the requirements
  • Use cases annotated with screens and reports can be used to collaborate with remote off site customers
  • Well written use cases can easily be broken up into a sprint back log
  • Use cases will work if you are not using Agile development methods
So don't forgo the speed and dynamic nature of user stories, just recognize that there are limits to user stories and that you will need to transition to use cases when your project team or application grows.