Defining Enterprise Coaching

I call myself an "Enterprise Coach," rather than an "Agile Coach" - because I feel that what the market typically understands under "Agile Coach" doesn't really match what I do. I work to improve organizational systems, and Agile frameworks and approaches are just one tool in my belt when doing that. And recently, with the TOP Structure, I have reclassified and restructured how I myself see this role. Let me share my defintion, which I have turned into an interactive site that also gives you a score at the end, so feel free to tick the boxes of competencies you believe that you bring to the table.

We'll take a look at the role of an Enterprise Coach through the lens of the TOP Structure, which - to keep things as simple as possible, stands for "Technology, Organization, Product." These are the three core pillars for (almost) every modern enterprise. An Enterprise Coach works at system level, hence they need to be familiar with all three pillars, as well as their interactions, at every level of the organization.

Domain Overview

The TOP Structure offers an integrated competency model to frame key skills and experiences across three primary domains: Technology, Organization, and Product. These domains encapsulate the broad range of expertise necessary for excellence in Enterprise environments.

Technology

An Enterprise Coach won't necessarily be a profound technology expert, but needs a solid understanding of the technology landscape and the technical practices within it. They should be familiar with how Agile methodologies and principles apply to software development, IT operations, and technological innovation. This includes understanding DevOps, Continuous Delivery, TDD, BDD, and many other technical practices associated with Agile environments. They use this knowledge to guide teams in adopting appropriate technical practices that allow them to work effectively and sustainably.

	Topic	Details
	Lean + Agile Practice	Possesses a comprehensive understanding of Agile methodologies and how they apply to technology and software development environments.
	Software Development Lifecycle	Understands the software development lifecycle and how Agile principles apply to various stages, from demand collection to development, testing and even operational maintenance.
	Technical Practices	Familiar with technical practices like DevOps, Continuous Integration/Continuous Delivery (CI/CD), Test-Driven Development (TDD), Behavior-Driven Development (BDD), pair programming, and automated testing. Can provide guidance to teams in adopting these practices as needed.
	Technical Facilitation	Able to facilitate technical discussions, bridging the gap between technical teams and business stakeholders. Can communicate technical complexities in a simple manner to non-technical team members.
	Digital Transformation	Understands the role of technology in digital transformation and can guide the organization to leverage technology for business agility.
	Technology Trends	Stays updated on the latest technology trends and innovations, and understands how they can influence Enterprise systems.
	Systems Thinking	Understands the interplay between technical systems and processes in an organization. Applies a holistic approach to problem-solving.
	Technical Debt Management	Understands the concept of technical debt and can guide teams on strategies to manage and reduce it.
	Scalable Architectures	Understands the principles of building scalable and flexible architectures. Can guide teams in aligning their technical practices with these principles.
	Tool Familiarity	Familiar with typical tools used to organize technology work. Can guide teams on using them effectively.

Organization

This is a key area for Enterprise Coaches. They need to understand organizational dynamics and how to build collaborative environments across teams and business functions. Skills in this area include change management, strategic thinking, leadership, and communication. They should have experience in leading organizational culture shifts, influencing stakeholders, facilitating conflict resolution, and mentoring other Coaches and leaders. They need to understand how to design and implement strategies that align with the organization's structure, culture, and business objectives.

	Topic	Details
	Organizational Design	Understands how different organizational structures impact the organization's ability to reach its goals. Able to guide changes in organizational design to improve alignment between structure and goals.
	Theory of Constraints	Understands how to maximize effect with minimum change in large organizational systems.
	Change Management	Skilled in leading and managing organizational change initiatives, particularly Agile transformations. Understands the psychological and social aspects of change and can help address resistance.
	Strategic Thinking	Able to design and implement change strategies and how to align them with organizational objectives.
	Leadership	Demonstrates strong leadership skills, guiding teams and individuals through change and fostering a culture of continuous improvement.
	Influencing Skills	Able to influence stakeholders at all levels, including senior leaders, to foster beneficial change practices.
	Communication Skills	Excellent verbal and written communication skills. Able to clearly articulate the benefits of change to different audiences.
	Conflict Resolution	Adept at facilitating conflict resolution and consensus-building among diverse stakeholders. Able to maintain harmony within teams during transformation efforts.
	Coaching and Mentoring	Experienced in mentoring and coaching Agile Coaches, Scrum Masters, managers and leaders within an organization. Can help develop leadership capabilities across the organization.
	Cultural Understanding	Aware of the cultural aspects within the organization and how they impact its ability to reach its goals. Able to guide cultural shifts to align closer with intended goals.
	Performance Management	Understands how to align performance management systems with organizational goals. Can guide changes to recognition and reward systems causing undesired behaviors.
	Assessment	Able to qualify the organization's current state to guide continuous improvement efforts with empirical data.

Product

