Source: Culture & Methods Trends 2026: The Human Side of AI Engineering

• AI adoption demands maturity frameworks that assess risk and context, and organisations must be honest about what they are actually trying to achieve with AI in their specific circumstances.
• Collaboration patterns are changing fundamentally: Teams are shrinking, roles are blurring, and the question is no longer how to structure teams but how to make collaboration more effective in whatever form it takes.
• The explosion of AI-generated code demands entirely new processes for quality, cognitive load management, and accountability.
• Organizations that failed to embed agile fundamentals face catastrophic risk with AI adoption; fast feedback loops, reflective learning, observability, and shipping the right value to the right users remain as critical as ever.
• Engineers are shifting from contributors to custodians: The defining future skill is not writing code but effectively directing, validating, and building guardrails around AI agents.
• The industry must confront the environmental costs of AI usage, the erosion of diversity of thought from homogenized agent outputs, and the accountability gap when no individual fully owns AI-generated systems.

In the annual Culture & Methods Trends Report podcast, a panel of QCon speakers and InfoQ contributors discussed AI adoption maturity and risk, the transformation of engineering team structures and roles, and the human dimensions of software development that must not be lost in 2026. The discussion was hosted by Shane Hastie (Lead Editor, Culture & Methods) and included Ben Linders, Rafiq Gemmail, Craig Smith, Vanessa Formicola, Shawna Martell, Phillip Mortimer, and Yinka Omole.

Source: InfoQ Culture and Methods Trends Report – 2026

I was quoted in the article:

It’s the gap between the good and the not so good and the haves and the have-nots. Some organizations have embraced this and ran with it, but there are many organizations… they never really made the leap to agility practices in the twenty-five year span that we had in order to do that. And now they’re trying to adapt to these new practices and still building it on organizations that are still tending software’s being built in 1995.

The thought that you wouldn’t use Agile in a project where requirements were defined upfront was also an oddity to me – why wouldn’t you mitigate risk and get feedback as you deliver despite thinking that you got your requirements 100% right? At one stage of my life I was a Business Analyst. I wrote the best business and system requirements. My documents, in my mind at the time, were epic odes to the perfection of thinking. I learnt very quickly that defined requirements never changing was a farce. I was human and my mind had unintended errors and gaps. 

Some would dispute that Kanban is more a Lean method than an Agile one, however I have considered it one element of a wider suite a methods, practices and techniques. This suite used to be known as an “Agile umbrella” but it is now referred to as “New Ways of Working”. It combines Lean thinking, Lean Startup thinking, Design thinking, Agile thinking, Software craftsmanship thinking and much more. 

With such a broad toolkit now at the disposal of organisations we should be solving problems everywhere. But we aren’t. We aren’t consistent, nor predictable in the outcomes of our transformations. Our perfect designs and methods are failing on implementation or their stickiness is not strong enough to handle a significant c-suite change. Maybe we are suffering from the same problem that we had when we thought we could do requirements upfront – that we think we know all the answers when really we are doing it totally wrong.

I had for a while thought that the potential solution lay in experimentation – testing and learning the processes that work for a culture. Part of me is still attached to this thought, especially as I have seen it work more often than not. After all, complexity theory says that in a complex system that ‘probe-sense-respond’ is the best approach. But what if complexity theory is wrong too?

I love Agile. I love what it does to individuals and teams and the difference it can make to them. It is just a lot harder at scale to get it working. There are schools of thought that the best approach is to descale your organisation. I’m not against this as a tactic, but to me it is an overly simplistic answer to a complex problem.

Yes there is tonnes of literature about setting yourself up for success on what you need to do when kicking off an Agile transformation, I probably have a blog or three on this already, but lately I have been thinking that in some organisations we shouldn’t be trying to do Agile transformations. I know, this is very heretical.

I’m not proposing that we give up. I now have a different hypothesis – fix the more critical issues in the organisation before trying to kick off an Agile transformation. What critical issues you may ask? If you have any of the following issues I believe you should try to fix the root cause of these before trying any form of transformation (Agile, New Ways of Working, or something else).

The ‘restructure every three months’ organisation

If your organisation restructures at least every six months (and I know of a number in Australia that restructure its people at least three times a year) then I don’t feel like an Agile Transformation is going to be successful in this environment. 

Agile requires stable teams to create productivity. Every time you restructure you:

