Agile Manifesto: Incredible Success and time to Move On

This blog was originally written in April, 2012

I have incredible respect for the signatories of the Agile Manifesto. I believe it to be a great document. I say this for several reasons – the greatest being it created a new space for effective development to take place. It started a movement that has changed the lives of millions.

That said, I believe manifestos, by their very nature when they are effective, tend to be time dependent. In the case of the Agile manifesto, this is particularly so – it’s very success has created a vacuum.

The Agile Manifesto’s success has created opportunity for Agile to manifest (pun intended) throughout the organization. However, because it focused on the development organization, it has left a vacuum.

Some people have challenged me about my assertion that the Agile Manifesto focuses on the development team. A twittervation with Derek Neighbors (@dneighborsr) prompted me to make the following table about the Agile Manifesto – showing what it mentions by role/area:

  Which Area / Role Is Referred to
Principle Business Management Developers / Software / Project Customers
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software     Explicitly Mentioned Explicitly Mentioned
         
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.     Explicitly Mentioned Explicitly Mentioned
         
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.     Explicitly Mentioned  
         
Business people and developers must work together daily throughout the project Explicitly Mentioned   Explicitly Mentioned twice  
         
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.     Mentioned 4 times  
         
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation     Explicitly Mentioned  
         
Working software is the primary measure of progress.     Explicitly Mentioned  
         
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Explicitly Mentioned   Explicitly Mentioned Explicitly Mentioned
         
Continuous attention to technical excellence and good design enhances agility     Explicitly Mentioned  
         
Simplicity–the art of maximizing the amount of work not done–is essential.        
         
The best architectures, requirements, and designs emerge from self-organizing teams.     Mentioned 3 times  
         
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.     Mentioned  
         
Total Times Mentioned 2 0 17 3

I am sorry if I can’t see how the numbers on that last row don’t make my case. However, be very clear, that this actually is evidence that the Agile Manifesto was great and worked! So no one should take this as an attack on it. By working so well, we have expanded Agile into a space outside of where the Agile Manifesto originally existed. I can’t think of a greater testament to it than that.

Agile is now as much, or more, about the enterprise as it is about teams. We don’t need a new manifesto, we just need to be open to expanding what we are going after.

Straightening out your value stream

The value stream is the set of actions that take place to add value to a customer from the initial request to delivery. The value stream begins with the initial concept, moves through various stages for one or more development teams (where Agile methods begin), and on through final delivery and support.

Value streams are what they are, you don’t specify them. There are several ways to change them, however, including changing:

  • what goes into them
  • how people collaborate
  • the order of the work (e.g., test-first)
  • how teams are organized, the size of the work done
  • the amount of work being done by the people in the value stream

The idea is to remove handoffs, delays and handbacks in the value stream. Doing so will lower cycle times and increase process cycle efficiency resulting in quicker time to market and realization of value.

The New Scrum Game

Ken Schwaber & Jeff Sutherland created the Scrum Agile Framework based on The New New Product Development Game (TNNPDG) & empirical process control.

In the 20+ years since Scrum’s ascension, other useful methods – Flow, Theory of Constraints, Kanban and Lean Management have come to the forefront. In addition, while Scrum was designed for single product teams, Scrum is now being used in product teams that must collaborate with others as well as in IT organizations. In addition, empirical process control, a major tenet of Scrum, is not consistent with the systems-thinking or learning methods of Flow, Lean and ToC.

The “New Scrum Game” is the result of taking insights from TNNPDG and the aforementioned methods and creating a team-level framework that can be used for teams at any scale and both for product and IT. By going back to the source and incorporating new thinking (Flow, Lean) while discarding outdated thinking (empirical process control) a better Scrum is created.

This “New Scrum Game” already exists in the combination of Disciplined Agile Delivery and FLEX’s Team-Agility. It’s not a variation of Ken and Jeff’s Scrum, it’s simply a modern version of the Scrum Hirotaka Takeuchi and Ikujiro Nonaka (authors of TNNPDG) had in mind.

Handoffs, handbacks, holdups and multi-tasking- discovering impediments without value stream mapping

Back in 2006, I would always incorporate value stream mapping into the training or engagement. Over the years, however, as Scrum teams have become predominant, I have found doing to to be of less value. Not because value stream mapping isn’t important – it is, but because people don’t seem to be able to do it well.

Continue reading “Handoffs, handbacks, holdups and multi-tasking- discovering impediments without value stream mapping”

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”