Enterprise Coaches don't manage products directly. Instead, they support and enable product development efforts. They need to understand how roles such as Product Owners and Product Managers operate, and how product strategy, roadmapping, and backlog management can be conducted effectively. Their understanding of product management can help facilitate alignment between product strategies and ways of working, as they coach product-related roles in the organization.

	Topic	Details
	Product Management Practice	Able to apply product development functions, including concepts such as product-market-fit, design thinking, incremental bets, and iterative development.
	Value-Driven Delivery	Understands how to align product development practice with the delivery of value to customers and stakeholders. Can guide teams to refocus from output to value.
	Lean Principles	Understands Lean principles such as minimizing waste, amplifying learning, and delivering small batches. Can guide teams in applying these principles to their own work.
	Product Strategy and Roadmapping	Familiar with various approaches to product strategy and roadmapping, and can help align these with organizational objectives.
	Customer Centricity	Understands the importance of customer feedback and user experience in product development. Can guide product teams in adopting a customer-centric approach.
	Business Model Understanding	Understands the organization's business model and how product development aligns with it. Can guide product teams in aligning their work with the business model.
	Market and Competitive Analysis	Understands market trends and competitive dynamics that could affect the product. Can guide product teams in responding to these trends and dynamics.
	Metrics and Analytics	Understands how to use product-related metrics and analytics, such as customer satisfaction scores, throughput, yield rates, etc. Can guide teams in using these metrics for continuous improvement.
	Risk Management	Understands how to manage product-related risks including technical debt, market shifts, etc. Can guide teams in effective risk management practices.
	Product Owner/Manager Coaching	Skilled in coaching Product Owners and Product Managers on their roles and responsibilities, including for example backlog refinement, stakeholder management, and cost-benefit optimization.

So - how are you doing?

You scored:

• 0 / 0 Technology Competencies (%)
• 0 / 0 Organization Competencies (%)
• 0 / 0 Product Competencies (%)

That means you consider yourself equipped with % (0/0) of the TOP Structure Enterprise Coaching Competencies.

Would you like learn more about the TOP Structure, and how to become a TOP Structure Coach? Please visit The Official TOP Structure Page.

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

Addressing some SAFe concerns

Quite often, I encounter concerns with the Scaled Agile Framework. When looking at the Big Picture, and what many companies make out of SAFe, these concerns are valid - and should be taken serious. On the other hand, none of these concerns couldn't be addressed by a capable SPC and a management who cares about making a meaningful difference in their ways of working. In this article, I'm looking at some of them.

SAFe- Blessing or curse?

Typical Concerns with SAFe

Before digging in: I do believe that the skills and experiences of your SAFe Practice Consultants are critical for the success of SAFe. If you rely on people who don't understand the consequences of any advice they give, you're in for a rough ride. An SPCT friend of mine recently said, "Having the wrong SPC's - or skipping the guidance of an SPC altogether - will easily cost you tenfold of what a good SPC would cost you." I agree. Good SPC's are worth their weight in gold. Unfortunately, they don't grow on trees ... but that's a different story.
Now, let's take a look at some of the concerns I typically encounter, and what we need to consider.

SAFe caters to traditional mindset

SAFe acknowledges and respects that many organizations transitioning to agile practices still have a traditional mindset. Therefore, a lot of material in SAFe is written in a way that might be more palatable to people who have a low understanding of agility. This is the idea of "meet people where they are." Yes - that's contentious, but it's by far better than affronting the very people you need in order to make a change. What happens after we met them - that depends a great deal on their motivation to change, and the ability of the SPC to lead change.

Complexity overkill

First things first - if you don't have the problems SAFe addresses, don't use it. With that out of the way, SAFe can't - and usually shouldn't - be applied completely. Much rather, when we spot a problem for which SAFe proposes a solution, we can look at what SAFe says, have a discussion on whether that's worth a try - and if it is, then go for it. That neither means that you need to do things that solve problems you don't have, nor that you have to do things the way SAFe says if that doesn't work for you. For myself, when someone comes to me and says, "We're using SAFe, and have this-or-that problem," I commonly refer to a SAFe article, and the original source pointers SAFe refers to, and take the discussion from there. To me, SAFe is a discussion starter - not the panacea for all ails.

Dependencies everywhere!

SAFe recognizes that dependencies can be a challenge in complex organizations. It provides clear guidance and practices that make dependencies visible, and then offers a way to address these dependencies systematically. In many organizations, dependencies are inevitable - but at least we know which troubles we have because of them, and can start the discussion of what to do about them. I have encountered more than once that teams found their dependencies unworkable and decided to re-organize. A great discussion to have.

Length of planning intervals

SAFe employs a cadence-based planning approach with fixed-length Planning Intervals (PIs) typically spanning 8-12 weeks. Longer planning intervals provide stability and predictability for teams at the expense of flexibility. However, you can adjust the duration of PIs based on your own context. I have seen Agile Release Trains running 3 1-week Sprints plus a 1-week IP Sprint. That even fits Scrum's old slogan of, "Working Software in 30 days or less" - at scale! Try what works for you, and have the discussion.

Top-down planning processes

Maybe we have the wrong picture in our heads, but who can blame us - when we've been conditioned to think in hierarchies? In a SAFe context, we'd like to decentralize that which makes sense - but not everything makes sense to decentralize. For example, the Product Management function in SAFe could be staffed from team Product Owners, if they have the skills and capacity to succeed in that role, so it doesn't need to be hierarchical. What we need is a clear focus on the bigger chunks of value, and align all teams around them. How this happens can vary per organization, but having each team decide by themselves - doesn't bode well. Please be aware that SAFe encourages active involvement and empowerment of teams and individuals in making decisions.

Not proper Scrum

