being agile being good
play

Being Agile, Being Good Stephanie Troeth Paris Web, 2009 - PowerPoint PPT Presentation

Being Agile, Being Good Stephanie Troeth Paris Web, 2009 Stephanie Troeth co-founder/CTO, Book Oven Previously: UX consultant and mercenary product manager for startups Director of Interactive Technology at an agency What I


  1. Being Agile, Being Good Stephanie Troeth Paris Web, 2009

  2. Stephanie Troeth co-founder/CTO, Book Oven Previously: UX consultant and mercenary ✦ product manager for startups Director of Interactive Technology ✦ at an agency What I don’t get paid for: Web Standards Project (WaSP) ✦ member since 2002 WaSP InterAct ✦ Open Web Education Alliance ✦

  3. Meeting point: agile & quality

  4. “Agile” is not a single solution, but is a group of software development methodologies that share the same core principles.

  5. An Agile Approach — “Agile Estimating & Planning”, Mike Cohn

  6. Work as a team.

  7. Work in short iterations.

  8. Deliver something each iteration.

  9. Focus on business priorities.

  10. Inspect & adapt.

  11. Compared to the familiar waterfall: less documentation less “fixed” process less (long term) planning = perceived chaos

  12. The philosophy behind agile is that you never start with a perfect plan.

  13. It is a method for dealing with the unknown, and to use new knowledge to guide ongoing work.

  14. Quality: what is it?

  15. It is easy to think that quality results from a process.

  16. It is easy to think that quality results from a process. people

  17. “The best teams didn’t have a methodology or dogma they followed. The struggling teams often tried following a methodology, without success. [...] The best teams all focused on increasing the techniques and tricks for each team member.” — Jared Spool & User Interface Engineering http://www.slideshare.net/jmspool/journey-to-the-center-of-design

  18. “But if Quality and excellence is seen as the ultimate reality then it becomes possible for more than one set of truths to exist.” — “Lila”, Robert M. Pirsig.

  19. Quality is relative.

  20. what is valuable to me != what is valuable to you.

  21. Apply this to a team scenario: what a designer deems as quality != what a developer deems as quality != what a project manager deems as quality ... etc.

  22. So how does a team define quality, if we all have different and often contradictory ideas of “what is good”?

  23. 1. The Stealth Method: Foster a strong team culture that thirsts for quality.

  24. Understand what each other needs to succeed...

  25. ... so each of us can take pride in what we do.

  26. Pride is a big motivator.

  27. 2) The Measurable Method: Instill a quality vision as a belief system.

  28. A belief system is stronger than any process.

  29. Empower members in your team. Enable them to decide what is the right thing to do.

  30. A quality vision definition: ✦ generic enough so that it can be interpreted in each context ✦ specific enough so it contains a clear vision

  31. An example of a quality vision 90% of sites we produce should be ✦ accessible ✦ robust ✦ aesthetic ✦ secure ✦ usable ✦ cost-effective ✦ measurable ✦ scalable ✦ findable ✦ refactorable ✦ interoperable ✦ valuable ✦ relevant

  32. An example of a quality vision We want our product to be usable, easy and delightful to use for our target audience.

  33. Use a quality vision to decide: ✦ what level of training all team members need ✦ what level of work is globally expected from them ✦ enable them to decide the right thing to do.

  34. Hire wisely.

  35. Tips, tricks & (some) techniques

  36. Use user stories As a user I would like to see the history of a page so I can work out who did what.

  37. A user story with acceptance test cases: “A user can pay for access with a credit card.” ✦ Test with Visa, MasterCard and American Express. ✦ Test with Diner’s Club. ✦ Test with good, bad and missing card ID numbers ✦ Test with expired cards. ✦ Test with different purchase amounts (including one over the card’s limit). — “User Stories Applied”, Mike Cohn

  38. User stories: ✦ provide a user-oriented approach to defining requirements ✦ break the task of building into estimable chunks ✦ facilitate a discussion about what we’re building ✦ make it easy to prioritize what’s important to build

  39. User stories: ✦ allow team members to interpret requirements ✦ allow team individuals to take ownership of the solution ✦ are testable ✦ means no more 200+ pages of specifications!

  40. Trick: Document only as needed, especially decisions.

  41. Estimation & planning

  42. Method #1: Relative story points

  43. Assign relative points to each story. As time progresses, you get a better idea of your burn rate based on your team’s velocity.

  44. Assign relative points to each story. As time progresses, you get a better idea of your burn rate based on your team’s velocity.

  45. Method #2: The 4-hour bucket model.

  46. Split your stories so that they fit in an approximate half-day slot. Some will be bigger, some smaller, but eventually they balance out.

  47. Trick: Let your team own the task of estimating.

  48. Evaluate: are we too optimistic or too pessimistic? Rinse & repeat.

  49. Design & User Experience — “12 emerging best practices for adding UX to agile development”, Jeff Patton http://agileproductdesign.com/blog/emerging_best_agile_ux_practice.html

  50. Agile methodology states: everything happens in the same iteration.

  51. But as a designer or a UX specialist, what do you need to succeed?

  52. Designers need time to research, and to synthesise product and visual design.

  53. Trick: “Work ahead & follow behind” — #4, “12 emerging best practices for adding UX to agile development”, Jeff Patton

  54. Quality Assurance

  55. There’s no magic: Make time to care.

  56. Employ test-driven design and development.

  57. Method #1: Hire a QA person or team.

  58. Method #2: Set aside QA and refactoring days.

  59. Trick: Keep, reuse and add to a comprehensive list of all use cases or user stories that must pass before each release.

  60. Quality doesn’t need to be assured, it needs to be cultivated.

  61. Why do we insist on quantifying quality?

  62. Good work comes from good habits.

  63. A vision that allow your team members to judge critically is more powerful than any process.

  64. Identify accountability.

  65. Identify what each other need in order to succeed.

  66. The agile approach encourages good habits but it’s up to your team to decide what you collectively want to be.

  67. Empower your team.

  68. Give each other a sense of pride.

  69. What do monkeys, a banana, and a web team have in common?

  70. Quality should be the way that it has always been done.

  71. Thank you! Questions? Stephanie Troeth stephanietroeth.com hello@stephanietroeth.com http://www.slideshare.net/stephtroeth/presentations bookoven.com

  72. With thanks http://www.flickr.com/photos/dariuszka/264054626/ http://www.flickr.com/photos/johncarleton/16083172/ http://www.flickr.com/photos/32912172@N00/3369828460/ http://www.flickr.com/photos/cryztalvisions/343309195/ http://www.flickr.com/photos/mostudio/2384804297/ http://www.flickr.com/photos/mknott/3642179597/ http://www.flickr.com/photos/66164549@N00/2789668253/ http://www.flickr.com/photos/boojee/29777131/ http://www.flickr.com/photos/72213316@N00/3570803663/ http://www.flickr.com/photos/telstar/3174467026/ http://www.flickr.com/photos/76283671@N00/184612846/ http://www.flickr.com/photos/psd/3731275681/ http://www.flickr.com/photos/totalaldo/ http://www.flickr.com/photos/sfllaw/302647234/

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend