Aaron Hodder

Is agile coaching evolving into engineering leadership? I’ve observed a noticeable shift lately in New Zealand’s Agile community: many experienced agile coaches are moving into engineering leadership positions. This transition seems to coincide with decreasing engagement in traditional agile circles—fewer meetups and conferences, quieter forums, and fewer fresh perspectives. Have you observed the same? My top 3 hypotheses about what's driving this trend: - Broader Impact – agile coaches often seek wider organizational influence, and engineering leadership roles provide clearer pathways to strategic impact across teams and products. - Career Progression – as companies increasingly embed agile principles into their cultures, specialized coaching roles might feel limited. - Cost-Cutting Pressures – In tighter economic times, companies scrutinize every role. Agile coaching—especially when decoupled from delivery—is often seen as a “nice-to-have” rather than essential. And this change in the market may be driving agile coaches to look for new roles. Is this a natural evolution—or are we losing something vital? Don't get me wrong - I'm not saying this is a bad trend; after all, I followed the same transition; I'm just curious how the market has been evolving and what we can learn from this. And if you are new to tech leadership, make sure you follow Tech Waka Podcast & Leadership Collective, where we shape and share the journeys of Aotearoa's tech leaders. #AgileCoaching #EngineeringLeadership #TechWaka 

51

11 Comments

The power of work design via the SMART* model was a powerful Agile Australia 2025 opening keynote delivered by Sharon Parker. Sharon shared the case for effective, aligned work design because: ⭐ 20% of workers report burnout. Buronout is described as a chronic condition where worker exhaustion can manifest as cynicism, being jaded and potentially depression. ⭐ The new industrial revolution due to Ai is replacing components of roles, rather than entire roles, impacting Mastery and Agency in workers. Sharon recommends designing in the preservation of key skills such as regular train-driving for drivers who work from behind screens, except when they're required to resolve a problem ⭐ Impact of the aging population. Australia needs more people to keep working to achieve our productivity goals. But work is not designed optimally to support aging workers Sharon was able to translate her significant body of research into accessible data: ⭐ Different work personality types need different components of work, to be happy and fulfilled ⭐ work is interdependent and the SMART model applies cross-functionally and with peers ⭐ job-crafting is a powerful skill to ensure greater alignment between what you need and what your work requires I loved learning about the SMART model and can see how it can improve work *SMART - Stimulating, Mastery, Agency/Autonomy, Relational, Tolerable

25

3 Comments

The accessibility audit arms race More audits. More dashboards. More shiny scores. But are we actually removing barriers? I’ve seen teams pass every automated check with green ticks across the board, while real users still struggle. Like when alt text technically exists, but says “image123.jpg” or is a decorative image. Or when error messages only show up visually with no announcement. Or when a screen reader user lands on a page and has no idea what it’s about because there’s no heading structure. Audits can be powerful. I run them myself. But when they become the main event rather than a supporting act, we start measuring progress by paperwork instead of people. Accessibility isn't about ticking boxes. It’s about someone being able to do what they came to do — independently and with dignity. If we’re not pairing audits with lived experience, with user testing, with real conversations… are we really doing accessibility? Or just the accessible version of performance art? Curious to hear your thoughts. Are we measuring what matters? #Accessibility #Inclusion #DigitalInclusion #UserExperience #DisabilityInclusion #NothingAboutUsWithoutUs #InclusiveDesign

15

3 Comments

I've got a really anecdotal observation I wanted to sense check. I've worked with a lot of Project Managers and a lot of agilists. Naturally some agilists are more effective than PMs and vice versa. But I've got two central ideas I've been mulling over. When an org takes on a PM they've got a fairly good idea what that means, what they can expect from their PM, the value they'll provide and with some good hiring practices a decent read on the level of competence of their new hire. But when I contrast that with hiring agilists and scrum professionals I have a bit of a feeling it's harder for orgs to know what that means, harder to know what they can expect from their agilist/SM, harder to project the value they'll provide and very tough to get a good read on their new hires base level of competence. Alongside this when I think about all the PMs I've worked with they all vary in terms of skills, experience and overall quality but the variance is typically fairly tolerable. With most PMs falling within a fairly tight standard deviation from the mean. Agilists and Scrum Masters feel like a different story. They also vary but the variances seem wider and spiker. I've worked with some truly fantastic and transformational agilists but also encountered some who fell well short of what I'd call the base level of competence required to add value in a team or org. My theory is these 2 give hiring organizations a huge problem saying yes to agilsits and bringing them in to do the good work we live and breathe as a community. I've tried to visualize it below and as mentioned it's hugely anecdotal but I wonder if anyone else sees this the same way? And do we have any ideas how to fix it, who should, or if it's even a problem worth fixing? I'm not saying this is a nailed on factual analysis but I think it helps contextualize some of the market changes and I am very interested to see if I'm misunderstanding something here. N.B. Please don't read too heavily into the numbers and lines. I'm just trying to visualize the idea.