SAFe is not a strict implementation of Scrum, but rather a framework that incorporates agile principles and practices from various sources, including Scrum. Since many teams already run Scrum and are familiar with the core concepts of Scrum, SAFe has taken advantage of that and it retains the fundamental principles of transparency, inspection, and adaptation. When I coach SAFe teams, I quite often refer to the Scrum Guide, and suggest that understanding and practicing Scrum really well helps a lot getting the scaling part right. Unfortunately, what I see quite often is that organizations have already used a highly dysfunctional Scrum for years, and now want to change that. If anything, the SAFe transformation could be an opportunity to fix the Scrum stuff that was always broken and never got addressed.

Teams become Feature Factories

That's already a dysfunction - because SAFe features should focus on value, not on maximizing quantity of work delivered. We should only have a single ART Kanban that's prioritized by value - and teams should collaborate on shared objectives, using common backlogs and cross-team events to ensure a cohesive system solution that maximizes value. While sometimes, we see that individual teams may focus on delivering their own features irrespective of value, SAFe provides mechanisms such as System Demos and Inspect and Adapt events to ensure they don't go off on a tangent and do a large quantity of low-value work.

Fallacious estimation processes

A lot could be said about SAFe's estimation process, and I have my own opinion on the guidance they give. To keep it simple: its guidance is only for people who don't know how to get started. Coaching and empiricism should lead to an approach that meets the needs of those who need the estimates. We should realize that in larger organizations, where quite often multiple stakeholders, other teams and potentially large amounts of money depend on making fairly accurate forecasts for completion, estimation may have implications that don't exist in smaller contexts. My own go-to example is that we need to absolutely know whether the feature will be ready for the Trade Fair, or whether we need to mitigate. But "Well, we might or might not be ready in time for the fair" - could lead to a major PR disaster, and is probably unacceptable.

One Continuous Improvement event every 3 months is too little, too late

While the Inspect and Adapt (I+A) event occurs at the end of each Planning Interval (PI), SAFe encourages continuous improvement throughout the PI, with both the Scrum-of-Scrums (SoS) and Retrospectives being opportunities to surface and address cross-cutting issues. I myself like to give the guidance that teams are expected to make their own changes and improvements independent of the I+A event, and even share learnings with other teams during that event. I expect teams to bring short-term issues to the SoS, and only bring issues to the I+A which require longer preparation and observation periods, and have an impact far beyond the team boundaries. Most of all, we need to consider that the I+A is a point of reflection, where we detach from the daily routine, and come together as a team-of-teams to discuss the things we need to discuss that we never got to discuss before. There's always something. Yes, we could have such events more often - if you feel that it could help, there's nothing in SAFe stopping you. Try it.

Conclusion

I agree that the Scaled Agile Framework (SAFe) has areas of interpretation and concerns. Expecting it to be a silver bullet is completely unrealistic. It does provide a structured approach for larger organizations trying to make sense of this entire "Agile" thing, though - but that only works if they have someone who understands more than just what the material says. When you can address the complexities of large-scale development, cross-team collaboration and overall alignment while continuously improving, you've succeeded with SAFe. To get there, you absolutely must customize SAFe, and use it wisely - otherwise it will become a mess, and that's why you need some folks who know what they're talking about. And I've seen that mess: The shambles take years to clean up. The people who support your change initiative need to be able to address critical concerns based on their own experience and learnings. And the people in your organization who have concerns need a time and place to voice these concerns - because only then can we truly improve.

Scope Creep and agility?

"Scope Creep" is every project developer's nightmare. Best case, it only means overtime. Worst case, it means a lot of unpaid overtime, additional meetings, frustrated customers, angry managers and burnout. In any case - not a fun place to be in. But it's a relic from the traditional world of projects - is it?

No. Scope creep can also occur in agile contexts - and it's even more likely than in traditional projects because there are more interactions with stakeholders. But first, let's define "scope creep:"

A developer feeding the Scope Creep in its natural habitat. Image by: AI (picsart.com)

Defining Scope Creep

Let's turn to the Project Management Institute, as they have defined it best:

Scope creep - Adding additional features or functions of a new product, requirements, or work that is not authorized (i.e., beyond the agreed-upon scope)

Project Management Institute (PMI)

Now, what does that mean within an agile context - and how can we deal with it better than in traditional projects?

With every stakeholder interaction, we gain new insights - and so do they. Mutual understanding evolves together with the product. And each time we interact, what we knew yesterday could be invalid today. That's a great opportunity - but also a danger. Especially when we have a tight schedule and/or budget, this evolution can quickly get out of hand and go beyond our limits.

Confining Scope Creep

We have five critical instruments for dealing with scope creep easily and effectively. In combination, they reduce the risks, stress factors, and the negative associations that come with scope creep:

• Visualize anything that's being worked on,
• Agree as a team on what we take into the product, and
• Simplify with the YAGNI principle, i.e., don't build anything that's not needed.
• Limit yourself to a single demand intake channel, creating a controlled, well-managed process that prevents work flowing in from the side.
• Inspect and adapt frequently, validating that we're still in line with what's agreed upon among stakeholders.

Do's and Don'ts

To create the best product with the highest possible value while keeping scope creep at bay:

• DO pursue newly arising opportunities,
• DO capture stakeholder feedback and insights,
• DO address user problems surfacing in our current solution,
• DO consider improvement suggestions that might require rework,
• DON'T let stakeholders haphazardly drop "urgent requests" or "better ideas" onto developer's desks. These options need to be validated and prioritized against other work first,
• DON'T engage in "prioradditization." Anything added must replace or be prioritized against existing work, and there's always an opportunity cost,
• DON'T play favorites. Neither charisma nor positional power mean that an idea is good or valuable,
• DON'T pursue pet projects that may as well be "YAGNI" themselves. Initiatives without significant value don't deserve capacity, and also
• DON'T tolerate "submarines" that avoid agreements, or bypass the demand intake channel. This makes scope creep exactly as bad as we remember from the worst projects.

Closing remarks

Use the five instruments provided. Heed the Do's and Don'ts, but take it easy. "Scope Creep" always means that someone isn't getting what they want, at least not now, so there's going to be a conflict to defuse, and that's where being relaxed, respectful and open-minded come in very handy. With these tips, I hope that you can confine scope creep and avoid the negative consequences associated with it.

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.

Organizational design plays a crucial role in determining an organization's success or failure. As an organization grows, it faces numerous challenges that determine effectiveness, productivity, and profitability. Understanding the relationship between organizational design and organization size is crucial for businesses looking how to achieve their goals. In this article, we will explore the key factors that organizations face as they grow, and how their organizational design impacts their ability to overcome these challenges.

The Rule of Three

The Rule of Three is simple, but once you know it, it's hard to unsee:

When your organization's size gets to the boundary of a "Power of 3," then former structures deteriorate.

That means, when you reach:

Potence	Threshold	Structure	Potential observations
0	1	An individual	No collaboration structure needed.
1	2	A pair	Usually very informal. "Do what it takes."
2	9	Team	A team needs to form. The team will communicate their own affairs mostly ad hoc and informally.
3	27	Team of Teams	Up until this point, most likely, everyone knows everyone else: who they are, and what they do. Most communication remains informal.
4	81	Teams with Coordinators	People detach: no longer everyone will frequently interact with everyone else. Teams will separate communication channels for "inside" and "outside." Coordinative roles emerge.
5	243	Coordination Layer	It's technically impossible for everyone to be in contact with everyone: "everyone can work on everything" begins creating communication overload - specialist areas form. A coordination layer will be essential to stop irrelevant, premature or even wrong information from stifling team performance.
6	729	Hub-Spokes Organization	Executive management begins to lose track of everything going on. The coordination layer begins to become too big to act as a single team. Possible solutions could include a combination of: decentralization, delegation/reporting hierarchy and functional departments. Centralization and standardization are utilized to increase functional efficiency.
7	2187	Team of Hubs	Distinct entities with few touchpoints evolve. The coordination layer will require more formalization and will behave like a "team of teams." Business functions deteriorate into silos. At operative level, people no longer know what's happening elsewhere.
8	6561	Team of Entities	Operating as a single entity becomes unfeasible - entities will separate. Entity basis could be location, product or business function. Each of these has its own mangement. Underlying smaller structures are preserved while the overall organization remains strategically aligned.
9	19683	Coordinated Entities	Entities will begin to detach. Keeping the different entities aligned, effective and minimally redundant is a continuous challenge.
10	59049	Independent economic entities	Most likely, there will be some major entities that are independent economically entities (e.g. individual brands, regional OpCos, subsidies) which each have a smaller structure. Arguments around "duplication versus economies at scale by centralization" have no clear winner.
11	177147	Conglomerate	It's very likely that there are a number of entities that act economically independent, i.e. there's a parent entity is operating more like a conglomerate with smaller, underlying entities. Redundancy is a desired systemic capability.
12+	531441	A Nation?	Hey - we're talking about organizations bigger than the countries of Malta or Belize here! Let's leave it at the point that these are special and have their own, unique challenges.

Approximate or exact?

The question begs for an answer. These numbers cannot be treated as a "law," but rather a "rule of thumb." There is no clear-cut point where a hard switch is required, and it stands to reason whether the given numbers are applicable to a specific organization. Instead, they represent a trend: as we approach the threshold without modifying the structure, more problems will surface. For instance, a shift from a pairing to a team structure may work well for 3-6 people, but with 7 people, misunderstandings may increase overproportionally - or a team of 12 may still be feasible, but have more challenges to navigate.

Up and Down!

The "Rule of Three" not only applies as an upper limit of organizational size, but also as a lower limit. A structure designed for 150 people would be inefficient if applied to a team of only 20 individuals. Similarly, investing in role clarity and formal working agreements may not be necessary for a pair as they can collaborate and achieve their goals with fewer formalities.

What the Rule of Three means for you

Adapting to change is crucial for any organization, but how do you ensure your structure is still relevant as your company grows or shrinks? The "Rule of Three" suggests that as you approach certain size thresholds, the challenges and inefficiencies of retaining the current structure increase significantly. However, relying on traditional, heavy reorganizations is not an effective fix. In fact, by the time a reorganization is complete, your target structure may already be obsolete. Instead, building organizational adaptivity as a core capability can help you stay ahead of the curve and ensure your structure is always optimized for your size and needs.

Growing

It's important to recognize the signs that indicate your current structure is no longer effective for the size and be open to adopting new patterns that work for larger organizations. By familiarizing yourself with these patterns, you can anticipate the challenges that come with growth and take proactive steps to adapt your organizational structure to meet the needs of a larger organization.

Shrinking

