There has to be a better way of getting software developed

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 anyway!

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, deliverables 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?

What can Agile do for school management?

Having spent many years working on co-design and partnership projects with schools, I have become aware of the fact that schools in the UK, and particularly secondary schools, are in a constant state of flux. Even the best performing schools are continually managing change as handed down to them by government or because they get specialist status, being rebuilt or trying to become more outward facing through working in partnership with industry, cultural organisations, HE and FE. Then there are those schools that get entirely new management teams as they become academies or are working to get themselves out of special measures. These schools have to deal with change upon change and at times will feel like they are in constant crisis mode.

As Agile methodologies begin to be applied in new environments, it seems that schools are an obvious candidate as organisations that could really benefit from Agile. Some of the reasons for this are as follows:

• Constant change - as mentioned above, schools are continually working in an environment of constant flux and Agile is all about constant change.
  
• Lightweight processes - teachers are overworked and are resistant to anything that feels like additional management, administration or responsibility - Agile is simple and does not require reams of additional paperwork.
• Minimum iteration - in schools resources, particularly time, are scarce. Teachers will buy into a process and a project if they can see that it is delivering for them. Agile delivers results quickly and requires visible success criteria.
• Needs orientated process - the Agile use of 'stories' as a key concept used for defining goals and considering prioritisation is very useful for schools. Teachers often think in terms of 'need' and 'limitation' and both these are core elements of 'stories'.

Schools are expected to work in terms of projects more and more. Teachers need to be able to work together and with external organisations on project development and delivery in order to respond to the constant change that they are faced with. Agile is much more suited to the school environment than traditional project management approaches. It is flexible, easy to understand, lightweight and quick to implement, delivers visible outcomes quickly and responds effectively to constant change.

Are you busy?

I went along to "i-design: design for life" yesterday. In one Q&A session somebody mentioned that it was hard for people who were involved in new media to come to an event like i-design. They work for small companies. They're too busy with deadlines to spend a whole day, or even half a day, thinking deep thoughts. The comment clearly came from painful experience "We spend all our time pitching, we don't get paid for it."

One thing that Agile methods do is encourage teams to keep track of what a project really costs. This doesn't have to involve detailed filling in of time sheets, but it should definitely include all those late nights until three in the morning. Those late nights don't come for free. Everybody has a limited number that they can give you before they start sending out their CV or getting signed off work with stress.

Knowing how long a job actually took is useful in all sorts of ways. Research has shown that experts are much better than novices at knowing their own abilities. Keeping track of what you said you would do and what you actually did starts to provide you with this self-knowledge.

Agile methods are noted for reducing the number of defects the work that is produced. Many things might explain this, but perhaps the most important is that they encourage a way of working in which well-rested people work on projects during normal working hours. When you start to use these figures to inform the prices that you quote for future work, your clients will notice the difference.

Training in Agile in Central London

Agile Lab have announced the date for their first delegate course in London on 27th November. This will be the same course that we have already successfully run with companies like Desq (http://www.desq.co.uk), who liked the course so much that they've asked us to go back and teach it to the other half of their company.

The course will be called "Crawl before you leap: an introduction to Agile".

Agile, Lean, Kanban feed

For further information, contact mark@agilelab.co.uk (07736 807 604)