Nowadays, everyone feels pressure in an organization. Traditionally pressure has been viewed as starting at the top of the org chart and permeating and cascading down in the organization. For this discussion, let’s assume the pressure originates outside an organization as market or customer pressures. Those are often to deliver features and services and to do so faster and more cheaply. Patience is not a key virtue of today’s economy.
In an organization that subscribes to Agile values and processes, the pressure takes the following path:
- The market and customers require services and features faster, cheaper and at higher quality.
- Leadership (management, sales, customer success, marketing, finance, etc.) respond by putting pressure on the Product organization, which is – at the end of the day – represented by Product Managers and Product Owners.
- Product Owners ask for the Agile team(s) to delivery stories and features at high speed, but with good quality.
- The Scrum Master acts as protector of the team and helps negotiate a feasible commitment (related to scope and time).
- The Agile team attempts to deliver against their forecast/commitment.
Many companies are very much aware of what is called “technical debt”. While there are several trains of thought and definitions around this term, I’d explain technical debt– for the purposes of this conversation – as known technical shortcuts or compromises that were taken in the course of developing something or known, non-critical defects that are allowed to exist, at least for some period of time. Examples: Developers choose a sub-optimal technical design of a solution that is known to be less robust, but quicker to implement. Or: a key feature in need of being released to the market still has several medium-severity bugs that are deemed non-critical, so the feature is released with those defects. In either case, technical debt is like regular debt in that it has to be paid off, hopefully sooner than later, by refactoring the code, rectifying the design/architecture or fixing those known bugs. If not attended to, technical debt will pile up and make the product unreliable, fragile and harder to maintain in future. Some would argue that unresolved technical debt over time even incurs something equivalent to interest in that it gets – like financial debt – harder and harder to resolve. Mounting technical debt is also known to slow down new feature development as more and more energy is spent on just keeping technical issues under control.
Back to Agile: is there something equivalent to technical debt when it comes to transforming teams and an organization and moving them to Agile? I would argue yes, there is. Let’s think about some examples.
- Focus on practices without anchoring on values and addressing culture
- Ignoring of traditional behavioral patterns and management styles.
- Reliance on external consultants without growing local roots.
- Team-only approach without addressing team context and organizational impediments.
- Insufficient training (team members, Scrum Masters and Product Owners).
- Not investing in internal coaching and sustainment after the initial transformation (see Keeping the Agile Ship on Course).
- Leading the transformation with the implementation of an Agile tool (ALM) and assuming this will make teams Agile.
- Grass-roots only, bottom-up transformations without leadership support.
These are just a few examples that come to mind. To see other common anti-patterns, I recommend looking at the results of VersionOne’s annual State of Agile Survey.
The shortcuts mentioned above will – by themselves – not automatically result in doom and complete failure of an Agile transformation. However, similar to technical debt, they will weaken the impact and progress of a comprehensive transformation and limit the benefits the organization will reap. Dealing with the ramifications of these compromises will consume more and more energy as we’re attempting to pay off this debt. Over time, these “cracks in the foundation” will impede additional progress and the organization may even start to regress to the “pre-transformation state” due to the always present organizational inertia and tendency to revert back to previous state.
It comes down to this: Agile debt is real and at least as destructive as technical debt. So let’s not take the easy shortcuts, but focus on doing it right. Only that way will an Agile transformation “stick” and provide real and lasting benefits to an organization.