Reducing the size of an organization can be a positive thing, as it simplifies operations and allows for more streamlined processes. However, it's important to also eliminate any organizational patterns that were designed for a larger size in order to fully take advantage of the benefits of downsizing. Failing to do so can lead to inefficiencies and ultimately result in the downfall of the organization. Therefore, it's crucial to identify appropriate smaller-sized patterns and implement them effectively.

Decoupling

One of the most effective techniques in organizational design is decoupling, which involves breaking down a large organization into smaller ones with limited touchpoints. This approach allows decoupled areas to function with a lower "Rule of Three" complexity, enabling optimization with minimal overarching patterns. Decoupling scales well and reduces coordination overhead. When organizations become proficient at decoupling, they begin to ask, "How can we decouple further and simplify the structure of each area and the entire organization with less overhead?" There is no universal rule for when to decouple, but when it is appropriate, the benefits are significant.

Consequences of Ignoring the Rule of Three in Organizational Design

The "Rule of Three" is a soft but essential principle to consider in organizational design and management. Ignoring it can lead to consequences such as miscommunication, misunderstandings, overhead, poor outcomes, poor return on investment, and poor customer satisfaction. Growth and shrinking patterns in organizations should be organic, and it's better to constantly look for the next possible move rather than tie a change to a specific event or period of time. By applying the "Rule of Three" continuously and effectively, you can ensure that you're always working with the most efficient structure and prepared for any future changes.

Applying Occam's Razor to Organizational Design

Don't multiply entities without necessity

Occam's Razor

Applying Occam's Razor to organizational design means sticking to the simplest approach that works. This means not splitting teams if they can effectively communicate and collaborate as a single unit. It means avoiding adding a coordination layer if lateral alignment can work. And it means not using a team framework for a small group that could work like a pair, among other things. However, it's important to note that the caveat to Occam's Razor is to not increase complexity unnecessarily without a valid reason. For instance, if a small group of six people could function as an economic entity with their own funded subsidy, it may be better to let them operate independently rather than adding 20 extra people to deal with the bureaucracy of the parent company.

However, it's important to remember that when a simpler approach is indicated by the Rule of Three, but you don't know how to do it, adding complexity is usually the wrong solution. For example, if a single team is already not functioning effectively, creating a coordinated team-of-teams will only add further problems to an already unsolved issue: It's better to focus on mastering the basics before considering adding more complexity.

Closing Remarks
Always keep in mind that the "Rule of Three" is primarily meant to broaden your vision of what is happening, why it's happening, and to spark a conversation. The numerical thresholds are merely a signal of what to be mindful of. It's essential to prioritize doing what's straightforward and effective, and determining the simplest approach will vary depending on the situation.

Don't be Joe!

Working with Joe is a pain. If it was up to me, I wouldn't hire Joe. And I would advise every employer to also not hire Joe. Not because Joe would be a bad person. But Joe does and says bad stuff. Stuff that's bad for Joe's team. For his company. For the credibility of Scrum, even for "Agile" as a whole. And for Joe. Joe has good intentions - and "the road to hell is paved with good intentions." So - don't be like Joe.

Joe isn't a real person. Joe isn't a single person. Joe is what Joe does.

Joe is a collection of antipatterns that I quite often observe with inexperienced "Agile Coaches" or newly minted "Scrum Masters." We're all learning, and you might even have spotted Joe in what I did. I'm no better - just a little wiser. We need to have empathy with Joe, and Joe needs to reflect on their actions, as well as the consequences of their actions.

Maybe you got pointed to this page with a "don't be Joe" comment? Don't consider it an attack. Consider it a learning opportunity. We're all Joe on occasion. What matters is what we do about it. The less Joe we are, the more successful we will be.

Here comes Joe

I believe that Joe wants to do a good job. Unfortunately, Joe doesn't know what "doing a good job" in coaching means. And that spells trouble. 

Joe is certified

On their very first Sprint Planning session, Joe's team asked why they had to do Planning Poker. Joe answered, "I am a CERTIFIED Scrum Master, and that's the way you have to do it in Scrum." The team couldn't trust their ears: Joe's CSM certificate made him an authority on Scrum? They shook their heads, but obliged. The next morning, when Joe entered the office, he was shocked.

The entire back wall of the office was plastered with certificates. Joe thus learned that two developers held a CSP, two had obtained PSM-II, and everyone had gone through Scrum training years before Joe. Above that list of certificates, the team printed a big banner, "We know what we're doing, and if anyone has doubts - we have the certificates to prove it."

Joe was humiliated, and he could never establish any form of credibility with his team. Within just a few months, Joe left - and the team clearly told management that they'll never accept a Scrum Master who borrows authority from a silly certificate.

What should Joe have done?

Scrum training is really just something that gets us started on our learning journey. Joe should respect that others around him had their own learning journey, and it could be that they are much further than he himself.

Joe should be humble in order to build trust: "I am new here. I don't know who you are, how you work - or why you work this way. I would like to learn. How are you currently planning? How does that work for you?" These are simple, yet extremely effective ways to figure out where real problems are. We don't need to make changes "because Scrum says so." We'd like people to be successful, while reducing unnecessary pain.

If the team doesn't know about Planning Poker, and they have one of the problems it can address, Joe might start the conversation with, "I learned a technique in my training. Would you want to give it a try?"

And most of all - Scrum doesn't even mention Planning Poker. It's an optional, supportive practive. Joe should learn what makes or breaks Scrum before making bold claims.

Joe focuses