1. Create uncertainty. This uncertainty dramatically reduces individual productivity.
2. Force teams to go through Tuckman’s model, again decreasing productivity.
3. Force work to be re-distributed to teams, creating a hold on flow.
4. Confuse stakeholders who work with teams on where work is at and who to engage/work with, also dramatically impacting flow.

The science of impact on productivity for points 1 and 2 are well understood, but I believe there has been little done to demonstrate the significance to productivity of points 3 and 4. 

I would argue that you should test and learn to what extent your restructures are successful in removing problems. If your organisation restructures more than three times in a year I don’t think there is enough stability to be able to test and learn from. 

Also, all too commonly organisations restructure to solve one problem and inadvertently create new problems, hence creating the cycle of pain where another restructure is required. Any structural pattern will have trade-offs – most organisations don’t spend the time to understand the options, trade-offs and mitigating steps for each trade-off. 

If you are in one of these organisations, before implementing an Agile transformation you should:

1. Stop restructuring more than once a year (twice ideally)
2. Learn your choices and trade-offs and implement appropriate mitigations
3. Test and learn using real data – how do you know your organisational productivity and how does your structure affect it?
4. Change manage the restructure better to mitigate productivity risks (most organisations say they do this, in my experience I have yet to see one of them do it well)
5. Performance manage out your people that aren’t performing. This means having a HR group that can actually deal with difficult conversations and managers who have skills to deal with system thinking around performance (assuming Deming’s Law that 85% of issues are the system and not the person). Why did I add this one? Most organisations use re-structures as a means to remove poor performers (mostly due to labor laws) rather than doing the hard yards to remove them through the formal HR process. If organisations did proper systems and performance management a lot less restructures would be required. You could also argue that better recruitment processes would reduce poor performance issues downstream. 

The ‘implement change without change management’ organisation

If you are in an organisation that rolls out change poorly then trying to roll out an Agile Transformation is going to be impossible without good change support. Poor change management includes:

1. Change plans that are never implemented
2. Change plans that don’t target the right groups
3. Non existent change plans
4. Insufficient change plans (for example an email or two is done but nothing to embed a real capability change)
5. Lack of focus on behavioural value differences. Immunity to change talks about behaviours that are hard to shift because of unconscious needs. This requires a individual or a persona based approach to change management rather than a whole collective approach.
6. Rolling out a change that has been ill-considered or not piloted

If you are in one of these organisations, before implementing an Agile transformation you should:

1. Look at the capabilities and process by which you do change management and get real data from people (not managers) within your organisation as to how successful previous change initiatives have been
2. When you find that they haven’t been as successful as you have previously thought, find out why. Do some root cause analysis and fix these problems
3. Check to ensure that your change management processes can handle an incremental approach to delivery

The ‘waiting for the next CEO’ organisation

I haven’t seen this pattern often, but it tends to be in extremely bureaucratic organisations or in government organisations that have a fixed date of leadership tenure. In this type of organisation the CEO has had challenges in their leadership style. This includes:

1. They do not create a safe space; failures are not tolerated
2. They make outlandish promises to shareholders on what can be delivered and when, without ever checking with the people who will do the work if it is achievable. They often do this under the guise of creating a “strong vision” or “stretch targets”
3. They don’t connect with their organisation beyond their direct reports

The impact of this is an organisation full of apathy and disconnectedness. People within the organisation don’t want to invest their time in the vision or any changes driven top down. Consequently they do the minimum they must do to fly under the radar resulting in the organisation staying in a holding pattern whilst they wait for the CEO to be exited.

If you are in one of these organisations, before implementing an Agile transformation you should:

1. Have strong conversations at the C-Suite layer or even the Board about how the CEO is performing and how their behaviours impact the productivity of the whole organisation, how it sets an example for the leaders underneath them.
2. Think about having an ‘Undercover boss’ mechanism to get real feedback on problems and insights of people deep in the organisation.

The ‘new shiny’ organisation

Are you in an organisation that has trouble focusing? ‘New shiny’ organisations tend to act like a cat chasing after a laser light – everything else gets zoned out. The biggest issues with this type of organisation tends to be:

1. That once something is kicked off there is little focus on delivery or execution of the work
2. Which results in lower benefits realisation, lower value to customers and a delivery system filled with waste
3. And whilst the ‘shiny’ might be Agile, something new will come along and you will end up having an implementation that no longer has any focus or intent to follow through on
4. Then there are the real problems of the organisation that are never really prioritised as the new shiny keeps everyone’s attention.

