When a project starts getting into trouble, something quite predictable happens.

More meetings appear. Reporting gets more detailed. Governance increases. More KPIs get tracked. More people get copied into emails and invited to calls. Decisions that once required three people suddenly seem to need ten.

There is usually a good reason for all of this. People are trying to understand what is going wrong, reduce uncertainty and regain control.

I have done exactly the same thing myself.

But when I look back at some of the more complex and challenging assignments I have worked on, I sometimes wonder whether this instinct to add more can become part of the problem.

The interesting thing is that complication rarely looks like complication when we are creating it. A new report makes sense. So does another review, another control or another governance meeting.

It is only when you step back that you see what all those individually sensible decisions have created together.

Over the years, this has made me think quite differently about complexity and simplicity.

The complexity of a large programme may be unavoidable. But our way of dealing with it doesn’t have to become equally complicated.

And there are two distinctions that I have found useful in thinking about this.

Complexity is not the same as complication.

Simplicity is not the same as simplification.

They may sound like small differences in language, but I think they matter.

Complexity is often just part of the job

Large programmes are complex by nature.

There are multiple organisations, technologies, stakeholders, suppliers and teams. Dependencies are not always obvious at the beginning. Priorities change. People change. A decision made in one part of the programme can have consequences somewhere completely different.

Anyone who has managed a large transformation will recognise this.

Much of that complexity is simply part of the environment we operate in.

Complication is different. Quite often, it is something we create while trying to manage the complexity.

The fifth governance forum. A report that needs three other reports in order to produce it. A KPI everybody tracks but nobody quite remembers why it was introduced. A meeting where half the people are there because they are worried about what might happen if they don’t attend.

I am exaggerating a little, but probably not as much as I would like to think.

I don’t believe the job of a programme leader is to make all this complexity disappear. In most large programmes, that simply isn’t possible.

The real job is to understand enough of it to help people see what matters and make sensible decisions.

Which brings me to simplicity.

Keeping it simple doesn’t mean ignoring the complexity

“Keep it simple” is easy advice to give.

It can also be bad advice if what we really mean is “ignore the difficult parts”.

You cannot manage a complex transformation by removing dependencies, risks, commercial realities or organisational politics from the conversation just because they make the picture messy. They are still there.

That, to me, is the difference between simplicity and simplification.

Simplicity usually comes after doing the hard work of understanding the detail.

Take something as basic as a risk review.

It is relatively easy to put 30 risks on a slide. It is much harder to say — these are the three that could materially change our outcome, here is why they matter, and here is what we are doing about them.

The same applies to milestones, KPIs, dependencies and, frankly, presentations.

In my experience, large programmes rarely suffer from a shortage of information.

The harder problem is working out which information matters.

That requires judgement, and judgement is difficult to turn into a process.

What complexity theory gets right

I have become interested over time in some of the thinking around complexity and complex adaptive systems. Not because I want to turn project management into an academic subject, but because some of the ideas describe what we see in large programmes surprisingly well.

Projects involving hundreds of people do not behave like machines.

People react. Teams adapt. Priorities shift.

Put in a new KPI and people change what they pay attention to. Introduce another approval and people change how they make decisions. Escalate something and you may change behaviour well beyond the issue you were trying to address.

This idea of participants adapting to changes in their environment is a characteristic of what complexity theory describes as complex adaptive systems. The Santa Fe Institute Complexity Explorer, for example, describes them as interactive, nonlinear systems capable of adapting to a changing environment (source)

I find this useful because it changes the question slightly.

Instead of only asking, “Will this control solve the problem?”, it is worth asking, “What else might change because we introduce this control?”

An additional approval may reduce one kind of risk but slow down dozens of perfectly routine decisions.

A new KPI may improve visibility but encourage people to focus on the number rather than the outcome behind it.

A daily governance call might be exactly what a programme needs during a crisis. Leave it in place for six months and the same meeting can start taking ownership away from the people who are supposed to be running the programme.

I’ve seen versions of all of these.

It doesn’t mean governance or control is bad. Good governance is essential.

It just means adding something isn’t free. It comes with overhead and, sometimes, unintended consequences.

There is another related idea from systems thinker W. Ross Ashby that I find useful. His Law of Requisite Variety deals with the variety of responses needed by a regulator facing a system capable of many different states.

My interpretation of it for project management is quite practical.

When you are working in an environment that can throw many different situations at you, trying to prescribe every possible response in advance probably isn’t going to work.

We need clarity, but we also need room to adapt.

Be clear about the outcome. Be clear about accountability. Be clear about the boundaries and about the things that really are non-negotiable.

Beyond that, people close to the problem need enough room to respond to what is actually happening.

I find myself thinking about governance more and more in those terms: what really needs to be controlled, and where do we need to allow people to adapt?

Some questions that have helped me

I don’t have a framework for creating clarity. I am not sure we need another one.

What I do have are some fairly basic questions that I find myself asking repeatedly.

What are we actually trying to achieve?

When a project is under pressure, conversations become about activity very quickly.

We have organised workshops. We have created a task force. The team is analysing the issue. We have increased governance.All

All of that is fine.

But what is supposed to be different as a result?

I often ask — What needs to be different three months from now for us to say we have made progress?

It is surprising how quickly that exposes activity that has become disconnected from the outcome.

Then there is another question I like.

Can we explain the problem on one page?

This doesn’t mean a complex programme only needs one page of documentation. Obviously it doesn’t.

But if we understand a problem, we should normally be able to explain its essence without needing 40 slides.

Where are we trying to go?

Where are we now?

What is stopping us?

What decisions need to be made?

Who needs to make them?

If we cannot answer those questions clearly, another 30 pages normally doesn’t improve things.

And then there is probably my favourite project management question:

So what?

