Is it Time for a New Manifesto for Software Development?

The publication of the Manifesto for Agile Software Development in September 2001 changed software development forever.

The nineteen engineers present asserted that there was a better way of creating software than the “waterfall” approaches prevalent at the time by valuing;

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

It could be argued that the current “information age” started the day the agile manifesto was published, and that the massive product and service innovation we are enjoying now would not have been possible without it.

“Agile” software development has clearly served us very well, but would we now benefit from bringing together some of the emerging techniques and approaches in software development into a new manifesto?

Measuring a team’s value by measuring its’ impact on its’ business is a natural progression of better communication between developers and customers, and is an important maturity step. A software team exists to have impact on its’ business and good teams will want to take responsibility and accountability for their impact. To be effective as metrics the metrics need to be important, clear, unambiguous and consistently measured and communicated.

A company’s executive team should set overall priorities/strategy and add value by making sure their people are working on the right problems at the right time. Good teams are full of talented people that have a wealth of ideas on how to achieve the business goals, and their talent needs to be brought to bear on the business challenges. (Maybe going forwards we should measure the quality of an executive team by how effectively it deploys talent against its business challenges).

Modern tools, frameworks and approaches allow us to automate all of the activities needed to create customer affecting software. Testing, integration, deployment, monitoring and so on could and should all be automated and done quickly, easily and continuously. We want and need developers to be focussing their mental energies on solving business problems – not checking and moving software around.

Bringing this all together..should we now value?

Software team impact being measured by simple business metrics

Software teams being allocated problems rather than solutions

Low friction software development enabled by the automation of everything..continuously

At Hailo we formed teams using these principles (which we called “Mission Teams”) and one of the teams, the Driver Team led by the brilliant Dan Martins, was given the problem of improving the accept rate – which was the percentage of hails the taxi drivers accepted out of the total number they were offered. The team genuinely and honestly surprised the executive team with the quality, quantity and effectiveness of their ideas and had starting achieving all time record accept rates within weeks.

What do you think?