What I have seen in real practice is the Agile/Scrum process being imposed from the development side to the design side which is not the way to begin. I have not seen a good implementation of the design process in the Agile model yet, this could just be my bad luck. I believe if Agile/Scrum is the way to go for the design process then it needs to be formalized and have it's own early stage sprints and be clearly defined. Arch/Development sprints should not begin till after the design process is at the very least more solidified else it will be a disaster.
But again my experience could have been an anomaly, I wish I could find a best practice map or set of guidelines that lays out an end to end process where agile design and dev can truly reach that productivity panacea.]]>
Recently I decided to not follow this proces for a client of mine just because they are not ready for it (proven in earlier projects). The waterfall just works better for them.
So choosing this proces is not only a decision for the project manager, you really need a team to back it up. (yes this seems logical, but I found out that a lot of designers (visual and interaction and tech) find it really hard not to have the 'privacy' (lets say 2 weeks with the door locked) to do “their thing”.
The point of “not knowing” is great, that recently is much more accepted by my clients (they really learn) and is a great relief. Just more reasons to choose this proces.
But I also feel that the role of 'designer' changes (maybe it's just me). The agile-project can only succeed if someone is really in charge of the concept/goals/targets. You really need a concept-lead to check if everything is going they right way. This was not different in the 'old' methods but the lead is just more often in contact with the client.
So to me it's a great way of working, but only if you have a group together that is willing and able.]]>