Knowledge Sharing from Scrum Gathering 2009

I recently attended the Scrum Gathering 2009 in Orlando, FL. It was a great time to connect with industry professionals of Scrum as well as the thought leaders in Software Development. This is my attempt to share the knowledge and pieces of information I garnered from this event. I was not a big note taker in school. I did however end up with many pages of notes from this gathering and tried to summarize them as best I could (especially since they are taken out of context on a simple web page). I hope you find them useful.

Also, if you are in the DFW area, please feel free to join us at our next DFW Scrum User Group. Details here…

Ken Schwaber (3/16/09) View Presentation Slides

  • 54,000 CSM (certified scrum masters) world wide
  • 47 user groups throughout the world (get involved)
  • New website (www.scrumalliance.org)
  • Paying for research on Scrum and its adoption (get real evidence)

Dr. Mark Paulk (3/16/09) View Presentation Slides

  • Scrum Master = Project Manager
  • Product Owner = Product Manager
  • The Scrum method in principle should be used without much variation
  • What does DONE mean? 15,000 items? What is it?
  • Stabilization sprints simply mean you quit. QA / Testing should be accomplished within the sprint. It is what spawns hyper productivity and quality software.
  • Intelligent business decisions drive project successes. Did Scrum projects fail? No, they simply terminate early which means you just learned very quickly about the project. Money for knowledge.
  • Schedules are not the definition of success. Culture basis our raises and promotions on schedules, is that really success? Gaming delivery of a product around a schedule?
  • Balanced thought discipline vs. Agility.
  • Does the project have a “product vision” that characterizes success?

Ron Jeffries / Chet Hendrickson “Show Me the Software” (3/16/2009)

  • Product Owners want EVERYTHING (that’s ok, that is their job)
  • How do you handle the customer who wants a project plan? “We will be doing the project using Scrum, we are doing this in a way that you can see what/how we are doing and do something about it.
  • Be done when you think you are done. Stabilization sprints are bad as you can’t know what needs to be fixed / tested as you go.
  • Automate your acceptance tests. Putting tests in automated mode allows your testers to explore more and do less mundane tasks.
  • A feature (user story) should be able to be accomplished in no more than 2 days.
  • Test Driven Development is the way to go (automated unit tests)
  • A human tester cannot accurately test the same scenario, the exact same way, over and over again. Automate them.
  • Barrel analogy:
    • If you have a barrel of sewage and you drop in a drop of fine Bordeaux wine, you still have a barrel of sewage.
    • If you have a barrel of fine Bordeaux wine and you drop in a drop of sewage, you still have a barrel of sewage.
  • The design of a project must improve as you go (not all up front). Build up on it and refactor the design to improve.
  • Improve the work where you are, not where you are not.
  • Faster progress with higher quality is the goal.
  • A good design has low coupling and high cohesion (solves design epiphany).
  • 90 days is too long to deliver new features.
  • Prefer a team of generalists over a team of specialists.
  • Cross train using pair programming to get those generalists. They just need to know enough about everything to be able to complete anything that comes their way.
  • Implement User Story Ownership (small features owned by various members of the team, they sign off when the feature is complete before handing it to the Product Owner).
  • No Developer knows that they are going to do if it takes longer than 3 days. If they do, they are lying. Keep to the rule of 2-3 day features, we can’t possibly know much more in the future.
  • What if you were only paid for the DONE features? Would you work differently? Instead of having all stories 80% done in the sprint (which is $0.00), you would probably have 90% of the stories complete meaning you would only remove 1-3 stories at the end. But at least you will get paid on the stories that are DONE. Think about it!

Ken Schwaber / Alistair Cockburn “You Thought You Knew Scrum” (3/16/09)

  • PowerPoint is the refuge for cowards
  • Give people a chance to act as adults
  • Don’t be afraid to be wrong
  • Don’t let people take your joy and creativity
  • 20% turnover in Scrum. Some people just can’t do it
  • Scrum is gut busting hard work, it will take your problems and throw them in your face each day
  • Scrum is an opportunity to improve yourself
  • Top 8 items:
    • Treat people as adults (are they resources or are they people?)
    • Teach “Ask the Team” by actually asking the team
    • 3 Bells: Deliver, Ask the Team, and Inspect and Adapt
    • Scrum is a mirror
    • Scrum with beginners produces crap (thats ok, they will learn)
    • Scrum is a genetic algorithm
    • Sprint Failure? (The team doesn’t fail the sprint)
    • Don’t shun PM’s, turn them into servant leaders
  • Continuous “us” improvement instead of continuous “process “improvement

