Does Agile development work for ALL software products?

November 2, 2010

I think most people involved in developing software have a reasonable understanding of what Agile / Scrum development is all about.  The general idea is to get customer feedback early and often so that you can adjust the finished product to something that is almost guaranteed to be what the customer wants.

The Scrum project management method. Part of t...

Image via Wikipedia

This is clearly a much better idea than the traditional, or waterfall, approach where you spend months figuring out what the customer wants, more months building it, and then hope (or pray) that the customer hasn’t changed their mind or that the market hasn’t moved while you were doing all the work.

And history is full of examples of products developed using the traditional way that didn’t get close to living up to their original market expectations because they were obsolete or out of touch with their market the day they were introduced.

However, when you listen to some Agile zealots talk — you will hear things like “there never was a product that couldn’t be developed using Agile”.   Frankly, this reminds me of “one size fits all” which anyone over the age of 5 knows is simply not true — especially in today’s market where every customer wants it “their way”.

So with your help, I would like to identify products (or situations) where Agile development may not be the best approach.  The goal is to avoid trying to force-fit Agile where it clearly won’t work and to identify how to adapt Agile concepts in other cases so that we can get the best possible product in every situation.

OK — I know this is ambitious and possibly not achievable.  But a journey of many miles begins with a single step.  So let’s get started by talking about some product types where Agile will have problems:

  1. Embedded Software — The software that runs all of the “electronic” modules in your car are a good example, including the ABS system, the throttle control system, and the fuel injection system.  Obviously, you can’t ship an interim version of this software to your customers and ask for their feedback — they wouldn’t know how to test it.   And imagine if the software had a bug, the car accelerated out of control and someone was injured or killed.   How would the manufacturer explain that it was only a “test” version of the software? (Hmmm, this sounds vaguely familiar for some reason…)   Lastly, it takes a long time to ship a product like this to a customer.  So even if you could get customer feedback, it would come so long after the development had been completed as to be nearly useless to the development team.
  2. Enterprise Software that Requires Customization — This is an idea that I described previously, so I will summarize.  Imagine that you provide a customer with software that takes them 6 months (or more) to customize and deploy, how will they ever be able to provide you with timely feedback?
  3. Real Mission Critical Systems — The software that monitors and manages the nuclear reactor in a power plant is a good example.  How could any software provider explain away an interim software release that allowed a catastrophe to occur because a feature wasn’t “finished”?    I mean before they lost everything in the inevitable flood of litigation.

There are only a few examples, but they seem to have a few things in common.  Perhaps Agile / Scrum development only works with products / situations without these characteristics:

  • No Timely Feedback — It is not possible to obtain feedback from the customer / end user sufficiently fast enough for the Development team to review and incorporate it into the product.
  • No Ability to Fail — It is not possible for the product to fail, due to a feature that is incomplete, incorrectly designed, or improperly implemented, without subjecting the customer / end user to unacceptably high risks.
  • Not a Standard Product — It it not possible for customers to effectively use a “standard” version of the product.  Every version must be customized before it can be used (or tested) by a customer which makes it very difficult to detect whether a failure is in the product or a customization.

I’m sure I’ve only scratched the surface, so feel free to add your comments.

And next time, we’ll look at a few ideas for using Agile Development practices for products which have one or more of these characteristics…

Advertisements

Documenting Requirements — the Tools you will need to be successful.

November 2, 2010

I wrote previously about an approach that I have used to manage requirements.  Subsequently, I have been asked to elaborate on the tools and rationale, so here goes…

As previously discussed, “requirements” consist of a wide variety of inputs from numerous internal and external stake holders.   Yet all requirements suffer from 2 problems — (1) It is impossible to address all of your open requirements in a given software release, and (2) things change.

