A while ago, I wrote a series about rotten agile, and I thought I was done. Nope, I am not done, as there are more systemic issues in the marketplace.

Rotten Agile is not caused by bad intent, lazy teams, or a lack of training. It is caused by a simple and persistent failure: Agile is adopted as a method rather than built as a set of habits.

Most organisations that claim to be Agile have installed the visible parts. Ceremonies exist. Boards exist. Roles exist. Tooling exists. What does not exist are the repeatable behaviours that make those things matter.

This is the habit gap, and it explains why Agile so often looks busy but delivers very little.

Agile does not fail at design. It fails at repetition.

Agile practices are not complicated. The problem is not understanding them. The problem is doing the right thing consistently when it is inconvenient.

Examples are everywhere.

Teams know they should slice work thinly, yet under pressure, they revert to large batches.
Teams know they should integrate frequently, yet integration is delayed until the end.
Teams know they should expose risk early, yet bad news is softened or hidden.
Teams know retrospectives should change behaviour, yet the same issues reappear sprint after sprint.

This is not hypocrisy. It is habit dominance.

Under pressure, people do not act on what they know. They act on what is habitual. In most organisations, the dominant habits were formed long before Agile arrived.

Rotten Agile preserves old habits behind new language

One of the most damaging patterns in Rotten Agile is linguistic substitution.

Project managers become Scrum Masters, but the habit of driving delivery through control remains.
Requirements documents become backlogs, but the habit of upfront certainty remains.
Status meetings become stand-ups, but the habit of reporting upward remains.
Phase gates become sprint reviews, but the habit of approval seeking remains.

From the outside, Agile appears to be present. Underneath, nothing fundamental has changed.

This is why Rotten Agile often feels exhausting. Teams are asked to perform new rituals while maintaining old behaviours. That creates friction, not flow.

The marketplace reinforces this failure

The Agile marketplace does not accidentally produce Rotten Agile. It is structurally aligned to do so.

Frameworks, certifications, and maturity models are easy to package. Habits are not.
Training scales. Behaviour change does not.
Rollouts are visible. Habit formation is slow and quiet.

So success is defined as adoption rather than outcome.

An organisation is considered Agile because teams are “doing Scrum,” not because they can reliably deliver small increments, make fast decisions, or learn from evidence. When those outcomes do not appear, the solution offered is usually more coaching, more ceremonies, or a new framework.

Very rarely is the system itself challenged.

Habits require system change, not motivation

Habits form when behaviour is repeatedly rewarded by the system.

If teams are rewarded for predictability, they will avoid uncertainty.
If leaders punish bad news, the risk will likely be hidden.
If funding is annual and fixed, learning will be delayed.
If decisions require escalation, autonomy will never develop.

No amount of Agile training overrides this. The system always wins.

Rotten Agile persists because organisations ask teams to behave differently while keeping incentives, governance, and authority exactly the same.

That is not a transformation. It is a theatre.

Why does this damage trust in Agile

When Agile is implemented without habits, it produces a specific kind of failure.

Delivery feels chaotic but slow.
Meetings increase, but decisions do not.
Teams feel accountable but powerless.
Leaders feel uninformed despite more reporting.

Eventually, someone says, “Agile doesn’t work here.”

What they usually mean is this: we installed Agile practices, but we never changed how work actually gets done.

Agile then becomes associated with frustration rather than effectiveness. That reputational damage is deserved, but it is misattributed.

What unrotten Agile actually looks like

Healthy Agile is boring to watch and powerful in effect.

The same small behaviours happen every week without drama.
Risks are raised early because nothing bad happens when they are.
Work gets smaller because that is how success is achieved.
Decisions are made where information lives.
Feedback changes behaviour because it is acted on immediately.

These outcomes are not driven by mindset. They are driven by habit.

And habits only form when leaders redesign the system to make the right behaviour the easiest behaviour.

The uncomfortable truth

Rotten Agile survives because it lets organisations avoid the hardest work.

They can talk about agility without changing power.
They can adopt frameworks without changing incentives.
They can blame teams instead of redesigning systems.

As long as Agile is sold as a method to adopt rather than habits to build, Rotten Agile will continue to thrive.

Not because people do not care.
But because the system rewards appearance over behaviour.

At its core are principles, but more importantly, deliberate habit-forming mechanisms that focus on slow, repeatable behaviour. Not transformation theatre. Not framework implementation. Just the disciplined formation of new habits over time.

More to come on this.

I just posted about the BEE Cycle - https://blog.brettmaytom.com/p/the-bee-cycle. I am just sharing a personal story as to how the name came about.

The BEE cycle did not start with a neat diagram or a brand name. It started as an attempt to describe how people actually move from a problem to a solution, without shortcuts, theatre, or borrowed frameworks that do not fit.

Early on, I planned to call it the Boost Framework. The word boost fits what I was trying to do. Help leaders and teams improve outcomes in a positive, pragmatic and practical way. But as I explored trademarking, it became clear that the name was not viable. That forced a pause. And that pause mattered.

Around that time, I was spending long hours in the hospital with my daughter.

I talked a lot. She listened. She questioned. She challenged. Not in a formal way. In a human way. I would explain how I saw problems unfolding in organisations. How people rushed from idea to solution. How leaders skipped the hard thinking and then wondered why change did not stick. She helped me slow down and think more clearly about what actually happens between noticing a problem and making a real improvement.

The cycle itself was already there in my head. What she helped with was expression. Making the thinking simpler. More honest. More grounded.

She loved bees. Really loved them. She even had a “bee’s knees” tattoo. After she passed, it did not feel right to just find another name and move on as if those conversations had never happened. They mattered. She mattered. This cycle exists in part because of those moments where ideas were tested by curiosity, not ego.

So it became the BEE cycle.

Not as a gimmick. Not as a metaphor stretched too far. But as a way to honour her contribution and the way she helped me think.

Bees do not rush. They explore. They gather. They build deliberately. They create systems that work because each step depends on the last. Nothing is wasted. Nothing is performative. Everything has a purpose.

That is what this cycle is about.

The BEE cycle is not about speed for the sake of speed. It is about moving deliberately from exposure to improvement, without pretending certainty exists where it does not. It is about respecting the space between problem and solution. The thinking. The learning. The enabling. The human work that most approaches gloss over.

Naming it this way keeps me honest.

Every time I write about it, teach it, or apply it, I am reminded why it exists. It is not to sell a method. It is not to win an argument about agility. It is to help people do better, more thoughtful work in environments that are often impatient and noisy.

The name is personal. The intent is practical.

That combination is not accidental.

Having worked in leadership positions, run my own business, I have valued being both pragmatic and empirical in my decision-making.

But what I observed with many of the leaders of the customers I worked with is their reliance on frameworks, rituals, tools, and habits.

I saw leaders

• Jump to solutions without understanding the problem

• Unsure of how to solve complex problems

• Rigid and stubborn to change, even though all evidence pointed it’s not working

• Fear of failure if they made the wrong decision

• Avoiding dealing with issues

• Not taking ownership of the situation

The problems they faced were never addressed; they lingered and held back their teams, increasing the cost of delay and, worse, making their positions harder.

That’s why Practiqual® is built around a clear, grounded cycle —
BEE: Expose, Examine, Explore, Enable, Enact, Boost.

It may sound light, but it isn’t. BEE is the thinking engine of Practiqual.
Not a ritual. Not a diagram. A decision-making muscle for a complex environment.

Why BEE Exists

Because in technology and in many other industries, people are hardwired to rush from challenge to solution.

The solution starts before the problem is understood.
The change is launched before the cause is clear.
The system is changed before it is seen.

BEE says: Slow down and THINK before you act.
Not to waste time, but to use it smarter.

It gives leaders and teams the space to:

• Think clearly

• See the system

• Explore smart options

• And actually lead the change they’re trying to make

It’s slowification with purpose. A pause between trigger and response.
That’s where strategy lives.

The Six Steps of BEE

1. Expose: Say the quiet part out loud

Stop glossing over what’s broken. Expose is where truth is surfaced safely, clearly, and without the usual defensiveness.

No judgement. Just facts, patterns, tension
If you can’t see it, you can’t shift it.

This is where early systems thinking begins. It is not just about surfacing symptoms, but recognising patterns that might point to deeper structures.

If you're not going to talk openly and transparently about challenges, they will not magically disappear.

Reveal it! So you can deal with it!

2. Examine: Understand what’s really going on

Now you go deeper. This is where systems thinking becomes essential.

Examine means looking beyond the visible to uncover the loops, incentives, contradictions, and constraints that hold things in place.

