Strong opinions abound as to the extent to which agile should be implemented in a team which builds websites. I used to work at BT where agile development practices were so deeply ingrained that anyone not fully agile was viewed with derision - no doubt arising from bad experiences (Update 19/3: there's plenty of non-agile behaviour in BT, and the previous link was aimed at them. See Kerry's response below). But, coming as I do from a design-led background, this never sat entirely comfortably with me. In my experience, websites (and other products) not considering design from the outset are pretty awful to use. There are of course exceptions, but I haven't worked on them, and I think they're pretty rare. Maybe the project team had a developer with strong design sensitivities? A rare beast indeed.
The shortcomings of a waterfall approach are well documented - and learned first hand I should add. By doing all the graphical design (and too much documentation) up front, it restricts the chance to iterate during build and learn from testing. The process takes much, much longer and you end up with a poorer product which is difficult to fix. Unhappy customers claim this isn't what they asked for. All this is well known.
But the shortcomings of agile aren't often aired in public. When you implement one feature at a time, and build out from there, strategic vision often gets overlooked, as does design integrity. User experience and overall aesthetic tends to take a back seat. There's little consensus up front on the final solution, which means there's a level of uncertainty about how current work will fit into the solution down the road. The larger the team, the more these effects are amplified. And from an agency perspective, clients usually tender out work based on functionality agreed up front - if you're unwilling to commit to this, they'll go elsewhere.
There are several options that try to blend the best of both worlds, outlined in a session here at SXSW by Karl Nieberding (eBay) and Kris Corzine (Wells Fargo). These include "Mini-waterfall", where you put developers and designers in every sprint. The problem is that you get the same problems as full on waterfall (though less pronounced). There's also "Just in time", where designers work two sprints ahead of development, making sure design work is available when developers need it - and there's a sort of interim design vision to work towards. But then you lose agility and flexibility. You can find yourself working on three sprints at once - next, current and last (for testing). There would be too many complex interactions and versions to track - a huge loss of focus.
The system that works well for us at The Team, endorsed by the speakers here, is a system of partnership between designers and developers throughout the life of the project. There are steps you can take to reduce the waterfall risks, getting developers involved in the design process. We test (at best) or peer review (at worst) throughout the project based on whatever assets are available (sketches, wireframes, early designs, prototypes). Most of our projects are fairly short anyway (1-3 months), reducing the risk / impact of upfront design. And when it comes to build, we adopt standard agile development techniques, using e.g. kanban charts, scrum meetings, and other agile practices.
We've found this works best when we put a lot of emphasis on effective kick off meetings. This is the chance for everyone to contribute towards the vision of the project, and for all to understand what it is that's motivating the customer. A good kick off meeting is critical.
It also places a lot of emphasis on the sketching phase of the project. By kicking around the various approaches in sketch form together, designers and developers can explore the best way to solve problems. Then during design the developer can be thinking (possibly subconsciously) about how the solution might be built.
The proof of the pudding, of course, is in results. As well as defining KPIs at the start, we get a sense of success from whether our customer is happy and if users are satisfied. I'm pleased to say that we've had a lot of success implementing this approach, although the fact we improve with every project shows that we have a lot more to learn.
I'll leave you with the 7 rules of engagement as provided by the above-mentioned SXSW presenters:
1. Shared vision - defined clearly at the outset
2. Engage team - ask for input from everyone, but make it clear it isn't necessarily a democracy
3. Stakeholder buy-in - risk involved, but also reward
4. Excite with prototypes
5. Sit together
6. Communicate - build empathy
7. Get out of the way - once you've established working patterns, support rather than dictate
I can't emphasise No.5 enough - in my experience, all of this falls apart if you're not in constant communication. I don't just mean meetings (which we try and limit), I mean the awareness of activity across the team and involvement of people at a time convenient to the project.
And there's one more thing missing from this - I think the team can form around clearly articulated and prioritised software requirements. This helps drive assumptions out of the system, bringing crucial alignment to the thinking going on in the group.