Four steps to move you to Business Agility

I work with many organizations that are fairly chaotic and far from Agile. While I’ve led fairly involved transformations, there are four actions a development group that’s 50-300 in size can take, mostly on their own, that can have a great impact. These are:

  1. Use Minimum Business Increments (MBIs) to identify enhancements to make to the system
  2. Have an intake product backlog (even better to add service classes) where all work in the system can be seen
  3. Organize around product teams. These are teams that can develop the MBIs defined. You can then create Scrum-Kanban teams (8-12 people) if the product teams are too big.
  4. Do DevOps phase 1- create visibility between dev and ops so ops knows what coming and dev understands what ops needs. Work together even if you don’t take steps towards continuous integration and continuous deployment.

These straightforward steps can be done quickly. Even if you are planning on using an Agile at scale approach, taking these steps early will help prepare for that.

Creating cross-functional teams is more effective than coordinating teams with dependencies

Many companies find themselves organized around projects that come to their development group from all directions. There often isn’t even a backlog to see what’s to be worked on. This results in teams working on multiple projects at a time, multitasking, waiting for others, and general chaos. Short projects take months.

One solution is to get all of the groups of interrelated teams together every 3 months to do a big room planning event. This is putting all of the work that needs to be done over the next 3 months in a backlog and having the teams spend a couple of days ina big room planning together how they will manage it.

While not truly Agile, it is definitely an improvement in many ways:
1) all work is now visible
2) dependencies have been mapped
3) teams are now collaborating with each other

But this is really an accommodation to the challenge of value streams (workflows) that cut back and forth across teams. A better approach is to create teams that can get the work done on their own. This may be larger than a standard Agile team (8-12 people). But it can be subdivided into smaller teams with few dependencies between them. This is a much easier problem to solve.

Using Double Loop Learning on Key Scrum Concepts to Improve Scrum

Chris Argyris clarified that there are two levels to learning, which he described as single-loop learning and double-loop learning. Here are his definitions:

  1. Single-loop learning: Learning that changes strategies of action (i.e. the how) in ways that leave the values of a theory of action unchanged (i.e. the why)
  2. Double-loop learning: Learning that results in a change in the values of theory-in-use (i.e. the why), as well as in its strategies and assumptions (i.e. the how)

Continue reading “Using Double Loop Learning on Key Scrum Concepts to Improve Scrum”

Why empirical process control is insufficient to do Scrum well

This post continues my series on Getting Back to the Original Scrum.

Scrum is founded on empirical process control theory, or empiricism. Empirical process control means to try something, see what happens and adjust your actions based on this feedback.

There is no model (theory) underneath these practices. That is, you don’t make predictions based on an underlying theory you just see what happens (inspect) and then adapt to this feedback. This is why Scrum requires performing a Sprint to be able to see your impediments.

Continue reading “Why empirical process control is insufficient to do Scrum well”

I am not a big fan of Shu Ha Ri

As a metaphor for stages of learning it’s not bad. But even then it’s not a great metaphor. Let’s consider in the martial arts we’re trying to suppress our mind and learn certain moves. A collection of methods will let us chose the right moves from our repertoire. In knowledge work, we’re doing different things and wanting to engage our minds. I prefer to teach by:

Continue reading “I am not a big fan of Shu Ha Ri”

How Scrum’s core is useful and incorporates the essence of Agile

This post continues my series on Getting Back to the Original Scrum.

Ken Schwaber and Jeff Sutherland captured several key concepts of what The New New Product Development Game (TNNPDG) suggested how product development teams should work. I believe these core roles, practices, events and rules are the core reason that Scrum works. These include:

Continue reading “How Scrum’s core is useful and incorporates the essence of Agile”