An introduction to Agile
For me the process of designing and building websites is a fascinating experience; wholeheartedly satisfying but at times very challenging too. Having over ten years experience producing digital projects both big and small means that I've learned a great deal about managing projects too, gaining insight into the pros and cons of a variety of approaches and working methods. When I say working methods I really mean is 'just the whole darn process of planning, designing, building, managing clients and expectations etc from start to finish and onwards'.
Here, I would like to discuss two of the most common approaches; one being Agile, the other being Waterfall. They are in some ways opposite in nature and so hope by comparing them I will be able to identify some key features of both.
Back in the day
So, back when I started in web design on a smaller project, ordinarily I, or someone else would grab the print literature for a particular client and then build a fixed size web design from that. All the other pages of the site would also be designed up, printed out and shown to the client who would approve them (hopefully). Then with all the content (from the brochure) at hand it was a case of going away sticking the headphones in and building the whole thing from top to bottom, until finally just before launch date the client comes in, looks at the site and loves it! Awesome and so simple.
Nower days though thankfully the web is far more being far more expansive, flexible and complex and the ability to plan and deliver fixed designs and specifications from start to finish is far harder to achieve, especially with big projects. In fact the whole idea of 'start to finish', I think is a little strange in this process, because when you launch the site, that's really just the start. The start of an ongoing process; adding, refining and testing content and features. Not only do we need to be flexible in production, but our designs do too; now being delivered on any number of devices and resolutions.
Waterfall is largely perceived as more 'traditional' and I suppose is exemplified in some ways by the example above. It's all about planning; specifying all the features and information architecture in great detail using wireframes, prototypes, sitemaps, content collation and a great deal of detail so that what is delivered is unmovable and written in stone, from start to finish. Once this is complete and everything is ready so then the build begins and it will stay that way until complete. It may have some feedback and staging test sites, but it's much more about getting everything done within that estimated costing come hell or high water to the pre-build specification.
All very well, but if you're on a big project and start to finsh (or start to start) could be 6 months, then expectations may obviously change. Agile is kind of centred around the concept that during the process of plan, build and delivery nothing is fixed and that frankly 'we know things are going to change' so why plan everything anyway. What I like about this process is the regular client contact, not just at the start, but all the way through. this allows a site to grow and change organically and it leaves no room for huge shocks later down the line if a feature doesn't work how it was intended. I work in a business of communication and so regular contact, testing and feedback for me is essential.
It's also about flexibility. I'm simplifying a great deal here but with Agile the site build is divided up in features and blocks and each is developed in turn. Each feature must be completed before proceding onto the next one and so a very linear but comprehensive step by step approach occurs. At the beginning of the process each block or feature has an estimation of time put against it, this is then converted into a relative points score. It's also given a 'definition of done'- a description of exactly what it will be when complete.
What this means is that each stage of the process can be 'costed up' using the estimated points (time/cost) and a very clear scope of progress can be seen; before, during and after production which means if a feature is taking less time than expected then at the end there will be money or developmment time left over; unheard of generally usimng Waterfall. Alternatively of course it could be that if certain features take longer to develop. Then either other features are pushed out of this paid stage and will either need to be dropped or 'bought back' by the client. With Agile production is flexible and adaptive.
To a client this might sound understandably frightening; they have a fixed budget and they want everything in the spec. However, in my experience, the vast majority of projects actually come in at a lower price than if it had been fixed a fixed rate. When people quote for jobs using Waterfall they have to add on a certain amount for the 'well we just don't know how long that'll take, could be four days could be ten'. With Agile you pay for every feature and get each one complete in stages because it's so modular, for a client it must seem much more risky, but if the gamble pays off, you get a much better product at a better price.
A bit of both? Depending on the beast
I also believe that both methods are totally valid and I use them both depending on the size of the project. In fact I think it's possible to take a bit of both of them; some of the planning, research, wireframing and sitemapping can be really useful and although these are all not exclusive to either Waterfall or Agile, the large up front planning is more synonymous with Waterfall. However I do like many aspects of Agile and have adopted them in the way I work, particularly the regular feedback and client contact, but also the flexibility; doing things in stages and shifting around and adapting as the project develops and changes- it has an air of realism about it. Agile was originally conceived for software development and so fitting it into website development does, I think result in the need for using some of Waterfall's planning features, but not too much and in stages along with the clear structured blocks of feature development.
To compare such large working methods in a short blog is difficult and there is a lot more to both approaches and loads more reading out there. But for me Agile is my logical favourite and the approach that works best for me on bigger prjects, but I certainly am not drawing any lines.
Credit due for some great Agile training with Cake Solutions last year.