ASSUMPTION: we’re experiencing a global crisis with impacts as never seen before in modern times.
FACT: our familiarity in dealing with ordinary challenges is itself challenged because of a new set of “unknowns” which add to the complexity of systems which are subject to environmental, functional and human contributions.
New issues, obstacles and very likely emotions, all come into play and maybe regarded as limiting our ability to develop and deliver value as we got used to; without doubt, we’re in uncharted territory.
We already are (or should be) familiar with impediments/blockers, so the whole concept of constraints should not be a total stranger to us especially if we’re used to operate according to Agile frameworks; the increased complexity is driven by the “known-unknowns” as well as the “unknown-known“, the latter being the unforeseen issues that pop-up in due course of action.
With this in mind, it is clear and reasonable to ramp-up focus on identifying and managing constraints coupled with renewed discipline on the way we manage goals, regardless if these are short-term (such as those typically associated to a Sprint) or relevant to longer term objectives such as milestones or major releases.
Let’s first take look at the basics of the Theory of Constraints; then we can review the “smart” attribute of Goals.
“Theory of Constraints” (A Summary)
Every process has at least a single constraint (if not multiple) and the process throughput can only be improved when the constraint is improved, or removed altogether.
Spending time optimising what is not considered being a constraint will not provide significant benefits; only improvements to the constraint will further the ability of reaching the goal.
The Theory aims at providing precise and sustained focus on improving a given constraint until it no longer limits throughput, at which point the focus moves to the next constraint.
The underlying strength of the Theory of Constraints flows from its ability to generate a strong focus towards a single goal and to removing the principal impediment (the constraint) to achieving that goal.
So, although we often may not appreciate it first hand, the matter of fact is that we always face constraints: we must work to identify and remove these when possible, but if this is not possible, then we resolve by mitigating the impact on the planned outcome/output.
I mentioned earlier that constraints can also be those that we are used to referring to as impediments/blockers, so the first action for those involved in developing and delivering value, as a product or a service, is to spend quality time upfront to help identify and agree on what the known constraints/impediments/blockers are; this should be done no later than when planning for near-term or imminent work (e.g. Product Backlog Refinement, Sprint Planning sessions).
But, the “known” variables are only one part of the equation – the other part relates to the “unknown”.
This is where working in iterations comes in play: unknown constraints can potentially emerge in due course of action and the ability to adapt and change becomes vital; if these last-minute additions are proved (and agreed across team members) as being blockers for work planned to be completed in the current iteration, then the team’s ability to run effective Daily Scrums / Stand-Ups, not then simple and robotic rehearsals, is tested; appreciating daily team meetings as a powerful collaboration tool to spin-off corrective actions is a must.
It should also be pointed out that constraints are, in all intents and purposes, risk items; as we typically classify risks as financial, business or technical, then without introducing yet more parameters to prioritise actions, we can also consider classifying constraints as financial, business or technical:
- FINANCIAL constraint = a budgeted cost for development and delivery; alternatively the need to deliver added value by means of non-revenue generating effort which in turn requires to streamline the development cost.
- BUSINESS constraint = metric to measure user appreciation for the added value provided by a newly delivered product or service (adoption).
- TECHNICAL constraint = use of specific technology and/or on-time availability of technical resources (expertise, tools, infrastructure).
Focus on systemic constraints also feeds into continuous improvement and enhances our ability to adapt to impacts and change (such as what caused by the COVID-19 pandemic, as an example); the good news is that we don’t need to drastically change our behaviour when dealing with constraints, instead we just need to exploit known practices, such as:
- ITERATIVELY INSPECT GOAL-LIMITING CONSTRAINTS and plan work accordingly.
- FACILITATE THE REMOVAL OF CONSTRAINTS in the delivery path.
- EMPOWER DAILY SCRUMS / STAND-UPS TO SPIN-OFF CORRECTIVE ACTIONS and react to new obstacles.
As for goals, we must avoid ambiguity early-on, since this typically ends up snowballing into short-term failures with likely spillovers of objectives from one iteration to another and consequent loss of delivery pace.
Goals Need To Be “SMART”
All too often we forget considering the importance of well defined (and shared) goals a team can pursue across a Sprint or a Release, so, as we learnt that well conceived User Stories must comply to the “I-N-V-E-S-T” attribute (Independent, Negotiable, Valuable, Estimable, Small, Testable), for goals we must follow the S-M-A-R-T attribute.
When coaching teams on managing their goals, the following is the order I recommend to follow in addressing each of the five characteristics; without specificity to start with, I challenge anyone in being able to sort out the rest:
SPECIFIC = even short-term goals are often generically defined, while instead any goal must be specific to make it meaningful; to help ourselves ensuring this, we can leverage on the way we intend measuring its accomplishment: the simpler is the metric, the more likely is that we’ve defined a specific goal!
MEASURABLE = to avoid ambiguity or subjective interpretation, we must try to measure success according to a binary outcome: “Yes/No” – “Pass/Fail“; if we can measure the accomplishment of a goal in binary terms, then we also prove that the goal is specific!
TIME-BOUND = if we don’t set a target date, the value proposition of any goal becomes meaningless; “time is money”… after all!
REALISTIC = with Specific & Measurable both ticked and a target date set, the latter must then be validated against any constraint that may prevent the goal from being achieved in the time-frame; typically we should be looking into potential readiness issues or unavailability of resources and required skills.
ACCEPTED = this is something that too often is underestimated; individual team members, who may have not accepted the goal from the start, may develop internal resistance as soon as issues arise in due course of action and potentially create an unforeseen technical constraint; ALL team members, with direct or indirect involvement in achieving the goal, must be in agreement and onboard!
SUMMARY: I thought of highlighting two key aspects of our daily work for which we must improve on our due diligence.
Effective and reactive planning for short/mid/long term objectives cannot be done without a clearer line of sight of CONSTRAINTS + GOALS; the COVID-19 pandemic is requiring us to sharpen our capability to operate in what will likely be, in the long-term, a highly dynamic global system.
if you wish to follow-up on the topic, then feel free to reach out over LinkedIn or via email (see top header).