Values

There's a version of the current moment that goes something like this: AI writes the code now, so the ceremonies and the cadences and the careful slicing of work were scaffolding for a slower era, and we can quietly let them go.

We've spent the past year adopting LLMs inside our company. We have experimented with agentic engineering, LLMs pouring over research to identify patterns, leveraging design systems and AI for prototypes, exploring how we can reduce the turns on customer support, and a whole lot more. What we have found is that the tried and trusted agile practices haven't become less relevant. They've become the thing holding everything together.

Last week at our in person team get together, which we call Advance Easy Agile, we started calling this the agile renaissance.

The bottleneck moved. It didn't disappear

The most useful lesson we've learned is also the least glamorous.

When your team can suddenly produce X3 as much work in progress, the constraint doesn't vanish, it simply moves. Code generation stops being the bottleneck and review becomes one. Or testing. Or deployment. Or the single person who understands the integration well enough to say whether the change is safe.

The failure mode is subtle and it feels like productivity. You start more work because there's capacity to start it. Everything is in flight, nothing is in production, and the queue in front of your slowest step keeps growing. You've optimised one part of the value stream and yet made the whole system worse.

Lean principles were written for exactly this. Limit work in progress. Optimise the whole system, not the part you happen to be looking at. Find the constraint before you add throughput upstream of it.

A key reminder for our team as we experiment with agentic engineering: don't start more work just because the LLM has capacity. Shepherd what's already in flight through to production first.

Small slices got more important, not less

The instinct with a capable model is to hand it a bigger problem. A whole feature. A whole epic. It will happily oblige, and you'll get a large volume of plausible output that may be time consuming to verify and painful to unpick when one assumption at the base of it turns out to be wrong.

Small, thin, independently valuable slices give you something a large batch can't: fast feedback on whether you're building the right thing, and a cheap way to change your mind. That was true when a human wrote every line. It's more true when generation is fast and verification is the slow part, because the cost of a wrong direction now lands almost entirely on review.

Decomposition and just enough upfront planning for the LLM loop may become one of the highest-leverage skills on a team in 2027. Breaking a piece of work into pieces that flow through the system - that are composable, that each stand on their own, that can be checked in isolation, behind a feature flag - is the thing that lets the team go fast safely and in the right direction, rather than just fast.

Retrospectives make space to improve

Here's the pattern we didn't anticipate.

The more time people spend working with an LLM, the more their working day becomes a solo activity. It's a conversation, and a productive one, and yet it happens in a window on one person's screen. The incidental collaboration that used to form part of the regular work day - chatting to the person next to you, conducting an over the shoulder review of some WIP, or just overhearing a conversation that changes your approach - appears to have been thinning out for our team without a conscious decision being made.

So the deliberate moments carry more weight than they used to. Planning is where a team builds genuine shared context rather than parallel individual understandings of the same work. Retrospectives are where a team notices that its process has drifted, that a new tool introduced a new failure mode, that the way work moves through the system stopped matching the way it's described.

A retrospective was always the mechanism for a team to adapt, course correct and improve. Teams are adapting faster than they have in years. Skipping the ceremony that processes that change, right now, is poor timing.

Talk about the outcome, not the technology

One more (and perhaps the most important thing), and it applies as much to how we build our own products as to anything else.

Nobody really wanted AI per se. Companies sought predictable outcomes, customers wanted tangible value more quickly, and team members wanted engaging work and more time with their families and friends. There's a lot of software shipping right now with an AI feature bolted on, and folks can tell. It doesn't take long to work out which capabilities were built to solve a real customer problem and which were built to be mentioned.

Can we describe the value we are delivering without naming the technology underneath it? For example, can they plan more effectively? Are they able to spot a bottleneck sooner? Will they walk out of a retrospective with an action item that will improve how they work? That is what we need to be championing. How it works underneath is an implementation detail, and framing it as the headline usually means the outcome underneath isn't strong enough to lead with.

A constant reminder from our colleague Teagan last week - look at this from the perspective of our customers. We get caught up in the excitement too, yet we need to stay grounded in what our customers need.

A renaissance implies something went wrong first.

If you spend any time in this space, you'll have seen the other framing: agile is dead. It's said with a lot of feeling at the moment, and I don't think the feeling is unearned.

Somewhere over the past two decades, the four values in the manifesto got industrialised. A set of principles about how people work together became a thing you buy, roll out and report on. For plenty of teams, "agile" now names something that was done to them rather than the way they work. A multi-year transformation, a re-org, new titles, a wall of velocity charts, and a stand-up that quietly became the status report to a manager. Ceremonies observed. Principles nowhere. If that's the association, "agile is dead" seems like a fair thing to say.