24

39 Comments

One of the biggest wastes of time in modern organisations is the obsession with estimating work. I've lost count of how many teams I've seen spending hours debating story points or trying to predict exactly how long a task will take—only to discover later how inaccurate these estimates were. Estimates create unnecessary stress, unrealistic expectations, and unproductive pressure. More importantly, they rarely improve actual predictability. If you want genuine predictability, you don’t need better guesses—you need better data. Instead of estimating, adopt a data-driven practice of right-sizing work. Look at your team's historical data—actual cycle times, real throughput, historical trends. Use that evidence to break down tasks into manageable, similarly sized pieces of work that your team can reliably deliver within a predictable timeframe. Teams who shift from estimation-based planning to right-sizing based on empirical data experience immediate improvements in flow, delivery consistency, and morale. Instead of chasing arbitrary deadlines, they confidently deliver small, valuable increments of work at a sustainable, predictable pace. Realistic planning grounded in empirical data respects your team’s actual capability and constraints, reducing stress and eliminating guesswork. It leads to consistent delivery, improved forecasting, and far more realistic expectations from stakeholders. Are you still estimating based on intuition, or have you embraced an evidence-based approach to planning your work? [I’m working on an idea for a new post coming out next month, and I'd appreciate some eyes on it. If you provide feedback and I use it, you'll definitely get a mention. I'll drop the link in the comments. ]

21

18 Comments

Scrum Says "Sprint Goal" - Teams Hear "Story Points" We’ve all done it - looked at a sprint plan and said, "That’s too many points. We’re over-committing." I’ve said it. You’ve probably said it. And we usually mean well. It’s a common phrase. But that doesn’t make it right. It’s just a bad habit that’s hard to break. "Over-committing" gets tossed around in Sprint Planning like it means something. It doesn't. It’s usually aimed at teams that plan more points than their average velocity or capacity supports. The implication is they’ve committed to too much work within the timebox. But here’s the problem: Scrum teams don’t commit to work. According to the Scrum Guide, teams commit to a Sprint Goal - not to points or some number or scope of backlog items. Points and velocity aren’t even part of Scrum. Neither are stories. These are common practices, but they’re optional. Ironically, the Sprint Goal - which Scrum actually requires - is often missing. "The Sprint Goal is the single objective for the Sprint… It provides guidance to the Scrum Team on why it is building the Increment." Notice: "Why," not "How much." So when we say a team "over-committed" based on velocity, we’re misusing the term. They didn’t over-commit. They took a risk. Maybe they planned ambitiously or even recklessly - but unless the Sprint Goal is unrealistic, there’s no "over." Why does this misunderstanding persist? Simple. Teams and leadership are obsessed with velocity. It’s easy to track, chart, share, and... misunderstand. Many teams use points religiously but skip Sprint Goals entirely. Sometimes there isn’t even a Product Goal - just a task queue. The Scrum essentials get forgotten. Intent gets replaced with math. Metrics become the mission. Imagine a team with a velocity of 30 points that plans 45. You might think they’re over-committing, but what if the Sprint Goal were clear, focused, and tied to customer value? If the team meets the goal without finishing all the points, that'd be a win disguised as a loss. That’s the problem with this language. It gets teams thinking about outputs, not outcomes. It pushes teams to chase velocity and game the numbers. It discourages responsible and appropriate risk-taking. If the Sprint Goal is unrealistic, that’s a valid concern. But the fix isn’t fewer points - it’s smarter goals and more honest conversations. Velocity isn’t a performance metric, and points aren’t a contract. Treat them like they are, and you’ll turn optional tools into performance targets - and lose the plot. That’s not agility. That’s performance theater. If a team is transparent, focused, and working toward a clear goal, let them stretch. Let them learn. If they miss, that’s what inspection and adaptation are for. Don’t tell them “You’re over-committing” when you really mean “You’re planning more points than I’m comfortable with.” Unless the Sprint Goal is unachievable, the issue isn’t with their over-commitment... it’s with your understanding.