During a Retrospective, Joe went into great lengths to explain to the team that developers need to be "T-Shaped," or even better: "M-Shaped:" They should have a broader horizon, not only doing software development, but also learn how their business works, how to test, how to engineer requirements - everyone should be able to do everything.

One developer asked what Joe understands about software development. He answers, "I am a Scrum master. I don't need to understand. My focus is Scrum."

Another one inquired what Joe understands about the product. Again, "My focus is Scrum."

How about the company culture? Yet again, "My focus is Scrum."

Developers shook their head, then proceeded, "Isn't that hypocritical? You expect us to understand things you yourself don't understand, and you allegedly have a reason, but not us? How come?"

Joe reasoned how the Scrum Master's role is ensuring Scrum is done properly, and how challenging that is. The team wanted to have none of it, asking "Do you really believe that your stupid little 17-page guide is more complex than all of Software Development, our product, and the entire company around us?" - Joe countered, "The Scrum Master is a very special role, and if I'd get into those domains, I couldn't meet my own role properly."

What should Joe have done?

The true value of a Scrum Master is their ability to lead meaningful change. The question, "but what is meaningful?" - requires the Scrum Master to know enough about the context to ask the questions that need to be asked. At a minimum, Joe should be curious about what the team is currently doing before proposing any changes.

While Joe doesn't need to be a senior developer, Joe should show some openness and try to learn just enough about development to determine whether any of his suggestions even make sense to someone who does. It's all right if Joe doesn't understand anything about development: sitting down with a developer and having them explain how they work is a fast and easy way to figure out what the team is currently doing. Quite often, when people explain things, they already realize that something "we've always done" just doesn't make sense.

Joe also won't need to understand the details of every single one of the product's features. Without ever having managed a product before, however, Joe's advice to the Product Owner will be of limited value. Joe could start their own pet project - for example, running a Kickstarter campaign. The learnings will be invaluable for Joe.

Joe also should do a reality check: Understanding the organizational context is Joe's job. Indeed, that's the most important thing Joe has to do in order to help the team become effective.

Finally, Joe should invite rather than impose. Instead of telling his team to change their ways of working, Joe could create a link between a pain that people have, and how a specific change could make their life better.

Joe highlights complexity

Joe has learned from coaching that "in complex, adaptive systems, you can't know the outcome until you after tried." Joe uses this line to discourage any form of plan-driven approach, as well as any prediction of outcomes.

When management asked for a delivery forecast, Joe suggested - "we don't know, it's done when it's done." When developers discussed an implementation, Joe suggested - "Why don't you just get started? You'll know later if it worked." Joe's team was unaware of good engineering practice. Joe took it easy - "In the Complex Domain, we don't even know until afterwards whether we needed them."

Eventually, Joe's team got into a real pickle: the low quality product irritated stakeholders. Joe argues, "That's uncertainty. We use Scrum because of uncertainty."

Joe never mentioned that neither complexity nor uncertainty are binary: Things can be more or less complex, and more or less certain. Joe pushed his team into Chaos by removing whatever certainty they had, and making things complex that could have been simple.

What should Joe have done?

Joe's doesn't need to highlight the existence of complexity - success isn't knowing about complexity, it's simplifying until things become manageable.

"Complex" isn't an absolute. Planning, forecasting and good engineering practice could all help to make things simpler. It's just that we shouldn't bet on them.

When Joe's team has to make a forecast, Joe needs to learn what the forecast will be used for, and what the simplest way of providing the necessary information is. Clarifying margins of error and the tradeoff between accuracy and value reduces the complexity of forecasting.

When Joe's team wants to discuss implementation, Joe could probe where the team is uncertain, and what the consequences of a wrong choice are. Planning ahead just enough to avoid poor choices that could be hard to reverse is smart. If Joe was smart, he would even encourage the team to ask, "What will be the long-term consequence of this choice?" - and coming up with possible alternatives before implementing anything. That would reduce the impact of technical debt, which in and of itself causes complexity in other areas.

Equipping people to do the work they need to do can remove a whole layer of complexity in the "How."

Joe shows flexibility

Whenever someone addressed a question to Joe, he displayed his zen-like wisdom by always answering "it depends."

Joe's team eventually got fed up with this answer, because - of course: it depends. They knew that already. But: on what? Joe was missing that part.

During a Sprint Review, a senior developer proudly announced that they had fully automated Joe - the team presented a website with a free form field, and when you hit Enter - a text would appear: "It depends." Joe's manager rolled her eyes - it became Joe's last working day: his default answer wasn't earning him any respect - neither within, nor outside the team.

What should Joe have done?

Yes, it's true that "it depends." The question is: on what does it depend? What are the important factors that we need to focus on? Where are the forks in the road? What makes A preferable to B - and why?

The answer, "it depends" avoids commitment to the inquiry. A conditional answer is only valuable when it reveals viable alternatives or relevant risks.

If Joe doesn't know an answer, the best option might be - "I don't know - let's find out together?"

If Joe knows only one answer, he might state, "The only thing I'm aware of is this. We could research alternatives."

If Joe has limited experience, he might answer something like, "I have experience with this. I know there are alternatives, but I have no experience with them."

Finally, a coach doesn't get paid to be a dictionary. Stating, "I don't know" is not a character flaw. Much rather, it would be a character flaw of Joe to make it look like he has an answer, when really - he doesn't.

Joe keeps the rules

