Your SlideShare is downloading. ×
0
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Agile & UX
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Agile & UX

4,077

Published on

Agile Development and User Expereince: a primer

Agile Development and User Expereince: a primer

Published in: Design
2 Comments
6 Likes
Statistics
Notes
  • The solution is for the Designer to become the Scrum Master? That sounds roughly equivalent to the project manager being the designer. Oh wait - I guess some RIlly Big Companies do it that way... I certainly appreciate the problem, and your comment that success in one Agile product is no predictor for success in another depends on many factors including organizational design, process ownership, general politics, depth of detail in design documentation, whether the project is a new 'from scratch' development or additional features on a mature code base, etc. In my experience Agile is simply developer management and has nothing to do with design. I would really like to see some Agile Design methods that can work hand-in-hand with this movement toward incremental development.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • To get some missing context I put an explanation in my blog. Here it is to be more user friendly than just provide a link (http://arnoland.blogspot.com/2009/10/agile-ux.html):
    The presentation below started out as a short talk at the UX Cocktail Hour. However, the presentation has been gaining in popularity. So I decided to post it here. Because it does not really stand alone to people not at the presentation some misunderstandings have resulted. I will record the presentation with audio, but in the mean time, let a few words here suffice:
    It is a design-centric view of Agile, or rather a War weary design centric view of agile.
    The main point being that Agile is not a development method as much as it is a way of setting aggressive deadlines. What happens in one Agile project does not predict success for another. Instead the designer needs to be Agile in figuring out how they can best fit in. However, that agility should not extend to your design process. Designs still need to be well thought out concepts not something grown together in piecemeal increments.
    The bottom line message (found on the last slide) is to be truly successful in Agile, you need to follow your own design process but be intimately involved in the Scrum process, preferably as a Scrum Master. This is essential for maintaining an overview of what is going on with your design. At the very least, own the user facing stories/requirements in the product backlog.
    And Sherlock Holmes and Dr. Watson were meant to personify regression testing.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
4,077
On Slideshare
0
From Embeds
0
Number of Embeds
33
Actions
Shares
0
Downloads
0
Comments
2
Likes
6
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. The Average Ideal Agile Method Jonathan Arnowitz The Devil’s Advocate
  • 2. First Meet the Patron Saints of Software Engineering
  • 3. First Meet the Patron Saints of Software Engineering Lorenzo II de Medici Niccolò Machiavelli The first pointed hair manager The first Dilbert What The can I do? ends justify the means
  • 4. Evil These ends do not justify the means Source Free as in Freedom website.
  • 5. Good: An Agile Primer Source http://effectiveagiledev.com/
  • 6. The Agile Safety Valves
  • 7. The Agile Safety Valves
  • 8. The Agile Safety Valves
  • 9. The Agile Safety Valves
  • 10. The Agile Safety Valves
  • 11. The Agile Safety Valves
  • 12. The Agile Safety Valves
  • 13. The Agile Safety Valves Inefficient
  • 14. The Agile Safety Valves Inefficient Disaffected
  • 15. The Agile Safety Valves Inefficient Time killing Disaffected
  • 16. The Agile Safety Valves Inefficient Time killing Disaffected Distracted
  • 17. The Agile Safety Valves Inefficient Time killing Disaffected Distracted Waste of time
  • 18. Agile • Agile is for small co-located teams • Favored by large companies with low confidence in their process • Agile is for and about Engineering • It started out as a Designer-hostile movement • Improving waterfall makes much more sense from a design perspective
  • 19. Agile Myths
  • 20. Agile Myths • Agile is iterative
  • 21. Agile Myths • Agile is iterative • (it’s incremental)
  • 22. Agile Myths • Agile is iterative • (it’s incremental) • Agile is design friendly
  • 23. Agile Myths • Agile is iterative • (it’s incremental) • Agile is design friendly • (it is cut-throat engineering, with a forest of potholes, traps and other gotcha’s)
  • 24. Agile Myths • Agile is iterative • (it’s incremental) • Agile is design friendly • (it is cut-throat engineering, with a forest of potholes, traps and other gotcha’s) • Agile clarifies
  • 25. Agile Myths • Agile is iterative • (it’s incremental) • Agile is design friendly • (it is cut-throat engineering, with a forest of potholes, traps and other gotcha’s) • Agile clarifies • (it obfuscates via the backlog and the divorce of design from process/requirements)
  • 26. Agile Myths • Agile is iterative • (it’s incremental) • Agile is design friendly • (it is cut-throat engineering, with a forest of potholes, traps and other gotcha’s) • Agile clarifies • (it obfuscates via the backlog and the divorce of design from process/requirements) • Agile is sound
  • 27. Agile Myths • Agile is iterative • (it’s incremental) • Agile is design friendly • (it is cut-throat engineering, with a forest of potholes, traps and other gotcha’s) • Agile clarifies • (it obfuscates via the backlog and the divorce of design from process/requirements) • Agile is sound • (loose cannons pressured for quick results who throw out every known Agile safety valve)
  • 28. The wrong picture
  • 29. Designed Geknutseld The wrong picture
  • 30. Focusing on the wrong things
  • 31. Focusing on the wrong things Essential for design Essential for evaluation
  • 32. Agile UX Primer
  • 33. Can I play?
  • 34. Rather not
  • 35. Play ball
  • 36. Whatever
  • 37. You’re kidding me
  • 38. Excuse me, you’re in the way
  • 39. Good news: you can’t play
  • 40. • Agile is just a new flavor of Machiavellian Software Engineering: • the only rule is what works for this particular company/organization • but requires new strategies • No one Agile Development method fits all
  • 41. Nevertheless, Some Agile Specific Strategies • Strive to become the SCRUM Master or at least co-SCRUM Master • Attend all meetings especially so-called useless ones • Design hostility keeps you on your toes • Agile means agile for developers not you • Own the backlog or at least the user-facing issues (including so-called non-UI ones)
  • 42. Questions?
  • 43. Questions?

×