Why Agile Is Right For Web 2.0 Projects
24 November 2011, Jonathan Saipe
In the late 90’s and early noughties, we were firmly in the grip of Web 1.0. Websites were often one-dimensional brochures and the word “brochureware” was often cited – a term which I loathe nowadays.
Such online brochures were less likely to be multi-faceted and integrate 3rd party technologies or mash-ups; nor did they usually require much in the way of complex interaction between the user and the website – bar ecommerce websites.
Managing web 1.0 projects was often a relatively straightforward affair. If the scoping phase was carried out sufficiently well, with no hidden surprises, and if the technology and user-interaction was understood from the outset, then all being well the project was delivered successfully.
Web 2.0 Defined
Roll on to 2004 when the phrase Web 2.0 was born. Web 2.0 refers to websites or web applications that are more participatory, be it information sharing, technology sharing (via mash-ups), or heavily focused on user interaction.
Web 2.0 requires significantly more sophisticated user-centricity, including features such as social sharing, ratings, user generated content (UGC), commenting and other social actions, which is why web 2.0 is sometimes paired with the “social web”.
Rising Up To The Challenge of Web 2.0
The complexities around Web 2.0 mean more web project management challenges.
Working on web projects such as social sites, web apps or cloud based software, where user interaction cannot always be predicted in advance, makes the traditional or Waterfall method of project management almost impossible.
Waterfall says scoping and requirements gathering should be carried out up-front, followed by technical specifications, sitemaps, wireframes, design and production in a sequential manner.
While Waterfall can work well in more predictable situations, it has limitations when trying to factor in user-centered design or when deploying innovate ideas or technology. In the latter situation, Agile can be more effective in running projects successfully and guaranteeing a better outcome for the user.
What is Agile Project Management?
Agile is an umbrella term for a set of project and development techniques designed to ensure that web or software projects (sometimes the same thing), meet the needs of end users in a cost effective, high quality manner.
The techniques are designed to enable a project to respond to change by delivering in short increments, rather than going through detailed planning and requirements phases and then delivering everything in one go (as seen in Waterfall).
Agile is responsive not predictive and encourages learning and feedback during the project in order to build features that exactly meet the needs of end users. With complex web projects that heavily involve user interaction, burying your head in the sand and avoiding change will only result in unhappy users; so a responsive method is actively encouraged for better user-centricity.
Typical Agile methods include: Kanban, eXtreme Programming, Scrum, DSDM, Crystal Methods, each with their own nuances.
The Key Parts Of Agile
1. Incremental delivery
Projects are planned in micro stages termed increments or iterations. Increments contain multiple user stories or features which are a single requirement for the project. These are usually expressed as a single sentence or short paragraph. Features cannot be partially completed. If one feature is not completed, it’ll move to the next increment.
Features or user stories are planned according to priority. Higher priority features must be implemented first, giving the project owner or stakeholder an early return on investment and positive revenue generating features quickly.
Sometimes higher priority features can change over the course of project, based on user feedback, so incremental delivery offers the most flexibility and greatest chance of meeting user needs quickly and with the least budget spent.
This is a real plus for Web 2.0 projects as they often demanding on user input (take Facebook or LinkedIn for example), so adapting to user needs during the build is critical to get right.
In Waterfall, we have the “MoSCoW list”, a way of prioritising requirements by listing them as Must Have, Should Have, Could Have, Would Have. Whilst this is useful task to carry out, it doesn’t compare to Agile’s prioritisation and incremental delivery as the MoSCoW list is often drawn up at the start of the project.
From a Web 2.0 perspective, MoSCoW still requires the project team to understand user behaviour from the outset – no mean feat with complex user input and output.
Agile tends to focus on variations in scope rather than time or cost. Each increment is a fixed length – often 2-4 weeks in length. Timeboxing refers to a fixed increment length within which a set of features is delivered.
As mentioned above, if features are not completed, they move to the next increment. The increment doesn’t change in length and it is therefore timeboxed.
4. Test driven delivery
In Agile, production quality features are built right from the start. Quality is not negotiable. Test driven delivery is an Agile technique where tests are written before an activity takes place and the activity is only completed when the tests are passed. At the end of each increment, tests are carried out to ensure production quality features are produced.
Continuous testing is all part of a user centred design (UCD) process, and with Web 2.0, user interaction needs to be understood and tested throughout the entire length of the project.
If you’d like to learn more about deploying Agile techniques and how to bring agility to your web projects, check out our Agile Web Project Management training course.