In the summer of 2023, The Adaptavist Group convened some of the industry's leading agile experts for a special roundtable—Agile back to basics: foundations, interpretations, and paving the way forward.
With so much experience in one place, we invited a few of those experts to share more in a series of fireside talks—a fantastic opportunity to delve even deeper into some of the issues surrounding agile transformation.
First to get cosy by the fireside were The Adaptavist Group's own Tina Behers, VP Enterprise Agility, Aligned Agility, and Ronica Roth, Co-founder and Principal of The Welcome Elephant. They chatted to Issac Sacolick, President of StarCIO and contributing editor of InfoWorld and CIO Magazine, about:
- How helping teams to transform with agility has evolved (and how it hasn't)
- Balancing a team's desire to be agile with demands for long-term planning
- The importance of transparency and visibility for successful transformation
- How to help technicians understand why they should work with agility and how it will benefit them
Watch the full fireside chat here or keep reading to get the key insights
Some things change, and some things stay the same
"More organisations know going into transformation that it’s not just about a bunch of process changes, and that it's an actual cultural change."
While it's not always the case that leaders understand cultural change starts with them, there is a much wider appreciation for the fact that cultural change must happen for an agile transformation to succeed. Teams may not know precisely how they will have to think, talk, and feel differently about their work, but more of them have a sense that they will have to change these behaviours.
However, while leaders are stepping up and more people talk about an agile mindset, the naysaying remains. Tina has found that some people dig in their heels, declaring that they're already 'doing' agile or they've already tried it, and it didn't work.
"If I’m the leader of one team or the CEO, the change has to start with me. I have to embrace those behaviours to get the mindset adopted by those around me. It’s getting some of the folks who’ve been through bad transformations in the past to shift their behaviours to adopt agile and be better and quicker at their delivery, whatever it is."
Striking the right balance
When teams see the benefits of agility elsewhere, they want to give it a go but can feel constrained by the waterfall planning approach demanded by their business. Ronica explained that it's okay for forecasting to be expected—being agile is not having permission to keep what you're working on secret.
Agile teams should counsel leaders to expect something different from planning—not a commitment nine months in advance, but a set of outcomes and hypotheses about how to achieve those outcomes.
"[It's having] a rich conversation about how agility at the team level is going to manage the risk of those plans and of getting to those outcomes. Then turn to the team and say, 'Now we have all these tools at our disposal to get to those outcomes or to learn really fast that it's not going to be possible.'"
Meanwhile, Tina made the point that when teams want to change, it's generally because they’ve recognised something about their process is causing them pain. So alleviating their pain—whether that's through coaching them to do Kanban or Scrum or fixing what's broken in the process—is helpful. However, there's only so far you can go with agile at the team level.
"Ultimately, you end up with a conversation with the leaders in the organisation of 'This can only go so far as a team-only function or a technical function.' The value of agility is really at the enterprise level—when everybody is working to achieve value faster."
Clarity and safety are key
"Ambiguity is the one thing that will kill any effort. It doesn’t matter if it's transformation or just getting the kids to the baseball game on Saturday. Ambiguity will kill your ability to do that successfully."
Where leaders might be more courageous when it comes to exploration, failure, and learning, they still need clarity about what work is happening and when—whether that's work, experiments, or the fuzzy stuff in the middle. There's no room for ambiguity. It must be very clear across the enterprise if you want to keep buy-in and momentum.
And when teams use ambiguity and hide behind it, it's essential to look at the reason why. What's the ecosystem that supported the instinct to hide? Has your organisation punished experimental behaviour in the past and made hiding it safer? You need to make it psychologically safe for teams to try, fail, and learn, practising and reinforcing that message over and over for everyone to be as transparent as possible.
"How do we create a very clear ecosystem in which transparency leads to better decisions and better value stories, so you know you’re working on things that matter?"
Why be agile?
"What’s in it for me as a developer? In [an agile] organisation, I’m not having somebody who’s not as familiar with my code as I am tell me how to change the code."
With leaders bought in, it can be hard to bring teams along, especially when they're ingrained in old ways of working. But one of the primary sources of frustration for many technicians is the lengthy specification documents they have to follow that fail to tell teams why they're building something in the first place. In an agile organisation, technicians are told what's required and why, then given the autonomy and respect to make it in a way that meets the objective.
"In the past, quoting to the spec was safe; you never got in trouble for doing that, even when it caused trouble. So how do I create a space in which that team really can bring solutions…where it’s safe to have ideas, even bad ones, and try things and fail fast? We have to keep reinforcing that safety."