If you are in one of these organisations, before implementing an Agile transformation you should:

1. Stop starting and start finishing. Learn how to create focus through to value realisation before kicking off something new. 
2. Have a mechanism for being able to understand what the core problems/impediments are in delivery, ranked by waste and track very frequently the steps being made to resolve them. In essence, focus on delivery optimisation.

The ‘we don’t have time to be smarter’ organisation

Are you in an organisation that is so busy that there is no time to work smarter? People are always in meetings. They have meetings on top of meetings. They have lots of people doing the same thing. Each area solves their own problems, but the same problems exist all throughout the organisation. 

Fundamentally this is an organisation that has no slack (teams loaded 100%) and a fixed mindset. To be fair, there will naturally be individuals who in the organisation still have a growth mindset, but the organisation isn’t culturally setup to encourage continuous improvement and to encourage learning.

If you are in one of these organisations, before implementing an Agile transformation you should:

1. Stop behaviours like cutting project costs or time frames. I see this all too often – executives think a project costs too much, slashes the budget or time and forces the team(s) to deliver under this pressure and think they have saved the company millions. Every time I see the project ends up costing the original figure and time, but because teams were forced to think they had less time they cut corners, reduced quality and introduced technical debt. It is a false economy. Work ends up being costing more over time due to the operational maintainability of the solution.
2. Introduce slack time into the system – load teams up to only 80%. Slack allows the system of work to handle unplanned exceptions and gives people space to think critically about the what, why and how of their actions before starting them. It also gives people space to look more broadly to other people and other organisations for solutions to problems.

The ‘we’ve tried it six times before’ organisation

Some organisations have already tried Agile many times over and failed. They have this really strong belief that ‘this time it will be different’ which may be true, but all too often, little is done to retrospect on why previous attempts have failed.

If you are in one of these organisations, before implementing your next Agile transformation you should:

1. Do a root cause analysis on where implementations have gone wrong (it could have been one of the previous types of organisational patterns that has caused this)
2. Share with the C-Suite and the board these findings
3. Get buy-in with this group on how this implementation is going to be different and how it is going to address those root cause issues
4. Test and learn whether it does address the issues before rolling anything out.

The ‘we have five consultancies in here’ organisation

I am not saying that consultants are the problem – just that lots of different consultant groups who are unaligned is a really big problem. Consultancies, much like coaches, can help to give you perspective that you don’t ordinarily have, they can provide expertise and global knowledge and help drive a greater focus towards value. But if their perspectives differ then you are going to be creating deep factions of power in the organisation that are working against each other. Often they also don’t have visibility of what each other is doing. 

If you are in one of these organisations, before implementing an Agile transformation you should:

1. Think about consolidating/reducing the number of consultant groups
2. Create visibility about what what each group is focusing on, or ensure that the work is fully mutually exclusive
3. Determine if there is a lack of alignment between groups and hold workshops between invested parties (ie the people who are working with the consultancies) to reach alignment.

The ‘we have managers (not leaders) everywhere’ organisation

You may have picked up through some of the suggestions above that a few key techniques are being consistently utilised. Agile requires a different type of manager, a leader who can help to change the culture of an organisation, who can think critically of ‘the way that we do it now’ versus the possibility of the future of the organisation. A key enabler to Agile that you should consider prior to kicking off an Agile Transformation is a Leadership Transformation. A Leadership Transformation should: 

• Focus on lean wastes and flow analysis, systems thinking, and root cause analysis capabilities across the organisation
• Focus on the difference between management styles (Taylorism, Theory X vs Y, Management 3.0) and what works in the organisation now versus what is needed for the organisation going forward (which does depend on a really clear vision for the organisation)
• Educate managers on options on how to structure it’s people and what the impact that structure has on communication and flow
• Educate managers on options of governance and finance and what the impact that these options have on flow, engagement, and values
• Provide managers incentives to focus on new behaviours (though be careful as extrinsic motivation can backfire)

This leadership transformation creates the internal pull for an Agile transformation, but importantly puts leadership on the journey sooner so that they can be more effective in supporting an Agile transformation through the right behaviours. 

A final note

Agile Transformations are tremendously hard. Don’t make it harder by setting them up for failure before they have even started.