That's not what we're proposing a renaissance of. Nearly the opposite, in fact. The practices holding up under agentic engineering are the small, load-bearing ones: limit work in progress, slice thin, get feedback early, inspect and adapt together. None of that needs a transformation program or a maturity assessment. A team can start on Monday, on their own team, without permission.

I should be upfront abut where we sit in all this: Easy Agile has built a business on the industrialisation, and we exist to help teams live the principles at scale, in service of better outcomes for their own customers. The need is real - the manifesto was written about small teams who could see each other, not four hundred people across 11 timezones. The failure wasn't scaling the principles, it's that the apparatus became the deliverable while the feedback it was meant to produce went missing.

Where to from here?

It was great to come together as a team at Advance Easy Agile and reflect on the current state of the market, reflect on what we've learned within the product & engineering space over the past 25 years with the adoption of agile practices and lean principles. I think back to my first workshop with Mary Poppendieck in 2009 and how much we've learned and evolved in the software space since then. And then I think of how much we have to re-learn, how everything old is new again.

If you're navigating this with your own team, the least risky place to begin isn't a tooling decision. "Individuals and interactions over processes and tools".

What are you going to do? Perhaps start by looking at where work is piling up in the system and have a conversation with the team about it in a retrospective. Some conversation starters: what is genuinely faster? what has quietly become the new constraint? what is in progress right now that nobody is shepherding to done? Finish what you've started before pulling in more work.

None of this is new. And that's the point. We're an early adopter of agentic engineering practices and we are working with mid-market and enterprise teams who are starting to explore AI. We're surely going to be having these same conversations again and again over the next couple of years. The practices we see holding up best under the current changes are the ones agile and lean thinking gave us decades ago. The tools are new. The discipline isn't.

If you want to chat about this feel free to find some time on my calendar.

Easy Agile builds Jira-native apps that help teams plan, prioritise and improve together — including TeamRhythm for user story mapping and retrospectives, and Programs for PI planning across teams.

‍

Psychological safety is the key to high-performing teams. But how is it created?

Agility is the response to a complicated situation where unknowns override the knowns. A high-performing team is one where all members have their say, and there are multiple decision-makers. Psychological safety is the belief that the workplace is safe for speaking up about ideas, concerns or even failures.

But where does kindness fit in?

Kindness is the foundation for psychological safety.

Kindness is essential at each of the first three stages of Dr Timothy R. Clark 4 Stages of Psychological Safety model.

Stage 1: Inclusion Safety

Humans long to feel accepted before they need to be heard. As a leader, you can create inclusion by showing kindness by being aware, sensitive and curious about an employee’s life. A good starting place is; how was your weekend? How is the family this week? Have you got any exciting celebrations coming up? You seem a bit quiet today, is everything okay?

Stage 2: Learner Safety

Humans need to ask questions, give and receive feedback, and make mistakes whilst feeling safe. Showing kindness creates the trust to do so.

Stage 3: Contributor Safety

Humans need to feel safe to participate as team members. A commitment to kindness ensures greater information flow, higher quality connections at work, and an increase in collaboration.

Individuals thrive in environments with psychological safety. Fear triggers the self-censoring instinct, holding us back. When the environment nurtures psychological safety, there is an increase in confidence, engagement, and high performance.

3 Tips for Implementing Kindness in Your Team Today

Tip 1: Model kindness yourself. No matter your role, kindness is contagious. If you start acting kindly, this will soon spread to your whole team. You can serve with kindness by listening, working with forgiveness, offering a helping hand, showing concern, or celebrating significant events in a coworker's life.

To celebrate random acts of kindness day and live our Give Back company value, our team donated to Kind Hearts Illawarra.

Tip 2: Incorporate kindness into your team's ceremonies. Each team member can say one thing they are grateful for in the morning huddle. Each ceremony can leave room to give thanks to a fellow team member. At Easy Agile, we put this into practice by encouraging everyone to share a 'good thing' each day.

Tip 3: Implement Good Thnx in your company Slack. The Good Thnx Foundation provides a link between people and corporates that want to give and charities. As our team send “thanks” to one another, the recipient is given $50 to donate to a charity of their choice. Our contribution via Good Thnx for FY21 was $15,201.

Simply put, be kind today; it is free and enables high-performing agile teams!