Agility Takes More than Practices
Your organization has an Agile way of working. Your previous company probably did too, but theirs was different. And the popular Agile frameworks? They don’t all agree either.
What’s going on? In two decades of worldwide interest in Agile, haven’t its practices been perfected? The many practitioners and thought leaders – haven’t they distilled the best way to structure teams and define roles, to plan and estimate work, to basically set up the whole process?
If that were the case, agility and much-improved business outcomes would be everywhere. But they’re not.
One reason is that organizations and teams are “complex adaptive systems.” No two are alike and they change all the time, so there can’t be a universal optimum.
Let’s say you don’t aim for perfection. Instead, you apply conventional wisdom and commonly accepted “Agile practices” in the hope of becoming more agile. Even that may not yield meaningful change, because practices are superficial. You’d get different results from the same practice if you executed it with a different mind-set: three invisible elements that guide your application of the practices. Let’s examine them.
The first element: principles
Principles are the standards that guide choices, decisions, and actions. To see them play out, consider a ubiquitous Agile practice: the daily standup meeting. In its popular format, every team member answers the same three questions about their recent, current, and next work.
If a team obsesses over outcomes and effectiveness – two Agile principles – their answers will move them closer to their immediate goal and reduce wasted effort. If they also collaborate and self-organize on work, and are transparent with each other – three additional Agile principles – those answers will turn into a healthy dialogue that strengthens the team.
On the other hand, if the meeting leader has traditional work principles in mind, the three-question format will yield other outcomes. For instance, the answers might be used for holding team members accountable for individual micro-progress against a pre-made plan. There would be no team vibe or growth. The meeting would feel statusy; the members would engage to the extent they can avoid receiving blame or negative attention.
The second element: beliefs
Beliefs are people’s most impactful assumptions. Let’s see how beliefs play out in sprint planning, which is notionally a simple practice: every couple of weeks, the delivery team and the product owner choose, from among the most valuable work items, the ones that would fit in the next sprint.
These people may hold Agile beliefs, such as: we’re human, so we’ll make mistakes; valuable opportunities for changes in direction could present themselves anytime; requirements could go stale. Based on this narrative, both the delivery team and the product owner would prefer very short sprints and a focus on current needs, thus increasing their chance of creating truly valuable increments. They might even forgo sprints altogether and work instead in a flow model with more frequent decision points.
With traditional beliefs in mind, however, the same planning practice would produce different outcomes. Believing — correctly or otherwise — that the product owner knows what she wants, and that her ideas would remain valuable and mostly unchanged until baked into product, the team would work with a bigger backlog, longer sprints, and big early designs. That would limit everyone’s flexibility and increase the cost of seizing opportunities.
The third element: values
People’s values are what they consider most important. They are few but mighty – they guide every choice.
Consider the well-documented practice of refactoring software code. The idea is to improve the code’s design, without altering its functionality, to make it easier to work with. Personal-life parallels of refactoring include tidying up a closet, cleaning out the fridge, and moving computer files around to reduce clutter.
Teams and managers who prize getting deliverables right the first time — a traditional value — consider refactoring a penalty for poor execution, flawed designs, or bad planning. Therefore, they refactor code only when it absolutely needs to change, though by then that’s usually hard and expensive to do.
By contrast, teams and managers who value adaptation – an Agile value – take a different view on the exact same practice. They regularly refactor likely-to-change code, so when they inevitably need to maintain, reuse, or extend it, that’s safer and cheaper to do.
Values, beliefs, and principles are the three elements of a mind-set. If you like the promise of Agile but your current mind-set doesn’t quite align with it, executing “Agile practices” won’t do you much good, and may even do harm. Instead, start by adjusting your mind-set, and then customize your practices. That will create a meaningful change in your ways of working and improve your outcomes.
Copyright © 2021, 3P Vantage, Inc. All rights reserved.