Few people who have experience of delivering software projects would promote using the Waterfall Model and Big Design Up Front for managing software projects – accountants, bureaucrats and those that believe ‘designers’ possess crystal balls aside.
Most experienced technical project managers and developers recognise that a more agile approach is needed. One where the focus is on delivering working software, not ‘artifacts‘ and, where the project seeks to deliver via a series of rapid iterations not rapid recursion. This is because in addition to being more realistic and recognising that software is delivered by people rapid iterations reduce complexity and therefore risk.
There are of course a wide range of agile methods available and plenty of consultants and training companies out there promoting them. However, I fear that too often the way agile methods are employed, on the ground, is more akin to a sequence of mini waterfalls. That is there is a tendency, within each iteration, to lead with design (often creating Photoshop files) before coding up the application based on those designs. I suspect that this often happens for a number of reasons, including:
- engineers and developers like to solve problems and are happy to solve the problems whether they are set by the client or a designer;
- the waterfall model is still prevalent and people ‘expect’ design to start the process;
- people tend to prefer working in isolation – agile methods require people to work in close collaboration.
These and other reasons mean that if a team is left to their own devices they tend to default to the modus operandi of design up front (even if it’s small design up front) because it just feels more natural. And of course since agile methods encourage teams to decide how they are going to tackle the work this is too often the sequencing of work they settle on. But that doesn’t make it right.
It is better for the Project Manager to encourage the team to reverse this sequence by, for example on a web project, having designers working directly with the mark-up (designing with css) where the mark-up is being delivered by web apps which have been built by software engineers. And the software engineers, they need to work with the designers, information architects and client to define what data is needed on each page – by understanding the problem and the domain model.
Photo: Plitvice Waterfalls, by mpancha. Used under licence.
Derivadow 
In my department we have the reverse situation mini waterfalls backing in to mini-agile projects! What I mean by this is that we usually follow a waterfall-like development (partly due to lack of IAs and partly due to most new development needing to work within existing templates). But as you might expect the waterfall often fails because project owners will want to revisit the designs once they see a working prototype. At that point a project manager can play waterfall hard-ball (did I just invent a new water sport?) and whip out the change control procedures, or he can assess the resource availability and budget and see what can be done. In a large organisation with good internal resources this is not as disastrous as it might be for a small agency (provided the PM knows his game of course). I’m not advocating this as good practice, just my experience as to the reality of project management vs. the text book.
Indeed, I suspect the majority of projects are run using waterfall/BDUF – but as you point out the approach often fails because, for example, product owners change their mind when they see working code. I think this is because it’s just too difficult to think through all the design issues in the abstract – we need something concrete to try out.
I guess my concern is that when you are working with ‘enlighten clients’ who have embraced, or at least accepted, an agile methodology the worst thing you can do is adopt a waterfall approach within the team (it’s like being given a get out of jail card but deciding not to use it). While I don’t think this is intentional it can happen because we all get use to the status quo and so ‘expect’ design to front every sprint, with the result we recurse rather than iterate through the design and build.
[FYI we use Scrum here]
where is that waterfall its the prettyst thing ive ever seen
@where – it’s not my photo (see http://www.flickr.com/photos/mpancha/1449520442/)
According to the phoographer its Plitvicka Jezera in Croatia. It is lovely.
wow that amazing!
WOW THAT WATERFALL IS BEAUTIFUL!
WHERE WAS IT TAKEN ? PLEASE TELL!
THANKS -CHEXICAN
OH NEVERMIND!
I DIDN’T SEE THAT POST ON WHERE IT WAS. SORRY TOM! :)
thanks for the useful post, useful info i found on your article.i bookmarked this article.
“having designers working directly with the mark-up (designing with css)”
Hmmm. I can’t see how you can design rapidly or creatively design with mark-up and CSS. Design prototyping tools like Axure allow interaction designers to very rapidly move objects around, design completely new interactions and quickly view them as prototypes. Unless you are suggesting some kind of WYSIWYG built by engineers in the team?
I think a more reliable way to get a better user experience is that the design teams evolves design patterns and components that are reusable and rapid to build, that way interaction design timelines are rapidly reduced. A feature could be designed and built in one sprint.
On the whole I think most interaction designers would be uncomfortable just working with CSS. Even those with an expertise in HTML and CSS. More complex features and interactions and experiences, where an interaction designer is solving difficult problems requires design up-front, there’s no way around it. Sketching, thinking, prototyping are all tried and tested design methods. I dont think its feasible (in the majority of cases) to try to shortcut design just to make Agile (a development methodology NB) work, unless you have a very consistent and simple set of design problems that you want to solve.
PS!
My recent experience has been that user stories start as episcs, then detailed stories are created in a top-down, bottom-up process between product owner and UX, and in consultation with development. The user stories enter the dev cycle well defined and with at least interaction design in-place. Granted, visual design can happen in-sprint.
It has design up-front. Buts it’s not Big Design in the traditional sense.