So, that very carefully defined requirement from that key customer that was documented in year 1 may be significantly different from what that same customer needs in year 2 (or year 3).  You obviously don’t want to spend time developing something that doesn’t meet a business need and you also don’t want to lose any of the knowledge about that requirement that you have collected from this customer (and others).  Lastly, if you are going to reconnect with a customer to review the details of a particular business need — you MUST have a good understanding of what they have said before — or they will dismiss you as a waste of their time — which is not helpful on many fronts.

In other words for every requirement, you need some method to gather, track, and maintain its “definition” and the features that you will need to address it over time.  A document management system (such as Alfresco) is an ideal tool for this purpose.

You may ask — “but why not use a source code control system like Subversion or CVS?”   The simple answer is “they are not the right tools”.   Source code control systems are designed to help multiple people work on source code files that often overlap with one another.   Thus, these systems have sophisticated tools for identifying the differences between two versions of the same source code file and allowing them to be merged together.  In my experience, these tools do not work with documents — especially Microsoft Word documents — and can even corrupt the formatting and content in some cases.  In addition, source code control systems typically require each user to maintain a local content repository that must be synchronized on a regular basis to ensure that each user is always looking at the most current copy of a document — which is counter-intuitive, at best, for most non-Engineering personnel.

By contrast, a document management system is designed for editing, sharing, and managing “documents”.  It uses a simple check-in and check-out model that allows users to view any accessible document but requires all updates to be done using an exclusive write approach.  A document management system also provides tools for managing the maturity of each document so that preliminary feature ideas can be shared with some people and more mature feature definitions can be shared with others.   (Have you ever had a situation where a very early version of an idea was sold to a new customer by an overly aggressive sales person?  If so, then you should appreciate the ability to control when requirement and feature information is shared with different audiences.)

In other words, a document management system is the best tool for “managing documents” whereas a source code control system is the best tool for “managing source code”.  (Apologies if this seems redundant.)

You also need a method to plan a software release that will (hopefully) include numerous features that each address one or more requirements.  You need a method to select which features will be included in each release and a way to obtain estimates from Engineering on what it will cost to develop each feature.  You also need the ability to iterate the definition of each release numerous times — adding or subtracting different features — trying to get the “perfect” balance between features, schedule, and Engineering capacity.

You also need to capture all of the assumptions and dependencies that Engineering identified while creating their estimates for 2 very important reasons:  (a) Engineering spent time (and money) creating these estimates and if a particular requirement isn’t addressed now, it may be later.  You don’t want to pay twice for the same thing. (b) If you know how each estimate was derived, you are much more able to verify previous estimates or anticipate problems with current estimates, based upon$ its assumptions and dependencies — even if your Engineering personnel change over time.

You could plan each software release using a spreadsheet — but why would you want to?   Do you really want to continually update the spreadsheet, circulate it to numerous internal people, and then consolidate all of their inputs?   And even if you want to operate this way — do you really have the time?  Or are you assuming that you will get each release planned perfectly the first time?

This is where an issue tracking system (such as Jira) can (help) keep you sane.  You can use a field (such as “Specification”) to include a link to the relevant requirements document within your document management system.  You can use another field (such as “Target Release”) to designate the features that you want Engineering to review and have them include their estimates and assumptions in other fields — based upon the information on the feature and its underlying requirement(s) maintained in your document management system.  So when you generate a report (or Excel export) for a given software release — you will be able to immediately determine whether you have under or over defined the release based upon your Engineering capacity.

You are almost done — all you need now is a “plan” for this release.   If you are using the waterfall method, I suggest creating a project plan with Microsoft Project using the feature, dependencies, and estimate information from your issue tracker.   Update it regularly (I suggest weekly) and provide copies to all team members.  (I suggest using a PDF print driver so that you can easily share the project plan with everyone without requiring them to have access to Microsoft Project.)

If you are using Agile, I suggest using the GreenHopper plug-in for Jira — or something similar — to plan each sprint.

That’s all for now.  I hope this has been helpful.   As always, comments or questions are welcome.


%d bloggers like this: