DesignNotes: DesignNotes by Michael Surtees » Blog Archive »
edwin Rozendal
· 7 months ago
I enjoyed your talk/presentation and I must say that the 'agile' way of working looks the way to go.
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.
Nerd Stalker
· 7 months ago
Would be great if you did another one of these with a Mic the audio is a challenge to hear and audio is everything in one of these. Would also be great if you could do a longer session with more Agile specific examples from a-z as opposed to the high level change of mindset type stuff.
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.
michaelsurtees
· 7 months ago
I can't disagree at all with that assessment. Ideally once you have the road map considered and start prototyping hopefully some of the design principles have been sorted out.
All Comments
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.
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.