A hybrid

A hybrid

Being Agile is a lot easier than it was even a few years ago. However, there are still roadblocks; including lack of management buy in, not changing the whole development life cycle or and only vaguely considering technical Agile practices. The discussions I have had with colleagues, readers of blog and a professor at Penn State about roadblock have generated a lot passion over the relative value and usefulness of hybrids.

Classic software development techniques are a cascade beginning with requirements definition and ending with implementation. The work moves through that cascade in a manner similar to an auto assembly line. The product is not functional until it rolls off the end of the line. The model uses specialized labor doing specific tasks over and over. Henry Ford changed the automotive market with this technique.  However, applying this model to software development can cause all sorts of bad behaviors. Those bad behaviors are generally caused by a mismatch between linear work like manufacturing and work that is more dynamic and more oriented to research and development. One example of a bad behavior the abuse of stage gates. Often teams continue working even when the method indicates they must wait for a stage gate decision. The problem is that if they wait for a decision they will never complete on time. Managers are ALWAYS aware what is happening, but choose to not ask. It generally is not because anyone in the process is a bad player, but rather that the process is corrupt.

Agile is different. Agile stops the cascade by breaking work into smaller chunks. Those smaller pieces are then designed, developed, tested and delivered using short sprints (known as cadence) in order to generate immediate feedback. The “new” process takes the reason for running stage gate stop signs away.

Hybrid models attempt to harvest the best pieces from the classic and Agile frameworks to fit the current organizational culture or structure. The process of making the Agile (or classic methods for that matter) fit into an organization optimized for classic methods is where issues generally creep in. The compromises required often stray from the assumptions of built into the Agile values and principles.  Examples of the assumptions built into Agile include stable teams, self management and delivering functional software at the end of every sprint. It is easier to wander away from those values and principles than to tackle changing the organization’s culture or structure. One of the most common (and damaging) compromises can be seen in organizations that continue the practice of leveraging dynamically staffed teams (often called matrix organizations). Stable teams often require rearranging organizational boundaries and a closer assessment of capabilities.

Typical organizational problems that if not addressed will lead organizations to generate classic/Agile hybrids include:

  1. Silos: Boundaries between groups require higher levels of planning and coordination to ensure the right people are available at the right time even when there are delays. Historically, large development organizations have included the role of scheduler/expediter in their organization chart to deal with these types of issues.
  2. Overly Lean: Many development organizations have suffered through years of cost cutting and have far fewer people than needed to complete the work they have committed to accomplishing. Personnel actively work on several projects at once to give the appearance of progress across a wide range of enterprises. Switching between tasks is highly inefficient which reduces the overall value delivered, often leading to more cost cutting pressure.
  3. Lack of Focus: Leaders in development organizations often feel the need to accept and start all projects that are presented. Anthony Mersino calls this the “say yes to everything syndrome.” This typically occurs in organizations without strong portfolio management in place. Ultimately, this means that people and teams need to multitask, leading to inefficiency.
  4. Lack of Automation: While I have never met a development practice that couldn’t be done on a small scale using pencil and paper, automation makes scale possible. For example, consider running several thousand regression tests by hand. In order to run the tests you would either need a significant duration or lots of people. Lots of people generally means more teams, more team boundaries, more hierarchy and more overhead – leading to the possibility of just running less tests to meet a date or budget.

The values and principles that underpin Agile really matter. They guide behavior so that it is more focused on delivering value quickly. The four values in the Agile Manifesto are presented as couplets. For example, in the first value: “Individuals and interactions over processes and tools,” the items on left side are valued more than those on the right (even though those on the right still have value). Hybrid models often generate compromises that shift focus from the attributes on the left more toward the center and perhaps back to those attributes on the right. Hybrids are not evil or bad, but they are generally cop-outs if they wander away from basic Agile values and principles rather than addressing tough organizational issues.

Agree or disagree, your thoughts are important to guiding the conversation about what is and isn’t Agile.