128

45 Comments

Had a great conversation with Rosie Sherry  on the Leading with Quality podcast from Ministry of Testing, and it left me thinking (again) about something that’s been bugging me for years: Why are there so few senior quality leadership roles? We talk about quality being “everyone’s responsibility”, but at senior levels, that often means it’s no one’s job to lead it. In this blog post, I unpack a theory I’ve been circling for a while, about why quality is rarely represented at the top table, and what that means for both strategy and careers. Would love to hear what others think: Have you ever worked somewhere with a Chief Quality Officer? What role does your leadership team play in shaping quality? What would a proper seat at the table look like? Read my full blog post here:

27

14 Comments

My heart genuinely goes out to Agile Coaches right now. Three or four years ago, this was one of the most in demand roles in the market. Businesses were investing heavily in transformation. Coaches were commanding strong day rates. Organisations were building entire Agile uplift functions. Fast forward to today and the market has shifted dramatically. Many of those standalone Agile Coach roles have either been absorbed into broader delivery functions or removed completely as businesses look for leaner, more blended leadership profiles. That creates a real dilemma for highly trained and experienced Agile coaches who have invested years building their craft. Here is the honest market advice I am giving people at the moment. Start positioning yourself for hybrid roles such as Scrum Master, Delivery Lead, or Iteration Manager type positions. The biggest feedback I hear is: “I am not a Delivery Manager/Lead.” And I agree, you are not. And I know its a step backwards. The reality is though, many of these roles are not heavily focused on transitional budget ownership or PMO governance. I wouldn't suggest go on that journey, unless you wanted to of course. Scrum Master, Agile Delivery Lead, Release Manager, Agile Product Owner is the advised journey (For now) What organisations/teams always want is strong delivery leadership, stakeholder alignment, team enablement, and the ability to remove blockers and drive outcomes. Those are exactly the strengths great Agile Coaches already bring. Your value has not reduced. The job titles/duties have just evolved. (For now) If you are an Agile Coach navigating this shift, focus on: • Translating coaching outcomes into delivery outcomes • Demonstrating measurable business impact • Highlighting stakeholder engagement and influence • Showing examples of leading teams through change and uncertainty The market still needs people who can bring clarity, structure and momentum to complex delivery environments. The packaging/positioning just looks different now. If you are unsure how your profile fits the current market, or want an honest conversation about positioning, CV advice, my DMs are open. Success is a journey, we create the MAP. MAP TALENT

39

6 Comments

The end of agile coaching is happening. Sadly, many permanent and contract agile coaches have been let go during the recent two years. There are fewer and fewer job opportunities. Technically, agile has become mainstream. It has revolutionised the way teams work in the last ten to fifteen years. But demand for agile coaching is plummeting due to low perceived ROI as things have progressed. In general, agility is more important than ever before. Agile coaching has to reinvent itself. Instead of teaching and adopting Scrum and other operational frameworks, there are other types of needs. We need new change agents and transformers. - Upcoming change will be massive but won’t happen overnight. - How can we help people, teams, and organisations navigate the mess and become adaptable and resilient? We need flow development. - Once coding speed won’t soon be a problem, other bottlenecks and discrepancies will emerge. - How can we help identify them, make them visible, and remove them? We need a better understanding of future opportunities. - Becoming truly customer and user-centric will be vital as disruption becomes the norm. - How can we help build a culture of experimentation, discovery, and innovation? As agile coaches, we still possess skills that are transferable to new areas. However, agile processes won’t make this happen, and we need to expand our perspectives. As coaches, we need constant upskilling and better understanding of many areas. That shouldn’t be a problem as we anyway embrace continuous improvement. My upskilling is happening around AI, workflow automation, cloud, product delivery, and product management.   Are you already doing it?

89

45 Comments

