Last Friday Malcolm Beaton started a thread on our internal User Experience and Agile Community mailing lists - on how User-Centered Design and Agile can work together and any friction that may occur. Simon Bennett, one of our Agile Coaches, made a point that resonated - any problem may be "related to *how* we’re doing UX and/or Agile, and not inherent in either Agile or UX itself".
I started thinking about all the Agile projects I've worked on in the last 5 years - from short innovation-centric projects to full blown year long e-commerce projects and I managed to distill them into 4 different patterns:
Balanced Delivery
The Designer, UX and Developer work hand in hand; all strategy, features and decisions are discussed and decided as a whole. If there were technical issues, workarounds and compromises will be made. All team members pushed each other to do the best they can. In short, a beautiful working relationship that is geared towards creating something rather special. I've experienced this pattern on small to medium sized innovative projects where the end goal is known, but the journey to get there is unknown and the client is fully engaged and supportive. I've experienced this pattern twice and those projects are still a personal career highlight.
Unbalanced Delivery
Due to delivery commitments / being late to the engagement, the Developer is not so involved in the Design / UX process which slants the strategy, features and decisions, causes drift and less room for workarounds and compromises as issues are not generally found until implementation occurs.
Creative Led Delivery
Being late to the engagement, either by commitment or project set-up, the Developer arrives too late to input on strategy, features, decisions on what’s possible and achievable. From a team gelling perspective - the Developer can feel slightly left out because all the fun work has already happened and feels like they are just an agent of implementation rather than delivery.
Buffered Creative Led Delivery
Designers & UX have to run an iteration ahead of the development in order to keep the queue of work full. There may be Developer input into the process, but unless iteration capacity is adjusted to allow for collaboration, Developer input may be limited or insufficient, this is not ideal; decisions may be made in isolation as Development team are too busy developing to feedback into the Design / UX process. This pattern keeps the team running optimally, but may lead to long term problems.
Matt Roadnight pointed out that the following diagrams are missing "the customer" - so I'll leave it to you to add them (they should be central to each pattern).