Back to news & views

Should I “go Agile”? It depends…

Agile development is one of those topics that regularly polarises the development community.  A quick online search reveals a wealth of anecdotes about how Agile revolutionises your software development, ensures iterative delivery of business solutions, minimises inefficient processes and needless documentation and ensures sustainable and motivated development teams.  The Agile manifesto (http://agilemanifesto.org) and the associated 12 principles of Agile make for compelling reading and it is easy to see why there is considerable enthusiasm for an approach with such promise.

The same search also reveals a similar number of articles bemoaning Agile.  Critics argue it delivers poor quality software, large numbers of unfixed defects and endless refactoring; that it results in insanely optimistic expectations, poor forecasting, planning and a lack of control; that it leads to broken, exhausted teams, unsupportable software and a high cost of change.  The list goes on.

Look a little harder and the interested reader will see the same is true for most other software development processes / methodologies / approaches [delete as applicable].  The curse of anonymous internet debating is as present here as with any other hotly debated internet topic.  Reasoned arguments deteriorate rapidly, sides are taken, anecdotes are offered as evidence and opinion as truth.

Which approach is best?  In which basket should you, the conscientious development manager, put your departmental eggs?  Should you choose Agile, waterfall, the IBM rational unified process, SCRUM, extreme programming or remain with your (or your partner’s) current development approach?

The answer, in the opinion of your author, is “it depends”.  Changing your development approach to Agile, waterfall or other variants or derivatives is a choice that needs to be made on a case by case basis.  Software development processes are to software engineering as assembly lines are to manufacturing.  If you need to churn out few hundred thousand widgets easily assembled from component parts, an assembly line is the obvious way go.  Creating a limited number of bespoke products requires something different.

So how to choose?

The right development approach for your project is a function of multiple factors.  Crucially the importance of each will vary by organisation.  An approach that is right for one may be disastrous for another.  Insurmountable constraints in one organisation may be easily sidestepped in another.  Critical factors include:

The customer organisation, its behaviours and constraints

  • The ability and willingness of the business to support iterative working patterns
  • The criticality of the project.  Higher criticality often equates to additional senior management focus and demand for control
  • How formal the “contract” is between you and your customer and the level of governance required around change.

The nature of the software solution being created

  • Whether this is a COTS based solution or a bespoke development.
  • Whether it is a green or brownfield site, how well defined the requirements are at the outset and the expected level of change
  • Whether this is a standalone solution or a heavily integrated part of something larger.  The more dependencies there are with other components, for example, the harder it will be to adopt iterative approaches in their purest forms.

The programme / portfolio environment in which it is being built

  • The level of governance and documentation mandated around stage gates, reporting and other project controls.
  • The ability of senior management and PMO to work with a (potentially) new approach
  • The level of project management consistency needed with other projects in the programme or portfolio.

The development operations (DevOps) environment in which it is being built

  • The experience of your team(s) with the approach(es) being considered
  • The control, visibility and processes for change, configuration and release management
  • Geographic location of dev teams and quality of collaboration tools
  • Maturity of, and level of trust for, your automated testing capabilities.

Ultimately, how you develop software is an important decision in the same vein as how you manage projects or how you procure services.  It should be considered carefully at the outset of any new software development endeavour.

Choosing the wrong approach, or failing to tailor it to suit the nature of your organisation, won’t automatically doom your project to failure or mean you end up with the wrong result.  But it may make the difference between a smooth project delivery and a bumpy ride.