When implementations go wrong they need to be repaired.

When implementations go wrong they need to be repaired.

Not all Agile implementations succeed. Failure is a broad concept that boils down to the business not getting what it needs, when it needs it and at a price it can pay. Five macro categories of behavior can lead Agile implementations towards failure.  Each of these categories of bad behavior can generate friction within and between teams and the organization. Friction will lead to miscommunication or letting development get out of sync with business needs – both of which can lead an implementation toward failure. Each category needs to be understood so that it can be addressed and prevented. The categories are: buy-in, partial implementations, unaddressed team problems, communication problems and ignoring the concept of product ownership.

Buy-in is the engagement of the team, management (IT and corporate), business (those folks outside of IT) and other stakeholders (which may include vendors or partners) in implementing Agile techniques.  Without buy-in, an Agile implementation will fail because the changes need to make Agile work will be someone else’s ideas.  Implementing Agile will require changes to processes used by all groups involved in delivering software. However, just telling them that change is likely will illicit animosity or passive aggressive behavior.  Engagement helps defuse this issue.

If you only partially implement Agile, the risk the implementation failing increases because of the boundaries that are created between what is Agile and what is not.  Some organizations only partially implement Agile, i.e. Agile techniques are used for only some parts of the software development life cycle.  There are all sorts of names for this syndrome, including: “iter-fall” (Agile up to a point, then a big bang of testing and rework and re-testing occurs) and “fall-iter” (big upfront analysis, then Agile for coding).  Partial implementations require a significant amount of communication and negotiation between the teams that are using different techniques.

Agile teams have different structures (hierarchy versus collaborative structures) and organization (project manager versus coach). Implementing Agile requires addressing team structure by flattening the team’s organization and the mechanisms used to manage human resources, such as using retrospectives to change behavior.  Failure to redesign how teams are structured and managed creates a mess that make implementing Agile difficult. Picture the impact on an Agile implementation of a department manager visiting a team’s standup meeting and passing out daily assignments.

Without good communication, your Agile implementation will fail because Agile does not generally leverage paper artifacts as a communication framework. Communication is just about the most important behavior underlying successful Agile implementation.  All of the techniques in Agile are geared to facilitate the transparent flow of information. Unfortunately, old organizational habits are hard to break.  Examples of non-Agile communication behavior include: information hoarding (I am important because I know something you don’t) and information hiding (we are in trouble, but maybe it will go away if we don’t tell anybody). Actively facilitating and encouraging the creation of communication channels inside and outside Agile teams becomes one the primary roles of Agile coaches.

The product owner is difficult to implement initially, which can lead organizations to postpone integrating a business representative into Agile teams.  Failure to implement the product owner role properly will reinforce the divide between IT and the business division.  That division leads to delivery of functionality that doesn’t quite meet business needs. Each Agile team needs a product owner or they risk delivering the wrong functionality.

The top five behaviors that cause Agile implementation to fail are not new problems.  Each of the five behavioral categories rob Agile techniques of their effectiveness and therefore place a drag on projects. That makes teams and organizations more likely to will revert to methods and techniques that have been used in the past with all of their attendant problems of late delivery, high cost and poor quality. In this week’s Daily Process Thoughts we will examine each category in more detail so we can avoid or fix the problems.