How do you build trust with people you’ve never met in person?" Reflecting on this question took me back to the early days of managing a fully remote Scrum team spanning different time zones. One particular sprint planning session stands out vividly in my memory. Tension lingered in the air – cameras off, voices subdued, and collaboration at a standstill. The distance seemed to breed silence, and that silence, in turn, fostered disconnection. Rather than intensifying the pressure, I chose a different approach. I called for a moment of pause. I invited each team member to share something outside of work that brought a smile to their face that week. Initially met with reluctance, the atmosphere gradually shifted as personal stories unfolded – tales of family, pets, and even a newfound passion for baking sourdough bread. The dynamics transformed. Cameras reactivated. Laughter replaced the once-ominous silence. As we delved back into our tasks, collaboration flowed effortlessly, no longer needing to be coerced. This experience left me with a profound realization: Effective management of remote teams transcends mere task oversight. It hinges on cultivating genuine human connections that underpin trust, collaboration, and accountability. In my current role, I prioritize three core principles: ✅ Transparency – setting clear objectives and fostering open dialogue ✅ Trust – empowering teams to take ownership of their responsibilities ✅ Humanity – recognizing our shared humanity before our professional titles Remote work doesn’t equate to detachment. With deliberate effort, it can foster resilient, empathetic team dynamics. 👉 Have you navigated leading a team without face-to-face interactions? How did you nurture trust? #ScrumMaster #AgileLeadership #RemoteWork #ServantLeadership #AgileMindset #TeamEngagement

9

2 Comments

The most useful plugin that anyone could ever create for Jira (or the most useful feature Atlassian themselves could create) would be: Showing the age of a ticket on the ticket itself. And no, I don't mean those silly dots that are meant to signify the number of days an item has been an a particular column - I mean an actual number, showing the number of days since the item moved into the first "doing" status. Yes, I know this can be hacked together using automation and custom fields, etc., but it's 2026, and this *still* isn't easy to do in Jira.

127

102 Comments

55 Agile coaches were made redundant after 2 years Read on to learn why When a business isn't hitting financial goals? It starts to look into cost-cutting The first pass will always be headcount Because it's the most expensive cost A leader asked the agile capability what value they'd delivered. They struggled to answer the question with clarity or confidence Their biggest problem? They failed to baseline the before-state The state of play [before] they made any changes The result? When asked what value had been delivered for the investment after 2 years - The story wasn't compelling And the whole department was removed The reality; When you're tasked with delivering Value → You need to be able to prove it Doing so without data? That's like me asking you to believe my name is Tarqqquinnn from El Salvador [Despite looking and sounding like a pasty, white British guy] It isn't believable. Experiment tracking allows you to be empirical linking your work back to: → Data → Learnings → Relevance → Future Value You wouldn't try to submit an expense without a receipt So why would you try to claim value without one? At Undeniable. we are making it easier than ever to link your day to day work back to value Credibly. Confidently. Coherently. We're launching publicly with this feature soon Join the waitlist to get early access Thanks for reposting - It helps others to show their value P.S - How do you prove your value in the workplace?

63

8 Comments

I was just thinking about that Product Thinking episode with Melissa Perri. Is scaled agile really helping teams get things done, or does it just give them something to lean on? Too often, organisations lean on frameworks like SAFe as a safety net. But real agility doesn’t come from following steps - it comes from letting go. What goes wrong? ➡️ Teams stay dependent on big-batch planning ➡️ Progress feels slow, even with a framework ➡️ Independence and innovation get postponed The result: Teams can walk, but they can’t run. The companies we've partnered with in Europe show that teams can break away from that support system. Do small experiments, release things faster, take things one step at a time, and suddenly, teams are working at a fast pace every single day across many different products. Catch the full episode here: https://lnkd.in/eFZVGvzu

33

3 Comments

🚦 ROAM: A simple way Agile teams deal with risks In Agile, risks don’t disappear because we move fast. What makes high performing teams different is how transparently they handle them. One of my favourite techniques from SAFe and broader Agile practice is ROAM. R – Resolved The risk is no longer a threat. O – Owned Someone is accountable to manage and monitor it. A – Accepted We understand the impact and choose to live with it. M – Mitigated We’ve taken action to reduce probability or impact. Why it works? Because every risk leaves the conversation with clarity. No ambiguity. No someone will look at it. There is always a decision. ROAM shifts teams from discussing risk → to taking responsibility. Next time a risk comes up in planning or a review, try ending with: 👉 How are we ROAMing this? You’ll be surprised how quickly alignment improves. #Agile #SAFe #RiskManagement #Leadership #Delivery #ProjectManagement

18

2 Comments