(My) Definitions

  • Organizational Constraints

    • "Organizational Constraints" ^1 are constraints that prevent a software team from achieving the full vision and benefits of Agile or Scrum. For Agile, this means a constraint against one of the value statements or principles of The Agile Manifesto . For Scrum, this means a constraint* against the The Scrum Guide. If too many serious Organizational Constraints are present in an organization, a team's success will be very limited with Agile and/or Scrum. Note also, that in large part, that the organizational constraints generally are just dysfunctions/constraints that existed prior to Scrum. Scrum didn't cause the constraint. It just made the constraint much more visible via Scrum transparency.
      • An Organizational Constraint is one of many types of impediment, but what distinguishes an Organizational Constraint from the regular ol' impediment is that the barrier to removing the constraint is very very high. Often, when teams are on the march to Agile/Scrum, we tend to focus on removing the impediments that yield us the best ROI in a fairly short period of time. Said another way, we focus on fighting the battles we can win now, and incrementally trying to win the other battles over time. Attempting to remove organizational constraints tends to yield a low or even negative(getting fired!) short term ROI. Again, we don't surrender, we just attempt removing these impediments incrementally. Sometimes a Mitigating Practice will help us remove an organizational constraint eventually.
  • Mitgating Practices

    • On the other hand, it is incumbent on Scrum Coaches, Scrum Masters, and highly motivated Scrum individuals to use the "art of the possible" to find a "Mitigating Practice" that limits and/or mitigates the damage done by the Organizational Constraint. Teams should never lose sight of their Mitigating Practices because there may come a day where the Organizational Constraint is lifted or changed.

Organizational Constraints Cause Process Debt

"Process debt" is the process cousin of Technical Debt. To me^2, technical debt is a debt incurred by taking a quality shortcut in the present that decreases the time to deliver something. This debt, because it reduced quality, will accrue interest over time that must be paid. If the interest is not paid, then the debt swells, and eventually it will cause the system to collapse if the debt is not serviced. (the equivalent of bankruptcy -- or in software terms -- a full re-write of an existing, clunky system) The same is true of process debt. It is important for Scrum Coaches and Scrum Masters to educate the organization on the costs of this process debt, particularly when viewed as a whole and taking into account other process debt created by *all* other organizational constraints placed upon Scrum.

Too Much Process Debt Causes Process Collapse

Like financial debt, a small amount is probably ok, but a large amount is never good. If left unserviced and unaddressed, over time, the process debt will collapse a Scrum implementation. Many will incorrectly blame Scrum, but the reality is that almost always, it was the organization that failed, by placing too many organizational constraints on the Scrum implemention. In my view, the *only* time Scrum fails is when it is incorrectly applied to the wrong problem space. For example, Scrum is for product development and for projects whose sprint scope changes very little over the sprint length, so trying to apply Scrum to a team whose scope changes very frequently is an incorrect application of Scrum.

^1- Organizational constraints in Scrum are an example of what used to be known as a "Scrumbut", though the Scrum creators are trying to get away from that terminology and more towards a theme of doing Scrum "correctly" vs. "incorrectly."
^2- I view technical debt a little more generically than the way it was originally defined by Ward Cunningham. That's ok in my view, because most in the industry do the same thing. Unfortunate, but true.