Joe took his responsibility very serious to make sure that his team had a proper Scrum environment where the rules were followed.

Joe's Scrum Team had visitors from other teams during their Daily. As one developer mentioned that there was some issue with a component being worked on by another team, that person couldn't stay silent any more and stepped forward. Immediately, Joe stepped in, "The Daily is only for the team. Nobody except for them speaks." The silenced developer raised his hand and barely could open their mouth before Joe escorted him out of the room: "If you can't follow the rules, you're not welcome."

It later turned out that Joe's team was building incompatible features and their sprint's work could not be integrated without major rework: Joe had successfully stopped the only person who could have helped from speaking up.

What should Joe have done?

Communicating the right things right at the right time is extremely difficult - even if we dedicate our entire life to this topic, we still get it wrong more often than not. The journey starts with a realization that communication tends to be pretty messy almost everywhere.

As a Scrum Master, Joe has to work on helping people communicate more effectively. When they don't know how to do this, Joe has to find out. Blocking necessary communication is never the right solution - someone will always end up with bruises.

Joe's first responsibility isn't simply to make sure that the rules are followed: Where team members lack essential information, or they aren't providing necessary information to others, that's a high-priority impediment that dramatically reduces their effectiveness - and Joe is accountable for the team's effectiveness.

Joe should try to discover where, how and why information flow between the team and outside actors is broken, and work on fixing that. Scrum has very little to say about information flow across team boundaries. When people outside the team are part of the same system as Joe's team, Joe has to find ways to help everyone communicate more effectively, not just the team amongst themselves.

If in the short term, this means breaking the rules of Scrum, Joe should accept this breach, point it out, and ask, "How should we deal with this next time?" Otherwise, Joe risks being called a Scrum Fanatic, who inists on rigorously following the rules, "without reason and against all reason."

Joe protects the team

During a Sprint Review, one of the stakeholders mentions that they're not happy with the outcomes of the Sprint. Immediately, Joe intervenes to point out that the team acted based on available information, and "if you don't give us the correct information - you need to work on that."

On another day, there was a full server outage. It turned out that someone entered data that corrupted the database. Again, Joe was ready: "You have to train users properly. It will take us days to clean this up. You can use that time to train your users properly, so this doesn't repeat."

Yet another day, finance needed some figures to calculate investments. Joe shot down the request, "If we'd help you with that, we're not going to meet the deadline for the trade fair."

Joe was slippery like an eel. Whatever problem stakeholders faced, Joe always found a way to flip it around and make sure that the problem landed somewhere else. This indeed protected his team both from overload and blame. One day, though, a sales executive mentioned to a board member, "They're not helping at all. Each time I meet them, I wish I hadn't wasted my time." - that was also the team's last Sprint.

What should Joe have done?

"Protecting the team" is a responsibility that needs to be considered in context.

Sheltering the team is a short-term mechanism to stabilize the environment. By pushing the problem elsewhere without defusing the conflict, Joe sets the stage for drama that will make things worse for the team in the long term.

Joe needs to show courage by taking ownership of the conflict, and guide parties to resolve it.

Likewise, Joe needs to create an environment where everyone from his team feels confident to courageously say, "Yes, we didn't think of this. Let's work on this and find a solution that works for everyone."

Summary

Did you realize how I managed to sneak the five Scrum Values - Courage, Commitment, Focus, Openness and Respect - as well as the foundation of trust - into the article? Joe becomes a beacon of all that Scrum is, not so much by what he knows - but by being. Every day, Joe can take a few minutes off to reflect in silence, "Which of the things I did today reflect the Scrum Values, and which of my actions don't? What could I do tomorrow, so that I am a living example of what the Scrum Values mean?" Joe could also invite his team, his peers and his management to give him feedback on how they see the Scrum Values in what he does.

We make mistakes. We have setbacks. We act based on what we know today, and tomorrow we may cringe at what seemed like a good idea today. We progress not by trying to be perfect, but by dedicating ourselves to learning. If Joe keeps this in mind, then one day - Joe will be a Master of Scrum.

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. 

The highest priority?

 "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software" - What if it isn't? What if this "highest priority" is myopic?

Ultimately, the goal of every organization is to "survive and thrive."
In product development, we do this exactly by satisfying the customer.
And in software development, we do it in small bites - sooner is better, so that we have data on what's actually valuable.
All that said, the first Agile Principle is merely a means to an end.

I must highlight this because many agile teams - and organizations - aren't built to survive and thrive. They're built to deliver. Deliver earlier, deliver faster, deliver more. Focus on customer value. Ignore everything else.

The result? A dysfunctional organization that subordinates sustainability and growth on a personal and technical level towards the delivery of "business value."

And the result of that? Technical and organizational debt, which at some point incapacitate the delivery of value - people get fed up and leave. The real problems were never addressed, and when this realization hits, it's too late: the team is already broken beyond repair.

"Agile processes promote sustainable development." - they indeed should, but who reads the fine print, when the promise is all about more value faster?

"Doing Scrum" alone is no guarantee that you get sustainable development - not for the product or its technology, but also not for the organization. Organizational development is work exactly like product work. Indeed, the organization *is* also a kind of product. But Scrum Masters and Agile Coaches are often ill-equipped to develop an organization. They lack the competencies, and the mandate, to do so. And managers, whose role is to shape better systems, don't know how to deal with agile teams properly.

