Thursday, February 12, 2015

Notes from Arlo's "Scale without stupid" session at some

Scaling Agile beyond SAFe with Arlo Belshee

Why are we here?
   * Need to scale.  We're growing.
   * Can we scale technology instead of people?  (Conway's Law)

What is impeding us from scaling?
   * Delivery is hard and expensive
   * Intrinsic Organization issues
   * We're not sure what we want to scale (Teams, technology, etc.)

Mike Cohn on Scaling Agile
   * Master Product Owners and Master Scrum Masters
   * Sprint Planning in a big room: Do Sprint Planning for 10 Teams in the same room
      * Semaphore flags to indicate that a Team needs help from a Product Owner or someone outside the Team

Arlo's notion of "pseudo time"
   * Hierarchy (Traditional, all work is done by individuals)
      * Not Agile, but lots of people are doing Agile and techniques like TDD
      * Managers still dole out work
   * Individual accountability (Work Groups)
      * Lots of Scrum transitions get to here.  Early XP Teams got here also.
      * Still judging individuals, but they work on interdependent things.
      * One shared backlog, broken up by Team.  Work is implemented by individuals, though.
      * Company, as a whole, still has a hierarchy above Teams
      * SAFe implementations often end up here.  Hierarchy breaks up work and doles it out to Teams.
   * Team Accountability (cross-functional Teams)
      * Team has responsibilities to go from concept to cash
      * Team works towards goal of company (objectives instead of tasks)
      * People are truly sharing work and collaborating across roles
      * Management provides strategy and resourcing: "We need our product to be relevant to open source community"
      * SAFe is taught here, but ends up above because people don't notice the technical practices of SAFe (XP).
   * Local dependencies and decisions (consent-based decision making)
       * Hierarchies are much fewer here and they are weak.  Relationships and influences are a graph instead of hierarchy.
       * Authority isn't a legitimate way to make decisions.  Authority tends to vanish.
   * Data-based decisions
      * Lean Enterprise.  Decisions not made by the highest-paid person in the room.
      * Business runs itself by numbers that are continuously monitored and discussed.
      * "What is the shortest experiment we could run to see if it influences the numbers?"
      * Having the data let's your Business Analysts make much better decisions on what experiments to pursue.  Experiments replace stories.  Experiments have to be inexpensive as possible.
   * Shared Strategic Intent
      * Strategy is no longer owned by the person at the top.  There is natural contention because there is a lot of data from other parts of the company.
      * Globally-writable document that captures realities from all parts of the company
      * Yammer is almost to this level

Your company's location on the map is determined by the amount of trust in the organization.  The speed of gathering feedback (on product changes) may also affect the organization's location.  (Arlo thinks that this is just an excuse in many cases.  Lots of people have found ways to get the feedback without releasing product.)

The opinion of a Product Owner is really good, but it's still only an opinion.

How much consistency do we need in the system?
   * Centralization in consistency (e.g., a PM Organization is in charge product direction with communication via the hierarchy) from Hierarchy through Team Accountability
      * It gets more complexity and resource contention as it scales because it has to deal with a bunch of exceptions and variations.
      * Lots of resource locking/contention and decisions made based on a subset of the known data
   * Decentralization in consistency (e.g., anyone in the company can come up with an idea and all ideas are equally valid until the experiment is run) to the left
      * People can easily add features to Bing that are monitored and reviewed
      * Let's smaller groups perform experiments individually.  Then they can be ranked based on their impacts to the statistics to decide which experiments to implement for all customers.
      * This requires a lot of trust because it disempowers the people who used to make the decisions
      * Look for the one thing that matters to the business that will let us increase the core capability (drive down bugs, etc.)
      * Discover what has changed in order to deliver that one thing and determine what else it enables.

Look at our competitors who moved to the right.  It took them 9 years to get there, but we're only 9 years behind.  We can leverage what they learned and do it in less.

Look for places in the organization where people have some amount of autonomy (usually somewhere in middle management).  Find out what they want to change and involve them and champions below them in the conversation.
   * In this example, you don't need to work with Directors because they are above the change

An organization faces an existential threat to its product.  Tried multiple approaches and they all failed.  Used IM to share information among Teams and low-level people (direct sales and low-level engineers) about customer trends.  Started talking about what kinds of changes could be made in the product.  Being hierarchical, they had to propose the changes, but once they were funded, they could be decentralized.  Parts of the organization can be towards the right and would fall back to left when it is fit to purpose.
   * They can get feedback via the automatic update functionality and opt-in user metrics (leveraged Lean Startup inside same organization: Fast cadence, see what sticks)

A lot of people who want to scale are getting stuck in SAFe which only gets you half way across the spectrum.  Be careful with SAFe because it matches pretty closely what we're doing today: Makes it easy to transition to it, but may make it difficult to transition to the next step.

Ninja trick: What's the most important business problem to solve?  Are you willing to change a lot (roles, processes, responsibilities) in order to make that change happen?

David Whitlock
Adjunct Lecturer
Portland State University

No comments:

Post a Comment