Notes from Agile2012

Last month I attended the Agile2012 Conference, where the core themes were Agile Organization Transformation and thoughts challenging the effectiveness of the currently defined Product Owner role.

Agile Organization Transformation

• We are failing at agile adoption 3 out of 5 times – Sahota
• Do you have a deliberate plan on how you are going to change the organizational culture? – Sahota
• The only thing of real importance that leader sod is to create and manage culture – Edgar Schein
• Culture = how do we do things around here to succeed – Sahota
• Read more: The Reengineering Alternative: A Plan for Making Your Current Culture Work by William E. Schneider

• Lots of talk about Being Agile vs. Doing Agile
  • Doing – Process, Tools, Instructions, Ceremonies
  • Being – Values, team reaction, understanding, adaptability, leadership everywhere, failure is ok
• Wait until there is friction before you define new roles or processes
• Navy seals have teams of 4 and some argue for 5, but everyone agrees 6+ is too much as it creates to  much communication overhead
• Bad interactions pack 5x the wallop of good interactions
• Bad is stronger than good. Bad behavior is stronger, longer-lasting, more contagious and more difficult to stop than good
• Spiral Dynamics was an interesting tool to use when trying to measure team maturity
• Jurgen Appelo How to Change the World

Product Owner Role Change?

• Most companies are drowning in a sea of opportunity – Rubin
• Interesting dimensions that affect what type of PO and process work – Patton
  • Are your users internal or external?
  • Do your users have control over the use of your product?
• Velocity isn’t a measure of value. The outcome is where we need to measure if we are delivering value. Are we changing the world?  – Patton
• Found a Jeff Patton presentation where he talked about the Underpants gnomes. He is now one of my new favorite thought leaders.
• What if the PO role was defined as a servant to the team to help facilitate bringing the customer perspective closer to the team? – Patton
• MVPe = minimal viable product experiment. Smallest viable experiment to validate a product hypothesis – Patton
• We need to be focused on learning about outcomes – Patton

• David Hussman

• • The product backlog is too much about delivery and not discovery
  • The Product Owner is structured as a singular failure which needs to be distributed
  • We need a group of people speaking with one voice
  • Stories often miss the real value
  • Focus on User-centered user experiences over user stories and product backlog
  • Once you are not bad at delivering, then you need to start focusing on delivering the right thing
  • Discovering through mapping
    • Name the goal
    • List a few examples (simple complex)
    • Walk a day in the life of each activity
    • Back up and resell the experience
  • The problem is that documentation isn’t read. It doesn’t allow us to get interaction and discovery
  • Can everyone on the team tell the story?
  • Leave the map whole. The map gets you discovery and then you create the delivery stories underneath which may duplicate.
  • Story maps show examples
  • Examples are a type of test
  • Story maps can drive testing
  • A test would be one scenario of a path through the story map
  • Story maps foster product thinking, product learning (MVP) thin sliced product discovery
  • Pragmatic bookshelf Videos $50 for 6 hours of content
  • When you are unclear, say ” can you give me an example?”

Misc.

• Played a great game where you start a story and each person in the circle adds to it
  • 1st round you start your statement with “yes, but”
  • 2nd round – “yes, and”
  • 3rd round – “yes, and because of that”
  • Try it and see which one takes the team into a very negative place and which one creates a much more positive and constructive discussion
• High trust companies outperform low trust companies by 300% – Pixton

References:

• When you’re Agile you get Lean by Charlie Rudd