If the agile development methodology isn't working for your organization, maybe it's time to look up - to the C-suite - and ask whether the executive team bought into agile in the first place.
In meetings with business executives, I occasionally hear complaints that agile hasn't delivered desired results and that the organization now wishes to return to the traditional waterfall development methodology or to a version that blends agile and waterfall.
In many cases, agile isn't the problem. Common areas of breakdowns occurring agile teams happen as a result of:
- Poor team dynamics.
- Lack of required aptitude or skill sets to support critical functions.
- Failed investment in cross-team interdependency management.
While these breakdowns do occur and must be managed at the team or departmental level, often the problem is that the executive team didn't undergo the paradigm shift that agile requires.
In the waterfall methodology, development work is done assembly-line style, and new functionality isn't delivered to the business until the entire project is complete. In the agile methodology, work is done iteratively, typically in two-week sprints, with functionality delivered as it is completed.
At CapTech, we not only incorporate the agile methodology into our own practices, but we also teach clients to incorporate agile into their work. Agile delivers benefits that go directly to the bottom line:
- Two-week sprints put development teams into a rhythm that boosts throughput;
- Quality increases as error rates drop and testing improves;
- The business receives new functionality on a routine basis and knows what to expect;
- Questions and issues get resolved quickly as business owners work closely with developers, testers, and analysts, further increasing velocity and quality.
As an organization prepares to make the transition to agile, employees typically undergo extensive training. We find that developers and other IT employees are eager to undergo the training because they recognize that, with agile, their work will become more predictable and more effective.
In contrast, many executives skip the training; they are busy people and are intelligent enough to infer the meanings of such terms as agile, sprint, and backlog. According to Webster, agile is an adjective that means "ready to move with quick easy grace." Doesn't that mean that executives should be able to change project requirements more often and that delivery dates should be more flexible?
For agile practitioners, however, agile is a noun that refers to a set of core tenets and best practices that, if followed with discipline and rigor, increase the likelihood of project success. One tenet is that delivery dates aren't flexible, and a two-week sprint is a two-week sprint. If you need additional time to complete a feature, you include that feature in the next sprint rather than miss a delivery date.
When executives don't make the paradigm shift to agile and, instead, use new terminology to drive development teams in the same old way, the foundations of the agile methodology are shaken. That can lead to project failure and to the mistaken belief that agile is the problem.
In some cases, organizations then drop the agile methodology altogether, despite the disruptions and costs of returning to waterfall, or they move to a "wagile" methodology that incorporates aspects of agile into waterfall. Both options generally serve only to reduce productivity while damaging morale.
The Agile Alliance recently surveyed more than 4,000 agile practitioners, asking them why agile projects fail. According to the organization's website, some 42 percent said company philosophy or culture was at odds with core agile values and 36 percent noted a lack of support for cultural transition.
According to the Alliance's summary of the survey results, "[s]enior leadership holds the most leverage in facilitating the transformation of an organization's culture to one that embraces agile" and "[t]angible, active involvement at the executive level is critical to cultural transformation."
I would argue that executive buy-in is even more important than active executive involvement. Unless executives truly understand agile and undergo a fundamental change in their thinking, their active involvement in particular projects or in cultural transformation will yield a half-hearted adoption of agile and, with it, project failure.
While we may be able to infer the meanings of terms such as agile, we can't infer a paradigm shift. You have to invest your time and energy in the training before you can understand and embrace this new and highly successful way of doing things.