Yes, all clients want this, I think :-) But what design? The entire thing? The home page? The signup page or shopping cart? Just the overall structure?

I think even with design, it’s possible (and beneficial) to incrementally deliver. Not where you change everything each time, but “finish” a manageable piece.

“plus would find it difficult to find the time to review and provide feedback on version of features.”

Yes, there is a time commitment, but the idea is that you’re doing this to reduce the client’s risk, and you’ll need this frequent communication anyway for a good outcome. The alternative is “signoffs” on what “we all agreed to” a few months ago, then an adversarial relationship during the “construction” of the site.

So maybe you design the overall layout and call it good. Then next time the client might be reviewing a catalog page layout. Most humans can’t reasonably review more than 3 or 4 major things at a sitting anyway – so why force them to review 20 major items with lots of details up front?

Again, I really can see the advantages to this approach in the development phase, but the clients I deal with all tend to want to see design first and want to know exactly what functionality they’re getting – plus would find it difficult to find the time to review and provide feedback on version of features.

The more I research, and hear, about Agile, I am more swayed towards a methodolgy that uses approaches from several traditional methodolgies… I so need to to compile my thoughts into an article! Would love to kick off a healthy debate on the topic.

I think that an Agile approach is especially well suited for a smaller agency. In my experience, the smaller the shop, the less formality you need, but the principles are solid.

The place to start is really in incremental/iterative delivery. Instead of creating a detailed spec, estimating every piece of the project, then delivering the first big chunk to a client 3 months later, an Agile approach would say:

Get an overall sense of the client goals, etc., then choose a few of the basic website functions and deliver those in a couple of weeks. Get feedback, choose some additional priorities, and repeat.

When it’s “good enough”, the client may decide to go live, even without all of the features in the original plan.

To be fair, Agile is probably more beneficial to the client than it is to the web shop – they’ll have more visibility, be able to see the site evolving quickly, and yes, be able to kill the project if it’s moving in the wrong direction.

But like you, I too believe in not picking a methodology and running with it, it has to be whatever works for each company, and sometimes each project. At small web agencies I find most use a hybrid of Waterfall and Agile.

Waterfall in that phases are planned sequentially, planning, design, build, test etc. but Agile in that if a change is required to a phase that has been signed off, most agencies will make not point blank refuse to do so (as per Waterfall methodology), but instead work with the client to accommodate scope flexibility under a fixed price budget by perhaps compromising in other areas (as per Agile).

I will steal someone else’s quote and say that I believe in “appropriate planning” for a project, sometimes its little, sometimes it’s a lot – it really depends on the project.

One, of many, ways to judge what appropriate planning is, is to ask the questions “Has the planning captured, for us and the client:

* What is going to happen in this project?
* What is not going to happen in this project?
* If scope creep starts to happen, has ambiguity been reduced enough to push back?
* When is everything in the project meant to start?

If the answer to that question is “yes”, enough planning has probably been done. Sometimes this can be done in an e-mail, sometimes its five documents – the key lesson is to know when it’s one or the other.

Good points. I do manage an in-house web team that primarily works on 3-4 large websites. While we do client based work from time to time, mostly we are developing for in-house management. We work on both full website creation/redesigns with many members of the team, and on web app projects, with one or 2 developers at a time.

I am not a purist of any methodology at all. Rather, I try to be effective and practical. Keeping up on technologies, and techniques, and molding them to my particular situation. We have a relatively small team, and have had to adapt our development in order to keep innovating. We have adopted many techniques of agile/iterative development.

Personally, I am also not a fan of too much planning, because plans change too frequently, and plans really only create an ‘illusion of agreement’
I have written an about this topic, it may be of use to you in creating your agile post. Iterative Development is Effective: http://www.effectivedevelopment.net/2009/03/iterative-development-effective/

I’m considering writing a post on the practicality of Agile in a small web agency environment simply because I can’t see it working..yet. Not only because of the variety of work but also the fact that in that agency environment you are working with different people all the time but also the clients not feeling comfortable with such a project management methodology.

I would go into more depth here but it would list the points of my planned article. But everyone who I meet who says they work in an “Agile” way, either genuinely does and is part of a team that builds web applications or very large websites, or, just say that to make their lack of planning skills look intentional – and I’m yet to find someone working in a small web agency who gives Agile the thumbs up as an agency-wide methodology that works well.

However, I SO want to meet people who can convince me, I feel like I’m not quite in the cool gang while I’m not practicing Agile :)

I have my reservations about the practicality of Agile in a small agency simply because of the kind of projects we tend to work on; small to medium sized websites.

However, when developing web applications I think it would prove extremely effective, and that’s why it works in large company environments.

The big barrier in my head I have is how you would go about mixing up the methodologies in a small agency. I’m not sure its feasible to run two projects using a Waterfall / Agile hybrid way, and three others using Agile and with team members spanning both… sounds messy to me – but I’m very open to hear opinions from someone with experience of Agile in a small agency!

@Rob and @Jim, what do you think about Agile in a small web agency?

I personally find a hybrid of Waterfall and Agile works best, in that each project has a fixed price, but the scope is flexible-ish throughout the project, as long as quality and schedule arent affected.

Very true what you say about learning from mistakes. I’ve gotten into the habit of jotting down anything that I miss during any web project now, and then adding it to my mega huge web project task list template.

This combined with an ever increasing sized lessons learnt document help me try to avoid future fires, although new ones just keep popping up!

Maybe it will be complete when I retire.

When I don’t love doing something I tend to do it quick n dirty too if the truth be told, but if it’s something that could be expensive to get wrong, I bring in the professional and give them the time and money they want!

As for if there is something inherent about working with the web that encourages somebody to be a fire fighter… wow, that’s an interesting question, not one I’d really thought of before. Web projects do seem to be extremely fluid in nature and thus that could make them hard to manage in a structured way, or it could be that the industry, and practice of web project management is still really in it’s infancy and so a tried and tested formula hasn’t yet been created? Unlike with I.T. projects and making a TV programme… those projects have been run for a million years now, but maybe in the first ten they were run by Fire Fighters too! Very interesting…

The differentiator that I look for in a Project Manager is what they do after they have fought a fire. The good ones reflect on what happened and ask questions – Why did the fire start? Why didn’t we notice that it had started sooner than we did? How could we have put it out faster? Then they proactively apply that to the next project.

Maybe that’s why a good plan feels like fire prevention, but with the hindsight that comes from having fought a few fires at the sharp end.

Anyway – another thought provoking post – am looking forward to part 3!

Also, the stress and pressure involved with being on the edge in this way is simply not sustainable.

Do you think that people are fire fighters because they genuinely believe it to be the way that a project should be run or is it because of lack of experience / even laziness?

Is there something inherent about working with the web that encourages somebody to be a fire fighter?