Search

Being Agile, Being Good

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

0 comments

Post a comment

    Post a comment
    Embed Video
    Edit your comment Cancel

    Notes on slide 1

    * survey of the room - who knows what agile is? anyone using agile now? who is wanting to be using agile methods? who likes/hates it? who doesn’t know what agile is?

    So, there’s a reason and inspiration for this talk. Last year at in London , I did a “conversation” with Ann McMeekin on practical ways to implement accessibility in a development process. And Gavin Bell from Nature Publishing Group asked me (not these exact words) “how do you ensure quality in a development process? how do you make sure things like copy is correct, and things behave according to spec?”

    I gave some kind of answer about managing quality assurance (QA), but I wasn’t confident. It’s a fascinating question. It’s taken me the whole year to think about it.
    And I thought I’d share my ideas with you today, here at Paris Web.

    This is a fascinating question: is the problem with the process, or the team? Is it something else?

    * survey of the room - who knows what agile is? anyone using agile now? who is wanting to be using agile methods? who likes/hates it? who doesn’t know what agile is?

    So, there’s a reason and inspiration for this talk. Last year at in London , I did a “conversation” with Ann McMeekin on practical ways to implement accessibility in a development process. And Gavin Bell from Nature Publishing Group asked me (not these exact words) “how do you ensure quality in a development process? how do you make sure things like copy is correct, and things behave according to spec?”

    I gave some kind of answer about managing quality assurance (QA), but I wasn’t confident. It’s a fascinating question. It’s taken me the whole year to think about it.
    And I thought I’d share my ideas with you today, here at Paris Web.

    This is a fascinating question: is the problem with the process, or the team? Is it something else?

    two foundations for our discussion today: agile & quality
    looking for a meeting point between quality and agility
    I’m going to start with talking about agile, then we move on to quality, then we mash up the two and see where we end up.

    Even if you’re not doing agile -- I think you will benefit from this discussion, as many things I say about quality apply in many circumstances.

    agile: used a lot by big companies + startups, very little in between.

    Mike Cohn builds upon the four principles of the Agile manifesto, and gives us 5 ways that agile teams work together.

    Individuals and interactions over processes and tools
    Working software over comprehensive documentation
    Customer collaboration over contract negotiation
    Responding to change over following a plan

    Everyone collaborates. No throwing over the wall at one another. no hot potato games.
    product owner, customer roles, developer, project manager.

    No grand delineation of phases
    all work happens concurrently.
    Iterations are timeboxed.

    During the iteration, they transform one or more imprecise requirements statements into coded, tested, potentially shippable software. Iterations are not releases- a release may be one or two iterations.

    deliver features according to biz priority

    focus on user-valued features rather than completing isolated tasks.

    Not all projects are suited to agile.

    Yesterday Florent & Benjamin talked about quality in web application design.

    Problem is, design leads to implementation. It’s interesting to speak about quality in a more general sense -- because a design alone doesn’t necessarily get implemented to spec the moment it leaves your photoshop file.

    Then one doesn’t seek the absolute “Truth”. One seeks instead the highest quality intellectual explanation of things with the knowledge that if the past is any guide to the future, this explanation must be taken provisionally, as useful until something better comes along.

    when you think about it like this, you can realise, it’s not just about the process.
    the process is what supports the vision.
    the quality vision must exist.

    How do we bring a team to agree on what is good?

    how to do this as a team lead
    how to do this as a team player

    understand the motivation of your team members
    look at how each of them need to succeed

    people who do the best job are the ones who take pride in their work.

    how do you give them pride?

    by giving them room to creatively solve the problems they are experts in.
    but making sure they have what they need to get their job done.

    how do you define quality for everyone in your team?

    you want your team to know what is the right thing do before they have to truly think about it.

    you want your team to know what is the right thing do before they have to truly think about it. For example, there are communication issues. Typically communication issues come from not knowing who is the right person to communicate to, what and why.

    Provide realistic goals, maybe even goals in stages for your team.

    Provide realistic goals, maybe even goals in stages for your team.

    * the idea is to let them decide themselves, when they are faced with a question, without coming to ask you.

    I can’t emphasise this enough. Building a team is like building a house. you want to build with strong materials to strengthen the team, not to weaken it.

    Yesterday we spoke about how hard it is to find people with skills.
    But we tend to hire on skills, not aptitude. Skills can be acquired, personality -- not likely changed.
    Trick: line up 2 seniors with one junior, train up the juniors. Hire them for their enthusiasm, energy, and their love of learning. Skills are easy - skills they can learn.

    use these as requirements that feed into everything.
    allow flexible interpretations, provided the requirement is met.
    document all decisions/changes.

    use these as requirements that feed into everything.
    allow flexible interpretations, provided the requirement is met.
    document all decisions/changes.

    use these as requirements that feed into everything.
    allow flexible interpretations, provided the requirement is met.
    document all decisions/changes.

    use these as requirements that feed into everything.
    allow flexible interpretations, provided the requirement is met.
    document all decisions/changes.

    use these as requirements that feed into everything.
    allow flexible interpretations, provided the requirement is met.
    document all decisions/changes.

    estimating the age of the universe

    Make time for everyone to care about the quality of their work (and make it their responsibility).

    Stop trying to quantify quality.

    A process is there to serve a philosophy.

    8 Favorites & 1 Event

    Being Agile, Being Good - Presentation Transcript

    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. Method #2: The 4-hour bucket model.
    45. Split your stories so that they fit in an approximate half-day slot. Some will be bigger, some smaller, but eventually they balance out.
    46. Trick: Let your team own the task of estimating.
    47. Evaluate: are we too optimistic or too pessimistic? Rinse & repeat.
    48. 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
    49. Agile methodology states: everything happens in the same iteration.
    50. But as a designer or a UX specialist, what do you need to succeed?
    51. Designers need time to research, and to synthesise product and visual design.
    52. Trick: “Work ahead & follow behind” — #4, “12 emerging best practices for adding UX to agile development”, Jeff Patton
    53. Quality Assurance
    54. There’s no magic: Make time to care.
    55. Employ test-driven design and development.
    56. Method #1: Hire a QA person or team.
    57. Method #2: Set aside QA and refactoring days.
    58. Trick: Keep, reuse and add to a comprehensive list of all use cases or user stories that must pass before each release.
    59. Quality doesn’t need to be assured, it needs to be cultivated.
    60. Why do we insist on quantifying quality?
    61. Good work comes from good habits.
    62. A vision that allows your team members to judge critically is more powerful than any process.
    63. Identify accountability.
    64. Identify what each other need in order to succeed.
    65. The agile approach encourages good habits but it’s up to your team to decide what you collectively want to be.
    66. Empower your team.
    67. Give each other a sense of pride.
    68. What do monkeys, a banana, and a web team have in common?
    69. Quality should be the way that it has always been done.
    70. Thank you! Questions? Stephanie Troeth stephanietroeth.com hello@stephanietroeth.com http://www.slideshare.net/stephtroeth/ bookoven.com
    71. 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/

    + stephtroethstephtroeth, 1 month ago

    custom

    482 views, 8 favs, 1 embeds more stats

    Given at Paris Web 2009.

    More info about this document

    © All Rights Reserved

    Go to text version

    • Total Views 482
      • 479 on SlideShare
      • 3 from embeds
    • Comments 0
    • Favorites 8
    • Downloads 38
    Most viewed embeds
    • 3 views on http://it-corporate-cetelem.sfdi.echonet

    more

    All embeds
    • 3 views on http://it-corporate-cetelem.sfdi.echonet

    less

    Flagged as inappropriate Flag as inappropriate
    Flag as inappropriate

    Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

    Cancel
    File a copyright complaint
    Having problems? Go to our helpdesk?

    Categories

    Tags

    more

    Groups / Events

    -->
    Search
    RSS Feed
    What's new?

    © 2009 SlideShare Inc. All Rights Reserved