If you ever travel to Maine, I highly recommend a visit to the Maine Maritime Museum in Bath.  We took our kids there when they were younger – the exhibits were both fun and educational, and the boat ride on the Kennebec River was a blast.  One thing has stuck in my memory about that visit: an interactive display of a lobsterman describing the details of his craft.  Periodically he would return to his standard catch-phrase: “But I know what you really want to know…how much per pound?”.

In my last post, Bridging the Communication Chasm, I talked about how much better software requirements are when both technical and business users collaborate in creating them.  Just as with lobstering, there are many, many details that go into how we will collaborate with you in putting these requirements together.  We will write User Stories – driving to the heart of your business problems, expressed in business language.  We will talk often, to ensure that the software we create solves the targeted business problems.  We will show you early prototypes to ensure that we have communicated effectively.  But I know what you really want to know…how much per pound?

The “Cost of Change” in software development describes the exponential rise in the cost of changing software over time.  When defects are found during requirements analysis, the cost is small.  When defects are found during system design, the cost is higher.  When defects are found after product release, the cost is higher still.  Scott Ambler describes the impact of Agile development methodologies on the cost of change curve in his article Examining the Agile Cost of Change Curve.  Ambler concludes that the cost of change curve flattens when Agile methodologies are used "because we follow techniques which reduce the feedback cycle".  Rather than waiting until the end of the development effort to get your feedback, we work with you from the start, reacting to your feedback in each iteration.  Defects will be found early, and fixed affordably, either during story creation or during frequent demonstrations of the solution as it progresses iteratively towards completion.  We have a common interest here: building the software that solves your business problem the best way, and leaves you a raving fan of AMS.  But I know what you really want to know…how much per pound?

You don’t get this benefit for nothing.  You will have to work with us as we develop your solution.  We need your help in writing the user stories for your solution.  We need you to answer questions that come up during development.  We need your feedback during frequent web-ex presentations showing the progress of the solution to date.

Let’s imagine that you assign Susan, one of your best business analysts to work with us as a member of the Agile team that is developing your solution.  During story development, Susan might spend 8 hours per week on this team, for two weeks.  Following that initial period, she makes herself available 3 hours per week to answer questions and participate in web-ex presentations of the forming solution.  This period lasts for 12 weeks in this pseudo-project.  At the end, Susan puts in more time, lets say 8 hours validating that the resulting solution does in fact satisfy the user stories and all validations created for the stories.  Add it all up…16 + 36 + 8…we get to 60 hours of Susan’s time.  Yes, there are other tasks that Susan would have been working on during this time.  What do you get for this investment in your software solution?  At the end of the project, you take delivery of a solution you know solves your business problem.  No haggling over enhancement requests resulting from misunderstood requirements.  How much is that worth?

It just makes sense.  So think of the answer to the “How much per pound” question not as how much you’re spending, but how much you’re investing in your AMS software solution.  Enjoy the lobster!