Creating software innovation

How does a business embark on software innovation? It’s all about people and process, argues Mark Pascall, director of 3months, a Wellington-based web software development and Agile consulting company. He says it’s vital that management understands the risks and rewards of being Agile and here he discusses why:

The people factor

The most successful projects occur when a small, motivated group of people with all the skills required, work effectively towards a shared vision.

Some of the characteristics of an effective team are:

• Having the right balance of skills — this includes business and technical experts.

• A high degree of mutual respect and trust between team members.

• All team members (yes even developers) having excellent communication and “people” skills.

• The team operates within a culture and process that encourages innovation, learning, creativity and individual responsibility (see process below).

The process

Most people outside of the software industry (and many within it) believe that the process used to create software is the same as the one you would use to build a house. This engineering process (often referred to as the “waterfall” process) involves defining requirements (in a requirements definition document), creating a detailed plan (known as a functional specification or architectural plan), writing a contract and then getting it built and tested.

An increasing number of people believe this process is a fundamentally flawed way of developing innovative software. There are many reasons for this, some of the key ones being:

• It is hard to define exactly what you want up front. This is partly because you are often creating something that hasn’t been done before and you often don’t realise what you do want until you see what you don’t want.

• Often innovation occurs not just at the beginning but during the project, when the brilliant minds of the developers and business experts come together. This innovation (commonly known as change requests or scope creep) is typically resisted as it incurs extra cost and causes deadlines to be missed.

• The time taken to go through the whole process can mean that your site is out of date before it is finished.

These and other problems with the traditional “waterfall” process have resulted in a fundamentally different process called Agile.

Some of the more relevant aspects of the Agile are:

• As described above there is one small, motivated, cross-functional team working towards a shared vision.

• The project is broken into a numbers of small phases acting as stepping stones to the vision. Each phase must result in something giving business value and must be completed in a short timeframe (usually one to three months). Release early, release often.

• There are no detailed written plans or contracts. At the beginning of the project all known high-level requirements and features are written down and given a business value rating by the business, with an estimate of difficulty by developers. The team and client then prioritise and order the high-level requirements.
• The iteration plan is created. Each iteration is two to four weeks long and results in working, testable software.

A well-run Agile project puts the person paying the bill firmly in the driving seat, reduces risk, stress and cost as well as increasing innovation. In order for Agile to be successful however, it is vital that senior management and stakeholders understand the principles, risks and rewards of this different approach.