Tag Archives: agilty

Review HBR May-June 2018, Agile at scale

HBRIn this interesting article Agile at scale – How to go from a few teams to hundreds the authors Darell K. Rigby, Jeff Sutherland, and Andy Noble give insights in their study of scaling up of agile at hundreds of companies.

Some key take aways:

  • Leading agile by being agile, don’t use top-down plans and directives to scale up
  • Create a taxonomy of teams. Break the taxonomy into three components – customer experience teams, business process teams, and technology teams – and then integrate them (see picture)

HBR Agile at scale

  • Get agile rolling. Launch an initial wave of agile teams, gather data on the value those teams create and the constraints they face, and then decide whether, when, and how to take the next step (test and learn cycle)
  • Sequence the transition. Don’t make the mistake of going for easy wins. You have to create a learning environment or organizational changes necessary to scale dozens or hundreds of teams
  • Big bang transitions are hard. Require total leadership commitment, a receptive culture, enough talented and experienced agile practitioners to staff hundreds of teams without depleting other capabilities, and highly descriptive instruction manuals to align everyone’s approach, a high tolerance of risk along with contingency plans to deal with unexpected breakdowns. It’s often better to roll out agile in sequenced steps, with each unit matching the implementation of opportunities to its capabilities
  • No agile team should be launched unless and until it is ready to begin. The team is:
    • Focused on a major business opportunity with a lot at stake
    • Responsible for specific outcomes
    • Trusted to work autonomously – guided by clear decision rights, properly resourced, and staffed with a small group of multidisciplinary experts who are passionate about the opportunity
    • Committed to apply agile values, principles, and practices
    • Empowered to collaborate closely with customers
    • Able to create rapid prototypes and fast feedback loops
    • Supported by senior executives who will address impediments and drive adoption of the team’s work
  • Master large-scale agile initiatives with teams (of teams) of teams
  • Building agility across the business
    • Not every function needs to be organized into agile teams, but ensure that the functions that don’t operate as agile teams support the ones that do
    • Push for greater change in four areas: agile values and principles (agile and traditional teams), operating architectures (modular approach), talent acquisition and motivation (you need expertise combined with enthusiasm for work on a collaborative team, coaching, public recognition, team reward, …), and annual planning and budgeting cycles (annual cycles constrain innovation and adaptation, view decisions as opportunities to purchase options for further discovery, …).
Advertisements

Scrum or Kanban

In one of my previous blogs I wrote about ‘Agility by delivering changes as ‘business as usual’

In that article I showed a picture with different agile methods and frameworks. On the team level I mentioned Scrum, Kanban and DevOps. I came across a blog post from Roman Pichler titled ‘Is Scrum right for your product?’. A nice article explaining when to use Scrum and when to use Kanban, by following a product life cycle from launch via product market fit till the end of life. I added DevOps to his approach in the same product life cycle and will use this to expand my own article. See the animated PowerPoint too.

During the first part of a product life cycle the uncertainty is high and the focus is on goal driven iterations for the first product launch and market fit product. During this part of the life cycle Scrum is a great fit to cope with uncertainty and product iterations developed by the whole team. During the rest of the product life cycle the amount of uncertainty and change gradually declines. Here Kanban is a good fit. User Stories will be realized in a continuous flow by one or more of the individual team members.

When a major product upgrade has to be delivered by the whole team Scrum could be a better choice for that goal oriented iteration, otherwise Kanban stays a good fit.

To avoid the error prone handover and to shorten the time to market the Development and Operations teams can be integrated. Kanban is a good fit for the DevOps team. When to start with DevOps varies.

See: Is Scrum right for your product?