Instead of developing better systems, many companies struggle to maintain them while they're degrading and struggle to prevent the eventual collapse.

If that's you - don't despair:

I have summarized 9 principles in the TOP Structure that serve us in ensuring that everything important is considered, helping us avoid treading an unsustainable path:

You can find the official TOP guide here.

They don't replace Scrum or the Agile Manifesto, they focus and highlight the often-forgotten or underappreciated third pillar of "_Product_ _Development_ _Organizations_" - the organization.

Optimize at the Constraint - only!

The Constraint of a system, in a nutshell, is "the most limiting factor." By definition, it determines the capacity of the entire system: if the Constraint is underutilized, the entire system is underutilized. However, if the Constraint is overburdened, no amount of additional input into the system will lead to more output. Many organizations struggle with this - and that has dire consequences!

Let's start by taking a quick glance at the Constraint:

In our example, the third step (C) is the Constraint - because it has the minimum capacity in our system. An important consideration is that we're not talking about investment or staffing here, our concern is the ability to generate throughput.

As an example, if we have a single A costing $100k to generate 50 Throughput, but ten C costing $1m to generate 30 Throughput, then the Constraint is C, not A.

This simple truth has tremendous consequences:

Don't work more than necessary

All of the capacity in our entire system in excess of the Constraint won't help us generate additional throughput. Let's examine what this means in practice:

• Excess capacity behind the Constraint is "idle." It exists, but can't generate throughput. Adding more capacity at this point has no effect.
• Excess idle capacity in front of the Constraint doesn't generate throughput.
• Excess busy capacity in front of the Constraint adds overburden to the Constraint!

The third point is critical - because of the consequences: Let's say our Constraint is a specialist, and work is piling up at their doorstep. Work waiting at the Constraint generates no value for our company. Since someone was asking for that work in wait, these people will start wondering when their request gets served, i.e. they become unhappy. Eventually, the Constraint will be tasked with managing their undone inventory. At a minimum, some capacity gets diverted away from doing actual work - into managing work. At worst, it will reduce their capacity with each piece of work in wait, until they are fully incapacitated and spend their entire time in status meetings, explaining why nothing gets done.

And that brings up an important question:

Assuming you are not the Constraint: should you optimize your own work?

The astonishing answer is: No. And here's why.

Where's your Constraint?

This image visualizes four possible scenarios:

1. You're stream-aligned. The only people depending on you are the customers. 
2. You're behind the Constraint. There's someone, or something, that determines how much work arrives at your desk, and you get less work than you could do.
3. You're before the Constraint. The more you work, the bigger the "waiting for" the Constraint pile grows.
4. You and others are working in parallel. What you do, they don't. What they do, you don't need to.

The image doesn't display the scenario that you are operating at the Constraint, because that's equivalent to being unconstrained: the more you do, the more throughput you get. So - let's examine the above four scenarios.

In scenario 1, you are operating as if you were the Constraint, until you get into a "Before" or "Behind" scenario by overburdening your customers. Here, improvement works in everyone's favor until customers start to scream.

In scenario 2 - you have excess capacity anyways. Customer throughput is limited by the Constraint, so the only thing you can spend your optimized capacity on would be gold-plating. At best, nobody notices. At worst, you'll get scolded for wasting company assets. In any case, your optimization efforts won't win you a medal.

In scenario 3 - your capacity outmatches the Constraint. If you want to optimize the Whole: do less. You can only make a difference by reducing burden on the Constraint, that is: by taking work away from them. If you optimize in ways that allow you to do more work, you'll either get scolded if that makes you idle, or your extra work won't lead to extra customer value. In the latter case, you'll get scolded for not delivering more (even though you did, but the customer doesn't see that.)

When optimization doesn't work

In scenario 4, you're acting similar to scenario 1 - you're essentially the Constraint yourself and optimize accordingly.

That leaves scenarios 2 and 3. In both scenarios, you lose by winning.

Any optimization you do when you're not the Constraint will evaporate, be invisble, or make things worse for the Constraint, and thus for the system, and thus, in extension: for you.

When teams try their best to optimize their ways of working, and see that it either does nothing, or backfires - eventually, they get change fatigue: "Why should we change anything that doesn't help us?"

And that's a core problem with Scrum: The Scrum Guide suggests that teams should identify improvements in every single Retrospective, without considering whether the team is even the Constraint. If you aren't - you won't see anything coming out of your changes. To make  Retrospectives meaningful, identifying and enacting change is insufficient. You have to make sure that the changes are actually beneficial to the organization as a whole.

What now?

Here are four simple checks you can do:

1. If you are the Constraint, do whatever it takes. Do less, do more. Simpler. Faster. Better. It will be noticable immediately, and you may even generate massive leverage. If you're five, and you have 100 people in your organization, every minute you save will have a twenty-fold impact. You'll be celebrated like heroes for even minor improvements.
2. If you're pushing work "downstream" for other teams to pick up, and you see work piling up, do not try to discover ways to do more: Do less. Use the free capacity to pick up work that would otherwise happen downstream.
3. If you're not receiving enough input from "upstream," don't try to do whatever you do better. Instead, pick up work that would otherwise happen upstream.
4. If you see that "downstream" is challenged, and you receive flowback, i.e. defects, complaints, questions or anything that makes downstream wait for you, then you have to improve how you work, so that there's less work to do downstream.