The milestone has slipped by two weeks.

So what?

A dependency is late.

So what?

Costs have increased.

So what?

I don’t mean this dismissively. The whole point is to understand the consequence.

A two-week delay might be completely manageable. A seemingly insignificant dependency might put the entire outcome at risk.

Both can look equally red on a dashboard.

Knowing the difference matters more than having a better dashboard.

I also find it useful, particularly in difficult meetings, to separate what we know from what we think.

What are the facts?

What are we assuming?

What do we still need to find out?

What decision needs to be taken anyway?

Facts, assumptions and decisions tend to get mixed together when people are under pressure. Separating them often makes the conversation considerably easier.

And one final question I probably ask more today than I did earlier in my career:

Before we add something, what can we remove?

Our default response to problems tends to be addition.

Add a meeting. Add a report. Add a control. Add another approval.

Sometimes subtraction works better.

Two governance meetings may be discussing essentially the same thing. A report may still be produced every week even though nobody has used it to make a decision for months. Ten people may attend a meeting simply because ten people have always attended it.

These things accumulate remarkably easily.

They rarely disappear on their own.

Experience can get in the way too

There is a line from Zen teacher Shunryu Suzuki that I have always liked:

“In the beginner’s mind there are many possibilities, but in the expert’s there are few.” [e-buddhism.com

I think there is something in that for people who have been managing projects and programmes for a long time.

Experience is valuable because we recognise patterns. We have seen difficult situations before, we know many of the warning signs and we have a reasonable idea of what has worked in the past.

But occasionally that also gets in the way.

We recognise the pattern and jump to the answer.

More governance. More control. A recovery plan. Another escalation.

Maybe that is exactly what is needed.

But perhaps not.

Sometimes the most useful question in a room full of experienced people is also the most basic one:

What problem are we actually trying to solve?

I have come to appreciate people who ask questions like that. They make everybody stop for a moment and think rather than immediately reaching for a familiar solution.

And then there is a crisis

A crisis is probably where all of this becomes hardest.

Everybody understandably wants more information and more control.

Reporting increases. Meetings multiply. More senior people get involved. Decisions get escalated.

I have done all of these things myself, and sometimes they are absolutely necessary.

But at some point, the role of leadership changes.

You have to make the problem smaller in people’s heads.

What actually happened?

What is the impact?

What matters right now?

What can wait?

Who owns the next action?

What decision needs to be taken?

When will we know whether what we are doing is working?

The underlying problem may still be enormously complex.

That doesn’t mean the conversation about what we do next has to be.

And perhaps that is what I have gradually come to believe about simplicity.

We sometimes think it means thinking less.

My experience has been the opposite.

You have to understand the dependencies before you know which ones are critical. You need to look at the data before you know which indicators matter. You may need to listen to five different versions of a problem before you understand what the real problem is.

Sometimes you have to go quite deep into the complexity before you can find your way back to something simple.

These days, when a project starts to feel overwhelmingly complicated, I try to step back and ask myself:

Is the problem really this complex, or have we made the way we are managing it too complicated?

There isn’t always a comfortable answer.

But I have found it is nearly always a useful question.

Maybe that is one of the more important things we do as project managers, programme leaders and executives. Not demonstrate how much complexity we can personally handle, but understand enough of it so that the people around us have some clarity about what really matters.

The world we work in isn’t going to become less complex.

Hopefully, the way we manage it can.

Note: The ideas are mine; AI helped me shape, refine, and express them.

When I first started using Copilot, I paid a lot of attention to prompts. I would think about how to frame the question, how much context to provide and whether there was some better way of asking it.

I do much less of that now.

Most of my use of Copilot, and increasingly Claude, is fairly ordinary. I am not coding or building AI applications. I am trying to understand a document, prepare for a meeting, review a proposal, make an argument clearer, or work out what I might be missing.

So my questions have become fairly ordinary too.

What would the customer challenge here?
Can you make this simpler without changing what it means?
What am I missing?
What should I understand before I go into this meeting?
Don’t rewrite this yet. Tell me what you think is wrong with it.

That last one, in particular, has become quite useful.

What I have learnt is that the quality of the conversation matters more than finding a clever prompt. I usually start with what I am trying to do, look at what comes back, challenge it, add some context and keep going.

But occasionally I come across an instruction that changes the output enough to make me stop and take note.

This happened recently when I was trying to make a fairly complicated explanation easier to read and found an interesting blog that had a good tip. Instead of asking Copilot to “simplify” it, I tried:

Explain this using the spirit of ASD-STE100. Keep sentence structures direct, limit procedural steps to single actions and avoid unnecessary synonyms.

It worked surprisingly well.

ASD-STE100 comes from technical writing, where clarity and consistency matter. Borrowing some of its principles gives AI something more useful to work with than the rather vague instruction to “make it simpler”.

And that made me think about the other small things I have picked up through using AI in my day-to-day work. Things that rarely appear in discussions about AI, but that have become useful when dealing with the rather mundane reality of managerial work — too much information, too many meetings, complicated documents, competing viewpoints and the constant need to explain things clearly.

So I thought I would write some of them down.

Not as a list of “ultimate prompts”. Just things that have worked for me.

Make “simpler” a bit more specific

I use “make this simpler” quite often. The problem is that AI has to guess what I mean by simple.

Do I want fewer words? Less jargon? Shorter sentences? Less detail? Or do I want the idea itself simplified?

The ASD-STE100 example above helped me realise that sometimes it is better to describe the kind of simplicity I am looking for.

For everyday work, I might use something much less formal:

Make this easier to read. Use direct sentences and everyday language. Keep the meaning and don’t add anything that isn’t already there.

The last part is important for me. I often work with proposals, commercial documents and other material where an apparently helpful rewrite can subtly change the meaning.

So I tend to tell Copilot what I want changed, but also what I want left alone.

Sometimes I want criticism, not better writing

This is probably one of the bigger changes in the way I use AI.

If I have written a proposal or an important email, my first instinct used to be to ask Copilot to improve it.

Now I will often ask

Don’t rewrite this yet. Tell me what you think is wrong with it.

Or

If you were the customer receiving this, what would you challenge?

If it is a commercial proposal, I might be more specific:

Look at this from a procurement perspective. What would you question, and where would you ask for more clarity?

This tends to be more useful than immediately getting another version of the document.

There is also another benefit. If I ask AI to improve something straight away, I can easily get drawn into its version of the argument. Asking it to critique the original first lets me decide whether I agree with the criticism before changing anything.

I have found myself doing this more and more.

The perspective you give it matters

One useful extension of this is to look at the same problem from different sides.

Suppose I am reviewing a proposal involving commitments, measures and dependencies.

I can ask

Read this from the customer’s perspective. Where would you want stronger accountability?

Then

Now read the same proposal from the provider’s perspective. Where are we accountable for something we may not fully control?

I don’t expect either answer to tell me who is right. What I am interested in is where the tension appears.

I have found this particularly helpful when preparing for discussions where different people can read exactly the same material and come away with quite different concerns.

Summaries are useful, but often I need something else

“Summarise this” was probably one of my most common Copilot prompts when I started using it.

I still use it. But increasingly, I tell Copilot why I am reading something.

If I need to review a long document before a discussion, I might say

I need to make a decision on this. Tell me what has changed, what matters, what could create a problem and what I need to decide.

If I am reading something for the first time

Assume I have not followed this topic. What do I need to understand before I form a view?

The difference can be quite significant.

A summary tells me what is in the document. What I usually need as a manager is help working out what deserves my attention.

Those aren’t quite the same thing.

I use Copilot before meetings as much as after them

Getting a summary after a meeting is useful, particularly when there were a lot of actions and decisions.

But some of my more useful interactions happen before the meeting.

Rather than asking for a long briefing, I might start with

What are the five things I should understand before this meeting?

Then I will follow wherever that takes me.

Why does this matter?
Where are we likely to disagree?
What happened the last time this came up?
Is there anything I have committed to that I should remember?

And one question I particularly like

What are three questions I should ask in this meeting?

That can be much more useful than asking for talking points.

As a manager, I don’t necessarily need AI to give me more things to say. Sometimes I need it to help me work out what I should be listening for.

I increasingly separate facts from conclusions

There is one problem with a well-written AI answer — it can all sound equally convincing.

A fact taken from a document and a reasonable interpretation of that fact can sit next to each other and sound almost identical.

When that distinction matters, I now ask for it explicitly.

Separate what is directly supported by the material from your interpretation and your suggestions.

I find this especially useful when working across several sources of information.

If I am preparing for a decision, I want to know what we actually know, what we are assuming, and where judgement is required.

I don’t need an AI tool to remove that judgement. I just want it to help me see the information more clearly before I exercise it.

I tell it what not to change

There is another habit I have picked up after many slightly frustrating rewrites.

If Copilot gives me something that is 80% right, I try not to ask it to “improve” the whole thing again.

I tell it what bothered me.

Keep the structure. Make it shorter. Don’t introduce any new ideas.

Or

The position is correct, but the tone feels too defensive. Make it more collaborative without weakening the position.

Or even

Only change what you need to. Keep the wording close to the original.

This feels much more like editing with someone than generating something from scratch.

It also avoids a pattern I used to encounter quite often — fixing one paragraph and discovering that three other things I liked had changed as well.

Context accumulates

This is probably why I think less about prompts now.

A useful interaction with AI rarely consists of one brilliant question followed by one brilliant answer.

My actual conversations are messier.

I give it something. It misunderstands part of it. I correct that. It suggests something I hadn’t considered. I ask it to explore that. I dislike the wording. I tell it why. Eventually we get somewhere useful.

Sometimes my most effective instruction is simply

“No, that’s not quite what I mean.”

Followed by an explanation of why.

That might not make a very impressive screenshot for a prompt library, but it is much closer to how I actually use these tools.

I still save good prompts

None of this means prompts don’t matter.

When I find an instruction that produces consistently better results, I keep it. The ASD-STE100 example is one of those.

I also find myself reusing instructions such as —

Don’t rewrite it yet. First tell me what you would challenge.

Keep the meaning unchanged. Only simplify the language.

Separate what the source says from your interpretation.

Look at this from the other side of the discussion.

What question should I be asking that I haven’t asked?

But I don’t really think of these as prompt engineering anymore.

They are just useful questions.

And that is probably the biggest change in how I think about Copilot and Claude.

I started by wondering how to write better prompts.

Now I am much more interested in whether I am asking a good question, whether I have provided enough context, and whether I am willing to challenge the answer I get back.

For the kind of managerial work I do, that seems to matter much more.

There is already plenty written about what AI might eventually do to management.

For now, I am finding plenty of value in something considerably less dramatic — having a patient second pair of eyes on the ordinary work that fills the day.

Note: The ideas are mine; AI helped me shape, refine, and express them.

From Projects to Possibilities: Empowering Managers to Lead in the Age of AI

A few months ago, a seasoned project manager I know — let’s call her Meera — was asked to lead an “AI transformation initiative.” She’s delivered complex ERP rollouts, managed global teams, and navigated every flavor of stakeholder politics. But this time, she paused.

“I don’t even know what AI does, let alone how to manage it.”

Meera’s not alone.

The market for AI technologies is exploding. It is roughly at 244 billion U.S. dollars in 2025 and is expected to grow well beyond that to over 800 billon U.S. dollars by 2030.

Across industries, project and program managers are being asked to lead AI initiatives — often without the tools, language, or confidence to do so. And with technologies like Generative AI and Agentic AI entering the mainstream, the stakes are higher than ever.

This post is for leaders like Meera. If you’ve ever felt curious, overwhelmed, or just unsure about your role in the AI era, you’re in the right place.

AI Is Here — and It’s Not Waiting

AI isn’t just a buzzword anymore. It’s writing code, generating marketing copy, analyzing customer sentiment, and even making decisions on behalf of users. From chatbots to autonomous agents, AI is becoming a core part of how organizations operate.

And it’s not just Generative AI — those large language models that can write, summarize, and create content. It’s also Agentic AI: systems that can plan, reason, and act independently. Think of digital workers that can book meetings, respond to emails, or even manage workflows.

As these technologies become more embedded in enterprise strategy, project managers are being asked to lead initiatives that look nothing like traditional IT projects.

The Leadership Gap

Let’s be honest: most of us didn’t train for this.

We know how to manage scope, timelines, and budgets. We know how to align stakeholders and mitigate risks. But AI introduces a new kind of complexity:

• It’s probabilistic, not deterministic.
• It learns and evolves.
• It can be opaque, unpredictable, and autonomous.

And that means our old playbooks don’t always apply.

Three Questions Every Project Leader Should Be Asking

If you’re stepping into an AI-related initiative — or even just thinking about it — here are three questions that can help you find your footing.

1. What do I need to learn to lead AI projects confidently?

You don’t need to become a data scientist. But you do need to understand the basics:

• What is machine learning?
• How do generative models work?
• What does it mean when an agent “acts autonomously”?

More importantly, you need to know how to work with AI teams:

• How do you scope an AI project?
• What does iteration look like when models are learning?
• How do you evaluate success when outcomes aren’t binary?

This is about fluency, not expertise. It’s about asking the right questions, spotting red flags, and knowing when to push back.

Tip: Start with short courses, podcasts, or even internal lunch-and-learns. The goal is to build comfort, not mastery.

2. How can I help my organization become more AI-ready?

AI isn’t just a tech upgrade — it’s a mindset shift [You have heard this before for every damn transformation, but it is true.. once again].

It changes how decisions are made, how teams collaborate, and how value is created.

And that means change management becomes critical.

As a project leader, you can:

• Help teams understand and trust AI systems.
• Facilitate conversations between business, IT, and data teams.
• Advocate for responsible AI — ensuring fairness, transparency, and accountability.
• Be aware of regulations around AI (that are still evolving)

This is especially important with agentic systems, which may act on behalf of users or teams. People need to know how these agents work, why they make decisions, and when to intervene.

Tip: Don’t wait for a formal AI strategy. Start small — pilot a use case, gather feedback, and build momentum.

3. What are the common pitfalls — and how can I help avoid them?

AI projects fail. Often.

They fail because:

• The problem wasn’t clearly defined.
• The data was not there or messy or biased.
• The expectations were unrealistic.
• The ethical implications were ignored.

With Generative AI, you might face hallucinations, IP concerns, or content safety issues. With Agentic AI, you might deal with unintended actions or lack of oversight.

Your role? Be the voice of clarity.

• Ask: What does success look like?
• Ask: Who owns the data?
• Ask: How will we monitor and govern this system?

Tip: Create a simple checklist for AI projects — covering data, ethics, governance, and stakeholder alignment. [Find one such checklist here. Build your own for your context]

The New Role of the Project Manager

Here’s the good news: you already have most of what you need.

You know how to lead teams, manage complexity, and deliver outcomes. Now, it’s about adapting those strengths to a new context.

In the AI era, project managers become:

• Translators — bridging business goals and technical capabilities.
• Stewards — ensuring responsible innovation.
• Navigators — guiding teams through ambiguity and change.

You don’t need to be the smartest person in the room. You just need to be the one who connects the dots, asks the right questions, and keeps the team moving forward.

Let’s Talk

If you’re a project manager, program leader, or IT executive navigating the AI landscape, I’d love to hear from you:

• What challenges have you faced in AI-related projects?
• What skills or knowledge do you wish you had?
• What would help you feel more confident leading in this space?

Drop a comment, share your story, or connect with me directly on LinkedIn. Let’s build a community of AI-ready project leaders — together.

Note:

These are my own thoughts and ideas — AI did help me tidy them up and make them sound better.

The comments from Usman Shaikh highlighted in his LinkedIn post is a sharply articulated reflection of the Indian IT services industry — and TCS is merely a mirror to a much broader, systemic challenge.

For decades, TCS ran on two engines. | Usman Sheikh

Many in leadership already sense the tremors. Yet, instead of confronting the disruption, they seem to retreat — burying their heads in the sand, hoping this is just another passing storm. But here’s the uncomfortable truth:

This is not a storm. This is a tectonic shift.

The change underway is not cyclical — it’s structural. The traditional operating model, built on the pillars of low-cost labor and supply-demand arbitrage, is cracking under the weight of a new reality.

In a world that now demands exceptional quality, deep tech expertise, and innovation at speed, the old playbook of “good enough at low cost” is rapidly losing relevance. And yet, many leaders seem unprepared — or unwilling — to pivot.

The challenge is existential. The very DNA of many IT services firms is rooted in cost efficiency, not competitive differentiation. Reinventing that DNA is not just hard — it’s unfamiliar territory.

The question is no longer if the outsourcing model will evolve, but how fast and who will lead that evolution.

Evolution or Obscolesence

Curious about the future of the Scrum Master role? How will emerging technologies, remote work, and evolving Agile practices reshape this vital position? Join me as we explore the future of Scrum Masters, uncovering the skills and innovations needed to thrive in an ever-changing landscape. Discover the new challenges and opportunities ahead, and learn how Scrum Masters can stay ahead of the curve. We’ll also delve into the evolution of Agile to understand the journey so far, setting the stage for the Scrum Master’s evolving role and the essential skills for the future.

In modern business’s dynamic and ever-shifting landscape, Agile methodologies have emerged as a critical approach for organisations seeking to adapt, innovate, and consistently deliver value. As we discuss the evolving role of the scrum master and the skills needed for Scrum Masters of the future, it is vital to look back on how we got here in the first place, some of the mistakes we may have made and the evolving context for the world of Agile.

The Four Parts (Jump to later sections with hyperlinks provioded if you wish too)

01. The Evolution of Agile

02. The Hard Truth — Reality Behind the Hype

03. The Evolving Role of Scrum Masters

04. Critical Skills for the future

🛣️ The Evolution of Agile

#️⃣ Agile Journey so far

In the 1980s, 1990s, and early 2000s, approaches based on scientific management and frameworks like the Capability Maturity Model (CMM) dominated the headlines. While groundbreaking in their time, these traditional approaches emphasised rigid hierarchies and standardised linear processes, making them ill-suited for modern knowledge work’s fast-paced business demands and evolving and complex IT landscape.

2001 saw a group of visionary software developers craft the Agile Manifesto, aiming to break free from these constraints. They prioritised collaboration, flexibility, and a relentless focus on the customer, thus creating a framework better aligned with the dynamic needs of contemporary work environments.

However, even before the Agile Manifesto was conceived in 2001, several pioneering approaches laid the groundwork for its evolution.

Extreme Programming (XP), introduced by Kent Beck in the late 1990s, was one of the foremost methodologies that challenged traditional project management. XP emphasised practices like pair programming and test-driven development (TDD), promoting a collaborative and iterative development process. Rapid Application Development (RAD) and the Dynamic Systems Development Method (DSDM) also emerged in the early 1990s, focusing on rapid prototyping and user involvement. The New New Product Development Game — an article published in HBR in January 1986 already talked about “realising that the old, sequential approach to developing new products simply won’t get the job done.”

In today’s fast-paced, fiercely competitive world of commercial new product development, speed and flexibility are essential. Companies are increasingly realizing that the old, sequential approach to developing new products simply won’t get the job done. Instead, companies in Japan and the United States are using a holistic method — as in rugby, the ball gets passed within the team as it moves as a unit up the field.

The New New Product Development Game by Hirotaka Takeuchiand & Ikujiro Nonaka (link)

These methodologies collectively highlighted the limitations of conventional approaches. They underscored the need for more adaptive, customer-centric processes, ultimately shaping the principles enshrined in the Agile Manifesto.

#️⃣ From Scrum to Scaling Frameworks

Scrum emerged as a dominant methodology, characterised by time-boxed iterations (sprints), cross-functional teams, and the delivery of product increments. However, as organisations scaled their Agile practices, especially with large enterprises taking the Agile plunge, new challenges surfaced, necessitating the development of frameworks like the Scaled Agile Framework (SAFe), Large-Scale Scrum (LeSS), and Disciplined Agile Delivery (DAD).

The SAFe website has an impressive list of case studies from diverse industries — from South West Airlines to Nordea and much more. While each of them may have its own uniqueness and may/may not have implemented SAFe fully, the fact remains that enterprises have started to give a serious shot at agility. Agile now had boardroom acceptance.

#️⃣ The Silver Bullet

By 2020 and beyond, Agile became the magical silver bullet that everyone thought could solve all problems. It started in the IT world, but then it spread everywhere.

Trying to market a product? Just called it Agile, and it was golden!

Needed to manage personal goals? Slap some Agile on it, and suddenly, you were a productivity guru.

Learning and development? Agile had it covered, making every training program sound cutting-edge and relevant.

It didn’t matter what people were doing; if they sprinkled a bit of Agile jargon on it, others would think they had discovered the secret to success. Apparently, Agile could do anything and everything — no questions were asked.

The agile mindset was forgotten in the mad rush to adopt frameworks, practices and tools — which was actually the heart of agile!

This continued until 2022, when cracks started to show in the agile movement, with declining interest in the roles of Scrum Masters and Agile Coaches. Why did this happen? Let’s explore that in the next section — a reality check!

💯% Hard truth — The Reality behind the Hype

🔴Disillusioned leadership with failed or non-impactful agile transformations

Despite its widespread adoption and success, Agile has faced significant criticism (Agile Is Dead! or The End of Agile), particularly in the context of prescriptive frameworks like Scrum and SAFe. The proliferation of buzzwords and linking every new management concept to agile, the mindless pursuit of certifications that actually have become a circus, and an overemphasis on rituals without the right adaptation to context have often obscured Agile’s core values and principles.

This has resulted in weak Agile implementations that brought minimal or no business benefits, leading to disillusionment and apathy among many senior leaders.

Take the case of ANZ . ANZ embarked on an Agile transformation with much fanfare. The company invested heavily in training and certifications, ensuring that all team members were well-versed in Agile and had a very focused and high-investment Agile transformation program. However, a few years down the line, they ran into major problems.

“It’s been a disaster,” says one former senior ANZ executive. “It doesn’t work and whoever becomes the next CEO, the first thing they’ll do is to get rid of agile.”

Source: Shayne’s world: How Shayne Elliott’s ‘agile’ ANZ got stuck (smh.com.au)

While ANZ might be an extreme case, Scrum Masters often find themselves overwhelmed by the complexity of their environment and run into unsupportive and sceptical leadership. The organisations continue to not focus on fostering a culture of empowerment and innovation.

While many are only doing agile for “compliance” as lip service, even where there is good intent, their focus remains solely on rigidly following Scrum rituals like daily stand-ups, sprint planning, retrospectives, and, if SAFe is being implemented, PI Planning. The agile mindset — conveniently forgotten.

The mechanical execution of these rituals lost the true essence of Agile, which emphasizes adaptability and responsiveness to change.

With Agile often reduced to a set of rituals and certifications rather than a mindset shift, it has led to tonnes of ineffective implementation and disillusioned leadership that is developing an apathy for Agile.

🔴Context has evolved — 2001 was more than 20 years ago.

People are usually afraid of change because they fear the unknown. But the single greatest constant of history is that everything changes.

― Yuval Noah Harari, Homo Deus: A History of Tomorrow

The Agile Manifesto was written more than twenty years ago, and in this fast-paced world, that’s a really long time. Things have changed.

As we fast-forward to the present, the context in which Agile operates has transformed dramatically. Remote work, globally distributed teams, and the relentless pace of digital transformation have become the new normal.

Team members who graduated from university within the last five years. are likely native Agile users who have never worked in a Waterfall environment.

Additionally, most people in the IT space today, regardless of their experience level, especially those involved in application development, maintenance, and support, have undergone Agile training. This training might be digital learning or instructor-led. Still, they probably received formal instruction on the Agile Manifesto and/or Scrum. While the implementation may be flawed, many of these individuals are already working on projects utilising some Agile methodology.

10 years ago, the primary role of a Scrum master was training and coaching people on the transition to agile. But in a world where people have been running agile transformation for well over a decade now, and agile methodology is considered business as usual, not a novel concept anymore, do we really need Scrum Masters to entirely focus on training and coaching?

🕺EVOLVING ROLE OF SCRUM MASTERS

This brings us to the critical question of where do we go from here? What could be the changing landscape for Scrum Masters to help them chart their way towards building a strong future for themselves.

The following are pivotal trends that I see will shape that future:

Trend 1️⃣: AI won’t replace Scrum Masters; Scrum Masters who use AI will

By leveraging AI as a personal assistant, Scrum Masters can significantly enhance their effectiveness and efficiency. Imagine an AI tool that provides real-time advice during sprint planning meetings, suggesting optimal task allocations based on team members’ past performance and availability. This AI assistant could answer common questions about Agile practices, freeing Scrum Masters from repetitive inquiries and allowing them to focus on more strategic and high-value activities.

AI could analyze team dynamics and provide insights into potential interpersonal conflicts, enabling Scrum Masters to address issues proactively. It could also curate relevant articles, videos, and case studies to keep teams updated on the latest Agile trends and best practices.

Additionally, AI can automate routine administrative tasks, such as tracking sprint progress and generating performance reports, giving Scrum Masters more time to foster collaboration, innovation, and continuous improvement within their teams. In this way, AI becomes a powerful ally, amplifying the impact of Scrum Masters rather than replacing them.

Trend 2️⃣: Scrum Masters as Leaders with “Skin in the Game.”

In the evolving Agile landscape, the role of the Scrum Master must go beyond mere facilitation and coaching. Scrum Masters need to have skin in the game, fully integrating into their teams rather than being seen as outsiders. If they have to be critical for enabling high-performing teams and guiding them to define and deliver value within their contexts, they need to do it from within, not as a consultant or a coach. They need to be in there with the team — with their skin in the game.

Scrum Master who can actively inspire and empower their team by encouraging ownership of challenging tasks, fostering innovation through brainstorming sessions, resolving conflicts and making things happen will be more successful. By being deeply involved and committed, these Scrum Masters create a high-performance and innovation culture, ensuring their teams thrive and deliver substantial value. This shift from facilitation to genuine leadership distinguishes successful Agile teams in today’s dynamic business environment.

Trend 3️⃣: Scrum Mastery as a Skill — not a role

Scrum Mastery as a skill, rather than a dedicated role, will become increasingly important in modern Agile teams. While there will still be dedicated Scrum Masters, many roles, such as Project Managers, Architects, Business Analysts, and others involved in team-based activities, will need to develop and rely on Scrum Mastery skills.

The shift to Scrum Mastery as a Skill ensures that Agile principles are embedded throughout the team, fostering a culture of collaboration, adaptability, and continuous improvement without always depending on a dedicated Scrum Master.

For today’s Scrum Masters, this change means evolving into more strategic leaders and mentors and probably picking up other roles while continuing to guide others to embrace and apply Agile principles effectively. Even if the role title may not be “Scrum Master,” in whatever role they play, they will still be the “Ambassadors of agility.”

🔮 CRITICAL SKILLS FOR THE FUTURE

While some Scrum Masters exhibit these behaviours and skills today and that contribute to their immense success, they are in the minority and not the norm. In the future, these will become mandatory, non-negotiable skills.

Skill 1️⃣: Operate from First Principles

In the future, the most effective Scrum Masters will excel at operating from first principles rather than strictly adhering to guides and frameworks.

This involves breaking down problems into fundamental building blocks and essential elements, allowing a deeper understanding of the core issues. Imagine a Scrum Master leading a team facing delays in project delivery. Instead of just enforcing standard Agile practices or following a predefined process, the Scrum Master would deconstruct the problem by examining the root causes, such as communication gaps, unclear requirements, or bottlenecks in the workflow.

By asking powerful questions like “What assumptions are we making about our process?” and “What are the fundamental obstacles preventing us from meeting our deadlines?” they can uncover the absolute truth, separating facts from assumptions. This might reveal that the team needs to be more committed during sprint planning due to unrealistic expectations or that the developed user stories need more clarity.

Armed with these insights, the Scrum Master can construct a clear and logical view from the ground up, proposing tailored solutions such as adapting the backlog refinement process, implementing more rigorous acceptance criteria, or introducing a daily check-in to enhance communication. This approach fosters innovative thinking and problem-solving, empowering teams to navigate complex challenges with agility and insight. By focusing on first principles, Scrum Masters help their teams become more resilient and adaptable, ultimately driving greater success in an ever-changing environment.

Skill 2️⃣: Be Masters of Complexity

Scrum Masters will be adept at navigating the complexities of Agile teams by deeply understanding complex adaptive systems. They will leverage this knowledge to anticipate and manage the dynamic interactions and emergent behaviours within their teams. While many Scrum Masters of today misinterpret the Cynefin framework as a mere classification tool, Scrum Masters of the future will use it as a sensemaking framework to guide decision-making in complex environments.

By embracing complexity theory, future Scrum Masters will recognize patterns of change and evolution, enabling them to foster environments where teams self-organize and adapt organically. This deeper understanding will empower Scrum Masters to facilitate collaboration more effectively, anticipate and mitigate risks proactively, and guide teams toward innovative solutions that thrive in an ever-changing environment. For instance, instead of categorizing problems into predefined domains, they will dynamically assess situations and tailor their strategies to the evolving context, ensuring that teams can respond with agility to unforeseen challenges and opportunities.

This mastery of complexity will be crucial as Agile teams face increasing unpredictability and interconnectedness in their work. Future Scrum Masters who can skillfully navigate these complexities will be indispensable in driving their teams’ success and innovation.

Skill 3️⃣: Outperform the machines at “being human.”

Successful Scrum Masters will distinguish themselves from machines by harnessing their creativity and adeptness at connecting the dots. As Steve Jobs famously articulated, “creativity is just connecting things.” This means synthesizing diverse perspectives to form new, innovative solutions. Unlike machines, which excel at processing data and executing predefined tasks, Scrum Masters will leverage their human ingenuity to envision possibilities beyond conventional frameworks.

Imagine a Scrum Master leading an Agile team through a challenging project. Instead of relying solely on data and standard practices, they draw inspiration from seemingly unrelated fields — perhaps incorporating design thinking principles from the creative arts or problem-solving techniques from engineering. This ability to connect disparate ideas fosters an environment where novel solutions emerge from collaborative efforts.

By nurturing creativity and facilitating interdisciplinary collaboration, Scrum Masters inspire their teams to innovate boldly. They create a space where team members feel empowered to think outside the box, drawing connections that machines might overlook. This approach enables teams to solve complex challenges creatively, driving continuous improvement and sustainable growth in Agile environments. As Jobs said, “You can’t connect the dots looking forward; you can only connect them looking backwards.” Scrum Masters, with their unique human touch, will guide their teams in making these vital connections, outperforming machines by being truly human.

THE WRAP

The journey of Agile continues, and the role of Scrum Masters remains pivotal in its evolution. Those who fail to evolve and cultivate the essential skills — the ability to leverage AI, a deep understanding of complexity, creativity, and connect the dots — may face significant challenges. In contrast, Scrum Masters who actively build these skills will thrive. Whether the title of Scrum Master persists or not becomes inconsequential; what truly matters is mastering the principles and practices of Agile. By embracing continuous learning, fostering innovation, and facilitating effective collaboration, Scrum Masters can steer teams towards success in an ever-changing landscape. As we look ahead, let us remain proactive in shaping the future of Agile, ensuring it continues to empower teams and drive meaningful outcomes.

** Did you like this? Feel free to bang that clap button. Do you want more? Follow me on Medium, LinkedIn or Instagram or read more here. ***

Agile methodologies have dominated the project management landscape for the past few years, promising flexibility, faster delivery, and closer alignment with customer needs. Once seen as the revolutionary approach that would transform organizational workflows, Agile is subject to much criticism these days.

It’s Time to Move on From Agile Development

Like many other trends that come and go, Agile’s luster is fading.

Everything has its time. Methodologies like the Theory of Constraints made famous by Eliyahu Goldrat’s The Goal (first published in 1984), Lean made famous by the whole Toyota revolution, PMBOK, and CMM approaches, all had their hay days of widespread popularity, and seemed — to be the only way forward. Agile is going through a similar cycle.

These topics remain relevant and valuable but have become common foundational knowledge. Agile enjoyed a good run for 10–15 years, and now the industry is naturally evolving.

As we delve into the reasons behind Agile’s decline in popularity, we uncover valuable lessons for leaders, particularly in the emerging trend: Generative AI (Gen AI).

The parallels between Agile’s waning appeal and the potential pitfalls of Gen AI implementation are striking, making these insights crucial for leaders to navigate this new and emerging landscape.

Avoid Over-prescription and Misapplication

Agile’s decline in appeal is primarily due to its misapplication across industries, a cautionary tale for Gen AI implementations. Coming out of software development with the release of the Agile Manifesto in 2001, Agile principles have been stretched into various domains where they don’t quite fit. This misalignment has led to frustration and disillusionment as teams grapple with applying frameworks like Scrum or Kanban in contexts that demand different approaches. I have seen Learning and development teams start calling their monthly training plans sprint-based with no change in their approach. The change was done primarily to meet management demands of everyone to be “agile.” These changes are so unnecessary and wasteful. This is not to say Agile cannot be made to work in those domains, but the right application, contextualization, and adaptation are necessary.

Lesson for Gen AI:

The key is to avoid a one-size-fits-all approach. Instead, identify the areas where Gen AI can genuinely enhance your business and where traditional methods may still be more effective. This discernment is crucial for successful Gen AI implementation.

For example, Teams that do not have basic automation of their Excel-based processes using standard tools like Power BI or others are suddenly hoping that the O365 copilot will be the magical pill for all their worries.

It won’t. You may get better results by starting with Power BI.

Avoid Ritualization and Templatization

Agile aims to provide flexibility and adaptability.

Ironically, it has become rigid and ritualized in many organizations. Daily stand-ups, sprints, and retrospectives often feel more like obligatory chores than meaningful practices.

When the focus shifts from outcomes to strict adherence to process, the spirit of Agile is lost, and teams go through the motions without reaping the intended benefits.

Lesson for Gen AI:

Focus on outcomes rather than rigidly adhering to popular AI tools and options. Evaluate your use cases well and ensure that the integration of Gen AI remains flexible and adaptable to actual business needs.

The key is answering the fundamental question of why we are doing this in the first place. Only join the bandwagon if you can answer the why.

Build Solutions that Scale and Keep them Simple

Scaling Agile practices across large organizations has proven to be a significant challenge. Frameworks like SAFe (Scaled Agile Framework) and LeSS (Large Scale Scrum) add complexity and bureaucracy, contradicting Agile’s core principles. This is not to say that these frameworks are inadequate.

Still, blind adaptation without the proper contextualization and adaptation creates a significant challenge for adoption. As a result, many large enterprises never really scale agile successfully. The resulting end state could be better than where it started because of the overcomplications.

Lesson for Gen AI:

Be cautious of over-complicating Gen AI implementations. Strive for scalable solutions that maintain simplicity and effectiveness. Stick to the fundamentals. Make progress step by step, iteratively, and incrementally.

Prioritize Knowledge and Capability Building Over Certifications

The proliferation of Agile training and certification programs has led to a commoditization of Agile skills. Certificates often emphasize theoretical concepts over practical application, resulting in a workforce that may be certified but not necessarily competent. This industrialization has diluted the essence of Agile, making it more about credentials than real-world effectiveness.

Lesson for Gen AI:

Be wary of over-reliance on certifications and training programs that promise quick expertise. Focus on building deep, practical knowledge and skills within your team.

This pattern is already observed in GenAI, and many training and certifications are mushrooming. This anti-pattern is mainly observed in mid-management and senior leadership training, which is relatively superficial and has few practical insights.

Training is essential and has its utility, but to create value, it needs to go deeper so that people understand enough to apply the concepts in their day-to-day lives and not just pick up terminology to show off their so-called knowledge.

Business Outcomes not, Terminology Transformations

While there is fatigue over agile practices, it is not like businesses have lost their pursuit of agility. Enterprises are moving towards a broader understanding of agility that transcends specific methodologies. True business agility is about being adaptive and responsive to change, not just following a prescribed set of practices. This shift in mindset prioritizes outcomes over processes and emphasizes the ability to pivot quickly in response to market demands.

Lesson for Gen AI:

There is a big lesson for GenAI adoption here. Do not base your GenAI adoptions only based on the most hyped tool in the market or what your competitors or peers are doing.

Spend time and effort to understand your context and use what makes sense in your context and will add value.

Keep your focus on outcomes.

Know that the old and the new live side by side

In response to Agile’s limitations, many organizations are adopting hybrid models that combine the best aspects of Agile with other methodologies.

For instance, Water-Agile-Fall (a blend of Waterfall and Agile) allows for a more structured approach where needed while still embracing iterative development and continuous feedback. These hybrid models offer a more tailored approach better suited to the specific needs of different projects and teams.

With Agile, this was most observed with the contracting models, where despite fully agreeing to the exploratory nature of agile approaches, businesses still hesitated to move their contracting strategies entirely away from the tried and tested fixed cost and schedule because of other business compulsions.

Lesson for Gen AI:

The world will not suddenly move to start leveraging all the benefits of GenAI overnight. Many other technologies and approaches will live side by side to address several regulatory and social considerations.

Be aware of that and take cognizance before throwing all your eggs in the GenAI basket and making huge investments.

Foster a culture of Continuous Learning and Improvement

Agile isn’t dead; it’s evolving.

The principles of continuous learning and improvement, which are at the heart of Agile, remain crucial. However, they are now integrated into broader frameworks emphasizing organizational agility. This includes fostering a culture of innovation, encouraging experimentation, and continuously iterating based on feedback. This emphasis on continuous learning and improvement is also key to staying ahead in the ever-evolving world of Gen AI.

Lesson for Gen AI:

The journey towards successful Gen AI implementation is continuous and long. There is no overnight success here. Foster a culture of learning and improvement, encouraging your team to experiment with Gen AI and iterate based on real-world feedback.

This commitment to continuous improvement is the key to harnessing Gen AI’s full potential.

Conclusion

Agile may no longer be the cool kid on the block. Still, its core values — collaboration, flexibility, and customer focus — are more critical than ever. As organizations navigate the complexities of the modern business landscape, they realize that true agility comes from a mindset, not a methodology. By embracing this broader perspective, businesses can stay adaptable and resilient, ready to meet the challenges of an ever-changing world.

Agile’s decline in popularity is not a failure but a natural evolution. The shift from rigid adherence to Agile frameworks to a more fluid understanding of agility reflects the growing maturity of organizations in their pursuit of excellence. Agile isn’t dead; it’s transforming, paving the way for a future where agility is embedded in the DNA of every successful enterprise. Just as the industry evolved past the bulk-hiring of Lean or CMM coaches, it is now evolving past Agile coaches, adapting to meet the current demands with continuously redefined and refined roles.

For leaders, the key takeaway is to apply these lessons to the Gen AI trend.

Avoid the hype cycle traps, focus on genuine value creation, and ensure your organization remains flexible, adaptive, and focused on continuous improvement. This approach will help harness the true potential of Gen AI without falling into the same pitfalls that led to Agile’s decline.

** Did you like this? Feel free to bang that clap button. Do you want more? Follow me on Medium, LinkedIn, or Instagram, or read more here. ***