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.

 

At each transition point, the pressure could either be passed through, amplified or filtered (reduced). While we can’t directly affect market (external) pressures, I’d like to think that in healthy organizations filtering occurs internally to protect the organization from undue or exaggerated demands. Some of the mechanisms for this include, not surprisingly, good prioritization, lean portfolio management & experiments, and managing WIP.

Instead of simply passing the pressure through to the next level – or even amplifying it – the job of an organization’s leaders at all levels is to validate and negotiate, which means determining what’s feasible and when. Prerequisites for such healthy conversations include transparency, mutual trust as well as psychological safety.

Without these, serious problems arise, even in organizations that seemingly embrace Agile. What makes this more troublesome is that the resulting problems are often not obvious and can be missed because they occur under the surface and the symptoms tend to be lagging. In the absence of trust, transparency and safety, teams can’t just say “We will not be able to achieve this.” Instead, they seemingly “agree” that an unrealistic goal is achievable (or at least they don’t openly disagree). Leaders walk away thinking they have commitment of their organization, but don’t see the impacts and dysfunctions that occur in the wake of this.

For those of us with project management background, we certainly recall the “iron triangle”:

The pressure on the teams is often tied to fixed scope and fixed time requests. While resources are technically not necessarily a constant, Agile teams more often than not can’t just scale up or out. Even if resources can be added in the short-term, they tend to destabilize the team, force it to go through the forming/storming/norming/performing process again and little or no incremental throughput is gained due to learning and onboarding new team members to a new application and/or domain. So what gives? Traditionally quality has been used as a 4th variable, but I’d like to highlight a broader set of common responses; these are:

  • Incurred debt, e.g.
    • Architectural debt: short-cuts in the architecture that cause the application to become brittle or less scalable or extensible later on.
    • Product design debt: poorly thought-out features and sub-optimal solutions.
    • Technical debt: low-quality code that’s not performant, hard to maintain and not scalable. Code reviews are skipped.
    • UI debt: Visual elements are inconsistent with the rest of the application, the style guide or otherwise non-standard. Local CSS-overwrites are used, pages are non-responsive, etc.
    • UX debt: the chosen design is not user-friendly or intuitive. There is no time for usability testing and iterating. This is common for “feature factories” as well.
    • Process debt: Shortcuts are taken in documentation, release notes, market-rollout and customer training. Feature adoption and satisfaction are not measured.
  • Escaped defects and other QA issues caused by poor code, rushing development and insufficient and only superficial testing.
  • Partially implemented features (often sub-MVP) are released with the intention to “finish the rest of the feature later”. In the lean world, this may be considered waste as the feature are still technically WIP.

 

The above issues might allow a team to meet unrealistic deadlines in the short-term, but at a significant price. If the team is not given the time to pay off these debts and fix the issues right away, which is common for a high-pressure environment because the next customer crisis or life-or-death feature loom, the application is plagued by issues, becomes more fragile, code viscosity is increasing and it becomes harder and harder to maintain and extend. The next set of features will be more difficult to implement and velocity drops. A vicious cycle ensues. As these debts accrue the equivalent of “interest”, they become ever harder to pay off and doing so will take more and more time, which would often slow down or even prevent development of new features for months. That, of course, will not be acceptable due to the existing market pressures.

Since it may take months or even longer for these problems to become fully apparent, the individuals involved in causing these issues by failing to filter pressure appropriately may not see the true root causes and might end up blaming the dev team for poor craftsmanship. Rarely is the true root cause identified and addressed. In the worst cases, the technology organization is blamed and applications eventually have to be completely rewritten and re-architected from scratch or may have to be discontinued and sunset after customer satisfaction and adoption plummet.

Getting out of this mess is hard. Really hard. Rather, it would be better to avoid this situation:

  • Ensure Agile is not just a process to be followed, but a true mindset and culture in the organization, which includes trust, safety and truly honest and transparent conversations.
  • Leaders at all levels should be aware of their responsibility to be filters for external pressures and foster conversations to negotiate achievable goals.
  • These leaders should also be aware that employees may not be comfortable challenging their requests and providing honest feedback. (Even the sincere question “Can we get this done by December 1?” may actually be heard and perceived as “We need to get this done by December 1!”.) Building trust takes time, especially in a company culture that’s transitioning from traditional to true Agile.
  • If the organization can’t help but incur debt to meet a necessary but hard-to-achieve deadline, it should be fully aware of and transparent about the impacts of its decision and explicitly reserve time to pay off that debt ASAP. This choice should remain an exception and not become the rule.