Ten reasons publishers should adopt agile

Agile is an iterative approach to product development ‘where requirements and solutions evolve through collaboration between self-organising, cross-functional teams.’ IPC Media’s Web Technology Director Kelly Waters, who blogs on agile, gives us his thoughts on why media owners should use agile in building new products, ahead of more traditional, micro-managed approaches.

This article was originally published when I worked at AOP, on 23 June 2011


There are undoubtedly many reasons that people adopt agile development methods, whether it’s from a technical perspective or a management perspective, or both. From my experience, here are 10 good reasons to apply agile principles and practices...

1. Revenue

The iterative nature of agile development means features are delivered incrementally, enabling some benefits to be realised early as the product continues to develop.

For example, in more traditional projects, the software development lifecycle is to Analyse, Design, Develop, Test – first gathering all known requirements for the whole product, then designing and developing all elements of the software, then testing the entire completed product.

In agile software development, the cycle is faster and more iterative, doing the analysis, design, development and testing of each feature in turn, one feature at a time. The result is that benefits of the earlier features can potentially be realised while subsequent features are still being developed.

2. Speed to market

Research suggests about 80% of all market leaders were originally first to market. As well as the higher revenue from incremental delivery, agile development philosophy also supports the notion of early and regular releases, leaving the product in a constant development cycle of 'perpetual beta'.

As a result, earlier incarnations of the product can be delivered faster and built upon, rather than waiting for ‘everything’ to be built.

3. Quality

A key principle of agile development is that testing is integrated throughout the development lifecycle, enabling regular inspection of the working product as it develops. This allows the product owner to make adjustments as necessary and gives the product team early sight of any quality issues.

For example, unlike more traditional development methods, testing would start right up-front at the beginning of the development, testing each feature as it is developed. Sometimes it’s only possible to detect issues or potential problems when you can really see a feature working. It’s not always as obvious from a paper specification.

The result is that agile methods are far more likely to produce a quality product, one that not only works as expected, but one that meets the user’s real expectations, not just the expectations they envisaged when the spec was written.

4. Visibility

Agile development principles encourage active user involvement throughout the product's development and a very cooperative collaborative approach.

This provides excellent visibility for key stakeholders, both of the project's progress and of the product itself, which in turn helps to ensure that expectations are effectively managed.

For example, if the product owner for a website is the Web Editor, they would work closely with the development team, participating in fortnightly planning meetings and joining the team’s stand-up every day to see how things are going.

5. Risk Management

Small incremental releases made visible to the product owner and product team through its development help to identify any issues early in the project, or at least as they arise, making it much easier to respond to change.

The clear visibility in agile development helps to ensure that any necessary decisions can be taken at the earliest possible opportunity, while there's still time to make a difference to the outcome.

With more traditional software development methods, it is quite common to realise problems with the software, or with the project’s timescales, only in the latter stages as the product is finally being tested. With agile, that’s not the case.

6. Flexibility / Agility

In traditional development projects, we always used to write a big specification document up-front and then tended to tell business owners how expensive it is to change anything, particularly as the project goes on. In constant fear of scope creep and a never-ending project, we resist change and put people through a change control committee to keep changes to the essential minimum.

The result is a severe lack of flexibility, often meaning essential changes are not made, and that the product and project suffer as a result. Agile development principles are different.

In agile development, change is accepted. In fact, it's expected. Because the one thing that's certain in life is change. Instead, the timescale is fixed and requirements emerge and evolve as the product is developed.

Of course, for this to work, it's imperative to have an actively involved product owner who understands this concept and makes the necessary trade-off decisions, trading existing scope for new. Otherwise, naturally, you may well end up with a never-ending project which you can’t afford!

7. Cost Control

The above approach of fixing timescales and evolving requirements enables a fixed budget. The scope of the product and its features are variable, rather than the cost, and the team and product owner work closely together to ensure these trade-off decisions and the impact of them is highly visible throughout the project, so there are no surprises. Although you can’t guarantee what features will make the final cut, you can at least work to a given budget.

8. Business Engagement/Customer Satisfaction

The active involvement of a user representative and/or product owner, the high visibility of the product and progress, and the flexibility to change when change is needed, create much better business engagement and customer satisfaction.

Relationships between business owners and development teams naturally becomes more human, due to the large amount of face to face communication. People become magically more reasonable, as they understand what is going on and, more importantly, why. This is a very significant benefit of agile development methods that can create much more positive and enduring working relationships. The consequence: a team that transcends organisational boundaries, and actually works as a team.

9. Right Product

Above all other points, the ability for requirements to emerge and evolve, and the ability to embrace change (with the appropriate trade-offs), the team is much more likely to build the right product. Unfortunately, in more traditional software development projects, it's all too common to deliver a "successful" project in IT terms, only to find that the product is not what was expected, needed or hoped for. In agile development, the emphasis is absolutely on building the right product.

10. More Fun!

The active involvement, cooperation and collaboration make agile development teams a much more enjoyable place for most people to work.

  • Instead of big specs, we discuss requirements in workshops, working together with other people who share the same goal.
  • Instead of lengthy status reports, we collaborate around a task-board discussing progress face to face.

Instead of long project plans and change management committees, we discuss what's right for the product and the project and the team is much more empowered to make decisions.

In my experience, all of this makes it a much more rewarding approach for everyone. In turn, this helps to create highly motivated, high performance teams that are very cooperative and enjoy their work.


But there are of course implications. There's no such thing as a free lunch! And there's no magic bullet for software development. In exchange for all these benefits, you do get less predictability, software and humans are still difficult, you can't blame someone else if things don't go right, and it generally requires much more commitment and effort from everyone involved, as teamwork is even more important.

Business owners need to get used to working in a much more ambiguous environment, where uncertainty is accepted, as it’s really the true reality and the nature of software. Similarly, developers and testers need to get used to that ambiguity, and need to take on more personal responsibility. No-one will specify every detail for them. They will not be able to refer back to the spec. They need to think for themselves and get used to the fact that nothing will really be mapped out until the time comes to build it.

So there are implications, but the advantages of agile development are really compelling and in my experience, people rise to the challenge.