Insight Why Wikipedia is wrong about Agile

Looking at the Wikipedia entry for "agile project management", we were reminded that there are many myths and misinformed views surrounding this very adaptable method of delivering projects. Certainly it started us thinking about how we could update and better inform the article, but before we took that step we thought we'd try exploring and explaining some of our reasoning in a post of our own: just to provide balance to some of the alternative views of Agile that are out there.

The Wikipedia article reminds us that: "..many believe it [Agile] doesn't scale well..".

We say the likely reason this might be the case is if the overall approach taken treats the project as an isolated IT project, with no reference to the business priorities and benefits it could deliver to the organisation.

Wikipedia goes on to say that Agile: "..does not offer any advantage over Waterfall [a traditional methodology for project management] when it comes to classical projects [like construction projects] where requirements are nearly always constant and unknowns are rare..".

Common assumptions:

• A lot of the time it is assumed that Agile only applies to projects under ideal conditions in which a waterfall approach is equally applicable (using new technology platforms, delivered by co-located teams, not dependent on any outsourced elements of delivery etc.) with unlimited access to customers and buy-in of management to the Agile approach
• Similarly it is assumed you can only apply a standard Agile method (e.g. Scrum, XP etc) in its entirety, and that when an Agile approach encounters real world constraints (e.g. a project around a COBOL mainframe or with dependence on an outsourced offshore development team) the project will fail.

Not so:

• Agile should be considered as a series of tools or methods that each address particular issues (some address quality, some timely RoI etc).
• These should be selected and applied according to the real world constraints, priorities and real world issues that need to be addressed
• Then they should be applied in priority order (i.e. gradually transitioning to an Agile methodology), exploiting current strengths where they exist and addressing weaknesses where they are the issue: e.g. if quality is the biggest issue then look at the engineering techniques first.
• The result will be a method that works within the particular business context of the organisation.

We believe that in order for Agile to scale it is vital that everyone understands the business priorities and issues that the business is seeking to address so that appropriate prioritisation decisions can be made within the project. The key is to establish adequate governance and, having identified the priorities, to set targets and provide senior management with realistic assessment of the benefits and measurement of progress towards achieving them.

Also we believe Agile is applicable to all types of project. It can be used successfully within and alongside other methodologies, such as PRINCE2 or MSP, and has strengths that can benefit every type of project.

The key to applying Agile as outlined above is to understand the business priorities. For example, when we worked on redeveloping the Guardian Unlimited website (www.guardian.co.uk), their key priority was brand reputation. Other factors, such as potential to increase traffic and advertising revenue were added in to the mix but the highest priorities were quality and levels of service. The programme delivered hundreds of man-years of development effort and incremental improvements to the site without any significant break in service and all the time user numbers continued to rise.

Things are not always so straightforward. When you are setting the priorities there are multiple people who need to be engaged so that they can feed in their requirements. This allows the stakeholders to define a set of objective measures against which you can prioritise. Then delivering incremental updates and improvements allows you to review progress, reprioritise and respond to the new situation after each incremental step.

Isn’t this the way that Wikipedia itself works? The fundamental principles are stated on their website, the content is there for us all to see: we are the stakeholders and consumers. Anybody can check the content against the stated priorities and act upon it accordingly. But only if we buy in to the process and play our respective stakeholder roles by providing feedback in to the project will we effectively collaborate in the process of ensuring that in future it [Wikipedia] has the accuracy that currently it sometimes lacks.