Agility Takes More than Practices
Imagine that you knew nothing about Agile. One day, a friend tells you, “We’ve implemented Agile practices at my company and they’ve done wonders to our development efforts. You should try them. Wanna visit us and take a look?”
Intrigued about the potential for improving your own team’s results, you visit your friend’s office. His team is working in a noisy open space. You notice a wall covered with stickies and duct tape, and upon close examination you realize that it is their work plan. You ask your friend where they store project artifacts, and he points to the wall, saying, “That’s most of them, right there.”
Before you can decide whether these Agile practices are promising or crazy, you’re invited to the team’s sprint planning. That meeting doesn’t feel like anything you recognize. You’re a bit uneasy when you realize you can’t tell who the project manager is. And then you wonder, why are so many people getting together just to plan for a couple of weeks? Don’t they care for efficiency? Why do they keep asking to simplify, split, remove, or defer work items? Why do they avoid making large commitments? Where is the accountability?
Such scenes could well give you the impression that Agile is not a responsible way to work. A quick Internet search, however, would put your mind at ease: There are established Agile process frameworks and solid practices. If you just followed them, you would produce better, cheaper, faster results. And you could be formally trained to do that. Trust us, this stuff works.
The trouble is, it wouldn’t — not if you merely followed someone’s recipe or practices…even if those practices applied perfectly to your unique context. Your friend and his team are getting their results not from the practices you observed, but rather from three invisible elements that guide their application of the practices.
The first element: principles
Consider a ubiquitous Agile practice: the daily standup meeting. In its popular format, every team member answers the same three questions about their progress.
If a team lives by the principles of Time-Boxing and Outcome, they will give answers that move them closer to their iteration goal and to a delighted customer. If the principles of Transparency, Focus, and Self-Organization also guide them, their answers and the ensuing dialogue would strengthen the team. These are only five of the Agile principles.
On the other hand, if the meeting leader has Waterfall principles in mind, the exact same format will yield other outcomes. For instance, the answers might be used for holding team members accountable for individual micro-progress. In that case, the outcome will not be a stronger team that’s closer to their goal; the daily meeting will be more likely to amplify individualistic and self-preserving behaviours.
The second element: beliefs
Beliefs are convictions that people hold to be true in their situation. Let’s see how they play out in iteration (sprint) planning. It’s a simple practice: the delivery team and the product owner choose from among the most valuable work items the ones that will fit in the iteration.
These practitioners may hold Agile beliefs: Being human, they might make mistakes; valuable opportunities for changes in direction could present themselves anytime; and requirements could go stale. Given these beliefs, both the delivery team and the product owner would prefer short iterations and a focus on current needs, and thus could increase their chance of creating truly valuable increments.
With Waterfall beliefs in mind, however, the same planning practice would produce different outcomes. Believing — correctly or incorrectly — that the product owner knows what she wants, and that her ideas would remain valuable and mostly unchanged once baked into product, the team would work with a bigger backlog, longer iterations, and big designs up front. That would limit everyone’s flexibility and increase the cost of seizing opportunities.
The third element: values
People’s values are what they hold most important. For an example, think about the well-documented and partially automated practice of code refactoring. It improves the code’s design without altering its behaviour, thus making the code easier to work with.
Teams and managers who value “getting it right the first time” — a Waterfall value — consider refactoring a penalty for poor execution or bad decisions. They refactor code grudgingly and superficially.
By contrast, other teams and managers who subscribe to the Agile value of adaptation consider refactoring a deliberate and desirable practice. Wanting to get to “Done” without delay, they develop simple, sufficient, and safe code for their increments. Once that code needs to grow, they’ll refactor it to make room for whatever that growth happens to be. They rely on this technical practice to support business decisions.
Values, beliefs, and principles are the three elements of a mind-set. If you like the promise of Agile, executing the practices without adjusting your mind-set will not get you that promise. So, before you adopt Agile practices, examine how the principles, values, and beliefs behind them fit your current mind-set about the work. If they don’t fit well, start by adjusting your mind-set — otherwise the practices won’t stick, and may even do harm.
For years, Agile coaches and bloggers have been saying, “Don’t just do Agile (go through the motions), be Agile (have the mind-set).” Yet few went beyond the super-brief Agile Manifesto to explain what that meant. So in 2015 I took on the challenge to explain Agile thinking in simple, concrete terms without prescribing specific practices or frameworks.
The result is my book, The Agile Mind-Set: Making Agile Processes Work. Apparently the need is real, and the book’s reception has been heartwarming. It’s available in print, electronic, and audio formats. Please check it out.
Copyright © 2015, 3P Vantage, Inc. All rights reserved.