The Hardest Thing in Agile
I’ve been struck by this over the past few months, as I watched our team shuffle around a little, update our strategy, our team missions and remits, and get cracking on bringing some magic to our customers in 2025. I even posed the question to the Cape Town office canteen full of product and technology staff when I was there a month or so ago; “what is the hardest thing in agile”. And I think I know…
It isn’t the pace, the changing priorities, the pivoting, the inter-team communication, the process selection, the pointing of tickets, the lingo, the cheesy team socials, the CI/CD, etc…
The hardest thing in agile is the thinking bit. The spending of brain power. The conscious and intentional calculation on the journey across the sand of where each step should go.
The whole point of agile was to get “working software” to a customer - to solve a real customer need in a rapid, quality, smart way. That’s a pretty outdated way of saying it; I think most would say we get “value” to a customer now (and it sure should be working, of course!), but the right intention was there.
But today, so many organisations are adopting agile, often by default. Even forward-thinking, smart, modern companies can fall into the “lazy agile” trap. Companies with a lot of history undergoing an “agile transformation” can miss the point by further. If you’re not paying attention, you can think it is just a cookie-cutter process to follow; you tick the ceremonies, policies, tools, and roles boxes, and you instantly become agile. It isn’t like that.
In this world of agile, there are genuinely awesome processes that empower you with simple frameworks and language for how you work together, with great practices that champion clarity, communication, collaboration, and pragmatism - but you can do all of that and still suck. Those processes just exist so that you don’t have to spend valuable brain cycles thinking about them; to free up your mind to focus on the task, not the process.
领英推荐
The real root of delivering value in an agile way for any product-centric, lean, agile company is being incredibly focused and thoughtful on WHAT you are going to deliver, WHY, and HOW. It is that simple. There are lots of frameworks that talk about things like this across both Product and Engineering teams, but fundamentally this is the root of it.
Your brain should be always-on in agile; every sprint planning, every customer need, every technical solution, every delivery approach - they should consume brain cycles to find the fastest, most effective, least wasteful path to victory. If you can be super smart in how you pick what to work on next, on how you deliver value to the customer, faster; you win. The end.?
Don’t do auto-pilot agile, be consciously agile. Engage your brain, lean in, pay attention to the detail, be creative, etc. Because if you don’t, you lose. That’s the alternative end. I like the other one better.
Are you Consciously Agile? Am I talking sense? I’d love to hear your thoughts…
[Edit 27/03] I find it fascinating that people who have reached out about this article are defaulting to talking about being conscious and intentional about process... but the point of this article is that you should focus on the work more than the process; be conscious about how you do the work! The process is useful (maybe even important/critical) but it doesn't bring you success - focus on the customer need, consciously. Maybe I should have articulated better.
A really interesting read Simon. As you say, agile is often the default way of working in many organisations, but to a lot of people it's just a process to plod through. Consciously doing agile and caring about what you're doing, and more importantly, the outcomes it produces is what makes the difference. When you have that care and commitment, the process doesn't really matter, but agile done right is a really good guide.
Helping teams manage delivery through coaching, facilitation and taking risks!
5 天前Interesting read, thank you for sharing Simon. For me the hardest part of "Agile" is it getting in its own way when it's used as a tangible 'thing' that has to be 'implemented' to be a success. 'Agile' is simply a mindset described by values and principles. It's a way of approaching how we THINk about what we do, why we're doing it and how we should do it (las you said). I believe it fails when it becomes a process over being a guide.
occasionally allowed to write code
6 天前Generally agree Simon, but some auto-pilot is good. If you challenge every activity required for every delivery then you risk a team all spending 60 minutes thinking about a task that may only take an individual 10 minutes to do. So some rinse and repeat processes are OK (especially if they can be automated away in future.) The challenge then becomes determining which activities warrant more thinking about, and that needs... yet more thinking. It's all getting a bit meta now, maybe I've not thought about it enough...
You're definitely talking sense Simon. One of the best examples of this is the Spotify Model. Spotify did the hard part, the thinking part. The part where they took apart all of the problems they were facing and came up with a model that combined both borrowed and new ideas. However, people then took the cookie cutter parts and said "we need to start organising ourselves as tribes, squads, chapters and guilds" without doing any of the thinking!