The Phenomenon of Prevalence Induced Concept Change

In organizational change, people may respond to improvements in unexpected ways - even though things are getting better, they may be under the impression that things are getting worse - and they may even have data to back up their claims! So, how do you get out of the dilemma of having to justify improvement without starting a theoretical debate detached from what people see, hear and feel?
In this post, we will take a peek at a typical case of Prevalence-Induced Concept Change (PICC) and how to address it in a constructive manner.

What is Prevalence Induced Concept Change?

"Prevalence induced concept change" (PICC) occurs when the frequency of events changes, leading people to modify their definition of what constitutes a problem. This shift in criteria means that as major problems become less common, minor topics start to gain more attention and are perceived as more significant than they actually are - or in reverse!

We will take a common example connected to "Agile Transformation" to illustrate our case - although you may encounter PICC in many forms and shapes.

Transitioning from Classic Project Management

In Classic Project Management, we have our ways of doing things, and everyone knows that nobody's perfect, so there are always some concerns. But, we have arranged ourselves with them, understand them, and how to manage them.

Classic Project Management

• Long-Term Schedules - Projects span several months, with a final delivery date set well in advance. The impact of missing a timeline tends to be massive, and a slippage in schedules requires serious management attention.
• Delayed Feedback - The first feedback comes on "Release Day," and the events on that day tend to be overwhelming due to the sheer volume and severity of problems that went undiscovered during the project.
• Hidden Issues - Problems remain undiscovered until late in the process, making them costly and difficult to address.

And now let us contrast that with a more modern approach.

Modern Delivery Approaches:

• Rapid Cycles - Large projects are divided into short cycles, with intermediate evaluation points.
• Frequent Feedback - Developers receive timely feedback on completed work in small batches.
• High Transparency - Problems are identified and addressed quickly, promoting continuous improvement.

This leads to many follow-up questions: First, how do we even work in a way that we can collect feedback faster - and second, what do we do when we get "bad feedback?" Especially in organizations where Continuous Improvement is not systematized in project management, the question "what do we do with the feedback" can lead to a quagmire of followup concerns that can completely derail a team if not properly addressed.

The Impact of PICC

An organizations advancing from classic project management to a more modern delivery approach may have stakeholders fall for PICC and misinterpret the nature and frequency of what's going on:

• Buffer sizes - By slicing a large project into a sequential set of deliverables, the project gets more checkpoints, and each of them gains a small buffer. So a buffer overrun on one of them is not even an issue - the main timeline is not even in danger when a day of buffer has been consumed! However, a buffer overrun may lead managers to overreact who are used to a buffer overrun always requiring management intervention.
• Higher Expectations - With frequent deliverables, stakeholders have more time to focus on individual deliverables, so they will pay more attention to minor issues they would never have noticed in a project where it was normal that half the scope was unusable upon delivery.
• Perceived Underperformance - A successful product review will always elicit improvement potential, and the constant appearance and high volume of new issues can be misconstrued as underperformance by a management that's used to every report being a quality flaw.

Preventing Misconceptions Caused by PICC

To prevent the misconceptions caused by PICC and ensure that successful improvements are recognized as such, it is essential to create transparency and educate stakeholders of what's actually going on:

Define the Benchmark

Highlight Changes - Frequent evaluations in modern delivery make more issues visible - but also lead to quicker resolutions and thus, better outcomes.

Differentiate Categories - Clarify that the issues reported now are generally smaller and require lower fixing efforts, unlike the severe and late-discovered issues in classic project management that often led to minor issues not even getting addressed at all!

Create Transparency

Provide Objectivity - Agree on severity levels early, and categorize issues accordingly, illustrating, for example, that whereas before, people were simply accepting showstoppers, they are now arguing about button colors.

Analyse trends - Use trend analysis to show how severity classes and quantities shift over time, demonstrating that the measurement is subtly changing.

Manage Expectations

Frame Feedback - Highlight that the feedback is now on a different level than before, and that the purpose of that feedback has also changed.

Correlate Action - Show how feedback is now differently correlated with action, and that the time between highlighting an issue and getting a fix is improving.

Conclusion

Prevalence induced concept change (PICC) can significantly impact how stakeholders perceive the success of teams. Hence, understanding that PICC is happening is a key instrument in managing change and expectations effectively. Be aware of the situation, create objectivity and transparency, then manage expectations to move beyond category errors, misconceptions and perceived deterioration.

In Scrum we do ...

"How do you do this in Scrum?" - A common question, and still: not a meaningful question. Why? Let's explore.

Scrum has no prescriptions.

Scrum is but a container, and something that works within Scrum should also work without Scrum. If that's not the case, and something only works because of Scrum - you probably misunderstand Scrum.

Does it make sense?

If something makes sense irrespective of Scrum, you may want to try it. If you believe that it has to be done because of Scrum, but your senses are tingling - they may be right.

Does it work for you?

Whatever "this" is - how are you currently doing it, and does it give you the results you're looking for? If so - why would you want to change it?

A better question

We're currently doing this, and those are the issues we're facing. How could we address these?

Whenever you hear or say, "In Scrum, we do ..." - whatever follows next is either complete and utter nonsense, or has very little to do with Scrum. Most likely, the first.

Agile vs Waterfall - the wrong question

22 years after the "Manifesto for Agile Software Development," the battle for Agile vs. Waterfall still isn't settled - despite many prominent publications, such as a recent HBR article, trying to "settle the debate."

Unfortunately, this debate can't be settled - because it starts with the wrong question. We will take a look at the question that needs to be asked.

Finding the right question

Most authors start with a question that doesn't bring us any closer to a sensible answer, quite often out of ignorance on what "Agile" is.

What "Waterfall" isn't.

Let's examine some definitions you may find floating around.

"Everything that's wrong"

Well, congratulations: with that definition, even adding too much salt to your breakfast eggs is Waterfall. Fun facts - even "Agile" doesn't prevent things from going wrong, and not even "Waterfall" projects always go wrong (would that mean that Waterfall isn't Waterfall because Waterfa ... argh, paradox!)

A sequential, linear approach from idea to completion.

