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:

The information provided in this content is meant for general informational purposes only and should not be regarded as professional guidance for specific business scenarios. Results may differ depending on your organization’s circumstances. It is recommended to consult with a qualified industry expert before acting on this information. The coaches at Agile Velocity are available to address any inquiries you may have.