One year ago I joined Caplin as a UX designer. It was my first experience working on a true Agile environment and it took me some time getting used to, but I believe it can be done. The list below collects a few observations from working on Agile projects over the last year, in no particular order.
This week (Feb. 15th) Caplin is hosting a Agile UX Safari, it’ll be an awesome opportunity to discuss and compare different approaches to Agile UX. See you there!
Relocate with your team: relocating with your team helps communication and building team spirit, your team should be comfortable asking you questions and sitting right next to them is the best way to achieve that.
Show interest on all aspects of a project (yes, that includes the backend): when starting a new project spend a few minutes talking to your team mates, as it might be that this is the first time you’re working together. It’ll pay off in the long run and will make agile activities like standups less painful. Wikipedia is helpful here too – if you keep hearing a certain word over and over again it’s worth checking it out so you’ll have at least some idea of what it means.
Assume responsibility for checking the quality of work: Think of it as a UX QA. Check that both the interaction and the visuals match your design, but don’t expect your team to be able to follow every detail of your design from day 1 – they’ll learn to appreciate and pay more attention to details over time.
Acquire some frontend development knowledge: it helps communication with developers and also keeps design decisions grounded. That awesome idea you had for a feature while you were on the shower? If you can’t find any example that somehow relates to it, it probably can’t be done (yet).
Join all the Agile activities proposed by the ScrumMaster: Stand ups, retrospectives, planning sessions, etc. are all part of the process, and you’re part of the team, so be there. On time.
Keep the Big Picture in mind: when working on the individual goals of a sprint, don’t forget the big picture. Where does this feature or component fit in the overall application? What user goals is it accomplishing? Probably one of the most difficult aspects of designing on an agile environment.
Learn to deal with expectations/frustrations: that really great feature you thought of? It might not happen any time soon (or ever), get over it. Design the best you can on the given time/budget. If the results show off, your client will find the time (and budget) for any other improvements you propose.
Do not be afraid of being picky: Every pixel counts, and your team will learn to appreciate the detail of your work, but keep in mind the next item on the list…
Learn when to let go: Sometimes that 2px mis-alignment is not as important as a build failing or an external environment that can’t be accessed by the client during a demo day. Learn when to raise your concerns.
10. Make the design process transparent: Avoid “ta-da” when designing, that’s when you go back to your desk and show up with a “finished” design idea hours/days later. Make your design process as transparent as possible, create a wiki page or equivalent to show the progress of your work, from sketches to detailed visual design, people will understand (and respect) your role in the project if they can follow how your work is done. Leave magic to magicians.
11. Don’t be a jerk. Let me say this again: don’t be a jerk. No one enjoys working with a jerk, especially an Agile one. Check out Robert Sutton’s The No Asshole Rule (chapter 4 “How to Stop Your Inner Jerk from Getting Out” is particularly useful).
I’ll try and keep this list updated with new comments based on my experience with Agile UX, so check back in the future.