A guide to commissioning software part 2: Questions about agile practices

In part 1 I covered a few of the advantages of agile development when commissioning software. In this second post, I deal with common questions that arise from a client perspective; particularly for clients who are new to working with agile developers.

I start with a couple of big questions, about money and particularly about value for money and procurement, and them move on to questions about working with agile developers; what to do to maximise productivity and maximise the probability that the delivered system delivers business value.

This is a developing blog post, asking questions in the comments or mailing them in (mark at hedtek dot com) will result in more questions and answers being added here.

Do agile developments deliver value for money?

Agile developers don’t charged fixed prices. Instead they charge according to labour expended on the project. In such circumstances it’s natural for clients to wonder about value for money, and if the software cost is going to spiral out of control.

An experienced development team should be able to give you a ‘feels like’ estimate of costs on the basis of time involved in developing similar solutions. The cost of developing radically new systems can’t be estimated in this way; often a ‘suck it and see’ approach of doing some work and using experience so gained helps markedly refine expenditure estimates.

Agile solutions are likely to be more cost-effective than conventional solutions, for these reasons:

  • Agile delivers the solution you want, rather than one you think you want before development starts.
  • The process avoids big up-front specification, which is always a source of problems and instead uses more effective and tractable specification methods during the project.
  • The process can incrementally deliver early releases which provide the most important business value ready for use.
  • For various technical reasons, agile development is more efficient than conventional development.
  • Agile can deliver more robust, reliable and maintainable code
  • Expenditure avoids the often very considerable ‘safety margin’ that is built into fixed price contracts .

But my procurement process can only deal with fixed prices!

Simple, get the agile company to bill regularly against a fixed sum. If the project finishes before all the money is spent all the better.

When does an agile project end?

In most forms of contracting used for agile development, there is considerable flexibility about what goes into the project, you can stop the process when you have enough business value realised in the new system.

Often this goes hand-in-hand with in-project the discovery that you don’t need some features you thought were compelling, and would have paid for in a conventional project.

Co-operative work and communications between clients and developers – what does that mean for me the client?

There is a wide variety of communications patterns between clients and developers, for agile development processes to work there needs to be a minimum level of client involvement: You need to work with the developers to specify, in an incremental way, what you want from the system.

In turn the developers should be showing you the system on a regular basis; perhaps every two weeks. Good developers will have a development server on the Web, which means you can go there and look at progress whenever you want to.

This is not recommended, but: Sometimes it may be possible for you to minimise your involvement in the project, if the project team has a surrogate product owner (or product manager) who understands your application domain and can make decisions on your behalf. But in cases like this, if the team delivers something you don’t want, you have only yourself to blame!

This entry was posted in Uncategorized. Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

Post a Comment

Your email is never published nor shared. Required fields are marked *

You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>