The Global Flipchart is IAF's quarterly magazine about the power of facilitation – made by members, for members. Contact the editorial team by email: globalflipchart@iaf-world.org
Global Flipchart #9
September 2017 |
Issue #9
Beyond agile practices
By Gil Broza
“Agile” has been a steady buzzword in business. Having started in software development 20 years ago, it slowly crept into design and marketing. I’ve now brought Agile to HR, content production, even corporate real estate management.
Imagine you know 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. Want to visit us and take a look?”
Intrigued by 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 realise 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 recognise. You’re a bit uneasy when you realise you can’t tell who’s in charge. 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 – certified! – 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 get their results not from the practices you observed, but rather from three invisible elements that guide their application of the practices. And they put those elements in place first with awareness and training, then with coaching, and then with a lot of facilitation.
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 since their previous meeting 24 hours earlier.
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, Self-Organization, and Focus also guide them, their answers and the ensuing dialogue would strengthen the team. These are but five of the Agile principles.
On the other hand, if the meeting leader has traditional management 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, which is 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 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 once baked into a deliverable, 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 example, consider the well-documented and partially automated Agile practice of code refactoring. It simplifies the code’s design without altering its functionality, thus making the code easier to work with.
Teams and managers who value “getting it right the first time” 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.
Mind-Set
Values, beliefs, and principles are the three elements of a mind-set. If you support a team that likes the promise of Agile, executing the practices without adjusting their mind-set won’t deliver on that promise. So, before they adopt Agile practices, help them examine how the principles, values, and beliefs behind them fit their current mind-set about the work. If they don’t fit well, start by helping them open up to the Agile way of thinking — otherwise the practices won’t stick, and may even do harm. And since mind-set change is individual and voluntary, client-driven facilitative techniques are your best tool.
Gil Broza is on a mission to make the world of software development more effective, humane, and responsible. How? By helping leaders and teams truly adopt the Agile approach. Several of the world’s largest organisations are having him train their managers and executives on leading toward the Agile mind-set. Many companies have relied on his coaching, training, and facilitation for people-first Agile transformations and complete makeovers. He is the author of The Human Side of Agile and The Agile Mind-Set. Get a taste of his approach at OnTheWayToAgile.com