Thanks – you raise some very good points. I believe that Agile can sit on top of the process I outlined, which is how we work in our organization. We do a lot of the upfront work (uncovering needs, prioritization, requirements, etc.) before issues go on the backlog, but once they’re in a sprint, we continue iterating as we go along.

I agree that some (not all) projects require Big Upfront Design, but I do believe that the last 20% or so of those specs should happen as part of the Agile process. So, in terms of how this impacts contract work, I think it’s important for the contractor to (1) involve engineering during the upfront design work, and (2) stay available during the sprint so that the last 20% can happen as part of an Agile sprint.

BTW, here are a couple of great articles on how UX fits into the Agile process:
http://agileproductdesign.com/blog/emerging_best_agile_ux_practice.html
http://www.andersramsay.com/2010/07/08/agile-ux-and-the-one-change-that-changes-everything

I think this is the way to go in order to fulfill everyone’s product/project requirements.

I however struggle to see how the doing things in a Agile manner (eg Scrum) can be better than this process (let’s call it a waterfall type of process) will focus the team on
1) finding out what the requirements are for a project
2) brainstorming & researching potential solutions
3) defining that solution and outcomes
4) adjusting the solution based on time, functional, technical or budget constraints
5) finally having an idea of what’s needs to be built – aka final Spec
6) start building and testing
7) tweak things while building due to technical and UX issues/learnings
final testing & bug fixes
9) deploy
10) maintain

The I understand that Agile methods like Scrum utilise use cases to cover steps 1-3 above however they don’t appear to dig into the details. I’ve found that it’s often better to get into as much detail as you can initially to find potential problems or hurdles before you start development. Obviously it’s not always possible to see potential problems ahead of time.

I agree with Agile in principle and to a certain extent am Agile with projects (and functionality and features) that have ‘big design’ up front, but I don’t think that one can do away with ‘big design’ upfront on contract projects that require a fix cost quote up front.

Maybe if one works in a organisation where you develop internal applications where there is more flexibility in terms of project size, deliverable dates, etc and where the staff are full time employees vs per hour contractors/resources.

Does this make sense?

I agree with you 100% on the need for user feedback. I see this fitting in during 2 phases: (1) Requirements gathering (feedback on existing flows at the very beginning of the process), and (2) the Build & Iterate phase. Depending on the size of the project/changes, the feedback can be on wireframes/paper sketches, the hi-fi mocks, a functional prototype, or some combination/all of the above. As I mention in the post, the importance of user feedback cannot be overstated, and “we have no time” is no excuse — you just adjust the artifacts you get feedback on based on the time/budget you have available.

In an agile environment, where UX is in danger of being left by the wayside, it’s important to point out that this phase doesn’t have to hold back development – you can still iterate on the mocks while back-end development + the basic front-end framework implementation is happening. I’m partial towards this approach because I’ve seen too many times how endless user research cycles can hold up development and make a project drag on much longer than it needs to. So I personally like the idea of iterating and doing user testing as development kicks off, since there’s usually plenty of dev work that needs to happen before final front-end mocks are needed.