Gather facts and data. Stop the madness of decision-making on pure opinion, especially the H.I.P.P.O. (Highest Paid Persons' Opinion).

You start asking questions like:

• What is driving this behaviour?

• Where are the feedback loops?

• What assumptions are still in play?

• What is the impact?

• What is the root cause?

This is where “fix it” becomes “understand it”. Your goal is to really understand the challenge. Get the facts. Get the data. Get the real picture. Use this to make better-informed decisions.

3. Explore: Think through the smart options

Now, and only now, you think about possible solutions.

Explore is structured creativity. It is informed by what you have exposed and examined, and guided by systems thinking to avoid short-sighted fixes.

It asks:

• What could shift the system in useful ways?

• What are the trade-offs?

• What is best to try, safe to test, and meaningful to learn from?

• You are not hunting for perfection. Just the next best move.

Brainstorm ideas, even if the idea is “suck it up and live with it”. Just don’t jump at the first solution that pops into everyone’s head.

Look at the pros and cons of each.

Then make an informed choice. Choose one!

4. Enable: Set the change up to succeed

This is leadership territory. Not just permission, but preparation.

Enable means communicating clearly, getting alignment, removing blockers, and creating the conditions where change can land and last.

It also means anticipating how the system might push back and working proactively to reduce that resistance.

Too many leaders announce a change and walk away
Enable is how you make sure it does not die on impact.

This is change management 101.

5. Enact: Make the move

Enact is where intent becomes real. You do the thing
Visibly. Accountably. With a full understanding of the context behind it.

You are not just delivering change. You are intervening in a system with clarity about consequences and interdependencies.

The change is no longer an idea
It becomes part of how we operate.

6. Boost: Make it stick or move on

This is where momentum comes from.

Boost is where you learn out loud:

• What worked? What did not work?

• Why?

• What could have been done better?

• Who else needs this insight?

• How do we embed or scale it?

Boost reinforces beneficial patterns and shifts systemic behaviours. This is not just about writing up “lessons learned.”

No more “that was last sprint’s win, we’ve moved on”
Boost makes sure improvement does not evaporate.

Boost is re-entering the BEE cycle to amplify the learnings. It’s there to raise the bar higher and better. It is the relentless pursuit of continuous improvement.

Comparison: BEE, OODA, PDCA and Scrum

Many established models support feedback and adaptation. These include OODA, PDCA, and Scrum. Each has influenced how organisations respond to change. Each has strengths.

However, BEE was developed to address a recurring pattern: the move from problem to solution is often rushed, shallow, or overly focused on teams alone. In contrast, BEE provides a deliberate reasoning model that places equal emphasis on systems thinking, organisational resistance, leadership enablement, and reinforcement of success.

Here is how BEE compares:

OODA (Observe, Orient, Decide, Act) is a decision-making loop designed for rapid response in dynamic or adversarial environments. It supports fast thinking, tactical shifts, and continual adjustment in response to new information. BEE shares the goal of informed action but takes a more deliberate approach. Where OODA focuses on speed and muscle memory to specific situations, BEE introduces structured reflection through Expose and Examine, and slows decision-making when complexity or collaboration requires it. OODA does not address how options are explored, how change is enabled, or how improvements are embedded. BEE includes Explore, Enable, and Boost to provide those capabilities, making it better suited to organisational change that requires shared reasoning and sustained follow-through. OODA has its place and is especially effective in chaotic environments.

PDCA (Plan, Do, Check, Act) is a structured loop for continuous improvement and process optimisation. It is effective in stable systems where processes are known and improvements are incremental. BEE overlaps with PDCA in its focus on deliberate action and learning, but provides more structure in situations of uncertainty. PDCA does not include explicit steps for exposing hidden issues, exploring multiple options, or preparing the organisation for change. BEE adds Expose, Explore, and Enable to deal with ambiguity, and Boost to reinforce progress across the system. This makes BEE better suited for complex or adaptive environments where linear plans are insufficient.

Scrum is based on empirical process control, which is defined by three pillars: transparency, inspection, and adaptation. These are essential mechanisms for managing complexity and enabling iterative improvement. BEE aligns directly with these pillars through Expose (transparency), Examine (inspection), and Enact (adaptation). However, Scrum provides no formal mechanisms for exploring options before acting, enabling the system to support change, embed, and amplify success. BEE fills these gaps through Explore, Enable, and Boost. This ensures that the three pillars of empirical control are not just present, but deeply supported and sustained across the organisation.

BEE is not a delivery method. It is a structured thinking model that enhances decision-making, change preparation, and progress integration. BEE is not competing with OODA or PDCA; they have their place and benefits. Context matters. Scrum, on the other hand, I feel, is misunderstood, and most people treat transparency, inspection, and adaptation as mechanical actions.

BEE Is the Missing Layer

You do not need another framework. You need a better way to think.

Most teams are already building, reacting, and adapting. But that alone is not enough.
Without slowing down to understand, prepare, and reinforce, most changes are short-lived.

BEE fills that gap. It brings structure to clarity, leadership to action, and durability to learning.

And in Practiqual®:

BEE is not just how we think. It is how we lead.

I want to be clear from the start. Practiqual® is not Agile.

Practiqual does not subscribe to the values and principles outlined in the Manifesto for Agile Software Development. It is not a framework, a method, or a delivery playbook.

Practiqual is a leadership approach to leading complex products in complex organisations and/or marketplaces.

That distinction matters because much of the confusion and frustration in organisations comes from applying delivery ideas where leadership judgment is required.

Practiqual is About Leadership

Agile was born in a very specific context: small teams, software delivery, short feedback loops, and a focus on responding to change. In that space, many agile practices are genuinely useful. Agile is a value system that has four values and twelve principles for software development. These are sound and still make sense today.

But not all things are software development, not all teams need agile, and organisational structures vary and pose different types of challenges.

There are problems of:

• competing priorities across portfolios

• complex operating models

• legacy systems and organisational constraints

• regulatory and governance obligations

• human behaviour, incentives, and power structures

• Scale and size of organisation

• interconnected ecosystems of vendors, platforms, and products

Practiqual exists to help leaders operate in that reality. But it does not mandate any single method or framework. Its fundamental design is to build one’s own framework or way of working that suits the organisation's context.

It focuses on how leaders think, turn up, decide, and act when the problem is not obvious, the solution is unclear, and the consequences are real.

Yes, Agile Has Useful Ideas

Many good practices emerged from agile thinking.

You can absolutely use them.
You can build feedback loops.
You can limit work in progress.
You can create transparency.
You can shorten learning cycles.
You can empower teams.
You can even choose to subscribe to the agile values and principles if they genuinely align with your context.

Practiqual does not reject agile practices.

What it rejects is blind allegiance and dogmatism in the agile marketplace.

Practiqual encourages leaders to deliberately choose practices that fit their situation, rather than inheriting someone else’s ideology and hoping it works.

Practiqual Is Not Here to Fix Agile

This is important. Practiqual is not an attempt to “fix agile”, rebrand it, or offer a better version of it.

It deliberately distances itself from the toxic agile marketplace and what is now the “Agile Brand”.

The space that is full of:

• certifications without accountability

• cargo cult implementations

• dogmatic enforcement of ceremonies

• frameworks sold as universal solutions

• snake-oil organisations with low skill in the market to make a buck

• leaders not engaging and hiding behind the process

• old management styles enforced on agile

• low skill and barrier to entry of agile coaches, scrum masters and the like

• eroded trust

Operating in that world no longer interests me. I cannot deny the good in the market and what I have seen, experienced and done. The good, however, is overshadowed by a toxic marketplace.

I do not relate to it, and I do not want Practiqual associated with it.

Ideas Come From Many Places

Yes, Practiqual uses ideas that are often labelled as agile.

It also uses ideas from:

• systems thinking

• complexity theory

• theory of constraints

• product management

• organisational design

• risk management

• change leadership

• governance and decision theory

• lived experience leading real organisations

And some ideas are simply my own, shaped by years of seeing what actually works and what repeatedly fails.

Practiqual is not trying to be pure. It is trying to be useful.

Built for Complex Organisations

Practiqual is targeted at leaders operating in environments where:

• Products that are complex

• Teams do not exist in neat, autonomous bubbles

• Technology is deeply entangled with process and policy

• Change cannot be delegated and forgotten

• Leadership decisions shape outcomes more than ceremonies ever will

• There is no one solution for every situation, even in the same organisation

These are complex organisations with complex products and complex ecosystems.

They do not need another delivery framework.

They need leaders who can think clearly, act deliberately, and take responsibility for shaping the system they lead. The world has changed, and leaders need to step out of outdated management thinking.

That is what Practiqual is for.

Use What Helps. Leave the Rest.

If agile practices help you, use them.
If they do not, do not force them.
If they fit your context today but not tomorrow, adapt.

Practiqual gives leaders permission to stop pretending there is a single right answer and start building an approach that actually fits their reality.

It is not agile. It can help a leader fix their broken agile.

And that is entirely the point.

What Is the Principle?

The Win-Win-Win Principle means this:

When leaders remove obstacles that block delivery, the team wins, the customer wins, and the organisation wins.

It sounds simple, but it is rarely practised. Most leaders are trained to observe, manage, and report, not to intervene and resolve. They supervise the pain but don’t step in to fix what’s causing it.

True leadership means creating the conditions where delivery can succeed. That doesn’t happen from the sidelines. It happens when leaders take ownership of the environment in which their teams are working.

When you actively help teams succeed:

• The team wins because they are unblocked, trusted, and supported.

• The customer wins because real value gets delivered.

• The organisation wins because it gains momentum, credibility, and results.

This principle isn’t about being nice. It’s about being useful.

The Spiral of Passive Leadership

Dysfunction often begins with a subtle but damaging pattern: passive leadership. Here’s how it plays out:

1. The manager stays in observer mode
The team raises a blocker. The manager listens, nods, and moves on.

“This is your problem to live with.”
No ownership. No outcome.

2. The problem is converted into a process
Instead of solving it, the issue gets wrapped in structure:

• “Let’s track it.”

• “Make sure it’s on the board.”

• “We’ll review it next sprint.”

Now it’s visible, but it’s still there.

3. Control replaces ownership
Leaders increase involvement, but not responsibility:

• More meetings

• More updates

• More check-ins

They’re close to the issue but not in it.

4. Pushback becomes a deflection
The team asks for help. The response:

• “That’s governance.”

• “That’s not in our control.”

• “That’s the process.”

No escalation. No trade-off decision. Just a dead end.

5. The team is told to adapt
With no change coming, the team is told:

• “Be pragmatic.”

• “Work around it.”

• “That’s just how it is.”

They now carry the blocker and the pressure.

6. Pressure increases, but leadership doesn’t
As outcomes slide, management tightens:

• Shorter timelines

• Tighter reviews

• “Where’s the plan?”

Still, the blocker remains.

7. Inaction becomes normal
Because the problem is “tracked,” no action is taken.

It becomes part of the system. A tolerated dysfunction.

The Cost: A Vicious Cycle of Control and Frustration

This doesn’t lead to silence. It leads to something worse: overcontrol without resolution.

The issue remains visible. It frustrates the manager. They lean in more:

• More tracking

• More oversight

• More demand for status

But they still don’t take ownership of fixing it.

The team is now under pressure to deliver within a broken system. Leadership feels helpless and irritated. They keep managing the problem but never resolve it.

And when the issue persists, frustration turns into resentment.

This is the cycle:

• The team is controlled but unsupported.

• The manager is involved but ineffective.

• The problem stays stuck.

Everyone knows it. No one owns it. And the damage compounds.

Applying the BEEEE Cycle™

Most leaders believe they support their teams. They believe they are enabling delivery. They believe they are clearing the path. But belief doesn’t equal behaviour.

The BEEEE Cycle™ is not just a product or process tool. It is a way to test your leadership in real-world conditions.

Ask yourself:

• Expose – Are blockers actually being surfaced? Or have people stopped raising them because they’ve learned nothing changes?

• Examine – When problems come up, do you investigate the root cause? Or do you listen politely, nod, and move on to the next meeting?

• Explore – When a team needs help, do you actively look for options with them? Or do you default to “That’s not in our control”?

• Enact – Are you taking personal action to remove constraints? Or just supervising the team while they struggle to work around them?

• Boost – When blockers are removed, do you publicly show that raising issues makes a difference? Or do you quietly move on? Are you looking to take your solution to the next level?

This is not a checklist. It’s a leadership audit.

If your answers to these questions are mostly no, the issue isn’t team maturity. It’s leadership avoidance.

The BEEEE Cycle™ doesn’t just improve delivery; it also improves the customer experience. It reveals whether you’re actually doing your job.

How to Practise the Principle

Start here:

Ask every team you lead: “Is there anything I can help remove that’s getting in your way?”

Then prove you mean it by acting on what they say.

Also:

• Pick one unresolved issue and own it fully. Don’t track it, fix it.

• If the process is the blocker, challenge it.

• Celebrate real examples of blockers being removed so teams know it is worth speaking up.

Final Word

Your job is not to supervise struggle. Your job is to remove the obstacles that stop your team from delivering.

Don’t manage the problem.
Own it. Resolve it. Lead through it.

That is what your team needs. That is what the work demands.
Start there.

The best leaders aren’t measured by how well they monitor, but by how quickly they remove what’s in the way.

Practiqual® is a modern leadership approach for working in complex environments.
It is grounded in principles that make sense, not rituals or slogans.

The Win-Win-Win Principle is not mandatory in Practiqual®. But if you’re serious about leading well, it is a principle you are highly encouraged to live by.

Because when your team wins, your customer wins. And so do you.

In any complex system, clarity beats chaos. And clarity starts with principles.

What Are Principles?

Principles are not preferences. They’re not mottos or motivational posters. They are deeply held beliefs that shape how we lead, decide, and act. Especially under pressure. Principles guide behaviour when rules don’t exist. They act as your compass in unfamiliar terrain.

In the Practiqual® approach, principles sit at the core of leadership. They’re not optional. They are the foundation for consistency, integrity, and direction.

But here’s the catch:

You can’t rely on someone else’s principles.
You have to define your own.

You don’t just need principles. You need shared ones that people believe in and are willing to act on. Principles people will stand by, and hold themselves and others to account when they’re not upheld. Sure, be inspired by others, but only adopt a principle if you genuinely believe in it, if everyone aligns with it, and if you’re prepared to back it with action. Otherwise, it’s not a principle. It’s someone else’s wish.

Why Are Principles Important?

Because complexity demands decisions. Constantly.

Most dysfunction inside teams is not due to a lack of knowledge. It’s a lack of shared principles. People may know what matters, but they don’t act like they believe it. They optimise for politics, avoid conflict, or make decisions based on assumptions no one has questioned. If your team, leaders, or clients don’t know what you stand for, don’t expect alignment when it matters.

Defined principles give people a shared mental model. They reduce noise. They speed up decision-making. They help stakeholders stay aligned, even when the path forward is unclear.

In Practiqual, leadership is not about enforcing a checklist. It is about defining the why behind the choices. Principles make that why visible. They create a standard that leaders can be held to.

What Happens When Principles Are Missing or Misaligned?

Without clear principles, confusion takes over. Decisions become reactive. People rely on assumptions or copy others. Nothing has been made explicit. This breeds misalignment, tension, and rework.

Worse, when people pretend they have principles but really just have wishes, it creates the illusion of alignment. Teams claim to share values but interpret them differently.

You see this all the time in Agile:

“We value collaboration.”

One person thinks that means daily standups.
Another thinks it means consensus decisions.
Someone else thinks it means posting tons of messages in Slack.

It is a disaster waiting to happen.

Misalignment isn’t always about misunderstanding. Often, it’s about conflicting principles that were never made explicit. Many disagreements and arguments have fundamental differences in the principles people stand for. When enforcing a principle costs political capital, it usually indicates a more profound mismatch is being exposed. One leader is acting on a belief that the organisation doesn’t honestly share. That’s not a failure of principle. That is the problem principles are meant to surface.

And ambiguity? It can be helpful when it’s intentional. But ambiguity that protects indecision, preserves power structures, or avoids trade-offs is not neutral. It’s a choice. Without shared principles to guide how ambiguity is used, it becomes a breeding ground for dysfunction.

Don’t Borrow Principles. Define Your Own.

This is the heart of the matter.

Too many organisations copy values from conference slides or manifestos. That is branding, not belief.

And when pressure hits, branding will not guide you. Only your fundamental principles you stand for will.

Practiqual does not adopt universal principles. The approach recognises the critical nature of principles, but expects you to define your own, grounded in your context. Be inspired by others. But adopt only principles you are prepared to enforce. Even when it is inconvenient, costly, or uncomfortable.

Your principles should align with your identity, purpose, and strategic intent. They are not slogans. They are your operating system.

When they are yours, they guide you.
When they are someone else’s, they mislead you.

Leadership Needs Principle Alignment

Leadership in the Practiqual Approach is principle-first.

We believe leadership must be:

• Grounded in clearly defined, agreed-upon principles

• Aligned across all involved

• Revisited regularly to ensure decisions reflect what we stand for

When alignment exists, decisions are faster. Trade-offs are clearer. Trust increases. When it is missing, everything slows down. Friction multiplies.

Most conflicts are not about process or priorities. They are about misaligned principles. Or worse, principles that were never real. Just slogans. Just noise.

And when a principle is broken? That must have consequences. If it doesn’t, it was never a principle. It was a performance.

Use the BEEEE Cycle to Strengthen Your Principles

The Practiqual BEEEE cycle is not just for product work. It supports leadership too.

Use it to reflect, test, and act:

• Expose: Reveal how well shared principles are driving decisions. Look at both good and bad situations. When alignment is smooth, it shows the principles are working. When it breaks down, it shows where they are not.

• Examine: When there is disagreement, confusion, or drift, dig into the underlying principles. What assumptions are clashing? What has gone undefined or misinterpreted?

• Explore: What needs to change? What better reflects your identity? What would you be willing to defend publicly?

• Enact: Reinforce principles through visible action. Make them real through rituals, behaviours, governance, and design. Take accountability seriously. When people uphold principles, you should recognise it. When they don’t, expose it. Reward alignment. Address drift. Do not allow principle-breaking to go unchecked.

• Boost: Highlight what is working. Strengthen impact through repetition and reward. Make it part of how the organisation learns.

This keeps principles alive. It turns them from statements into systems. And systems into culture.

How to Get Started

Principles only matter if they shape decisions. To define your own, start with real situations.

Pick a current challenge or decision. Ask yourself:

• What principle should guide this?

• Why is this principle important?

• What would it look like in practice?

• How would we know it is happening?

If you cannot answer clearly, the principle is either missing or not shared. Use that tension to refine it. Then ask whether your team is willing to act on it.

Example
Teams are under pressure to release features fast. To meet deadlines, they skip documentation. Critical context is lost. When people leave, knowledge leaves with them. Onboarding becomes slow. Diagnosing problems becomes guesswork.

You might define a principle like:

• What is it? We do not stop until documentation is complete.

• Why? To protect the organisation’s intellectual property and reduce long-term risk.

• What does it look like? When pressure builds, teams pause and acknowledge what is missing. They explain the impact. They learn to say no to releasing incomplete work.

• How would we know it is happening? Documentation is reviewed before release. If business pushes for shortcuts and teams comply without naming the risk, that shows misalignment. Either the principle is not truly shared, or people are not ready to act on it.

A principle only matters if people use it to make hard decisions. If not, it is not a principle. It is a hope.

Define. Don’t Pretend.

This is the leadership gap Practiqual was built to close.

You don’t need more frameworks. You need principal clarity. Defined by your leadership, in your context.

So stop copying what looks good on someone else’s wall.

Define your own principles.
Make them visible.
Make them real.
Make them matter.

References

1. B. Maytom, The Practiqual Approach, v1.0, 2025

2. S. Covey, Principle-Centred Leadership, Free Press, 1991

3. ISO 26000, Guidance on Social Responsibility, International Organization for Standardization, 2010

   
   
   

Let’s get this straight: not all demos are created equal.

In complex product work, the words demo or showcase get thrown around like they mean something. But most people are faking it. Some demos are just glossy presentations, dressed up to get a round of applause. Others are raw, real, and uncomfortable, and they’re the ones that actually move the product forward.

If you’re serious about building something valuable, you need to know the difference. Because confusing the two isn’t harmless, it’s dangerous.

Performative Demos Are a Dead End

We’ve all seen them. Polished. Rehearsed. Click-throughs so perfect they could be cut into a promo reel. And yet some teams record demos so people can “watch them in their own time.”

But they’re not showing the product. They’re performing the team’s effort.

It’s not about a showcase, it’s about feedback and validation. The unspoken message? “Look how busy we were. Please clap.”

And they do. Everyone thanks the team for their hard work. People nod. Then they leave. And nothing changes.

The assumptions stay untested. The risks remain hidden. The work looks “done” but nobody’s actually asked if it’s right, useful, or even needed.

In complex domains, this is a trap. It creates the illusion of progress while quietly steering you off course.

Exploratory Demos Are Where the Work Gets Better

Now contrast that with a real demo. An exploratory one.

You bring something to the table—maybe rough, maybe half-built—and you say, “Here’s where we are. Let’s inspect it together.”

You ask:

• What are we learning?

• Does this reflect our vision?

• Is it delivering value?

• What assumptions are we testing here?

• Does this move us closer to validation?

You put the product under the microscope, not to defend it, but to improve it.

You’re not aiming for approval. You’re looking for real, uncomfortable feedback that lets you adapt.

This is how emergent solutions are uncovered. This is how you build through iterative and incremental progress.

Exploration Demands the Right Audience

Let’s be clear: a good demo isn’t just about the team. It’s about who’s in the room.

If your stakeholders are just there to rubber-stamp and nod, you’re screwed. You need people who will challenge assumptions, inspect value, and engage in real product thinking.

Without that, even the best-structured demo becomes a hollow ritual.

Let’s Make This Real

In one team, the demo is slick and silent. No discussion. Just a “done” stamp and a move to the next ticket.

In another, the team shows a broken journey. A stakeholder immediately spots a mismatch in the value proposition. That triggers a rethink. That insight reshapes the next iteration.

One of those teams is wasting everyone’s time. The other is actively testing assumptions, adapting, and getting closer to a real solution.

This Is What Practiqual Stands For

Practiqual isn’t about process theatre. It’s about deliberate, adaptive delivery in complex environments where plans can’t be locked in, and truth only emerges through iterative and incremental work.

Exploratory demos are critical. They support vision, test value, drive validation, and make feedback visible. They create space to test assumptions early before waste accumulates.

They are deliberate acts of adaptive delivery. They must be done regularly, at any time that makes sense. That’s Practiqual.

If Your Demo Ends in Applause, You’ve Missed the Point

If you want praise, go do a TED Talk.
If you want progress, get uncomfortable.

Ditch the theatre. Use your demo to test assumptions, challenge the work, and sharpen the product.

Because in complex work, if you’re not iterating, inspecting, and adapting, you’re not building anything that matters.

There’s a lot of noise in the industry about benchmarks, maturity models, and “where you sit” compared to others. It’s time to call it what it is:

A distraction.

Stop measuring yourself against a model built by outsiders who don’t know your business.

Stop comparing your teams to others who work in different contexts with different goals and constraints.

Your business is unique. Your problems are unique. Each team is unique.
So your path forward needs to be as well.

You don’t win by being a “Level 4” or beating some industry average. There is zero value in that besides inflating egos.

You win by identifying what’s holding you back and start fixing that.

Spend your energy there.
Work on your systems.
Fix what’s not working.
Build what’s needed.

Focus on your own effectiveness and not someone else’s version of progress.

You do you. That’s where the real gains are.

Comparison is noise. Active improvement is the point.

Most teams treat Jira or Trello tickets as the primary record of their product requirements. That’s wrong, and it’s expensive. Tickets are a work coordination tool, not a product definition system. When teams use them as documentation, they embed designs, requirements, and test cases inside transient records that disappear once the work is done. This leads to confusion, wasted effort, and a steady erosion of product knowledge.

Separate Product Documentation from Work Items

Before diving into the structure of products, it’s important to recognise a key principle: documenting the product is not the same as managing the work to build or change it. Most organisations mix these two things together. They muddy the waters by embedding the details of the product in the work tickets. Those tickets are often full breakdowns, including detailed descriptions, requirements, designs, and even acceptance test cases. Over time, this leads to a loss of intellectual knowledge, drowned in a sea of old, disconnected tickets.

You need a clean separation. One space for tracking short-term work. Another for maintaining the long-term understanding of the product itself. Without this, you’re building confusion and loosing your valuable intellectual property.

Every Product Is Made of Features

Every product is made up of features. It doesn’t matter whether it’s something you can touch, use, or experience. Every product is just a collection of features. Some of them are easy to see, like the handle on a kettle or the ability to track a parcel in a courier app. Others are buried deeper, like the insulation that keeps water hot or the automation that sends the delivery notification. But those features are sub-features and nested features

Once you understand this, you start to see something important. Features can contain other features. A product is essentially made of features, which are made of more features, all structured together. A phone camera includes low-light adjustment, image processing, and autofocus. A booking system includes search, selection, payment, and confirmation. This is not just interesting, it is foundational. It’s how products are structured.

This is important to understanding the taxonomy of products. The essence here is to see a product is made up of a hierarchy of features.

Product
├── Feature [grouping or area]
│   ├── Feature
│   └── Feature [external product or component]

The Real Problem: We Confuse Work with the Product

Most teams use tools like Jira, Trello, or Azure DevOps to manage the work of changing a product. These tools are designed to track tasks, bugs, enhancements, and features through a delivery cycle. The problem is, many teams use these tools as their only source of truth for the product itself.

That’s where it starts to break down. Because once a piece of work is done, the ticket is closed. It disappears. If the feature only exists in a ticket, then it gets lost. A new change gets a new ticket. Another change gets another ticket. Over time, you don’t have a product definition. You have a graveyard of old tickets.

Ask yourself this: could a new developer join your team and understand what your product is just by looking at Jira? Could they see what features exist, how they work, and how they’ve evolved over time? For many teams, the answer is no.

The Costs Stack Up Fast

This isn’t just about clarity. It has real cost implications. Think about how much money is wasted writing requirements that disappear into a work system. Take a look at any old business requirement document. It took weeks or months to write, involved multiple people, meetings, and reviews. And today? The product doesn’t match what’s in that document. Some parts are outdated, some still matter, but no one knows which is which.

As a leader, look at the cost to company:

• Cost-to-company for the people writing, reviewing, and managing the requirements

• Hours spent researching and discussing them

• Time wasted reading outdated documents trying to figure out what’s still true

• Delays caused by misunderstanding or outdated requirements

• Rework created when decisions are made without knowing past choices

All that money spent, and the outcome is confusion. That’s not just wasteful. It’s damaging.

The mistake is clear. We’ve been using the wrong tools for the wrong job. Managing work and describing the product are two different things.

Why This Happens

It’s easy to fall into this trap. When deadlines loom and teams are stretched, it feels efficient to drop everything into the ticket. But short-term convenience creates long-term pain. A ticket isn’t designed to carry the memory of your product. It’s there to track the work while it’s happening.

Still, not every team is the same. In some fast-changing environments, documentation can feel like overhead. In regulated industries, traceability might require work records to carry more detail. That’s fine, but even then, product knowledge should be captured in a stable, referenceable place. Use tickets to trace activity, but point to a permanent record. That’s the problem. We’ve been using temporary scaffolding as permanent documentation.

A metaphor example is architectural design and building. Builders use construction drawings to guide the build, but those drawings live separately from the daily work schedule. The plans are updated, versioned, and remain the source of truth. That’s what your product documentation should be: evergreen, structured, and maintained.

What Work Items Should Be

Work tickets have a job to do, but it’s a simple one. They are disposable placeholders used to coordinate short-lived tasks. Their purpose is to define what needs to be done, not to explain how the product works.

Tickets should contain just enough context to identify the work. A short title or sentence. A status like "to-do," "in progress," or "done." Some teams may also track who is doing what, or break things down into smaller activities to help coordinate and focus effort. That’s fine, as long as the information stays short, sharp, and focused on the work, not the product.

All detailed information, such as descriptions, designs, test cases, and decisions, should live in the product documentation. Tickets can link to that documentation, but should never try to replace it.

You’re free to structure your documentation in whatever way fits your context. The point is that it must exist, and it must be separate. Your documentation, test cases, and designs should not sit inside a ticket that disappears once the work is done.

A Better Practice: Permanent Product Knowledge, Disposable Work Tickets

This is a core design principle. Work tracking tools are for managing short-lived tasks. They help coordinate what needs to be done. That’s it. They are not product documentation.

Product documentation needs to live elsewhere. It needs to be continuous, structured, and treated as a living artefact. A single place that explains what the product is, how each feature works, and how it has changed over time. It may contain design and technical information that needs to be retained for knowledge sharing and future trouble shooting. See this as future proofing your knowledge. It is also a single source of truth as to what the product is.

Use a tool like Confluence or another structured wiki to build a clear, navigable product record. Here’s a simple example:

Product 
|- Feature
   |- Sub-feature
      |-Test Cases

Standardize how product features are documented:

• What it is

• Why it exists

• Linked test cases

• Design references

• Dependencies

• Change history or decisions

This becomes the source of product truth.

You don’t need a rigid format. It should suit your context, product, and needs. Start small and improve it using the Practiqual™ BEEEE cycle™. Be brutal in reducing low-value information, especially if it doesn’t need long-term retention. Pay attention to where teams get stuck or where information and understanding are unclear, especially when new people join.

This kind of structure allows new team members to onboard faster, helps existing staff avoid rework, and makes feature behaviour discoverable at any time.

You still use Jira or Trello to track the work, but understand its role. These tools are designed for short-lived coordination. They help manage who’s doing what, when, and whether it’s done. That’s it.

Product documentation, on the other hand, belongs in a platform built for long-lived product understanding, like Confluence or an equivalent. That’s where you maintain clarity on what features exist, how they behave, and what decisions shaped them.

Make the boundary clear. Document it. Communicate it. Tickets are ephemeral. Product knowledge is enduring.

Practiqual’s Take on Product Knowledge

Practiqual approaches this as a systemic challenge. It recognises that teams must distinguish between work tracking and knowledge preservation. Simple tickets give you traceability—who did what, when—but they shouldn’t be burdened with deep detail. Intellectual property, on the other hand, must be retained. If people move on, we still need that knowledge.

Practiqual supports this through structural separation. Each product or service is expected to maintain a documented feature catalogue, supported by version-controlled tools that allow product knowledge to evolve without being lost. That creates a single source of truth. One that increases transparency, enables shared understanding, and dramatically reduces time to learn. It’s a practical decision that balances lean delivery with long-term resilience.

This isn’t a process suggestion. It’s a structural fix.

Additional Suggestions

Here are some practical suggestions to make it stick:

1. Make Documentation Part of the Workflow
   Update documentation as part of your Definition of Done or Quality Standards. Include it in product reviews or release notes. Assign reviewers or owners to check for accuracy at each increment.

2. Establish Shared Ownership of Product Knowledge
   Every team member should be accountable and responsible for keeping product documentation accurate and current. Make this a team norm. Shared ownership ensures that updates happen naturally as part of the work—not just when someone is explicitly asked.

3. Audit and Purge Regularly
   Set a regular cadence (for example, quarterly) to review, archive, or update outdated documentation. Keep it clean. Your documents may be in a mess, and that’s okay. You may just need a few small efforts now and then to bring things into shape. Fix it iteratively and incrementally, but be disciplined and consistent. Over time, small improvements add up to a more usable and reliable product knowledge base.

4. Train Teams on the Why
   Help teams understand the cost of tribal knowledge and the benefits of having structured, accessible product documentation. Include it in onboarding and team education.

5. Adapt to Context
   In regulated or compliance-heavy domains, you may need to embed traceability into documentation practices. Don’t ignore these constraints—adapt your model accordingly. For example, on a Confluence page you could link the associated Jira tickets automatically.

6. Hire a Technical Writer

   In larger organizations, it may be beneficial hiring a technical writer to maintain a consistent standard across the documentation. The cost of establishing clear information pays for itself, because not having it means teams waste time reanalyzing, renegotiating, trawling thought reams of outdated knowledge Even worse making a wrong change and then having to repair it.

   Found this useful? Please spread the word and share it.

   Share

Summary

• Teams aren’t short on effort. They’re just spending it in the wrong place.

• Treating work tracking as product documentation causes insights to vanish when tickets close.

• This leads to duplication, delays, and lost understanding.

• The fix is not more documentation. It’s better documentation in the right place.

• Separate short-term work tracking from long-term product knowledge.

• Build documentation into the workflow:

  • Update regularly

  • Share ownership

  • Tidy it up over time

• Design for longevity, clarity, and traceability.

• Don't aim for perfect from day one. Start with the mindset that knowledge matters.

• This protects intellectual property, speeds up learning, and helps build products that last.

• Set up a regular inspection cadence to assess the effectiveness of work item tickets and product documentation. Use the BEEEE cycle to help do this.
  

  Practiqual’s just getting started. Want in? Subscribe.

Leadership isn’t just about having a vision. It’s about owning two key areas: the product and the approach. These aren’t separate silos. They’re connected. You need to manage both if you want the organisation to thrive.

This is right at the heart of why the Practiqual approach exists. It gives leaders a clear way to look at both sides of the equation, the thing we offer to others and the system we use to bring it to life.

Let’s walk through them.

Product: What We Deliver

When we say "product", we’re talking about anything you offer to others that they find useful. That includes physical products, like something you manufacture. It also includes digital products, like apps, platforms, tools. And it includes services, like consulting, support, healthcare, education or delivery.

Practiqual treats services as products because they’re still designed and delivered to create value. They might look different from physical goods, but they still need leadership, structure and continuous improvement.

Now here’s the thing. It’s not enough to build something. It has to matter to someone. And if you're running a commercial business, it has to do more than matter. It has to generate revenue. It needs to keep the business afloat.

If customers aren’t using it, paying for it, renewing it, or recommending it, then you have a problem. The product may not be viable. It doesn’t matter how passionate you are about the idea. If it doesn’t solve something meaningful and return value back to the business, you’re in dangerous territory.

And if you’re a startup, it’s even more serious. You don’t have a real product until someone pays for it or chooses to use it. Before that, it's just an idea. Vapour. The only validation that counts is when real people interact with it and get real value from it.

This is exactly why Practiqual puts such a strong emphasis on product effectiveness as a leadership responsibility. It’s not just something for the team to worry about. It’s a strategic concern.

So as a leader, ask yourself:

Is our product effective, really?

That doesn’t mean "Did we ship it?" or "Do we like it?" It means "Is this delivering value? Is it keeping the business alive? Would our customers miss it if it disappeared tomorrow?"

You need systems that track:

• Customer behaviour

• Market feedback

• Revenue and renewals

• The real-world outcomes of using the product

• Whether the problem you’re solving still exists

Because if your product stops delivering, your business won’t be far behind.

Approach: How We Deliver It

If the product is what you offer, then the approach is the machinery behind it. It’s your engine room.

That includes team structures, planning cycles, governance, funding, coordination, and all the rhythms and routines that move things forward.

Even the best product can fail if your internal systems are messy, outdated, or too slow. You could have something truly valuable, but if your delivery system is clunky, reactive, or over-complicated, you're going to struggle to get it to market. Or you’ll burn out your teams trying.

So here’s your next question:

Is our approach effective? And is it fit for what we’re trying to build?

Too many organisations are using delivery systems that no longer suit their reality. Maybe they’ve outgrown them. Maybe they’ve layered on too many fixes over time and created complexity without clarity. Or maybe they’ve copied someone else's framework that never really worked in their context to begin with.

That’s why Practiqual includes a practical, structured approach to delivery. It’s not one-size-fits-all, but it gives leaders and teams a clear way to design a delivery model that fits their product, their scale, and their environment.

When your approach isn’t working, you feel it:

• Delays pile up

• Teams misfire or go in circles

• Coordination falls apart

• Quality drops

• Momentum slows down

Your product might be fine. But if your system is broken, the results won’t show up. That’s the hidden cost of delay, confusion, and churn.

Product and Approach Work Together

Here’s the big point. Product and approach shape each other. They’re not two separate streams. They’re constantly influencing each other. We deliberately draw this in a yin-yang style to show the interconnective and influence.

The kind of product you’re building affects how you should work. A digital platform built in a fast-moving market needs a very different approach than a one-off client service.

Likewise, the way you work affects the quality of the product. If your approach is slow, vague, or chaotic, your product won’t improve fast enough to stay competitive.

In Practiqual, we treat both domains as leadership responsibilities. They’re two sides of the same system. You can’t optimise one and ignore the other.

So you need to keep asking:

Is our product delivering real, sustaining value?

And is our approach helping or getting in the way?

This Is Leadership Work

Practiqual helps leaders focus on three things:

• Lead with clarity. Know what you’re offering and why it matters.

• Deliver with intent. Make sure your systems are fit for purpose.

• Adapt with integrity. Keep reviewing and improving both sides of the equation.

This is not about firefighting. It’s not about theory. This is the real work of leading a business that has to survive, grow, and serve real people.

Use the BEEEE Cycle™ to improve effectiveness

To help with that, Practiqual includes the BEEEE cycle. This is a structured way to reflect and reset at regular intervals.

It gives you space to ask:

Is this working, both product and approach?

The BEEEE cycle walks through:

• Expose what’s unclear or underperforming

• Examine the root causes

• Explore new options

• Experiment with safe-to-try changes

• Boost what works, and keep going

It’s designed to help you spot drift early, stay honest, and avoid big surprises. Whether you're a team lead or an executive, this reflection loop helps you see what’s real and act on it.

Summary

• Products include physical goods, digital tools, and services

• A good product must create value and generate income, or the business won’t survive

• The approach is how that product is built, supported, and improved

• Product and approach must work together. They constantly influence each other

• Practiqual gives leaders the mindset and structure to assess both areas and make meaningful improvements

• Use the BEEEE cycle to reflect regularly, course-correct, and raise the bar

• Keep asking:

  Is our product effective?

  Is our approach enabling that success or holding it back?

No matter what your company does, who it sells to, or how many layers sit between you and the market, you're still serving a human at end of the chain. Always!

You might be building backend systems for logistics.
You might work in compliance for a global supplier.
Maybe you run infrastructure buried deep in someone else’s supply chain.

It doesn’t matter. Because at the very end of that long chain of B2B, contracts, systems and transactions, there’s a real person. A real human. Someone using the thing. Feeling the outcome. Living with the result. That real person is paying for it directly or indirectly.

And if you’ve lost sight of that person, you’ve lost the plot.

There’s a lot of hype around AI taking jobs. Optimising industries. Automating roles. Scaling productivity.

Okay. Let’s pretend it happens. Let’s say most people are out of work because AI has taken over.

What then?

All those people with no jobs will have no income. No income means no spending. No income also no taxes. They won’t be able to buy your product, use your service, or take part in the economy at all. The consumer facing businesses will collapse first, and that will trigger the entire supply chain to collapse too.

But that’s not even the full story.

If billions of people are left out, it’s not just business that breaks. Society starts to break. Inequality grows. Trust collapses. Unrest spreads. It affects everything from healthcare to education to democracy itself.

You might end up with the perfect machine.
Efficient. Scalable. Flawless.

But in the end, you’ll have built it for no one.

Think about it!

Vision

Our vision is a professional marketplace where members lead with integrity, continually elevate the craft of delivering complex product in complex organisations, and set a new standard that empowers people, strengthens careers, and builds lasting trust with the organisations we serve.

Mission

Our mission is to replace the broken agile marketplace with a principled, professional ecosystem that values integrity over branding, competence over certification mills, and collaboration over tribalism.

We are not rejecting agility. We are rejecting the marketplace built around it, a marketplace that has become fragmented, commercialised, and unaccountable.

Goals

• Create career opportunities across consulting, delivery, leadership, and training

• Rebuild trust with consumers and employers

• Develop reputable certifications and assessments that protect members and give confidence to the market

• Raise the bar of professionalism

• Establish a marketplace for consultants and trainers

• Ensure shared and aligned understanding of key concepts and practices

The Practiqual Approach™

The Practiqual Approach™ is a structured, leadership-first system for navigating complexity in modern organisations. It replaces the dysfunction of the agile marketplace with a clear, principled alternative. It is designed to help leaders, teams, and businesses solve complex problems in the real world.

This isn’t a framework to follow. It’s an approach you build, grounded in leadership, evidence, and professional standards. And it’s developed and owned by the community, and not a single vendor.

The Practiqual Approach is made up of four integrated layers, each with a distinct function:

1. Core

2. Framework

3. Pattern Library

4. Customisation

1. The Core (Mindset and Leadership)

The Core defines the thinking behind the approach. It sets out the leadership behaviours, principles, and mental models needed to succeed in complex environments.

Rather than enforcing a fixed set of values, the Core encourages each organisation to define its own principles and behavioural expectations, aligned to its purpose. This creates a strong ethical and strategic foundation for decision-making, governance, and change.

At its heart, this layer is about Lead with clarity. Deliver with intent. Adapt with integrity.

Practiqual addresses many levels of leadership and there are areas of business acumen, risk management, change management, business strategy, product strategy and more.

2. The Framework (Structured, Customisable)

The Framework layer offers a base blueprint which a practical, structured starting point for how build and deliver your products, how decisions are made, and how teams coordinate. It draws heavily from frameworks and methods like Scrum, Kanban, LeSS, Nexus, Systems Thinking and Evidence-Based Management, but is not bound by any one of them.

This is a Build-Your-Own (BYO) framework. The blueprint must be customised by each organisation to suit its structure, culture, and strategic goals. Some may tailor it to become more flow-based and adaptive, while others may lean towards more defined or formal delivery controls.

What matters is that the framework is fit for purpose and is clear, coherent, and evolving as the organisation itself evolves. The only non-negotiable? You must regularly assess the effectiveness of both the products/services being delivered as well as the approach used to deliver them.

3. The Pattern Library

This layer is where theory meets real-world action. The Practiqual Pattern Library will be continually growing, maturing and a peer-reviewed collection of techniques, delivery patterns, and methods. Many of these already exist and we will not be reinventing them, instead enhancing clarity around them.

Each pattern is clearly defined, contextualised, and critiqued. They don’t come with vague descriptions or universal claims. They come with detailed how to steps, case studies, variations, trade-offs, and guidance for when to use them and when not to. Patterns will have short cases studies from other members who have used it, sharing their context and outcome of using that pattern.

This allows practitioners and leaders to explore patterns they may wish to use in their own framework and thus customise their framework accordingly. This mean they are not left alone to filter out noise, contradictions on their own. The can see success and failure that others have had.

The community curates, maintains and evolves this library. Practitioners can share their experiences, refine the methods, and contribute new ideas. It making this a living resource that gets more valuable over time.

4. Customisation

Customisation is essential. This layer gives organisations a structured way to customise their own framework responsibly, without compromising their framework and/or introducing unnecessary risk.

Rather than just encouraging customisation, this layer aims to guides it by howing where flexibility is healthy, where it carries risk, and how decisions ripple across the system. It helps organisations evolve with confidence, balancing innovation with operational safety.

The base blueprint is an optimal model with very clear intentions, risk controls and optomisations. Changing it is encouraged, but the customisation layer helps with “if you change x, realise the impact to y and the risk associated with it”

Every adaptation is intentional. Every trade-off is made visible. Every risk raised.

Customisation reflect the organisations reality, not someone else’s idea of best practice or someone else's principles. The consumer needs to own their own operation model.

The Practiqual Community

The Practiqual Community is a professional consortium made up of leaders in complex product and service delivery. Members come from diverse industries and roles. Some lead teams within organisations, others run their own businesses, and many influence strategy at various levels. What unites them is a shared mission.
To elevate the profession by building a credible approach and defining the standards that guide how we lead, work, and deliver.

This is not just a network of peers. It is a governed, structured community with real responsibilities.

The Practiqual Community is accountable for both:

• Shaping and evolving the Practiqual Approach, the shared method, principles, and mindset used to navigate complex work

• Defining and protecting the standards that support it, such as professional conduct, certification expectations, assessments, and quality benchmarks

The community is the strategic owner and critical stakeholder. Elected stewards represent the membership, guide decisions, and ensure the Practiqual Approach remains relevant, consistent, and high quality.

This structure matters.

It ensures that those who use the approach, and whose reputations and careers depend on its credibility, are the ones shaping and upholding it. That creates a shared incentive to keep the bar high.

To support this, the Practiqual Approach’s body of knowledge is protected by legal structures that guarantee it remains community-governed and not privately owned. No individual or company can claim it. All members commit to a shared Code of Ethics that enables trust, respectful collaboration, and open knowledge sharing, even among competitors. The community also respects copyrights and trademarks of existing patterns in the agile market.

In short, the Practiqual Community exists to build and evolve the Practiqual Approach. It defines, upholds, and protects the standards that give the approach its strength. Members apply the Practiqual Approach in their organisations, customers and end consumers.

It is a principle-led, profession-first consortium built to move the industry forward together.

Career Pathways

Practiqual supports diverse career roles aligned with the Practiqual Approach. These roles are:

• Practiqual Practitioner – Individuals applying Practiqual concepts in team-based work. No certification is required, just a commitment to a few core concepts. They need to understand and apply their framework.

• Practiqual Leader – For team leads and line managers who guide delivery and develop team capability.

• Practiqual Capability Leader – Senior leaders managing multiple teams or portfolios, focusing on strategic alignment and organisational capability.

• Practiqual Product Manager – Product professionals using Practiqual to shape, validate, and evolve valuable products.

• Practiqual Strategic Advisor – Experienced leaders helping organisations redesign operating models, governance, and leadership systems using the Practiqual approach.

• Practiqual Licensed Trainer – Independent professionals licensed to deliver official Practiqual courses. Trainers are assessed for facilitation skill and real-world experience.

• Practiqual Licensed Assessor – Professionals qualified to assess and certify members or organisations. Assessors must be independent from trainers and adhere to rigorous evaluation standards.

Note: Practiqual is still in its early stages. These roles and pathways represent our current direction, not the final design. As a community-driven initiative in startup mode, we expect things to evolve

Safeguarding the Integrity of Practiqual

Practiqual is not just another framework, it is a professional ecosystem built to restore trust, protect members, and raise the bar in complex product delivery. We’ve seen what happens when communities are left unguarded: brand erosion, fly-by-night operators, and certification mills that devalue the profession. Practiqual is structured differently by design. Each of the following safeguards is deliberate, essential, and non-negotiable. Together, they protect the community, the approach, the certification, and the broader public from the very behaviours that corrupted the agile marketplace.

Community Safeguards

As Practiqual is a professional community governed by ethical and legal protections. Membership is not a free-for-all, it is earned and maintained through conduct, contribution, and alignment with our standards. Opportunistic trainers, consultants, and fly-by-night actors are kept out through binding commitments, including a formal Code of Ethics and legal recourse.

The community defines the expectations. The IPAAA ensures those expectations are upheld. Membership can be revoked when standards are breached—this isn’t just policy, it’s enforceable. This structure protects the brand, the profession, and the careers of those who genuinely uphold it.

Approach Protection

The Practiqual Approach is not open-source and cannot be freely co-opted or misrepresented. It is protected through a suite of legal instruments such as copyright, trade secrets, IP trademarks, and certification marks. These protections are stronger than basic trademarks and give the community the power to challenge misuse in job ads, sales pitches, and training offerings.

Importantly, the intellectual property is not owned by any individual or business. It is held in a separate legal entity, which ensures that no single person or commercial actor can hijack or dilute the approach. That entity engages the IPAAA to uphold these protections on behalf of the community.

Certification Integrity

Practiqual certification is intentionally difficult and that’s a good thing. There are no 2-day course quizes sold as certificates as those are scams. These are based on knowledge, demonstratable skill and experience.

It follows ISO-aligned principles where trainers cannot assess their own students, and certification is based on demonstrated real-world competence, not rote memorisation. We are taking it a bit further though, examination and certification are separated too.

Every certified member is bound by the Code of Ethics and remains accountable. This is not a rubber-stamp. It’s a signal to clients and employers that a certified member is a true professional who has earned their standing through integrity, skill, experience and contribution.

This is not the weak, unregulated certification culture you may be used to. It is designed to protect both consumers and certified professionals from the damage caused by low-quality credentials.

The Role of the IPAAA

The International Practiqual Administration and Accreditation Authority (IPAAA) exists to protect the community and not to control it. It holds the legal framework, enforces the certification marks, and ensures compliance with the standards and ethics set by the members themselves.

The IPAAA does not provide training or consulting. Nor does it define the Practiqual Approach. Its independence is intentional, it serves the community’s interests, not commercial ones. We have invested in making sure the community’s standards and intellectual property is protected. This means breaches are defensible and action can be taken by the IPAAA on behalf of the community.

The IPAAA also provides critical infrastructure: such as websites, hosting the knowledge exams, offering tooling and support. It ensuring that certification assessments are performed independently by approved Practiqual Licensed Assessors and are fair.

Each of these mechanisms is an intentional safeguard. Not to make things harder, but to make them credible. To protect those who do the right thing and stop those who do the wrong thing. As for right and wrong, the community decides. It is there to give our community a future built on trust.

Frequently Asked Questions

Q. Is Practiqual agile?
No. Practiqual does not adopt the principles or values outlined in the Manifesto for Agile Software Development. Instead, we support organisations in defining their own principles instead fit for their context. That said, many of the MFASD principles are valuable and worth considering. We simply don’t treat them as sacred or universal.

Q. What happens to all the agile skills I already have?
The Practiqual Approach builds on many strong ideas introduced through agile. Your existing knowledge still matters and will often be useful when applying Practiqual in real work.

Q. What if my understanding of agile concepts differs from the Practiqual Approach?
Due to widespread confusion and misinterpretation in the agile space, Practiqual provides a single, community-aligned view on key concepts. If your interpretation differs, you’ll need to adapt and reframe so we’re aligned and speaking the same language. This alignment is deliberate to reduce conflict between members and provide clarity to those we serve.

Q. You keep using the word governance. That’s not agile.
That’s correct. Practiqual isn’t agile. We use language and terms that resonate with business leaders, because our goal is to support them and the organisations they serve. The discomfort with governance usually stems from outdated command-and-control models. Practiqual embraces modern, flexible, and pragmatic governance approaches. Ironically they are fully compatible with agility when done right.

Q. I’m a Scrum Master or Agile Coach. What’s my career path?
The role of Practiqual Leader is the most natural entry point. You’ll already have relevant skills and experience that align well. And there’s a clear path to grow beyond that. Practiqual opens up new leadership and strategic opportunities for those ready to step forward.

Q. How will you stop lazy tailoring from masquerading as innovation?
Customisation is structured and accountable. Changes must align with core principles, and risks are made explicit. We do not encourage companies to customise without help from a Practiqual Strategic Advisor or Practiqual Certified Consultant. Practiqual ensures tailoring is intentional—not just personal preference disguised as progress.

What happens when someone tries to monetise or subvert Practiqual?
They can’t. Practiqual is protected by legal safeguards and independent governance. Only licensed professionals can teach or certify, and misuse is enforced to protect the community and its standards. If you see this, let the IPAAA know and we will get the lawyers on it.

Leave a comment

Thanks for sticking with me through this series. If you’ve missed any parts, I’ve linked them below so you can follow the trail of dysfunction:

🔗 Part 1 – Fragmented Camps
🔗 Part 2 – No Standard, No Baseline
🔗 Part 3 – Blame Culture
🔗 Part 4 – Dogma, Ego, and Status
🔗 Part 5 – Certification Scam
🔗 Part 6 – The Illusion of Agility

Now, let’s recap.

Why the Agile Market Is Rotten at its Core

1. Everyone fights for their patch.
In Part 1, I called out the fractured and tribal state of the Agile marketplace. Agile is no longer one community. It’s splintered into camps such Scrum, SAFe, Kanban, XP, and dozens of niche methods. Each claiming superiority, defending their turf, and refusing to collaborate. Instead of advancing the profession, they bicker, compete, and sabotage any hope of unity. What started as a shared movement has become a noisy battleground of consultants, empires, and thought leaders fighting for attention and market share.

The result? Confusion. Division. Stagnation.

We’ve traded progress for personal brands. The agile market isn’t evolving—it’s fracturing. And in the noise, people new to Agile are left lost, misled, or exploited. This isn’t thought diversity. It’s a disorganised mess that’s tearing the industry apart.

2. There is no standard, and no baseline.
In Part 2, I tore into the fact that Agile has no real standards. Anyone can call anything “Agile” and get away with it. There’s no baseline, no guardrails, no shared expectations. Just buzzwords, frameworks, and personal interpretations. We’ve normalised chaos and labelled it agility. And because there’s no standard, bad ideas flourish and good practice gets drowned in noise.

The result? A marketplace where junk gets sold as innovation. Teams are left guessing. Leaders are sold smoke. And the industry keeps turning in circles. If Agile had a standard, we’d at least know what we’re arguing about. But right now, it’s a free-for-all where the people who suffer most are the ones trying to do the work.

3. We reward blame and fear.
In Part 3, I exposed how Agile has become a blame machine. When things go wrong, teams get blamed. Coaches blame leaders. Leaders blame teams. And everyone blames the framework. Instead of owning outcomes, we point fingers, hide behind ceremonies, and protect reputations. Retrospectives become performance reviews. Psychological safety is just a slide on a deck. No one’s learning—just surviving.

This culture of blame kills trust, kills improvement, and kills agility. People are too afraid to speak up or experiment. Failure isn’t a chance to learn, it’s a career risk. And the worst part? We still pretend it’s working. Agile promised empowerment. What we got was deflection, fear, and finger-pointing.

4. We worship frameworks and figureheads.
In Part 4, I went after the ego and dogma poisoning the Agile space. Too many so-called experts act like gatekeepers, treating their favourite framework as gospel and shutting down anything that doesn’t fit their narrative. It’s not about helping teams. It's about being right, being followed, and being seen as the authority. Agility has been hijacked by personalities more interested in status than outcomes.

This obsession with being the smartest in the room is killing progress. We’re not solving problems, instead we’re arguing over methods, titles, and who’s more “agile”. The humility and curiosity that once defined the movement are gone. In their place? Fragile egos, shallow thinking, and a market driven by noise, not knowledge.

5. Certification has become a joke.
In Part 5, I ripped into the Agile certification scam. Pay a fee, sit a quiz, walk out with a shiny title where there is no real skill, no real test, no accountability. It’s a cash machine, not a profession. We’ve flooded the market with underqualified “certified” practitioners who can’t deliver but still claim authority. It’s a joke, and everyone knows it.

This mess has trashed Agile’s credibility. Leaders don’t trust the titles. Teams don’t respect the roles. Real professionals are lumped in with the fakes. And the worst part? The industry lets it happen because it’s profitable. Mastery has been replaced with marketing, and the cost is being paid by every organisation that believed the hype.

6. We’ve lost the plot entirely.
In Part 6, I called out the illusion of agility. Teams adopt standups, boards, and new job titles and think they’re Agile. But nothing really changes. The same dysfunctions stay but with low morale, poor delivery, leadership confusion. We copied the rituals but skipped the thinking. Agility became theatre, not transformation.

We’ve been fed vague concepts with no substance, then left to figure it out alone. There’s no real help, no practical how-to, just buzzwords and false confidence. And when it doesn’t work, we blame the teams. The truth is, Agile was never going to work like this and deep down, we all know it.

The Nail in the Coffin

Agile was founded on a simple idea:

"We are uncovering better ways of developing software by doing it and helping others do it."

That’s the first line of the Manifesto.

But let’s be brutally honest. As a market, we are not doing that to fix these systemic issues.

We are not uncovering better ways.
We are not doing it.
We are not helping others do it.

Instead, we’re selling buzzwords, protecting turf, and propping up hollow reputations. The dysfunction is systemic. The silence on how we address these systemic problems from the so-called agile masterminds, the very people who wrote the Manifesto is deafening.

We are taught to help companies to inspect and adapt. But it refuses to do that itself.

The industry tells teams to focus on outcomes. But itself worships process, frameworks and appearance.

The industry tells people to be transparent. But it hides behind brands, titles, and rhetoric.

It’s a con.

A slow, corrosive rot that’s eroded trust, credibility, and any hope of true progress.

The agile market cannot fix itself because it refuses to admit it’s broken.

Trying to change it doesn’t work. Too many people are guarding their turf with a fortification mindset. Rebuilding consumer trust is impossible while bad actors still exploit the system. Ignoring it and letting it continue is a race to the bottom and will not end well for everyone.

But companies still need to build and deliver products. They still need help to be effective. Right now, they’re more confused than ever. Some are even reverting to waterfall or hybrid approaches, which is alarming.

So maybe it’s time to stop trying to save it.

Let it end. Let the market collapse under the weight of its contradictions. Let’s clear the ground so something real can be built again. Let’s learn from all of this and make sure it does not happen again.

Just people who actually care about quality, delivery, value, and each other. People who want to move the industry forward. People who want to bring credibility back so they can truly help their customers or employers.

That’s where I’ll be. If you’re tired of the noise and ready for something better, come join me. We're not fixing agile. We’re building something new. Together.

It’s about being Practiqual.

They said, “Just adopt Agile or Scrum.” So we did. And everything got worse.

A team makes the switch. Standups begin, Jira boards go up, job titles change. But nothing really changes, and there’s still no agility. Morale remains low. Leadership is still confused. The business is still angry. Agile was supposed to fix this. But it didn’t. And the truth is, it never could, not the way we did it.

People copied the practices, turned them into rituals, and completely missed the meaning.

The agile marketplace offered vague ideas and abstract concepts but little practical help. No strong foundations. No shared starting point. Just high-level principles and hollow slogans like “every team is different” or “you’ll figure it out.” But most teams never did. What they needed wasn’t more freedom. They needed clarity, structure, and guidance.

Take the Scrum Guide, for example. It’s extremely powerful if you’ve been in the industry a long time and understand the science behind it. But for a new company just starting out with Scrum, it’s useless. Too vague. No practices. No real guidance. Just concepts, and even those are ambiguous. That’s where many of the dysfunctions began.

Instead, our consumers and many practitioners were thrown into a world of confusion and frustration.

We treated Agile like a buffet. Everyone picked what suited them. Coaches made things up as they went, often echoing others who did the same. Companies sold frameworks and transformations. Leaders chose what felt comfortable, thinking that meant they were being agile. There were no standards, no accountability, just opinions dressed up as expertise.

The market rewarded mimicry over mastery. Selling was valued more than substance. And we all fell for it.

Let’s be honest. This mess isn’t just the fault of a few bad actors. It’s systemic. We all played a part. Executives who wanted agility without change. Managers who said “servant leader” but still micromanaged. Teams that accepted dysfunction. Coaches who stayed quiet to protect their contracts. Trainers loyal to their brand. Practitioners improvising and doing what felt right.

The whole thing became a performance. Something we pretended was real. But it wasn’t.

So let’s stop pretending.

Agile isn’t failing because people are incompetent. It’s failing because the market is broken. It has been designed to look agile without actually being agile. And it has been like that for years.

We didn’t build real capability. We sold the illusion of it. This is a young marketplace, still in its infancy and stuck in the wild-west phase with no history to ground it.

And when it failed, we blamed the leaders, the teams, the frameworks. We sent them on another course. Pushed a different framework. Handed out another badge. But the real problem was never inside the team. It was around them.

This isn’t something we can fix with small tweaks. It needs a complete reset. That’s why I built Practiqual.

Because people aren’t the problem. The systems they’re placed into are.

And unless we’re willing to stop faking change, we’ll keep failing for all the same reasons.

Let it fall apart. Then let’s rebuild with integrity this time. Let’s uphold standards of excellence in a professional way. Let’s create safeguards to stop the mess from happening again. And let’s protect ourselves from the sharks, the money grabbers, and those who would drag our market and profession into disrepute.

Series posts

Read other posts in this series

Rotten Agile: Part 1 – Fragmented Camps, Conflicted Market

Rotten Agile: Part 2 – No Standard, No Safety

Rotten Agile: Part 3 – Blame Culture and Broken Credibility

Rotten Agile: Part 4 – Dogma, Ego, and Tribalism

Rotten Agile: Part 5 - Certification Scam

Rotten Agile: Part 6 – The Illusion of Agility

Rotten Agile: Part 7 – The Nail in the Coffin

The agile certification market is broken—and everyone knows it.

You take a two-day course, sit a multiple-choice quiz that barely tests comprehension, and walk out calling yourself a “Scrum Master.” No real-world application. No experience needed. No professional oversight. Just a certificate and a new title. That’s not mastery. That’s marketing.

This is how we ended up with thousands of underqualified practitioners being handed the responsibility of changing entire organisational operating models. It’s no surprise leaders don’t respect Scrum Masters or agile coaches. They’re seen as amateurs because too often, they are. The market is flooded with people who don’t understand complexity, change, or even how to read a room, yet are expected to influence strategic direction. It’s a farce.

And it gets worse. The good experienced professionals with genuine capability are indistinguishable from the rest. Their credibility is dragged down by a certification model that rewards attendance, not competence. It’s guilt by association.

The root problem? A complete conflict of interest. The same bodies that create the frameworks, creates the courseware, run the training, also issue the certifications, and profit from both. There’s no separation of concerns. The Australian Competition and Consumer Commission (ACCC) and ISO have clear guidelines around certification marks to avoid this exact conflict. That is the certifying body cannot profit from training, consulting their own product. The agile market ignores that as profit comes first.

We’ve built an entire supply chain on low-bar entry: high demand, fast-track certifications, and a constant stream of “certified” professionals entering the market. The result is oversaturation. There are too many coaches, too many “Scrum Masters,” and very few who know what they’re doing.

Worse still, there’s no consistency. Everyone has a certification, but no shared standard. One person’s definition of “agile” contradicts another’s entirely. Take Scrum for example, you have Scrum Alliance, Scrum.org, Scrum Inc and then Scrum Study — they all have their own courses and own certifications. The consumers, business leaders, individuals are left confused, burnt, and rightly skeptical. But this is not just Scrum, it is across the entire agile spectrum and also the technology sector too.

The market is unregulated. There’s no central standards body, no professional licensing, no code, and no agreed criteria for capability. That vacuum allowed the entire system to run unchecked, encouraging profiteering over professionalism.

Individuals who’ve spent years and thousands of dollars building careers in agile now find their value eroded. Not because agile is no longer valid, but because the market has been diluted, oversaturated with low-skill practitioners with inconsistency, and conflict. There are no standards to protect those who do the job well, or the businesses who rely on them. Individuals with “high level” certifications cannot even get an entry level job. Top trainers struggle to get work in jobs they used train people to do. When they get a job, the business ignore don’t trust their experience.

And the mechanism itself is flawed. “Certification” is almost entirely theoretical with just a basic knowledge checks wrapped in a multiple-choice test. No demonstration of competency. No experience required. No validation of whether someone can lead, adapt, influence, or deliver. But they still walk away with a shiny certificate. It’s a pay-to-win model that is exploiting consumers.

Right now the agile marketplace is in infancy and the wild-west where snake-oil salesman are profiteering from selling the potions and tonics. Medicine, Engineering, Accounting, Construction, Law began unregulated, chaotic, or loosely structure before eventually creating formal governing bodies and codes of ethics.

We didn’t raise the bar. We need consumer protection. We need to stop these wild-west behaviour, grow-up and model around professional industries where the member professions are professionals. Where people collaborate to move the industry forward.

Practiqual™ provides an ecosystem designed to change the game. It separates the approach and training from certification, breaking away from the profit-driven model that undermines quality. Certification under Practiqual is fully independent and adheres to ISO and ACCC standards that exist to protect consumers. These standards are set deliberately, with consumer protection at their core. That is to protect you and your customers or employers.

The Practiqual Approach™, built around its Build-Your-Own (BYO) Framework, is community-owned, community-curated and community-maintained. Training is also managed by a community of trainers who own that content and delivery. Certification and assessments are rigorous but fair, demanding real-world application and experience. These assessments are administered independently to ensure integrity of the system.

To further protect the public, legitimate certification marks are backed by strict legal requirements for the assessing body. A professional code of ethics underpins the whole system, encouraging collaboration and mutual respect among practitioners.

Personally, I Brett am tired of the scam as I have been caught out a few times in my career. I am now on a mission to stop this scam behaviour, bring back credibility and legally protect the marketplace so this behaviour ends. Not ideas, I have hired a legal firm to help set this up. The more I have been digging, the more dysfunction I see and am just asking your to open your eyes and see the mess in the agile marketplace (not agility).

Series posts

Read other posts in this series

Rotten Agile: Part 1 – Fragmented Camps, Conflicted Market

Rotten Agile: Part 2 – No Standard, No Safety

Rotten Agile: Part 3 – Blame Culture and Broken Credibility

Rotten Agile: Part 4 – Dogma, Ego, and Tribalism

The agile marketplace isn’t just fragmented, it’s eating itself alive. What should be sharp, healthy debate has descended into tribalism, grudges, and ideological turf wars. Improvement is no longer the goal. Instead, we see camps defending territory, attacking rivals, and clinging to market share.

Many professional trainers, PSTs, CSTs, RSTs are deeply capable, with rich experience. But they’re often treated as enemies. Not because of what they teach, but because of which logo sits on their profile. It’s not about values or evidence. It’s about loyalty. For years, being both a PST and a CST was prohibited. Why? Not due to ethics or pedagogy, but because of a personal feud between Ken Schwaber and the Scrum Alliance leadership at the time. That’s not integrity. That’s dogma.

And that’s the only problem. When disagreement turns into heresy, evolution stops. Frameworks become belief systems. Trainers become gatekeepers. Anyone who questions the doctrine risks exile. It’s a staggering contradiction in a field supposedly built on adaptation and learning.

You also see this mindset echoed in initiatives like Agile 2 and Amplio. These aren’t just alternative views, but they’re designed in directly attack Scrum. The messaging isn’t about advancing agility. It’s about tearing others down. The tone is bitter, the critiques personal. There’s no curiosity. No learning. Only resentment. Challenge their ideas and you won’t get a thoughtful response, you’ll likely get retaliation.

When SAFe entered the scene, it didn’t arrive as a collaborator. It came to dominate. The approach was launched aggressively, with little interest in working alongside others in the field. It wasn’t about solving the real scaling challenges customers were facing. It was about owning the market. And the agile marketplace didn’t take it lightly. The reaction was defensive, even hostile. What followed wasn’t constructive dialogue, but with a backlash. Instead of uniting around the shared challenge of scale, the market fractured further, driven more by competition than collaboration.

This kind of ideological warfare poisons the well. Professionals who genuinely want to help teams and customers are forced into silos. Respect is replaced by suspicion. Curiosity gives way to brand loyalty. Each camp believes it holds the moral high ground. Everyone else is painted as corrupt, incompetent, or dangerous.

What we are seeing is brand warfare, dressed up in a language of improvement. Many claims are made without substantiated data and facts. Often these attacks are followed by selling their own product which is ethically questionable. And don't get me started on people who repeatedly call out dogma. What they never seem to realise is that their own ideology is just another dogma in disguise.

To those looking in from the outside, it looks like chaos. A profession at war with itself. Fractured. Defensive. Contradictory. What executive would trust a field that behaves like this?

Architecture, scientific research, aerospace and even accounting are all competitive fields with strong opinions and high stakes. But they’re underpinned by mutual respect. Professionals may disagree, sometimes fiercely, but the goal is to push the field forward, not to guard turf. Disagreement isn’t treated as a personal attack. It’s part of the process. You challenge ideas to improve them. You argue to learn. That’s how progress happens. Agile should be no different.

In contrast, agile argues to win.

Tribalism, fuelled by dogma and ego, isn’t just unprofessional, it’s destructive and unsustainable. If we want the agile industry to survive, we must call out posturing for what it is and rebuild a culture grounded in critical thinking and mutual respect. Loyalty must give way to learning. Rivalry must be replaced with rigour.

Tribalism, Dogma is rife in the agile market and a systemic problem. It’s not going to go away - there is too much bad blood.

Practiqaul™ is different. The community co-creates everything, the approach, the patterns, the courseware, and the toolkits. There are no turf wars here. There are no organisation is trying to outshine the rest. We don’t compete over whose framework is better. We focus on what works.

Practiqaul™ offers a guiding approach, not a rival product. Companies aren’t expected to adopt a one-size-fits-all framework. They build their own frameworks, shaped by the Practiqaul™ concepts and structures. They’re free to choose a flow-based model, and blend in ideas from Scrum, or even draw on scaling patterns. It is whatever fits their context. What matters is not branding. It’s more about fit-for-purpose thinking. There’s no need to defend a framework. Just the freedom to build what works for your customers or employer. That’s the a big difference.

Before you ask, I am not selling frameworks, training or consulting, but attempting to address serious dysfunction in the agile marketplace. If you become a member, you with other community members own the approach and practices. I will explain protection role of the IPAA role at a later date, it’s a complex topic - so please don’t jump to conclusions yet.

Are you over the agile circus too?
I’m gathering voices who want to step off the merry-go-round. If that’s you, comment below or message me privately. Let’s talk about what’s next as I am in startup phase.

Series posts

Read other posts in this series

Rotten Agile: Part 1 – Fragmented Camps, Conflicted Market

Rotten Agile: Part 2 – No Standard, No Safety

Rotten Agile: Part 3 – Blame Culture and Broken Credibility

Rotten Agile: Part 5 - Certification Scam

You’ve probably heard these before:

• “The teams can’t improve because management won’t let go.”

• “Management just doesn’t get Agile.”

• “Scrum doesn’t work for us – it’s too rigid.”

• “You’re not doing Scrum properly.”

• “Product Managers are not Product Owners.”

• “The problem is all these two-day certifications lowering the bar.”

• “Teams aren’t taking ownership.”

• “This organisation has a bad culture for Agile.”

• “The business keeps interrupting our sprints.”

• “It’s Scrum’s fault.”

• “SAFe isn’t Agile.”

This list could go on. What these statements have in common is blame. It’s everywhere. Any challenge, deviation, or disagreement quickly becomes weaponised.

The Agile market has developed a culture of criticism, defensiveness, and entrenchment. Most blogs and thought pieces are filled with blame, whether of frameworks, roles, companies, or each other.

These complaints often stem from real issues. But they become excuses. Easy ways to avoid responsibility. Everyone becomes a victim of a flawed system. No one steps up to own the outcome. Rather than foster collective learning and adaptive change, the conversation spirals into finger-pointing.

This behaviour contradicts what Agile claims to stand for. The same coaches who teach psychological safety, productive dissent, shared understanding and respect fail to model those behaviours in the wider community. We preach collaboration but attack each other. We talk about safety and respect, but don’t practise it ourselves.

We’ve also lost track of the customer and helping them succeed. It’s become about doing Agile right, not delivering better outcomes. It’s become about which framework is better. The customer got lost in the noise.

On social media, posts are no longer constructive. The majority are criticisms of what’s gone wrong. Really? Is this who we are? Okay, I see the irony. My post is a criticism too.

From the outside, especially to executives, the Agile community lacks credibility. It looks like a group of clowns arguing over who’s more right. That doesn’t inspire confidence. It erodes trust. No wonder more organisations are walking away.

Agile started with the right intent. It aimed to help organisations deliver better outcomes and work in more human ways. But in practice, it’s become noise, ego, and infighting. As the market contracts, it only gets worse. Everyone is defending their frameworks, products, and personal brand.

This isn't a tooling problem. It’s a behavioural one. It is tied directly to the Agile brand. No amount of rebranding, new frameworks, or certifications will fix it. The damage is systemic. Many of us helped create it, even if unintentionally.

Maybe it’s time to let the Agile brand rest. Not because the ideas are wrong. But because the market has become too toxic to heal from within.

I don’t believe a patch in the Agile market will cut it. The brand has eroded too far, and the behaviours are too ingrained. We have to break free of this, raise the bar, and reclaim a professional standing.

Practiqual™ is there to help solve this problem. But it won’t be easy. Many of us have been caught in the bad behaviours for years. Habits have formed. I know because I struggle with it too.

The Practiqual™ community has a code of conduct that directly addresses these challenges, and every member must subscribe to it. Mistakes will happen. We’ll fall down. But we hold each other accountable. Let’s fix this together. Let’s stop being negative. Lets show conviction with unity to help others succeed. Let’s walk the talk!

Are you over the agile circus too?
I’m gathering voices who want to step off the merry-go-round. If that’s you, comment below or message me privately. Let’s talk about what’s next as I am in startup phase.

Series posts

Read other posts in this series

Rotten Agile: Part 1 – Fragmented Camps, Conflicted Market

Rotten Agile: Part 2 – No Standard, No Safety

Rotten Agile: Part 3 – Blame Culture and Broken Credibility

Rotten Agile: Part 4 – Dogma, Ego, and Tribalism

Rotten Agile: Part 5 - Certification Scam

Unlike mature professions, the agile marketplace remains unregulated. There is no governing body or licensing authority comparable to bar associations for lawyers or medical boards for doctors. This means anyone can claim to be agile. While this openness encourages innovation, it also allows unskilled or unethical practitioners to cause harm, eroding trust and safety for clients.

Community-led efforts to address this are still in their infancy. Groups like the Agile Alliance have begun drafting voluntary codes of ethics. But adoption is scattered, and there is no enforcement mechanism to remove bad actors.

Unfortunately, this is by design or rather, a lack of design. It started with good intentions, hoping people would follow values and principles. But in a commercial, dog-eat-dog world, the opposite happens, and those good intentions are lost. There was no protection built in at the beginning, and it allowed exploitation to occur.

Without oversight, protection mechanisms, quality control is left to market forces and personal reputation. Anyone can present themselves as an expert, armed with little more than jargon. The burden falls on hiring organisations to assess credibility, and they are not doing a good job of that either.

As for consumers, anyone can claim to be “Agile”, as there are no standards and it can mean anything to anyone. No one is being held to account for that. At its core, the market model erodes credibility, destroys trust and encourages exploitation.

There are no fixed entry requirements or standard benchmarks. Take Scrum, for example. There is Scrum.org, Scrum Alliance, and Scrum Inc. But then there are others that leverage the brand, like ScrumStudy, SAFe, and PMI (formerly DA). This fragmented landscape adds to the inconsistency. Each has its own definition of what Scrum is, and each runs its own self-governed certification programs that compete with one another. I will discuss the certification-mill in another post.

Without a regulatory body, there is no common understanding. There is no standard. There is no accountability. There is no ownership. The result is variability and opportunism.

Organisations have taken notice. Several are walking away from agile altogether, as they are not getting the guaranteed “certified” expertise they need. They are not getting a return on what they were promised. When business leaders look at agile, they see a marketplace full of infighting, bad-mouthing, and inconsistency. Any sensible business person will look at that and think, “not for my business, no thank you.”

This fragmentation has increased ambiguity, where critical concepts are ignored or completely altered. It leads to differences of opinion, which causes fortification and conflict, resulting in unprofessional behaviour. This fragmentation has heavily contributed to the agile warzone, agile tribalism and dogma.

This reflects a broader crisis of confidence, rooted in the profession’s lack of formal accountability. People struggle with the idea of accountability, as there are far too many opinions about what that accountability should or should not be.

The agile market lacks oversight, governance, and an authoritative body to maintain standards. The market lacks ownership and accountability. The market lacks integrity. There is no credibility in the market.

Can this be fixed? No. You will not get organisations like Scrum.org, Scrum Inc., Scrum Alliance, and ScrumStudy to establish a shared, independent, and neutral standards body. Their businesses are coupled to a certification mill, which is about driving sales, training and leveraging on the word “certification”. Sadly this model is not a real certification model, its a marketing mill.

Agile will eventually crash and burn. I would rather learn from the past and fix the wrongs. The Agile marketplace needs to end and a new professional market emerge that is not associated with a tarnished brand.

Practiqual™ is a clean reset. It does not join the noise. It steps away from turf wars, personality cults and commercial empire-building. Instead, it offers a fresh foundation. One built on integrity, clarity and shared professional standards.

Practiqual™ introduces a code of practice that the profession values and upholds. Not because it is imposed, but because it is built together and reinforced by shared accountability. But in a world where bad actors exist, good intent is not enough.

That is why an independent, neutral body will be established to safeguard what the community builds. This body, the International Practiqual Accreditation Authority™ (IPAA), will not sell training, consult or compete commercially. It does not promote particular content or prescribe specific methods. Instead, it focuses on making sure the standards process is fair, transparent and respected.

The IPAA protects everyone involved. It helps preserve public trust, respects trade secrets and supports the secure development of ideas. Its role is to uphold the integrity of the system. Not to shape its direction. Independence is not optional. It is structural.

Are you over the agile circus too?
I’m gathering voices who want to step off the merry-go-round. If that’s you, comment below or message me privately. Let’s talk about what’s next as I am in startup phase.

Series posts

Read other posts in this series

Rotten Agile: Part 1 – Fragmented Camps, Conflicted Market

Rotten Agile: Part 3 – Blame Culture and Broken Credibility

Rotten Agile: Part 4 – Dogma, Ego, and Tribalism

Rotten Agile: Part 5 - Certification Scam

Fragmentation destroys coherence, and without coherence, no profession can mature.

One of the most damaging forces in the agile world today is fragmentation. The market has splintered into rival camps each battling for influence, recognition, and commercial dominance. Every camp insists that their version of agility is the right one. In doing so, they’ve pulled the profession apart.

Even within Scrum there’s no unified voice. Scrum Alliance, Scrum.org, and Scrum Inc. each offer different certifications, interpretations, and training pathways. Then there are opportunistic players like ScrumStudy, who created their own “Scrum Body of Knowledge” (SBoK). Their version strays so far from Scrum’s roots that it actively contradicts the very principles it claims to promote. These differences aren’t academic, they are competing, often incompatible, models trading under the same name.

Across the broader agile landscape, the problem only deepens. Frameworks like SAFe, LeSS, Kanban, ICAgile, Disciplined Agile, and PMI-ACP all present different philosophies, practices, and credentialing schemes. While they often borrow the same language, the meanings don’t align. One framework may celebrate a practice that another condemns. What’s taught as “best practice” in one course is labelled “harmful” in another. The result is contradiction packaged as clarity.

This inconsistency breeds confusion and opens the door to misinformation. Instead of a maturing discipline, we have a commercial free-for-all. For every article offering guidance, another counters it. For every practitioner recommending one method, another publicly dismisses it. These aren’t productive debates, instead they’re turf wars. And they’re tearing the profession apart.

The cause is simple: no shared governance, no agreed-upon standards, and no external accountability. Anyone can create a framework, issue a credential, or claim authority without oversight, peer review, or consequence. The hope that professionalism would regulate the market has failed. Commercial self-interest filled the gap. Promotion replaced principle. Posturing replaced progress.

And many have built businesses on this dysfunction. Differences are sold as innovations. Their approach is presented as the truth; others, as dangerous. It’s not about improving practice, it’s about capturing market share. The result is a flood of conflicting messages, underqualified practitioners, and fatigued customers who no longer know who to trust.

Even Agile’s founders have spoken out. Kent Beck, co-author of the Agile Manifesto, called the certification boom dishonest; likening it to a pyramid scheme and describing it as “a cancer” on the movement. When Agile originators speak bluntly, it’s a warning worth heeding.

Agile is not a unified profession. It’s a contested marketplace, where alignment is seen as weakness and fragmentation is mistaken for choice. Instead of improving how we build products, we’re fighting over which brand of “agile” should win.

And we must own that. This dysfunction isn’t external because it’s built into the structure of the market itself.

At this point, the fragmentation isn’t accidental. It’s deliberate. It’s a business model. Too many empires rely on owning their slice of the market. They treat difference as threat and division as brand differentiation. There’s no incentive to unify, no will to align, and no shared sense of professional responsibility.

Practiqual™ is a clean reset. It’s not entering this contest. It’s stepping away from it. It rejects the noise, the turf wars, and the empire-building. Instead, it offers a new foundation. One where shared understanding is possible, legitimate differences are respected, and healthy businesses can still thrive. Without tearing the profession apart.

Practiqual™ sets up an ecosystem, not an empire. It is a community-owned and legally protected approach. Members shape it together for the good of the profession. Each is an independent business. They are free to price, deliver, and adapt in ways that make sense for their situation. At the same time, they follow a shared code of conduct, apply common principles, and contribute to open knowledge. This balance of independence and integrity removes exploitation. It ends turf wars. It restores professional respect. Practiqual is not about control. It is about moving forward, together.

Are you over the agile circus too?
I’m gathering voices who want to step off the merry-go-round. If that’s you, comment below or message me privately. Let’s talk about what’s next as I am in startup phase.

Series posts

Read other posts in this series

Rotten Agile: Part 2 – No Standard, No Safety

Rotten Agile: Part 3 – Blame Culture and Broken Credibility

Rotten Agile: Part 4 – Dogma, Ego, and Tribalism

Rotten Agile: Part 5 - Certification Scam