That's crudely based on Winston Royce's paper from the early 70's - but face it: no company actually works like that, and even Royce wasn't suggesting that. Even "Waterfall," in industry common practice, is a continuous, incremental development approach. Just with very big increments, and extremely slow feedback cycles (it's not unrealistic that it could take 2-5 years between when a requirement is defined until people get the thing they actually need.)

A stage-gated approach to product development.

That definition has two fundamental flaws:
First, you can stage-gate "Agile" approaches as well, and before 2006 (i.e. five years after "Agile") - stage gating wasn't even a thing in most enterprises: You can well do non-Agile projects without stage gates.

You can find another, much more comprehensive article on other things that "Waterfall" is not referenced here.

So we're in a bit of a pickle: We can't even find a non-strawman definition of "Waterfall" that would go beyond the completely fictional definition used in Royce's paper for how to not do things.

What "Agile" isn't.

Let's do the same favor to "Agile" and pull out some of the common misleading beliefs floating around:

Scrum is not Agile

Hard to overemphasize this, but there are two core problems with equating Scrum and "Agile."
First, there's a boatload of terrible Scrum out there that not only doesn't qualify as "Agile," it hardly qualifies as professional.

Second, there are many "Agile" approaches out there, and even though Scrum dialects are the most common, quite a lot of agile companies don't use even Scrum.

Inadequate processes, plans, documents, or contracts

This definition of "Agile" only rings true for illiterate people who can't make sense of the statement "While there is value in these things ..." - Agile approaches make use of these things. Any argument against "Agile" referencing to Agile's inability to structure themselves is either a strawman or ill-informed.

Lack of direction or tracking

Humorously, if that's the definition of "Agile," it's not a stretch to say that most large Enterprises are indeed extremely Agile.

On a more serious note: most professional Agile practitioners will emphasize the importance of clear goals, as well as frequently checking progress on these goals.

We're stuck with the same issue: if we use a strawman definition of "Agile," then everything sensible is a better choice - but none of these definitions hold true to the intent of the Manifesto.
The best definition I can come up with today is based on the very first line of the Manifesto itself: "We are discovering better ways of developing software by doing it and helping others do it." My definition, hence, is "The ability to do the right thing right, at the right time." And with that definition, everyone who proposes anything other than "Agile" - would have to argue why it would be preferable to do the wrong thing, do things wrong, or have poor timing: I find that case extremely hard to make.

Note that this definition of "Agile" says nothing about Frameworks, Methods, Roles or any other form of rules. It doesn't even say anything about values, principles or goals. It's so broad and encompassing that the dividing line is only, "Is that right?"

So - if nobody in their right mind would purposefully do something wrong, why is "Agile" even a thing?
And that leads us to ...

The actual choice

After this introduction, we realize that choice isn't Agile versus Waterfall. It's about answering the question how we deal with things going awry. But: why do things go wrong? Let's take Mark Twain's opinion here:

This provides us a powerful reframing of the entire debate: The "things we know for sure that just ain't so" are - unvalidated assumptions. With this framing, we can rephrase the question to:

How are we dealing with assumptions?

The fundamental choice is: do we proceed based on predetermined assumptions, or do we capture evidence to validate our assumptions? And at which point do we do this?

The framing thus stops being the unfortunate false dichotomy of "Agile vs. Waterfall," it turns into:

Which mechanisms do we employ when reality contradicts our assumptions?

A classical plan-driven approach is built on three core assumptions: we are doing the right thing, we know how to do it right, and we can determine the right timing.

A classical "Agile" approach is built on the core assumption that there is uncertainty: we don't know what the right thing is, we could be doing something wrong, and the world doesn't always follow our timing. The concept is the "VUCA World."

These approaches are both extremes, and in practice, there's always a form of compromise:

• We can start with a hypothesis of what's the right thing, and when it turns out that it isn't, we need to change what we do.
• We can define how we do things, and we have to change that plan when it no longer works.
• We can schedule when we do what, and when we miss that schedule, we need to re-schedule.

Every project manager who learned their ropes will agree that even in a classical, plan-driven approach, this happens all the time. Likewise, every Agilist will concede that we need a product vision, some working agreements, and a bit of forecasting. We can also agree very easily that we need frequent inspection points and to check whether we're on track, and to change direction when that's not true. So - where does the disagreement come from?

Ultimately, we're talking about the probability that an assumption we made is wrong. How likely did we to bet on the wrong horse? How likely are we riding a dead horse? And how likely is the race not going as planned?

Statisticians understand that probabilities aren't 0 or 1, but somewhere in-between. Depending on how likely an event is, we should use practices appropriate to deal with the uncertainty. And depending on how far away an event is, the less likely we can predict it. Hence, the actual question becomes:

How do we deal with uncertainty?

The answer to this question is extremely contextual. We only know that rigid practices without flexibility will be more problematic when we ran into something that we didn't expect - and being so flexible that we can't make any form of prediction isn't sensible, either.

Summary

The question that we should be asking is how much it will cost us to learn that we are wrong? When the answer is tolerable, we are doing okay. Otherwise - we are gambling.

And in some cases, it could be the most wrong and costly thing to not have a detailed long-term plan. Even though that's not considered to be very "Agile."

The OPEN Transformation Roadmap

When looking at SAFe's "Implementation roadmap," we basically see "Training, training, training, training, do something, training, training, training, bye - have fun!" That looks great if you're a trainer - but it has little to do with how I, as a coach, perceive the journey of organizational change.
In this article, I'm trying to give you a short summary on how I personally perceive a change initiative - with "OPEN Transformation roadmap!"

Organize
Group	Activities	Objective
Change Direction	Formulate Change Objectives Coalition Formation	A guiding coalition that agrees on clear, relevant change objectives.
Change Planning	Change Backlog Change Coordination Organize Calendar	An overview of the predictable activities - what, when and by whom.
Knowledge Foundations	Basics Training Self-Study Q+A Sessions	Everyone has a fundamental understanding of the changing principles, practices - and what it means for them.
Role Alignment	Role Clarification Coaching Touchpoints	Those actively leading and conducting the change understand their roles and responsibilities.
Prepare
Flush the System	Identify hindering Tasks, meetings, roles & responsibilities Identify incompatible Incentives & Measurement Categorize current hinderances Determine flushing actions	Hindrances to change and suitable resolutions are identified, and resolution begins.
Change Overview	Problem-Solution Fitness Assessment Change Recommendations Extend Change Backlog	There's a map connecting Status Quo, change opportunities and the desired future state.
Team Preparation	Team Structure Planning Working Environment Setup Tooling Configuration Calendar Revamp Kick-Off Event	Teams are known and have the necessary means to get started.
Content Readiness	Content Preparation Feature Refinement Establish Backlog	Content and backlog items are prepared, refined, and established to start development in the new ways of working.
Execute
Event Setup	Establish Events Prepare Events with Role Holders Coach-led Events Team-led events with Coaching support	Events are set up, facilitated, and embraced by the people doing the work. Collaboration, transparency, and continuous improvement thrive.
Continuous Support	Daily I&A Sessions	Regular sessions where the change coalition reviews and adjusts their ongoing application and learning on the new ways of working.
Next Steps
Ongoing Support	Active Coaching Disengagement On-Demand Coaching	People receive Coaching support to address situational challenges and needs.
Change Review	Change Benefit Analysis Closing Assessment Further Recommendations Update Change Roadmap	The current state is transparent, recommendations for adjustment and further change are acknowledged and pursued.
Conclusion	Celebration Retrospective Wrap Up	The Adoption itself is concluded, and the organization continues on their Continuous Improvement and Learning Journey.

And yes, the acronym was chosen deliberately: First, it's catchy and memorable. It radiates confidence that we know what we need to do. And most of all: it makes explicit what needs to be emphasized: The "roadmap" itself is OPEN, and it leads ... into the OPEN!

10 signs that your Transformation has failed before it started

"Agile transformation" is a popular buzzword these days, and the promises improved efficiency, better collaboration, and increased customer satisfaction are too hard for any enterprise to ignore. However, the transformation journey is not without its pitfalls. Let's take a tongue-in-cheeck snipe at some of the common causes of transformation failure.

You Know That Your Agile Transformation Has Failed Before It Started, If you...

Brought in consultants to prescribe the details of what everyone must do, when and how.

An Agile transformation doesn't come with a one-size-fits-all approach. When consultants define roles and processes without considering the unique challenges and context, we'll get a "square peg, round hole" solution. Successful transformations rely on collaboratively progressing on the Agile journey, letting teams experiment and adapt based on their own understanding and experience with a continuous interplay of opportunity, ideas, execution and feedback.

Spend more time documenting the Future Mode than experimenting or talking to people.

Agile transformation is about establising a habit of growth and learning based on iteration and continuous improvement. An overreliance on assumption-driven documentation without enough actual interactions and experiments achieves the opposite.

Already know the perfect solution, before having made a single change.

Agility is only required because we have to deal with uncertainty. An agile approach needs to acknowledge that perfect solutions rarely exist. Assuming that a "perfect" solution can be found without experimentation, learning or adaptivity will lead to missed opportunities for improvement and won't make the future organizational system any more flexible.

Can show the future on a slide deck, but not in a team.

Agile transformation is built on "individuals and interactions," not on a top-down declaration by some smart folks who know it all. A vision that exists only on a slide deck without any backing of teams who can tell "war stories from the trenches" doesn't instill much trust.

Have defined the correct process that everyone just needs to follow.

Rigidly following predefined processes is what got us into the mess that agility tries to address by fostering adaptability and flexibility. Imposing a "correct" process without degrees of freedom undermines autonomy and the opportunity to take advantage of domain specific benefits, leading to decreased motivation and ultimately, failure to realize any significant improvement potential.

Declare a mandatory universal "Agile Standard" for all teams.

Each team and organization has its own unique challenges, needs and potential. A one-size-fits-all Agile standard that disregards context stops teams from effectively practicing Continuous Improvement. Successful agile organizations treat the diversity of teams as an advantage.

Consider teams deciding their own ways of working to be a problem.

Empowering teams to self-organize and make decisions that impact their work is the means by which organizations reduce risk of failure and coordination overhead. Treating team autonomy as a liability annuls this advantage.

Apply so much rigor that Team Retrospectives don't let people change, experiment, or learn to do it better.

If the rigor and formality tells team members that their ideas aren't welcome, they'll quickly stop highlighting opportunities for improvement. When teams can't figure out how to improve in their context, "Agile" will merely become a new status quo without any sustainable benefits.

Believe that "people are doing it wrong," without giving them any leeway to do it better.

Agile transformations often involve a shift in thinking and culture, not just the mechanics of Agile practices. Blaming individuals without understanding the systemic barriers causes demotivation and resistance. A successful transformation acknowledges that there is no single "one right" approach, and focuses on enabling teams to find what works best - for them.

Your Coaches can recite the doctrine by heart, but don't understand the psychology of change.

Coaches play a crucial role in guiding teams on their transformation journey. Reciting Agile frameworks, values or principles without understanding the human aspect of change and the psychology of team dynamics alienates people and deprives them of the meaningful support and guidance they require. Successful coaches empathize with teams, create a safe space for learning, and tailor their approach to the needs of the individuals and teams they work with.

Closing remarks

Although this list might be slightly humorous, it highlights some serious pitfalls that can seriously derail transformations. Understanding these reasons for failure will help you become more successful on your Agile Journey. Being agile, fostering collaboration, and living agile values and principles is as essential for the teams doing the work as it is for the change towards Agility itself.

Dealing with Organizational Debt

"Organizational debt" is a metaphorical term used to describe the accumulation of inefficiencies, shortcomings, and suboptimal practices within an organization over time. Similar to technical debt, it refers to the consequences of choosing expedient solutions that will require revisiting and improving the situation later on.

Organizational debt is often created by a desire to "just make it work:" when people opt for quick and convenient solutions to address immediate needs or challenges, they often ignore the long-term consequences. Effectiveness, scalability, and sustainability are often not considered in the heat of the moment. While shortcuts and compromises keep things going, a failure to address the systemic impact of these decisions will eventually take a massive toll on the organization's ability to operate efficiently and adapt to changing circumstances in the future.

"Organizational Debt" image created with craiyon.com

How can we deal with
Organizational Debt?

The following table is a guide which you can use to determine whether you have organizational debt, and how you can address it.

How to identify and address Organizational Debt

Organizational Element	Organizational Debt Indicators	Potential Remedial Actions
Purpose and Mission	Lack of clear mission statement Vague objectives or conflicting goals Disconnect between company mission and daily work	Clarify the organization's mission and objectives Communicate the mission effectively to all members Align goals across departments Identify and explore gaps between vision, mission and execution
Structure	Complex and rigid hierarchy Unclear reporting lines Overlapping roles	Make the hierarchy less felt Streamline the organizational structure Clarify roles and responsibilities
Leadership and Governance	Lack of transparency Poor decision-making processes Leadership conflicts	Foster transparent communication Implement clear decision-making protocols Address leadership issues promptly and proactively
People	High turnover rates Low employee morale Skill gaps within the workforce	Create open feedback channels to proactively resolve dissatisfaction Improve employee engagement and recognition programs Invest in training and development opportunities
Culture and Values	Unhealthy work environment Lack of shared values Lack of identification with values	Cultivate a positive and inclusive culture Reinforce core values through internal communication Lead values by example
Processes and Methods	Inefficient workflows Lack of process clarity Outdated procedures	Identify and resolve bottlenecks Frequently revisit and improve processes Document and communicate standards
Resources	Limited budget Inadequate technology Inefficient resource allocation	Analyze resource allocation and prioritize essential investments Seek cost-saving opportunities without compromising quality Embrace innovation to optimize resource utilization
Stakeholders	Poor customer satisfaction Strained vendor relationships Disengagement	Collect feedback from stakeholders and act on it Enhance customer support and engagement strategies Involve communities in decision-making
Communication	Ineffective communication channels Information silos Miscommunication	Optimize communication channels and protocols Encourage open and transparent communication across all levels Use collaboration tools to facilitate information sharing
Adaptability and Innovation	Resistance to change Reluctance to embrace new technologies Outdated practices	Foster an intrapreneurial culture of innovation and risk-taking Institutionalize grass roots innovation Invest in ongoing training and education
Measurement and Evaluation	Inadequate metrics Unsuitable performance tracking Not relying on facts	Identify relevant success metrics Conduct regular reviews to inspect and adapt Adopt data-driven decisions-making and improvements
Ethical Responsibility	Embellishing outcomes Passing the Buck Failure to address concerns	Provide "psychological safety" Encourage opennenss and non-judgmentalism Develop and promote a code of ethics

Don't hesitate to reach out if you need coaching on how to do this in practice.

Why Agile Coaches need to care about Delivery Speed

I often come across the sentiment that "Agile is not about speed of delivery." I believe that claim is a severe misunderstanding on what makes a team agile - and worse: it's already an early warning sign that at some point in the future, the Agile Coach will struggle to explain what exactly they're doing. Posing a false dichotomy between Agile and Cycle Time sets up their teams to underperform in comparison to teams coached by someone who understands both the impact of Cycle Time, and how to actively reduce it.

An Agile Coach setting themselves up for failure

Cycle Time Matters

Many traditional organizations I encounter still apply outdated delivery models, often stage-gated with various in-process queues and handovers. When a company takes half a year from demand to release - I'd say they're already well above average. In fact, a one-plus year delay from idea to value isn't uncommon. In such scenarios, managers and stakeholders often request their coaches to actively address time to market as a key success metric. For good reasons.

When we talk about agility, speed of delivery plays a crucial role. Cycle Time, which measures the time from development to production, directly impacts an organization's ability to respond quickly to customer needs, market changes, and emerging opportunities. An organization's agility is closely tied to the ability to rapidly deliver value to customers. The quicker they can do this, the more responsive and competitive they become. It's essential for Agile Coaches and Scrum Masters to recognize that optimizing Cycle Time is not a deviation from Agile principles but rather an integral part of fostering agility.

Reducing Cycle Time has several benefits to agility: First, it allows us to obtain customer feedback faster and more often, enabling them to validate assumptions, make adjustments, and iterate more rapidly. This feedback loop facilitates continuous learning and ensures that the delivered software meets customer expectations and quality standards. Shorter Cycle Times also reduce the delay between occurrence and resolution of risks and issues. Additionally, short cycle times reveal potential bottlenecks and delays. All these factors reduce rework and improve our ability to create value.

Furthermore, actively minimizing Cycle Time enhances adaptability and responsiveness to changes in the market. Rapid delivery enables organizations to iteratively experiment, learn, and adapt their product or service offerings based on real-time feedback. This fosters innovation and competitiveness. Agile Coaches who understand these aspects will guide their teams to optimize Cycle Time as a means to promote agility.

Don't make it a false dichotomy!

Assuming that "Agile Mindset" and "Delivery Time Optimization" are at odds would be a false dichotomy, but let's entertain the thought and see what the long-term consequences would be for a team whose coach would make an either-or decision, and focus on either one, or the other. In our scenario, we will assume that the Delivery Time is currently so slow that management is correct in being concerned - i.e., that the team is struggling to deliver one releaseable increment per month, and that Delivery Time Optimization would orient itself on Minimum Continuous Delivery requirements. These given, let's take a look at business relevant outcomes and how they'd develop over months and years:

Metric	Explanation	"Delivery Time" Focused Coaching	"Agile Mindset" Focused Coaching
Time to Market	Timespan between idea and value.	Strong - More deliveries, reduced batch sizes and shorter wait times. Faster commercialization.	Variable - "Results not guaranteed."
Product Quality	Software meeting standards and expectations.	Strong - High delivery frequency requires effective quality practices like automated verification.	Possibly - No direct measurement or systematic approach to address quality.
Customer Satisfaction	Maximizing feedback points while minimizing low-quality experiences.	Strong - Rapid delivery with definitive quality verdicts enables better control of dissatisfaction factors.	Limited - Limited opportunities to improve customer satisfaction through controlled delivery points.
Feedback Integration	Collecting input on ideas and Working Software.	Strong - Abundant and timely feedback, potentially multiple times per day, depending on stakeholder availability.	Uncontrolled - Feedback effectiveness unquantifiably tied to delivery process effectiveness.
Adaptability and Agility	Speed and accuracy in acting upon learnings.	Strong - High delivery frequency fosters adaptability and enables effective change implementation.	Poor - Limited means to determine the level of adaptability.
Collaboration and Alignment	Staying in sync and acting in unison.	Strong - Continuous Delivery exposes lack of alignment or collaboration through pipeline failures.	Difficult to quantify - "Soft" collaboration with unmeasurable outcomes.
Risk Reduction	Minimizing impact of issues and delays.	Strong - Mitigation of risks through proactive risk analysis and automated testing.	Poor - No inherent risk control mechanisms.

Verdict

Agile Coaches who discount speed of delivery will struggle

Agile Coaches who primarily focus on promoting the Agile Mindset without actively driving speed of delivery and its enabling technical practices and processes, such as Continuous Delivery, will likely struggle when asked to show clear, measurable outcomes. Here's why:

1. Lack of Transparency: Stakeholders and decision-makers often require evidence of improvements in key metrics, such as time to market, product quality, customer satisfaction, or change failure rate. Without indicative metrics that demonstrate the effectiveness of technical practices like Continuous Delivery, it becomes challenging to achieve significant improvements in these areas, making it harder for the coach to showcase the impact of their work.
2. Inability to Improve: Sustainable speed of delivery is a lagging indicator for the adequacy and quality of a team's technical practices. The Agile Coach ignoring speed will limit their ability to help teams meet stakeholder expectations. This leads to missed opportunities, increased lead time, and decreased competitiveness, rendering their coaching ineffective.
3. Limited Control over Quality and Risk: Teams that don't implement the practices supporting a rapid succession of deliveries will struggle to address quality issues and effectively manage risks. Systematic quality control mechanisms and risk mitigation strategies are essential enablers to consistently delivering high-quality products, hence scrutinizing and optimizing sustainable speed of delivery creates a strong focus on implementing the necessary supporting practices.
4. Inadequate Feedback and Collaboration: Rapid feedback and effective collaboration are essential drivers of agility. The Agile Coach who solely focuses on the Agile Mindset may overlook the importance of technical practices that enable fast feedback cycles and promote collaboration.
5. Limited Adaptability and Agility: Agility relies on an ability to adequately respond to changing market dynamics. Sustained delivery speed, supported by its enabling technical practices, is a powerful leading indicator for the level of adaptability and implementing effective change. Without leveraging practices that support rapid delivery and iterative improvement, the coach may hinder the team's ability to learn, adjust, and continuously improve.

Conclusion

The Agile Coach who neglects Sustained Delivery Speed and its incorporating technical practices, such as Continuous Delivery, is much more likely to struggle in demonstrating significant long-term outcomes. They may miss critical gaps in quality practices, feedback mechanisms, collaboration, and adaptability, thus leading to predictable challenges in meeting stakeholder expectations, driving improvements, and effective agility.

Important: This article consciously emphasizes "Sustained Delivery Speed." Our concern isn't the speed of typing, but the inherent capability of minimizing the time required for turning an idea into a high quality release candidate. Cutting corners to get one shipment through the door will quickly undermine a team's ability to maintain a high pace of deliveries - this tactic always results in incidents and failures which devastate a team's ability to maintain their pace. Hence, sustained delivery speed is an aggregate measurement that requires observing many technical metrics "under the hood," such as build time, build failures, incident frequency, recovery rates, and many others.

Flush the System for Agility!

A key activity that needs to stand at the beginning of every Agile Journey: "Flush the System." What that does? Well - it lays the groundwork so that working in an agile way is even possible.

Areas of investigation

The following areas can be considered "the usual suspects" where flushing activities may be necessary. Please be aware that terminating something is often the easy part - the challenging, and time-consuming part, is obtaining stakeholder support (and potentially: permission) to do so.

Work

Often, at the beginning of an agile journey, people are highly overburdened and it's not even clear who is working on what for how long. That makes it difficult to get anything done - so we need to clean up!

	Itemize ongoing work and complete or cancel tasks accordingly.
	Hand over tasks and responsibilities outside the scope of the Agile team.
	Terminate processes that aren't aligned with Agile ways of working.

Calendar

In many organizations, meetings are so rampant that there's no time left to do any work. And the more knowledge a person has, the more likely they're in this dilemma. Without sufficient focus time for getting any meaningful, valuable work - there's not going to be much "Agile" delivery.

	Cancel unnecessary meetings, such as status or reporting meetings, Jour Fixes, and others.
	Cancel meetings with intended outcomes that should be achieved during Agile events (e.g., Planning, Refinement, Review).
	Cancel meetings with unclear or irrelevant outcomes.

Roles and Responsibilities

Roles and responsibilities need to be clarified and aligned with Agile principles and be made consistent with the new way of working. Unnecessary or counterproductive responsibilities lead to confusion, overhead and conflict.

	Hand over responsibilities that aren't in the scope of the newly coming Agile team.
	Remove unnecessary or counterproductive responsibilities.
	Eliminate "telephone games" in roles and responsibilities that impede information and decision flow.

Incentives and Measurement

Incentives and KPI's often surface as an impediment for collaboration and a focus on value. Historically, these are often founded on beliefs that don't coincide well with Agile Values and Principles, hence cleaning these out will become critical to shaping a better system of work.

	Eliminate KPI's and management metrics distracting from value creation.
	Cancel irrelevant or counterproductive goals.
	Minimize the impact of (or preferably eliminate) incentive schemes and bonuses.

Take action!

As you embark on your Agile journey, "Flushing the System" creates a supportive environment that helps Agile teams to thrive. The above checklist is a powerful guide to streamline work, optimize their calendars, clarify roles, and align outcomes.
This list isn't exhaustive - merely a starting point, and you may find a lot more items you can flush as you look around in your organization.
Remember: "Flushing the System" isn't a one-time event, but part of the greater process of continuous improvement. Regularly assess and refine your system of work to ensure you're not missing "flushing" potential that will lead to better flow.

Navigating Hidden Agendas

We are constantly striving to create thriving organizations where collaboration, productivity, and innovation flourish. However, one of the most challenging aspects in organizations is the presence of personal agendas - both overt and hidden. Oftentimes, people say that if we could just eliminate those personal agendas and focus everyone on the overall goal and mission, we would have a lot fewer problems. But that "just" is a major problem - let's explore.

How are the pieces and the Big Picture connected?

The problem with hidden agendas

Hidden agendas arise when an individuals' have personal interests, motivations, or goals don't align with their environment. Such hidden agendas are often considered to be impediments to decision-making, execution and teamwork. They also erode trust within the organization. 

Acknowleding and understanding the existence of hidden agendas is crucial for effective leadership and organizational success.

The Impact of Personal Agendas

Personal agendas significantly influence the dynamics, communication, decision-making processes. When individuals prioritize their own motives over organizational goals, this can spark conflicts, damage collaboration, and hinder progress. Hidden agendas pose a particular challenge here as they aren't openly acknowledged and addressed, so everyone besides the agenda's owner is kept guessing. This can undermine trust, transparency, and alignment within the organization.

The presence of personal agendas can indeed have a substantial impact on organizational success by affecting alignment, transparency and collaboration. Acknowledging and managing personal agendas thus becomes essential for fostering a positive and productive work environment.

Why are there Personal Agendas?

As soon as you have more than just a handful of people, the diversity of individuals' motivations, aspirations, and goals becomes more apparent. We see the difficulties this brings even in marriages where only two people need to align their needs and desires with each other. And with growing organizational size, the problem of alignment grows.

While some agendas may be openly expressed, others are hidden or not immediately apparent. In some cases, this happens on purpose. In many cases, though, it happens because people themselves are either unaware of the impact of their goals on overall goals, don't know how to communicate their own goals, or there's no forum where they could address the discrepancies. 

Complex organizational structure with multiple stakeholders and diverse roles are thus a fertile ground for the emergence of personal agendas. 

Can't we eliminate Personal Agendas?

In short: No. Eliminating personal agendas from individuals within an organization is practically impossible. Humans naturally have their own motivations, interests, and aspirations, based on their needs, expectations, assumptions and reasons. If we were to successfully remove all of these, it would turn people into soulless drones without. Autonomy, creativity and engagement would be massively constrained.

Minimizing the negative impact of personal agendas requires effort into aligning people's objectives with one another and the overall organization. We can achieve this by fostering open communication and respecting the individuals' motivations.

The consequences of suppressing Personal Agendas

When individuals are unable to express their personal agendas openly, they will develop hidden agendas instead. Lack of a forum for discussion and transparency creates an environment of mistrust, where individuals resort to covertly pursuing their own interests. It could take a long time until the impact of the resulting actions on communication and collaboration becomes tangible. The gap between overall desired actions and executed actions in this case is "communication debt."

Communication Debt: The conversations we should have had, but failed to have.

Similar to other forms of debt, this communication debt comes with an interest attached, and will grow exponentially over time when unattended.

Permitting Personal Agendas

Should we then make a space for personal agendas? Yes.

While we might believe that systems permitting personal agendas would perform worse in the long term, that doesn't match the evidence. Even people like Steve Jobs famously said, "We don't hire smart people and tell them what to do - we hire them so they can tell us what to do." Books like Dan Pink's "Drive" have collected overwhelming evidence that systems giving people the autonomy to decide the best course of action by themselves create superior outcomes.

Creating a space for personal agendas within a structured framework harnesses every individual's talents and creativity. Systems recognizing and accommodating personal agendas fare better on engagement, ownership, and innovation. The challenge is striking a proper balance between personal agendas and their potential to override collective objectives or causing conflicts.

When managed effectively, such systems can leverage the diversity of individual perspectives to drive organizational success.

The Growth of Hidden Agendas

Without a platform to openly express their personal agendas, hidden agendas tend to proliferate. The absence of open communication channels will foster resentment, lack of trust, and covert pursuit of individual interests. Over time, the resulting hidden agendas may undermine communication, collaboration and organizational cohesion.

Whereas providing a forum for sharing personal agendas is no guarantee for the absence of hidden agenda, without such a forum, hidden agendas are likely to grow. Opportunities for open dialogue and transparent communication are essential in mitigating this risk.

The effect of Hidden Agendas on decision-making

There are two kinds of decisions: those that the individual makes, and those that the organization makes in their official channels and processes. Organizational decisions are based on various factors, such as goals, collective input, expertise, and external considerations. 

In some organizations, hidden agendas dominate daily operations. Official decision-making processes in such environments are mostly a show: "the real decisions" were already made, in different forums, with different actors, before anything is openly brought to the table: The hidden agendas determine the course of action. Strategy and organizational goals are reduced to being the pretext for the predetermined decision. 

In the grand scheme of things, this may go unnoticed - but it may also lead to massive failures. as the source of the discrepancy often can't be traced, this creates confusion as to why decisions were ineffective. Many organizations respond by introducing additional checks and balances which leave even less room for personal agendas, while also slowing down future decision making and incurring extra costs, which renders the organization even less effective. Instead of solving the problem, they exacerbate it!

Repairing Systems Dominated by Hidden Agendas

We have explored that one of the main reasons for the emergence of strong hidden agendas is a discrepancy between an individual's motivations and the constraints of the system. The absence of a forum that respectfully enables people to reveal their personal agendas and address agenda conflicts openly and constructively gave rise to the need for hidden agendas.

The consequence is "organizational debt," which consists of all the communication and collaboration structures and learnings that led people to form hidden agendas.

Organizational debt: The entirety of all communication and collaboration structures, processes, rules and learnings that impede organizations from effectively reaching their goals.

Repairing the system isn't as easy as creating a forum for open communication. Hidden agendas often involve unaddressed motives, intransparency, and conflicts of interest. Building a more effective system requires a comprehensive approach involving open communication, trust-building, active problem-solving and reestablishing a shared sense of purpose by offering meaningful organizational values with which individuals can identify.

Conclusion

Recognizing and addressing personal agendas is crucial for building a healthy organizational culture where collaboration, innovation, and productivity thrive. Instead of trying to eliminate personal agendas, we need to create an environment that encourages open communication, transparency, and alignment. This will mitigate the negative impacts of hidden agendas. A culture that values diverse perspectives and aligns individual aspirations with organizational goals, will be more resilient and cultivate an empowered workforce that drives long-term success.

Navigating the complexities of hidden agendas and proactively working towards building an environment that enables transparent and collaborative organizations is everyone's job. Enabling individuals to contribute their best while advancing the collective goals requires them to pursue their own agenda in line with the organization's agenda. Transparency and alignment of everyone's goals are keys to unlock the true potential of our teams and organizations.

The TOP Structure is one specific approach that can be applied at any level, in any organization, independent of state or size, to actively reduce organizational debt and build a better organizational system.

Does Agile make you faster? Yes! But not how you might think: A reorganization plus a calendar filled with recurrent meetings won't magically make things move faster. So - how do you become faster?

Work on fewer jobs in parallel

Think of it like this: We have 8 working hours in a day. If we work on 8 jobs for 1 hour each, it will take over a week to complete something that could be finished on a single day if we weren't distracted by 7 other things.

Work on smaller jobs at a time

Let me illustrate: If you have a job that says, "Paint porch and garage" - obviously, that thing will take longer than only painting the porch. By slicing the larger package into two parcels, you get two jobs that can each be delivered faster. The benefit? If you have painters paint your porch and garage over a period of two days, you need to inconveniently park somewhere else for two days in a row. But if you have the garage painted on day 1, and the porch on day 2 - you park in front of the porch on day 1, and return to your garage on day 2. Yay!

Admit that we're only guessing until we have a result

We often try to get the requirements right the first time, then do a perfect job. But - that usually doesn't work. The consequence? Arguments, blame and rework. None of that speeds things up. How about we simply accept that "this is version 1, now we need feedback, and we'll incorporate that?" The time spent on justifications, escalations and bickering can be eliminated from the process entirely.

There you have it.
We didn't reorganize.
We didn't assign new roles.
Or create new meetings.
Or introduce new tools.

With these three simple life hacks, I have helped development teams cut their time to market in half, while also increasing quality and stakeholder satisfaction

Product vs. Functional Organization - a false dichotomy!

#

There's a buzz going around that "we should move from functional organizations to product-led organizations." However, this binary perspective ignores the complexity of organizational design. The result of such a change is often a suboptimal, unsustainable system with a strong bias towards products, to the detriment of other things But I'm all for dissolving the classic functional organization model. And here's why.

Organizational Archetypes

Let us take a look at different organizational archetypes. You'll quickly realize that it's not as simple as a "product-led vs. function-led" organization - there are a myriad of possibilities. Before we dig into the details, let's briefly explain that an organization can emphasize different aspects, such as products, processes, or people, and each of these aspects can have a focus, a center, and a lead.

The focus is the organization's benchmark for success. The center defines the purpose of individuals and groups within the organization. The lead drives critical decisions.

Since in human systems, people think, do, and act - a focus means that there will be people paying specific attention to this, a center means that people's status in the organization is directly related to how close they are to the center, and a lead would be someone's primary responsibility.

But now, the heart of this article: the table with the different archetypes.

Emphasis	Focused	Centric	Led
Customer	Deliver high-quality products and services that meet the needs of customers.	Organize around delivering the best possible customer experience, and use customer feedback to inform decision-making.	Prioritize the needs and wants of customers above all else, and use customer feedback to drive decisions.
Data	Use data to achieve business goals. It emphasizes the importance of aligning data-driven solutions with business needs and objectives.	Organize around "what the data says," enhancing efforts that drive key indicators and reducing efforts without measurable impact.	Drive business decisions based on data insights, doing more of what's supported by data and less of what's disproven by data.
Function	Deliver high-quality specialized functional services that contribute in the creation of products and services that meet the needs of customers and stakeholders.	Organize around different functions or departments, and coordinate cross-cutting efforts.	Prioritize the needs and goals of individual functions or departments above all else.
Marketing	Create awareness of, and promote, the brand in order to generate demand.	Organize around generating visibility, demand and impact.	Prioritize activites and outcomes that increase demand for the brand.
People	Build a competent, motivated and engaged workforce that meets the needs of customers and stakeholders.	Organize around the needs and goals of employees, while maintaining a focus on meeting customer needs and other considerations.	Prioritize the needs and goals of employees above all else, recognizing that a healthy and engaged workforce is essential for the success of the organization.
Process	Deliver high-quality products and services through efficient and effective processes that meet the needs of customers and stakeholders.	Organize around executing efficient and effective processes, while paying attention to business objectives.	Follow established processes and procedures above all else, sacrificing other considerations in order to do so.
Product	Deliver high-quality products that fit to the company's market.	Organize around products or services, while maintaining a strong customer focus.	Prioritize product outcomes above all else, relying on the product's market impact to drive business.
Sales	Acquire leads, close deals and grow.	Organize around prospective deals and acquiring customers.	Highest priority is given to activites that generate growth.
Technology	Technological solutions and innovation keep the company ahead of the market.	Organize the business around technology capabilities. The development and maintenance of technology infrastructure are key drivers of business success.	Align technology solutions with business objectives and use technology to drive success.

Beyond the dichotomy

A "functional organization" will become highly ineffective when the internal communication and coordination gets in the way of employee and customer needs. Unfortunately, a similar thing might happen in a "product organization" when either-or situations between product progress and people's needs arise.
The table contains no single irrelevant item. In reality, no company is purely one archetype or the other. We thus can't even ask, "From which one archetype towards which other one should we transform?" We need to ask ourselves, "Which drawbacks do we see in our current archetype, and how could we integrate impulses from other archetypes in order to overcome these drawbacks and become more effective as an organization?"

Then, how should we organize?

Companies must strike a balance between the different archetypes, borrowing elements from each to optimize their performance. For example, a company may claim to be strongly customer-focused, but upon closer examination, may be product-focused, supported by data and people. To ensure success, companies should continually inspect and adapt their organizational mix to ensure it aligns with their goals. Leading questions might be, " Are we overemphasizing something that's not suitable for us? Are we underemphasizing something that we maybe should emphasize? If we continue our current approach, which challenges will we face? What do we expect to happen if we make a change?"

Author's note

I am not in a position to tell you how you should organize. My personal belief is that any single archetype, pursued exclusively, will end up being dysfunctional. I would expect most organizations to take impulses from product-focus, customer-lead and people-centricity, while paying due attention to technology and process, with specialized functional areas for cross-cutting platforms and capabilities. But most of all: they would adapt.

The best organizations wouldn't have to decide up front the lead, the center, and the focus - they are able to adapt both locally and globally without major shifts or changes.

Balancing interests at any time, every level of abstraction and in every area is important - because otherwise, people, teams and groups will prioritize their own needs, resulting in local optimization, cannibalization of efforts and unnecessary conflict.
Different people prioritize different things (e.g. time to market and revenue for product folks, quality and sustainability for technical folks, and growth and learning for organizational folks). A system of balance that makes conscious decisions from different perspectives is necessary. This balance of interest is necessary, and the critical question that many organizations stuggle with is determining whether something is going overboard. This won't be covered automatically when there's no transparency what the various perspectives are. Achieving balance is a difficult, ongoing process. Regardless of where we start to balance things out, at some point, we will discover that unless the company's Board of Management provides a balance, the imbalance will continue.

A possible solution

This post wouldn't be complete if I wouldn't be pointing you to a practical way to get this going:
The TOP Structure offers an approach that will help you make different goals visible and transparent, start discussions on whether you believe you're centered, focused and leading on the right things - and then get going to improve the situation.
You can use the TOP Structure as an individual, in your team, in your product group, in your department - or in your company, to balances the different perspectives and find the best thing that works for your context. Read the TOP Guide for practical guidance to get you started. And don't hesitate to contact me if you'd like to learn more.

Is "Agile" just smoke and mirrors?

The "Standish Group Chaos Report" is often quoted as the reason why companies should undergo an "Agile Transformation" and adopt Agile Ways of Working. It supposedly proves that "Agile" is essential to survival. But when you look at the data, you may get some doubts ...

Before we dig in, I must add a huge disclaimer to this article:

DISCLAIMER

It's incredibly hard to find accurate information about the Chaos Report on the Internet. For example, infoq quotes 29% success for 2011, whereas Wikipedia quotes 34%, whereas a paper I found directly at Standish Group quotes 39%. A youtube video quotes that period at a success rate of 32%. Another souce writes that "33% of projects are successful, but only 21% deliver a benefit."

Since I didn't want to spend a couple thousand bucks on original reports, I went with "most likely accurate source" in collecting data. If anyone has the reports, I'd be happy to correct my data where it is wrong.

That said, here goes the image based on the data I found:

Is "Agile" really the cause of success?

What does the data really say?

That it's not nearly as clear-cut as we might want it to be. It doesn't send an irrefutable message that "Agile changed the world, software development is now much more likely to succeed.

There's no proof for anything - only an absence thereof. We have levels of variation that indicate we still have too few data points to make any statement with certainty. The only statements we can make with certainty:

• The data does not prove that "Agile" made the difference.
• It also does not prove that potential improvements could be attributed to a framework like Scrum or SAFe.
• It also does not prove that "Agile" benefits are sustainable.

Factors commonly ignored

Looking back into the beginnings of the Standish Group Chaos Report - that was the 90's: Things other than Agile have changed as well. Here are just some of the major changes that happened since then:

Software was still "new."

Many people never operated with computers back then. They didn't know how to use them, much less how to formulate their needs in a way that made sense in the digital age. Nowadays, everyone knows what a computer is.

The Internet.

Not sure about anyone and everyone - but in the 90's, I didn't have Internet. My only reference was written books, usually published years before. There was a massive asynchronity between encountering a problem and finding an information source that could help solve it. Even as late as 2008, I was still developing for clients that restricted/disallowed using the Internet at work.

IT advanced

Back in the 90's, it was just much harder to process large volumes of data reliably. Back then, we struggled with challenges modern developers are hardly aware of. That included stuff for real nightmares, such as a CPU wrongly processing a correctly compiled piece of source code. Many sources of inexplicable failure have since been eliminated.

IT infrastructure advanced

Some of my early projects were extremely challenging, because "production like environments" were so expensive that it was impossible to afford one for each project member. Indeed, there was often only a single test environment for everyone - even that cost millions. Developers often didn't know what their code would be doing until it was live, simply because of environment constraints.

Transaction costs plummeted

Back in the 90's, we were often shipping literal CD's at project end, there was a final "golden build." Especially for consumer software, that "golden build" could make up for over 95% of the project's cost. I'm sure Atari's ET could have led to very different outcomes if they could've just made a few post-release updates at near-zero cost.

IT Project Management advanced

IT Project Managers also learned how to use these advances to become more successful. Project Management also adopted new and better ways of making their projects succeed.

What does all of that mean, then?

Restating the obvious: there were many factors at play, each of them certainly significant to boost success rates from about 15% in 1994 to the 30% we see today. But there's no one single factor that could be isolated to say, "This factor brought us to 30%, and if we just do more of that, it'll bring us to 50% or higher!" If anything, the data shows that no single factor has been identified that has the potential to boost success rates any further than what we already had in the early days of the Agile Manifesto.

"Agile" most certainly hasn't proven to be the Silver Bullet that will singlehandedly fix the industry.

Closing remarks

We don't have undisputable evidence based on publicly available, reliable sources to argue for or against Agile based on the Standish Group's research. In statistical lingo, "we can't reject the null hypothesis". That is: there's not enough evidence to reject any statement for or against.

There's a fact problem that amazed me: I would have expected that accurate data from the Standish Group's research would be more widespread. But it's not. It's a rabbit hole. I need this huge red disclaimer. I don't even know who's telling the truth or who's misunderstanding presented information (that could also include me - mind you!) Who's stating facts, who's simply pulling numbers out of thin air, and who's deliberately lying to drive an agenda?

Maybe if I had all of the data, undisputably, from its source, the picture could change?

But for now: I can't scientifically state that yes, the Standish Group has provided irrefutable evidence that Agile made a difference. 

So - I'd say that we need to drop Standish Group or Chaos Report from the list of "Reasons for Agile."  There may be others, but this one doesn't make the cut.

Sources

The following sources were used to produce this article:

• https://de.wikipedia.org/wiki/Chaos-Studie
• https://hennyportman.wordpress.com/2020/01/03/review-chaos-report-2018/
• https://www.infoq.com/articles/standish-chaos-2015/
• https://www.standishgroup.com/sample_research_files/CHAOSReport2015-Final.pdf
• https://hennyportman.wordpress.com/2021/01/06/review-standish-group-chaos-2020-beyond-infinity/

The Blurb transformation

Recently, there's been a lot of buzz about Blurb being the future of work. According to Blurb thought leaders, the adoption of Blurb makes companies more successful by operating faster, better and cheaper.

Company X wants to give it a try and starts a Blurb transformation. During initial training, Blurb practitioners explain that all the current problems only exist because of the current management paradigm - and how much better everything would be if everything would be moved to Blurb.

Management takes their hands off, lets Blurb practitioners do, and observes.

Blurb practitioners begin to do exactly what management did, ableit very inefficient, ineffective and infantile. To management, it appears that Blurb practitioners neither understand what a manager does, why they do it, nor how to do it properly. But - benefit of doubt: Maybe this Blurb thing really is the future, and managers just need to wait and see how it turns out?

At some point, management begins to question the advantage of doing Blurb - the actual outcomes could be achieved much easier and faster without Blurb? Blurb practitioners say that's management doesn't understand Blurb, because they're stuck in a non-Blurb mindset: you can't be Blurb without Blurb.

Eventually, management calls and asks what benefits has Blurb actually brought? Blurb practitioners explain that they have made a lot of progress doing Blurb and helping others do it. They emphasize that in order to get the benefits, you must be Blurb, not do Blurb. And that the key benefit of Blurb is that you become Blurb.

Management begins to get dizzy. They decide to cut funding for Blurb.

If you were a manager of Company X - what would you have done?

What's the value proposition of Agilists?

CapitalOne just fired all of their professional Agilists. They state that Product Managers can just take on Agilist responsibilities on top: Why?

The role of Agilists

Many Agilists think that their role is a subset of:

1. Introducing "Agile" ways of working by training, teaching methods and launching teams.
2. Supporting execution by organizing schedules, facilitating events and resolving impediments.
3. Doing managerial tasks such as monitoring and reporting team health, progress and performance.

Even the people doing these three are often different folks:

• Category 1 folks are a temporary role. It's better to contract them on demand: What do you do with them after everyone has been trained and is working in an agile team?
• Category 2 folks could give senior management the impression that "a Scrum Master is just a Junior project assistant with stickies and Sharpies." Self-organized teams shouldn't need them. They are clearly overpaid, and probably not doing their job.
• Category 3 folks are considered redundant by many developers, there are often also complaints that they're stopping developers from doing what really matters - they're contributing to the problem that "Agile" set out to solve.

When an organization sees agilists as defined by the three points above, all I can say: Firing them all is justified. An entire job family is technically designed for "doing efficiently that which shouldn't be done at all" - is redundant.

They don't have a long-term value proposition.

The Value Proposition

There are three pillars to every company: product development, organizational development and technology development. Scrum focuses exclusively on Product development, and SAFe somehow also blends Technology development in. But who develops the organization?

The real role of agilistas 𝘴𝘩𝘰𝘶𝘭𝘥 𝘣𝘦 in organizational development: build organizational capabilities, and improve systemic collaboration and communication.

Resolving delivery impediments is not enough - the organizational system must be ready today for the challenges of tomorrow: New business opportunities arise, existing business models become obsolete, even entire markets collapse. Having the capability to deal with that is critical to company survival. And yet - few agilists are working on this. Their approach is "hope and pray" that no major disruption will occur, and so they walk like lemmings to the cliff.

Learn about the TOP Structure

The failure of "Agile" roles is can be avoided with the TOP Structure: It gives Agilists a clear, indisputable value proposition, and meaning to their work.

And that's the very reason why every Agilist and manager should be familiar with the TOP Structure.