Pete Behrens “Death by Scrum Meeting” (3/16/09) View Presentation Slides

  • Meeting break down:
    • Daily Scrum (Product / Process) 5-15 minutes
    • Sprint Retrospective (Process) 15-30 minutes
    • Sprint Review (Product) 30-60 minutes
    • Sprint Planning (Product) 60-120 minutes
    • Release Planning/Grooming (Product) 120-240 minutes
  • Focus on resolving the 3-5 biggest impediments (more, you lose focus).
  • Release Planning
    • Project definition (story identification)
    • Relative estimation (don’t get stuck on the #)
    • Velocity projection
    • Retrospective (+ / Deltas)

Jeff Patton / Andy Powell “User Story Mapping” (3/17/09 Open Space Session)

  • 3 days max for a user story
  • Road Map Items > Epics (features) > User Stories (minimize ambiguity)
  • Backlog context is lost from your road map down to the smaller user stories (how do you know when the road map item is done?)
  • Provide a parent child relationship
    • Provide context
    • Show priority
    • Organization of the backlog does not always equal prioritization
  • www.agileproductdesign.com

Ron Jeffries / Chet Hendrickson “User Story Size, How” (3/17/09 Open Space Session)

  • What is too big, too small, and how do you know? (Lance Dacy)
  • Features that fit within 2 days seem to work best.
  • Don’t split UX/UI into a separate sprint.
  • UX paper prototype is not a valid sprint deliverable.
  • The work of UX experts is NOT a backlog sprint item. It is part of software envisioning/planning that comes from the PO.
  • Build the UX/UI to match the functionality agreed upon in the story, then add UI elements / functionality as you go through the iterations (the work flow / mock up of the larger picture is what you slice into user stories, the UX team can then code those in the sprint).
  • Scrum teams are about shipping software; don’t put items on the backlog that does not ship software (working software).
  • The story has business value, but YAGRI (you aren’t going to release it). You release a package of user stories.
  • Get as much customer feedback in the sprint review as you can.

Roman  Pilcher “Backlog Grooming” (3/18/09)

  • Anyone can contribute to the backlog
  • Product owner controls the backlog
  • Backlog must be prioritized (ordered)
  • Backlog must be estimated in size by the teams
  • Backlog must have acceptance criteria documentation on what has to happen for the story to be DONE.
  • Backlog changes and emerges
  • Make sure the top items are spec’d out and acceptance criteria are ready (they must be consumable)
  • The amount of documentation for the story is JITJE (Just in Time, Just Enough).
  • The backlog is like a garden, you must constantly tend to it (clearing brush, tilling, seeding, pruning, etc..) even in the winter.
  • 3C criteria for a user story: Card, Conversation, Collaborative.
  • Detail and define high priority items (fulfill the INVEST criteria)
    • I: Independent
    • N: Negotiable
    • V: Valuable
    • E: Estimate able
    • S: Small (feasible)
    • T: Testable
  • Prioritize based on value to the customer
  • Sequence (dependencies considered)
  • Risk and uncertainty are ALWAYS present, we must learn to work with it
  • Agile = Fail early and adapt
  • Success = Functional completeness (quality)

Ron Jeffries, Mike Cohn, Jim Coplien, Alistair Cockburn, and Ken Schwaber Lunch Panel (3/18/09)

  • “I don’t want to search for a perfect team, I want to search for a team who wants to do better than they were doing yesterday” -Mike Cohn
  • “Perfect? I won’t ever be perfect, but I do know that perfect is over there somewhere and as long as I am moving in that direction, then I am satisfied” -Ron Jeffries
  • “I may not be better today than I was yesterday, but I am certainly better off this year than I was last year” -Ron Jeffries
  • “OOPSLA needs to die. Objects won, I don’t say I need to go to the Object Oriented design meeting, I simply say I am going to the design meeting. I hope Scrum/Agile is not around in 2012, I want it to simply be known as software development” -Mike Cohn
  • “Scrum is like teenage sex. Everyone says they are doing it (and are not), the ones who are doing it, are doing it wrong. -Jim Coplien
  • Impediments should be celebrated; we found something we can do better! -Jim Coplien
  • “Your job as a Scrum Master is hard. Your job is to transform your organization. Not just teach techniques” -Jim Coplien
  • Keep the team in charge. I recall the story of a child who would not eat their carrots. The parents constantly said “Eat your vegetables, you have to have x number of bites”. The next tactic was to ask the child how many carrots would they like to eat today? The child responded with 2. Then after eating 2 asked for another. What changed? They were in charge. -Ken Schwaber
Advertisements

One thought on “Knowledge Sharing from Scrum Gathering 2009

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s