Principles really count because they define a set of behaviors, they can clear a path through the fog.

Principles really count because they define a set of behaviors, they can clear a path through the fog.

Every once in a while I get very confused when someone tells me they are Agile, but then list a whole bunch of their practices that make 1950’s management and software development practices look enlightened. Practicing and being Agile has meaning. Being Agile begins by embracing a set of principles. Whether you embrace the 12 principles in the Agile Manifesto or the 24 suggested by Gil Broza in his book The Agile Mind-Set (SPaMCAST 352), without a foundation of principles you can’t achieve stability in Agile. In the end principles really count because they define a set of behaviors. Organizations that don’t embrace the principles of Agile can do some of the techniques, but they can never really be Agile. There are all sorts of reasons why people and organizations eschew some or all of the Agile principles; however, whatever the reason rejecting any of the principles injures your ability to be Agile. The most pernicious reason for an organization saying they are Agile but not being Agile sits directly at the feet of management.

Management is critical to implementing Agile. Once upon a time Agile transformations were a bottom-up phenomenon. Teams would adopt Agile and then use the experience and value they delivered to sell the concept to management. These days every conference and magazine touts the benefits of being Agile to C-level executives. The marketing machine has ensured that every executive understands the value of being Agile; therefore, transformation has become a top-down phenomenon. The problem is that the value is sold but not the need to transform behavior, leading to a scenario where the people pushing Agile down don’t truly understand the necessity to embrace and principles and change how they behave. In this scenario Management views Agile is a developer thing . . . not a management thing. A few years ago I was sitting in on a meeting that a CIO was having with his direct reports to kick-off an Agile transformation. For me, the real nails on the chalkboard moment was when the CIO very passionately stated, “we will embrace one or two the 12 Agile principles this year and think about the others once we get our feet wet.” I think I shattered a molar on the spot (I now have a crown). In essence what he was saying was that he wanted all the benefits of Agile, but had no intention of changing his behavior, nor did he expect his managers to change. The goal of being Agile moved farther away as the result of that meeting. If you want to determine whether you have management support for Agile, look for these three symptoms.

  1. “Agile” projects with all three basic constraints fixed: budget, scope and duration. Typically Agile projects have fixed teams; therefore, they can vary either duration (to deliver a fixed scope) or scope (to deliver to a fixed duration). Fixing all three constraints prevents teams from respecting the Agile principles and using basic Agile techniques. For example, with all three constraints fixed teams will need to force their velocity/productivity to the level needed to deliver regardless of the amount of technical debt incurred by the process.
  2. Command and control project management. Agile teams self-organize and self-manage. Teams where someone is playing a command and control role are not Agile. This type of leadership can’t persist unless it is acceptable to management.
  3. Detailed tasks schedules at the sprint level (or worse yet at a release level). Detailed tasks schedules, typically accompanied by task-level estimates and assignments are a reflection of classic task-level project management, not Agile. Task schedules are caused when Agile practitioners either do not have the proper training or when they are required to develop schedules that strip the ability to self-manage and self-organize.

Management has a strong influence on how Agile is practiced. When management fails to understand their obligation to support and promote Agile, other strongly entrenched positions will generate resistance and compromises that reduce the effectiveness of Agile principles and techniques.