Why is it that many people have had painful experiences of procuring software? You would think this should be a wonderful opportunity
to engage in creativity and innovation, to learn something new and see some of your ideas become realised in ways you could not quite imagine. But the reality turns out to be completely frustrating. You don't get what you want or what you were promised, you get it late, over budget and it never works properly. Then you find out that what you just paid said web tech company many thousands of pounds for is available for free on the internet
The fact is that paying for software development at a time when technology is moving so fast will always be a risky business. Ironically, despite the painful stories and battle scars of those that have had bad experiences of software development procurement
, much of the problem can be put down to the processes that are used. If you are paying for development then the perception is that you want to know what it is you are getting before you sign a contract. Therefore you work with your supplier to develop and agree a list of functional requirements. These are costed
and their development is plotted on a some kind of time-line with milestones, deliverable
s and so on. Then you press the go button and in theory everything works out as planned. Or, as is more likely
the case you end up cutting requirements like crazy to make deadlines, getting half-baked functions that kind of work but not really as you had hopped and the rest is history.
So if this Agile malarkey
is so great then what could it do to this process?
Agile provides the software purchaser with a suite of methods that can help them get what they want, when they want it and on budget. However, for this to work it requires a potentially seismic
step outside of the comfort zone of a tight requirement list and schedule into a space where creative thinking and constant change are embraced jointly by the supplier and the supplied in order that everyone gets what they want. The supplied gets great software and the supplier gets to make some money and you are still on talking terms at the end of the project.
This works by the supplied selecting who they work with on the basis of who they want to work with because
they understand the problems faced in the environment the software is required for, have an attitude and approach that gives you confidence that they can deliver really good code and can talk to you in a language you understand. 'Ahhhh
', I hear you say, 'but we do that and still things end up pear shaped'. Yes, but despite having these feelings towards said developers, you also probably made them sign up to a fixed set of requirements and specifications and a tight and rigid development schedule so you were asking them to work with a big fixed design up front and a deliverables
time frame that required first this, then that, then we pay, then you do this and then and then and then. And then it didn't work out like that.
If you were working in an Agile way you would be only taking one step at a time and according to a continually changing requirements list. You would be able to add, change and re-prioritise
your requirements as you go so that you were always addressing the real needs of the project rather than a set of needs that made sense before you had any working code to play with. You would also be in a position
to learn more about what your needs are as prioritised working functions begin to emerge rather than having to rely on very early sketchy ideas of what you imagine you will need before you really know.
Then their are stories. Agile uses narrative and dialogue
between client and supplier, stakeholder and user to ensure that people really get useful stuff. Stories are much more effective than pretty pictures and technical descriptions. We can all understand them and that means that their use greatly improves communication around the project.
I could go on here. But I wont. I have been involved in enough projects that haven't gone smoothly to know that Agile makes a real difference
. Given that much software development is paid for by the public purse surely it is time that those responsible for this expenditure start to look for more effective ways of working. Anyone who has been close to software projects in the public and private sector will recognise some of what I have written
from their own experience so surely it is time that we innovate with process instead of using broken old fashioned approaches to software procurement
that often leave everyone feeling dissatisfied
Labels: pain, process, public sector innovation, software procurement