Prioritization isn't what it used to be.

"Prioritization" once meant finding the one, single most important thing. In the Latin root, prior was a singular absolute. There could be only one. But the world accelerated. Hence, the concept fragmented: we started juggling "priorities."

In this post, we'll explore how the historic concept of prioritization breaks down in complex, high-velocity systems, and what a modern, systemic view of "prioritization" looks like.

Where "Prioritization" Came From

For centuries, the term "priority" made perfect sense: Every monastery had one Prior - the one who led the monastery, coordinated its logistics, and gave meaning to the work of the monks. Rulers dealt with events in succession, because information changed slowly: During a public audience, there might have been interrupts, but other than that, everything was coordinated and arranged in a clear sequence. The "Kölner Dom" was built over centuries, and the decision how much labor and funding to allocate to the construction was made many times, across many generations. The world itself moved at a human pace.

The industrial age changed that, and the Internet completely broke us. Communication became instant; execution, however, did not accelerate at the same pace. Suddenly, multiple "first things" competed for limited time and attention.

The POTUS Dilemma

Imagine for a minute, you're the President of the United States. You look at your phone. There are 3 messages:

• China has declared war.
• A rioting mob is storming the Capitol.
• Someone threatens to kidnap your daughter.

You can't ignore any of these issues, but you can only make one call at a time. Which number do you dial first?

That is prioritization!

The Collapse of Time

In 1875, if China had declared war, the message would take weeks to arrive. Today, it would hit every device on Earth within seconds — but the machinery of response still moves at human speed.

The result: information travels faster than action. Decisions are always chasing relevance. “Prioritization” becomes less about choosing and more about adapting.

The Decision Loop

When people at operational level claim "prioritization failure," they usually mean, "management failed to decide what not to do." But that's just passing the buck. It fails to acknowledge that there's a much deeper, systemic design issue: it's not that easy.

Every organization today runs through the same cyclical funnel:

• Information: What do we notice?
• Decision: Which trade-offs do we accept?
• Action: Who acts, when, and with what resources?
• Result: Which outcomes count as meaningful?

Prioritization doesn’t happen once inside this loop. it happens continuously, at every stage.
And whereas in the past, it was quite easy to run this cycle maybe once a quarter at board level, today, even a day hardly cuts it.

Where Prioritization Really Lives

We must get beyond the concept that "Prioritization" is the management activity of deciding which work gets done and what doesn't get done. While not totally wrong, it misses the mark. Practically, "Prioritiztation" is not a management-only act. All the cognitive filters we apply to our environment are acts of prioritization - do we pay attention first to our own area, or to the system? Do we pay attention to the short term, how much attention do we pay to the long term?

When organizations struggle with "prioritization," it's rarely because "management doesn't decide properly." It’s because the system is designed in a way where prioritization flow naturally across the loop in an effective manner.

The task of leadership, then, is not to pick individual projects, tasks or activities from a pre-defined list of options - but to design how prioritization happens.

Conclusion

"Prioritization" is a concept from times gone by, where the speed of information was measured in days, and the world's information could be measured in books. Today, we're dealing with information arriving within seconds, and every day, the Internet is flooded with more new information than the world's biggest library could contain. The context is no longer one where we can easily sequence our activities, without loss of outcome quality.

The core issue is an inability to sense, interpret, and adapt quickly enough to retain focused on what truly matters.

As information accelerates, and as AI begins to process it at near-light speed, the meaning of "prioritization" will shift from choosing actions to defining value systems which enable full-automating not only the decision of which information is important, but also determining the impact: What needs to change, and who needs to be informed.

The real question we need to answer in prioritization is not about work packages. It's about the information we need to send, and to process.

The challenge is not coming up with an ordered task list. It's how we keep it relevant in real time.

"Agile" is not sacred

Some people believe that "Agile" or the ideas propagated by Agile practitioners should not be criticized. They view such criticism as a lack of understanding of Agile or disrespect for Agilists. I disagree. Let's delve deeper into this matter and explore how criticism intersects with science, reasoning, and growth intersect to bring Agile principles to life.

Agile is not a Religion

It's tempting to defend Agile against criticism. But this turns the pragamtic, empirical approach into religious zealotry - We shouldn't hold a Holy Writ or Prophets over observable truth and evidence: Agile is not dogmatic. It thrives on openness, interaction, and an objective dissemination of plausible ideas. Treating it as an unassailable dogma turns this dynamic way of doing the best thing possible into a cultic practice.

The Cult of Dogma

Trying to staunchly defend "Agile" against critique creates a paradox: Agile, by design, thrives on openness, interaction, and the pursuit of better solutions. Turning it into a dogma stifles progress and growth. Dogmastism —whether religious or ideological— resists questioning and dissent. Agile, however, would welcome both.

Agile is Dynamic

"Agile" isn’t etched in stone: it’s living, evolving. Its core values highlight the need for continuous reflection and adaptation. Agile practitioners must embrace critique as a catalyst for growth.

Science and Agile: Kindred Spirits

"Agile" was conceived out of frustration with heavyweight project management methodologies that led to more failure than successes. Its founders sought an alternative that valued interaction, collaboration, flexibility, and responsiveness. That's the opposite of religious dogmas: Agile doesn’t demand unwavering faith. Instead, it encourages empirical experimentation and adaptation.

A place for skepticism

Scientific progress hinges on skepticism, curiosity, and the willingness to challenge prevailing theories. Agile shares this spirit. When practitioners question assumptions, experiment, and learn, they embody the scientific mindset. Agile’s empirical approach encourages us to scrutinize practices, discard what doesn’t work, and refine what does. It’s a departure from dogma, where adherence trumps evidence.

Welcome Valid Critique

An idea or practice that can’t withstand criticism is inherently flawed. Rigorous examination sharpens our tools. When criticism arises, we need to either debunk the critique with evidence or adapt our approach to the criticism. Agile’s resilience lies in its ability to evolve based on valid feedback. It doesn't coincide with flat out rejecting uncomfortable ideas.

Lab conditions

Imagine Agile as a laboratory: a space where hypotheses are tested, results analyzed, and theories refined. Just as scientists revise their models based on feedback and empirical evidence so do Agile practitioners need to do. A laboratory mindset encourages us to embrace critique, learn from failures, and iterate toward excellence.

No Sacred Cows

As long as we stick to our assumptions irrespective of the evidence, we will struggle to produce best possible outcomes.

Letting go of ideas

Metaphorically speaking, Agilists need to wield a cleaver to butcher sacred cows — those unquestioned beliefs or practices that stand between us and excellence. This helps us evolve, learn from mistakes, and refine our approaches.

Being flexible

Agility relies on flexibility, adaptability, and learning. Rigidity stifles growth. By remaining open to change and questioning established norms, we create an environment where innovation thrives.

Scrutiny and Validity

Ideas need to be subject to constant scrutiny. Rigorous examination sharpens our understanding and ensures that only the most reliable concepts are propagated. Emotional reactions or thought stopping hinder progress.

The Crucible of Scrutiny

Agile thrives when subjected to rigorous scrutiny. Just as metals are refined in the crucible, Agile ideas are honed through examination. When we question assumptions, we refine our understanding and discard what doesn't hold up. Scrutiny isn't a threat; it's a catalyst for growth.

Emotional Resilience

Emotions have their place, but they're often a bad advisor when dealing with criticism. It's natural to respond to critique with an emotional reaction that clouds our judgment. Reason, logic and evidence are much more reliable guides when emotions flare.

Constructive Criticism

"Agile" benefits from constructive criticism. Rather than approaching dissent with negativity, we can understand it as a means to foster growth, refine our practices, and elevate our performance.

Avoid Buzzword Bingo

"Agile" arguments often deteriorate into buzzword bingo — where catchphrases replace substance. Avoid jargon and focus on substance: Show me the "better way" with clarity, backed by evidence. Buzzwords won't impress anyone looking for serious answers.

Be Positive

Criticism is not an attack that needs to be defended against. Instead of shutting down the question, let's open up a conversation. By challenging assumptions, we contribute to growth. But likewise: Simply lashing out at something stifles progress. This won't lead to improvement.

Be Reasonable

Ad hominem attacks and Gaslighting have no place in a collaborative environment. Instead, let's engage in thoughtful reasoning. When you disagree, present your case logically. "Agile" thrives upon the respect of differing viewpoints, perceiving uncomfortable questions as invitations to learn.

Summary

Agile isn't a fixed monument; it's a dynamic garden. Water it with constructive criticism, prune away dead branches, and watch it flourish. Let's cultivate growth, learning, and respectful discourse.

Understand Perspectives

Quite often, people jump on a point they disagree with using statements like, "You are wrong," or "You are ignorant ..." While the second has some merit when people literally talk about subjects they are unfamiliar with - the issue we need to talk about is the matter of perspectives. Everyone, regardless how informed, has a perspective based on where they stand. Let us discuss how this understanding helps us build better communication and relationships.

Whenever we interact with others, understanding and appreciating diverse perspectives is crucial for effective communication. Assumptions and assertions as well as our own bias can easily have us miss important points, fail to build agreement, and ultimately result in failure to come up with an effective way forward.

Who is right?

In the pursuit of truth and understanding, we quickly encounter contrasting perspectives. In order to pursue growth and collaboration, we need to acknowledge diverse viewpoints and also successfully navigate conversations to come up with solutions.

Assertive statements like "You are wrong," "You should ..." or a sentence that categorize the person are often hastily thrown into the discourse, with consequences that reach far beyond the statement itself.

This style of communication hinder productive dialogue and pollutes the atmosphere - individuals who get attacked with such statements are less inclined to explore, learn, and collaborate:

Defensive Reactions

Statements asserting that someone is "wrong" or "ignorant" come across as verbal violence and can trigger defensive reactions. People become less open to considering alternative viewpoints and focus more on defending their own position.

Communication Breakdown

Assertive language without considering the other person's perspective may lead to a breakdown in communication. It can create a hostile environment where participants feel attacked rather than engaged in a meaningful discussion.

Strained Relationships

Telling someone what they must think strains interpersonal relationships, as this implies an imbalance of power. Building mutual respect and understanding becomes challenging when communication is characterized by one-sidedness.

Closed-Mindedness

Assertive statements often contribute to a closed-minded atmosphere, where participants are less likely to engage in open-minded exploration of different ideas. Feedback that a perspective is not welcome will hinder the potential for collective learning and growth.

Barriers

When dismissing another person's perspective outright, they are unlikely to consider the perspective of the dismissing person more valid than vice versa. With this default position, dialogue is extremely challenging.

Missed Opportunity for Understanding

Categorical statements may close off opportunities for understanding the nuances of the other's viewpoint. They often assume a binary right-wrong dichotomy, neglecting the possibility that both perspectives can offer valuable insights or even overlaps.

Ten tips to improve your communication

Aggressive language is evitable. Instead of using confrontational language, here are some tips for a more constructive approach:

Express Curiosity

Instead of asserting that someone is wrong, express curiosity about their perspective. Ask open-ended questions to understand their reasoning and the experiences that shape their viewpoint.

Listen Actively

Practice active listening to truly understand the nuances of the other person's perspective. Engage in the conversation by paraphrasing, summarizing, and asking clarifying questions. This demonstrates a genuine interest in their viewpoint.

Adapt and Connect

Be aware of the different cultural backgrounds and adapt your communication style accordingly. This fosters a respectful environment and also promotes effective understanding.

Seek Common Ground

Identify areas of agreement or common ground before delving into differences. This can create a foundation for more constructive discussions.

Acknowledge Agreement

Acknowledge valid points from the other person's perspective. Recognize areas of agreement to build rapport and establishes a foundation for finding common solutions to shared challenges.

Use "I" Statements

Share your own perspective using "I" statements to convey your feelings and thoughts without implying anything about the other person's perspective.

Offer Information

You may believe the other person might benefit from additional information. Consider sharing it in a way that is informative and invokes curiosity. Prescriptive suggestions trigger defensive mechanisms, and these do not advance the conversation.

Be Patient

If your perspective is not immediately understood, exercise patience and elaborate your perspective. Use clear and concise language, provide examples, and repeat your key points to ensure effective communication.

Frame respectfully

Frame disagreements as differences in perspective rather than absolute right or wrong. This allows for a more respectful exchange of ideas.

Stay Constructive

Apply constructivism when you offer feedback. Focus on the specific behaviors or ideas that you want to address. Avoid making personal attacks. This encourages a positive and solution-oriented atmosphere.

Don't worry if you miss out on using these occasionally - it takes a lot of practice, self-awareness and patience to master these.

Conclusion

In the complex landscape of communication, the ability to navigate diverse perspectives is not only a skill but a necessity. By adopting a mindset of curiosity, empathy, and open dialogue, we can transcend the limitations our own biases and beliefs. Avoiding the use of overly assertive language helps us create environments conducive to mutual understanding and collaboration. As we engage in discussions, let us remember that true progress lies not in scoring points by declaring someone "wrong" - but in our collective willingness to explore, and embrace the richness of human experience.

It takes a tremendous amount of courage to open up a controversial perspective when the response might be backlash, personal attacks or outright bullying. Ask yourself: Do you want to be the person who makes it easier, or harder, for others to say what they think? Do you want to be the one who builds bridges, or burns them? Do you want to work towards understanding - or hostility?

With that, I would leave you with the following default stance - whenever someone starts a conversation,

Assume Positive Intent.

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!

The power of stakeholder promises

In the dynamic world of product management, one thing remains constant: the importance of stakeholders. Whether they're customers, employees, investors, or partners - stakeholders play a key role in the success of your product. How can you ensure that you're meeting their expectations and delivering on your commitments? The concept of "Stakeholder Promises" gives you an answer - so let's explore.

And since we're at it, let's start out with an example of stakeholder promises for this article:

Our promises to Product Owners:
1. You will build better products.
2. You will enhance your professional credibility.
3. You will have more effective stakeholder interactions.

The importance of Stakeholder Promises

Stakeholder Promises play a crucial role in guiding your product development journey. They are more than just commitments; they are the pillars upon which trust, credibility, and alignment with organizational goals are built. Focusing on Stakeholder Promises empowers Product Owners to navigate the complex landscape of stakeholder expectations effectively.

Alignment of Goals and Needs

Stakeholder Promises reflect on your values and your commitment to various stakeholders. By aligning your product with these promises, you keep the work in sync with the broader objectives of the company.

Trust and Credibility

Fulfilling Stakeholder Promises demonstrates your dedication to meeting stakeholders' expectations. This, in turn, builds trust and credibility with your customers, employees, partners, and investors.

Effective Prioritization

Defining Stakeholder Promises helps you prioritize features and enhancements that truly matter to your stakeholders. It's a compass that guides you in making informed decisions about what to build next.

Transparency and Communication

Promises serve as a foundation for transparent communication. You can openly discuss how your product aligns with these promises, fostering a sense of inclusivity and cooperation among stakeholders.

What Are Stakeholder Promises?

Stakeholder Promises are explicit commitments made to various stakeholder groups. These commitments are derived from the vision and encompass a wide range of areas - from customer satisfaction over employee well-being all the way to ethical business practices. Essentially, they represent the organization's pledge to contribute positively to the well-being of all stakeholders.

Take the example of Yamaha, where you see promises made to customers, employees, business partners, communities, and even the environment: These promises form the foundation upon which their products and operations are built.

Defining Stakeholder Promises

Here's a simple process that you can apply for defining meaningful Stakeholder Promises:

Step 1: Identify Product Vision

The foundation of Stakeholder Promises lies in your product's vision. Start by clearly defining your product's vision, which serves as the guiding force for all your commitments.

Step 2: Identify Key Stakeholders

Identify the primary stakeholder groups relevant to your product. These may include customers, employees, investors, partners, and other parties with a vested interest in your product.

Step 3: Relate Vision and Stakeholders

Establish a clear connection between your product's vision and the needs, expectations, and aspirations of your identified stakeholders. This step ensures that your commitments align with your product's overarching goals.

Step 4: Define Everyone's WIIFM

For each stakeholder group, define the "What's In It For Me" (WIIFM). In other words, articulate what value, benefit, or impact your product promises to deliver to each group. Be specific and consider how your product addresses their unique needs and concerns.

Step 5: Make Specific Promises

Make your promises effective and actionable:

• Make your promises specific, so there's no ambiguity about what you aim to achieve.
• Quantify your commitments wherever possible. This allows you to track progress and measure success objectively.

Step 6: Collect Feedback

Before finalizing your Stakeholder Promises, share them with the relevant stakeholder groups and seek their input. Such an initial round of feedback provides valuable insights and ensures that the promises resonate with your stakeholders.

This step-by-step guide will equip you to define Stakeholder Promises that are clear and actionable, and also well-aligned with your stakeholders' expectations and your organization's mission.

Successfully using Stakeholder Promises

Here are six tips to support you in maximizing the impact of your stakeholder promises:

Align your strategy: Your product and any work done on it should directly contribute to fulfilling your stakeholder promises - or at least: not contradict them.

Prioritize: Stakeholder promises help you prioritize what matters: Features that directly address one or more stakeholder needs or expectations have more impact on your product's success.

Communicate: Use Stakeholder Promises as a basis for transparent communication. Regularly update stakeholders on how your product aligns with these promises and any progress made.

Seek feedback: Actively seek feedback from stakeholders, especially those for whom promises have been made. Act on what you learn to improve your product.

Continuously improve: Frequently revisit your stakeholder promises, keep them up to date, and use them as a benchmark for improving both your product and pactice.

Be Responsible: Actively align your actions and outcomes with the standards outlined in Stakeholder Promises.

Conclusion

Never underestimate the power of Stakeholder Promises: They serve as a guiding light, directing your product development efforts towards fulfilling commitments to your customers, employees, partners, and the broader community. By understanding, defining, and leveraging these promises effectively, Product Owners and teams can build products that meet and exceed stakeholder expectations, while simultaneously contributing positively to the well-being of all involved parties. By paying attention to your stakeholder promises, you'll not only create better products - you also build trust, credibility, and sustainable relationships with your stakeholders.

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.

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?

Why we need clearly defined goals

 A common issue I observe in many organizations - there's no visible goal beyond, "Get this work done," and people don't even see the point in "wasting time to set a goal." The problem: many organizations are just tactical engines generating work and handling exceptions in the generated work. Yet, most of this work has no goal. Goal-setting is not an esoterical exercise, and here's why.

The Hidden Factory

One concept of Lean Management is the "Hidden Factory" - and this concept deserves some kind of explanation. A factory is an institution that applies work to input in order to generate some outputs. So far, so good. A "hidden factory," on the other hand, is a factory within a factory, doing work without generating viable outputs: either nothing - or waste.

To understand the problem of hidden factories, think like a customer.

You get the option to buy your product from one of two providers.

Company A has a straightforward process, turning raw input into consumable output, and Company B has a process that turns the same input into something, then into something else, then into something else, then into the same consumable output.

This extra work makes Provider B's product is more expensive to produce, without any discernable difference to the product sold by Company A.

Company A and Company B thus sell products which are identical in all aspects - except price. Company B has to charge a premium to cover the extra work they do. Which product would you purchase?

As customers, we do not care how much work is required to do something. Given all other things equal, we choose to opt for the cheapest, fastest way of meeting our needs.

And companies are no different here. But how does that relate to goal-setting?

Induced and intermediate work

Many companies are great at inducing work - and once that work has been induced, it becomes necessary, and the people doing it must do it, otherwise the outcome can no longer be achieved.

Let's pick a practical example.

We have chosen to use a Design Process that requires any changes to be made as a sequential series of steps:

1. Request the element to be changed
2. Describe the change to be made
3. Prototype the change
4. Validate the change
5. Implement the change
6. Verify the change

While you may argue that all of these steps are common sense and necessary, our specific process choice has just locked us into a process that turns replacing an image into a full day's work - a change that could be done by a competent developer in a couple of minutes.

How is that relevant to goal-setting?

Confusing Task and Outcome

Referring to our fictional process, an individual may have the specific responsibility of describing changes. Their input is a change request, and their output is a change description. As a customer, I address this organization to say, "I want a new backdrop on my website." Our execution agent of step 2 will say, "I am overburdened. I have too many change requests on my desk. I need someone to help me describe the changes." If we would ask them "Why do you need to describe the changes?" - they might say, "So that they can be prototyped." If we'd press and ask, "And why do they need to be prototyped?" - the answer could be, "So that we can validate the change." - which, of course begs the question, "And then - I get what?" - "An implementable change."

You see where this is going: Everyone has reasons why they do the things they do, and from the way this organization is set up, their reasons are indeed valid. And still, nobody really understands why they do the things they do. 

We should assume that everyone whom we ask should answer, "So that you can get your new backdrop." In many companies, however, that is not the case.

And that's where goals come into play.

Goals

Every company has a few - usually very few - first-order goals, and a specific context that provides constraints within which these goals can be realized. Surviving and thriving on the market is a baseline almost all have, and most of the time, the primary goal is to achieve this by means of advancing the products which define the company. That would be an example of a first-order goal.

From that, we get into second-order goals, that is - into derived goals which help us achieve this primary goal. Build a better product. Build the product better. Sell more. Sell faster. Sell cheaper. You name it.

These, of course, would be realized via strategies - which in themselves have multiple subordinate goals. For example: Increase product quality, add features to the product, reduce discomfort with the current product, improve perception of the product in its current state - again, the possibilities are endless.

At some point in the rabbit hole, somewhere deep down in the loop of operational delivery, we may then see a business analyst stating, "I am overburdened. I have too many change requests on my desk. I need someone to help me describe the changes." - but why are they doing it? Are we describing change in order to increase product quality, in order to sell more, or to sell cheaper?

It's easy to realize that "adding people to do the work" may indeed make sense when our goal is to add features to improve our product. And yet, it seems entirely backwards when our goal is to "sell cheaper."

That's why we are setting goals. It allows everyone, on all layers of an enterprise, regardless of their specific responsibility, to quickly and easily determine, "Do the things which I am doing help us achieve our goals?"

If the answer to that simple and straightforward question is, "No" - then this begs two followup questions:

• Why am I doing things which are not helping this company achieve its goals?
• What do we need to change, so that I am contributing to our goals?

The impact of goals

Well-defined goals immediately expose the Hidden Factories and induced work, and they set the stage for reducing waste in our processes as well as leading employees to do more meaningful, more important work.

Poorly defined goals - such as "to do X amount of work" - encourage establishing and inflating Hidden Factories, and they set the stage for wasteful processes and unhappy employees who may be doing totally worthless work, without ever realizing.

Undefined goals - or the absence of goals - remove the yardstick by which we can measure whether we are contributing to anything of relevance or merely adding waste. Without a goal, work is meaningless and improvement impossible.

The importance of goals

Goal-setting is important for organizations both large and small in:

1. Guiding decision-making
2. Enabling Improvement
3. Eliminating Waste

While a goal itself doesn't do any of these, a goal sets the stage for these. Once you know your goal, you can take it from there.

Decision-making in an agile organization

A challenging question in Agile organizations is: "Which decisions should be made where?" - we quickly end up in a heated debate of "team autonomy versus command and control." A red herring - and a false dichotomy that misses the big picture. There is a better way.

Making decisions

Let us first discuss briefly about the three ways that decisions can be made in companies:

Top-Down

Traditional organizations may be most familiar with this type of decision. When something needs to be decided, a manager needs to be informed about what is to be decided, preferably also with some information on the consequences of various decision types. At a convenient moment in time, the manager will decide, and the affected parties will act based on the decision.

Depending on how information is presented to the manager, the manager may decide based on an unknown bias. Managers are often unable to fully understand the consequences of their choices. In turn, teams have to deal with consequences that may not even make sense to them, but they lack the power to change things. The system encourages currying favor over full transparency, and a "making things look good" is worth more than "doing what is right." 

A lot of time is lost in presenting information to management in order to prepare the decision, even when the decision is seemingly obivous. Revising the decision requires significant evidence as well, even after the negative repercissions are already visible. Hence, top-down decision on the work are rarely efficient, effective or even helpful. And that's why they are avoided in leaner organizations wherever possible.

Autonomy

Agile organizations, especially those centered around Scrum, emphasize team autonomy - and thereby, autonomous decision making. Many developers don't like managers interfering with their work, and prefer this way of making decisions. Some get very religious on the "autonomy" part, and will insist on teams getting their way.

Autonomous decisions are both feasible and efficient when the team operates in isolation: As long as it works for the team, we're good. When the team isn't happy with a choice, they can quickly revise it and improve.

Team autonomy sounds great, but isn't a feasible approach when multiple teams interact.

Let's say that team A would like to define a customer as firstName and lastName referenced by customerID, and team B would like to define the customer as fullName and title referenced by customerRefID: Who is right?

If A and B decide autonomously, the system won't integrate, so everyone is "wrong."

Should management decide?

That brings us to the third option, which requires willingness to compromise:

Federation

Let us redefine team boundaries to objective boundaries. People contributing to the same goal, working in the same context, or on the same products, need to collaborate, lest they get stuck dealing with friction rather than making progress.

In larger organizations, we have multiple teams. They might be planning, working and delivering independently - yet, at some level of abstraction, they share the same goal.

As an example, if we're working on an Online Shop, we benefit little if our checkout process is optimized at the expense of user registration: our total revenue might go down if we force people to provide payment data upon registration already. Neither the "Checkout," the "Payment," nor the "Registration" teams can autonomously decide which approach is the best - they need to collaborate!

Thus, a "federation" is born: People whose work overlaps for one reason or another can federate. A federation compromizes on local autonomy to optimize globally. We have some centralization, and some decentralization, and we apply a higher-ordered decision framework to determine both how, and what, we need to centralize.

A federation offers us fast and efficient team-level decisions, as well as sustainable and effective overarching decisions.

Guardrails of federated decision-making

A number of common pitfalls can render a federation ineffective:

1. Not involving people who are affected by outcomes.
2. Involving people in the discussion who aren't involved in the outcome.
3. Forming decision queues.

This happens when we violate the general rule of thumb that any federation should decide as little as possible, and as much as necessary. 

The following decision-making flow can assist us in determining which decisions we would like to keep autonomous, and which are better to federate.

In sequence, we can ask three questions to determine whether we require a central federated decision session:

1. Will the decision affect others?
• We only need to involve those who are affected.
• If we affect nobody outside the team, we don't need others to agree.
2. Will the decision have long-term impact?
• Easily reversible choices can be subjected to experiment, and inspecting outcomes.
  
• Decisions that have a high cost of change require deeper discussions.
  
3. Is the decision highly time-critical?
• If there is a high cost of delay, "it's easier to ask for forgiveness than get permission."
• If cost of delay is lower than cost of change, the decision should be made centrally.

As we know from governments, federation has a cost attached and easily leads to bureaucracy. Hence, with every centralized decision, we should inspect and adapt on, "What are the costs and benefits of centralizing this?" - and, "Are there things we could change so that we could do this autonomously?"

The different definitions of Agility

One reason why getting different people on board in an agile initiative is because they may not understand what's in it - for them. We can put the different perspectives together by looking at the different definitions of agility. This allows us to negotiate better with people who have a different focus in their own work and gain their support for change.

Everyday definition

"Move quickly and easily." - Cambridge Dictionary

Note the two vectors here: Speed and effort. This definition doesn't focus on externally imposed change. Although only implicitly, it is primarily concerned with the ability to reach one's goals.

Managerial definition

Acting according to the current situation - Peter Drucker

“The greatest danger in times of turbulence is not the turbulence: it is to act with yesterday's logic.” 

Change is only a problem when we're not able to think and act in a manner suitable to the new circumstances. We must be sufficiently flexible to adjust when something unexpected happens.

Financial definition

"Turn on a dime for a dime." - Craig Larman 

There are business opportunities every day. Many businesses can't capitalize on opportunities for two reasons: Either, the cost of grasping the opportunity outweighs the gains from the opportunity (i.e., a negative business case). Or, the window of opportunity expires before we can grasp it.

Technical definition

"Minimizing the cost of change for code." - Kyle Griffin Aretae

"Cost of change over the long term is almost the only thing worth paying attention to when working in code. It's more important than doing any individual feature requested most of the time."

The initial creation of code is marginal compared to the cost of maintaining or changing the code. We have high code-level agility if there is a low cost of change for our code, and low code-level agility if we are spending a lot of time, energy and money to change our code.

The different focus

Looking at this diagram, we see that no single definition is all-encompassing - and that there is only a small overlap between them.

Hence, we have to be clear what we are setting out to achieve, and how we would like to achieve it.

• Do we want to increase sustainability and reduce effort? Unless we can tick these boxes, developers most likely won't care.
• Do we want to become more adaptive and faster? That makes our initiative interesting for management.
• Do we want to reduce cost and increase profitability? Otherwise, let's not assume finance will support us.
• If we're not in it to get more done in less time, surrounding stakeholders - like Marketing, Sales or Customer Service, won't care.

We can't dogmatically insist that we want to do only one thing, like increasing adaptability, because we'd struggle to get anyone to support this. Instead, we can use these different perspectives to have deeper conversations as to what people need from a change initiative, and how they would like to become part of this change.

And - the Customer?

Frankly - as a customer, I don't care about your agility. 

I care that I get what I want, how I want it, when I want it. How you do it - your call.

The Agile Tragedy of Commons

There's a socioeconomical dilemma called, "Tragedy of the Commons" which effectively means, "In unregulated systems, local optimization may become so extreme that the system becomes unsustainable."
And here's why you need to understand it in order to understand "agility at scale."

Before we get started, though, let me explain the dilemma:

The Tragedy of Commons

Imagine there's a huge, pristine green pasture. The lord of the land has decreed that everyone is free to use this pasture for shepherding their flock.

The first shepherd who arrives finds a vast green pasture, and the flock is happy to graze on the fields.

Soon afterwards, another shepherd arrives, and their sheep graze happily on the lush pasture as well. Both shepherds are happy, as their sheep have ample food to eat.

In the excellent conditions, the flocks multiply.

As the flocks grow, there is no longer an overabundance - the sheep of the two shepherds begin competing for food. The first shepherd's sheep had more time to multiply, and the second shepherd's sheep lack the required conditions to multiply freely.

Both flocks compete over increasingly scarce food: the sheep lack nutrition and are threatened from starvation. The first shepherd feels that the second shepherd's presence has caused this threat to their flock. The second shepherd considers the first to be using their unfair advantage of having a bigger flock to drive them off the pasture. Quarrels arise.

The feudal lord settles the dispute by dividing the once lush green pasture into an allotted segment for each shepherd, based on the size of their flock. Both shepherds now have access to less land than they could access before - but each now has full control over their flock.

Should the lord have settled the dispute in this way? Should the lord have found another solution? Take some time to think. What would have happened - had the lord not intervened?

Tragedy of Agile Commons

There are many, and massive, applications to the Tragedy of Commons in the realm of software systems - moreso in scaled environments. In the land of Agile, they're much more visible than in the land of Waterfalls, where the lots are already divided before they exist: Agile teams incrementally and empirically discover their next best move based on where they are today - perfect preconditions for the Tragedy of Commons.

Common Code

Teams who haven't learnt discipline in code will find it highly irritating to see one developer interfering with another developer's code: "my" coding style is always better than "yours."

Quickly, quality problems begin arising on the Common Codebase: quarrels over style, functionality placement, inconsistencies and many others.

As more and more developers enter the scene, the tendency for code silos built around personal preference, coding style, technologies, or even domains increases.

Whereas one team can often be left to freely roam the green pastures of service implementation, the field quickly turns into a brown quagmire when multiple teams all play their preferences, until the code base becomes entirely unworkable.

Once teams build fences around their codebase, Collective Code Ownership becomes a thing of the past, and Component Teams find themselves entertaining a dreadful nightmare of coordination meetings.

Better approaches could be:

• code conventions
• linting rules
• cross-team Pairing sessions
• Code dojos
• Continuous Integration / Continous Delivery

- but these things are all topics large organizations struggle with after the code has been divided into silos.

Common Innovation

A green field project is often a great way to introduce new, more powerful technologies that allow teams to do less with more.

As the development organization matures, and standards begin to shape the landscape, new ideas becomes exotic and marginal, struggling to overcome inertia.

Imagine - just for example - introducing agent-based logic into an architecture driven by RPC's and SOAP requests: There will be few takers for such an innovation.

The Tragedy of Common Innovation is that new ideas have to find a really small niche when the field is already taken by old ideas. Many good ideas go extinct before they can catch a hold.

With a constant decline of innovative ideas, organizations eventually find themselves investing massive efforts into servicing outdates ways of working and technologies, incapacitating their ability to deliver high value to the customer in the same ways others do.

Better approaches might be:

• innovation allotments
• hackathons
• innovation sessions
• innovation champions
• cross-team collaboration on innovation
• intrapreneurship

Common Meetings

Have you ever been in a 2-hour meeting with 40 people? Did you ever pay attention to how many people actually speak? Hint: it's most likely not an even distribution.

Small organizations find their meetings very effective, but as more and more people appear on the scene, meeting effectiveness quickly declines. And there's a reason.

In an effective 3-people, 1-hour meeting, every person gets to speak roughly 20 minutes. That's a lot of time to voice ideas, offer feedback and draw conclusions. That's a 33% activity ratio. And everyone has pretty much the same understanding afterwards.

When we constrast this with a 30-people, 2-hour meeting: Simply by dividing clock time, we see that every person gets to speak an average of 4 minutes, while being forced to listen for an average of 116 minutes: The ratio of ideas contributed versus passivity is staggering for each individual - the activity ratio has dropped to a mere 3%! In such a scenario, the tragedy of common meetings becomes that some of the more experienced people take the stage, and everyone else becomes decoration.

Solution approaches might be:

• focus sessions
• using a need-to-know principle
• Law of Two Feet
• breakout sessions
• topic ownership

Specialisation also removes the need for everyone to participate in all discussions.

The tradeoff is mainly between not everyone getting firsthand information and people suffering through hours of only marginally relevant meetings. To any solution, there's a downside.

Common Work

A single developer can work on any code at any time, and there will be no unpredicted side effects like merge conflicts caused by others' work. Small teams will usually learn quickly how to coordinate so that they minimize mutual interference.

Without good engineering practice, delivering a larger, integrated piece of software means lots of simultaneous changes in many places. Teams will either get into a Riverdance of constantly stepping on each other's toes, or they will require so much coordination that things get really messy. Of course, the "solution," is - once again - code silos and dependency hell: productivity tanks as risks and delays rise skywards.

Every developer joining an organization that hasn't managed to deal with the Tragedy of Common Work adequately, will make every developer's productivity decline - up to a point where the net productivity gain of hiring additional developers may be negative, i.e. with each new hire, the organization gets less productive overall!

Potential solutions could be:

• visual dependency management
• domain separation
• decoupling
• joint roadmap planning
• cyclical synchronisation points
• communication by code

Now what?

These are just four examples of how the Tragedy of Commons matters a lot in a Scaled Agile setting, and there are a vast number of potential commons.

Regardless of whether an Enterprise is new to agile ways of working or have been doing so for a while: you need to establish overarching rules that mitigate the conflicts, lest you run afoul of the Tragedy of Commons.

The "Tragedy of Commons" is entirely evitable in a holistic system where every participant sees themselves as an integral part of the whole. The solution is coexistence and collaborative conflict resolution rather than competition.

Ground rules address unregulated, harmful growth, a lack of discipline, and myopic actions, but each rule comes with a drawback: it reduces flexibility. While Team Autonomy needs boundaries where these are for the Greater Good, it's important to set these boundaries wisely, and revisiting these where they aren't useful. That can't be done by only one group - in a common system, it has to involve all those whom it concerns.

Which boundaries will you set to prevent your organization from suffering the Tragedy of the Commons, and what is their cost?

Improving Code Reviews

A "code review" activity is part of many organizations' development process - and oftentimes, it sucks. It frustrates people, wastes their time and the value in improving quality is questionable at best. If you feel that's the case, here are some things you can try.

What's a Code Review?

"Code review" is a feedback process, fostering growth and learning. It should not be confused or conflated with a QA sign-off process. While finding problems in the code may be part of doing the review, that's not the key point.

So-called one-way "gate reviews" without feedback on defect-free code are a waste. A major portion of their value is missed. The best reviews won't merely help people learn where they messed up - they help people find new, better ways of doing things!

Now, let us explore five common antipatterns and what we could do about them.

Five Code Review Antipatterns and how to deal with them

Review Hierarchy

In many organizations, the Code Review process "puts people in their place": A more senior person reviews the code of more junior persons, and annotates everything that these did wrong. Yes - this sounds exactly like a teacher grading a student's term paper, and the psychological implications are very similar.

While this does indeed foster some form of learning, it creates an anhedonian mindset: the key objective of the coding developer is to avoid the pain of criticism and rework. There is little joy in a job well done. Deming's 12th point comes to mind.

Suggestion 1: Reverse the review process. Let the junior review the senior's code, and see what happens.

Suggestion 2: Do review round robins. Everyone gets to review everyone else's code.

Suggestion 3: Have an open conversation, "How do Code Reviews affect our view of each other's professionalism?"

Huge Chunk Reviews

I'll admit that I've been both on the giving and receiving end here: Committing huge chunks of code at once and sending thousands of lines of code for review in one big bulk, without any comments. And the review outcome was, "This is garbage, don't work like that!" Rightly so. Nobody in their right mind has time to ponder such a huge amount of changes in detail. The review feedback will take a long time and probably not consider all the important points - simply because there are too many.

Code Reviews shouldn't create a huge burden, and they should have a clear focus.

Suggestion 1: State the review objective: What would you like feedback on?

Suggestion 2: Send increments into Code Review that can be thoroghly reviewed in no more than 15 minutes.

Suggestion 3: Reduce feedback intervals. For example: no more than 2 days should pass between writing a line of code and getting it reviewed.

"LGTM" or whimsical feedback

Poor reviews start with the premise that "the only purpose of a review is to find problems." On the positive side of the spectrum, this leads to a lot of a standard "lgtm" (Looks Good To Me) annotations as code is simply waved forward. On the opposite side of the spectrum, some individuals feel an almost sadistic need to let others know that there are always problems, today stating "this is good", and tomorrow stating "this is bad."

Behind this antipattern is the "controller mindset" that someone in the organization believes that a review is intended to tell others, "you did this wrong, you did that wrong." 

You can improve this by moving away from checking the code towards positive reinforcement, creating virtuous learning cycles. 

Suggestion 1: Change the guiding question from, "What is wrong with this code?" towards, "What could I learn from this code?" 

Suggestion 2: Create Working Agreements how you want to deal with extreme ends of the review spectrum.

Suggestion 3: Collect the learnings from Code Reviews and look at them in the Retrospective.

Ping-pong or Ghosting

Small story: One of my teams had just fixed a production problem that was causing a revenue loss of roughly €15k per day. Someone from a different team did the code review, demanded some semantic fixes, these were made - next round: lather, rinse, repeat. After 2 weeks, the reviewer went on vacation without notice. The fix got stuck in the pipeline for 5 days without response. This funny little event cost the company over €250k - roughly three years' worth of developer salary!

Things like that happen because the expectations and priorities in the team aren't aligned with business objectives and also because of a phenomenon I call "ticket talk."

Suggestion 1: Make the Wait Time and Flowback caused by Code Reviews visible.

Suggestion 2: Create a Working Agreement to talk face-to-face as soon as there's flowback.

Suggestion 3: Replace Code Reviews with Pair Programming.

Preferences, emotions and opinions

Let's return to the "whimsical feedback" antipattern briefly. Many times, I see feedback over "use CamelCase instead of Snake Case", "use Tabs indentation instead of spaces" or whether a "brace should open behind the method name rather than in a new line". 

None of these make the product any better or worse. The debate over such matters can get quite heated, and potentially even escalate into a full-blown religious war. These are entirely up to personal preference, and as such, not worth a review annotation: They are red herrings. 

Suggestion 1: Formalize coding conventions and put them into your Lint / SCA config.

Suggestion 2: If you're really bothered, use a pre-commit hook to prevent checking in code that violates static code rules.

Suggestion 3: If you think a rule is missing or unproductive, bring it up in the Retrospective.

Alternative perspective

Code Reviews are just one way to improve coding within a team and/or organization. Mandatory code reviews - by default - create interrupts in the flow, reducing overall performance by a significant amount. Better options include:

• Code Review upon request
  (e.g., "I want to talk with you about this code")
• Code Dojos, where the entire team assembles to learn from one another.
  (SAFe's IP Iterations are great for dojos.)
• Pair programming - making the discussion part of the process.
  (Reviews should be obsolete if you do Pairing right)

Still, if your organization mandates code reviews, try to make the best from them.

Summary (tl;dr)

Code Review is more about fast feedback learning than about "catching errors".
A positive "what can I learn" attitude makes reviews much more enjoyable and beneficial than a negative "what did they do wrong" attitude.

When reviews expose pressing problems, don't just annotate them. Engage the discussion about "how can we work differently?"

Tests without code knowledge are waste

I start with an outrageous claim: "Software tests made without knowledge of the code are waste."

Now, let me back that claim up with an example - a calculator applet which you can actually use:

Calculator

0

Have fun, play around with this little applet ... it works if your JS is enabled!

Now let us create a test strategy for this applet:

Black Box test strategy

Let's discuss how you would test this, by going into the list of features this applet offers:

• Basic maths: Addition, Subtraction, Multiplication, Division
• Parentheses and nested parentheses
• Comparisons: Less, Equal, Greater ...
• Advanced maths: Exponents, Square Root, Logarithm, Maximum, Minimum, Rounding (prefixed by "Math.")
• Trigonometry: Sinus, Cosinus, Tangens, Arc-Functions (also prefixed)
• Variables: defining, referencing, modifying
• Nested functions: combining any set of aforementioned functionality
• And a few more ...

Wow - I'm sure you can already see where our test case catalogue is going with minimal coverage, and we haven't even considered edge cases or negative tests yet!

How many things could go wrong in this thing? Twenty, thirty? Fifty? A thousand?

How many tests would provide an appropriate test coverage? Five, ten, a hundred?

How much effort is required for all this testing? 

Would it shock you if I said ...

All those tests are a waste of time!

Frankly speaking, I would test this entire thing with a single test case, because everything beyond that is just waste. 

I am confident that I can do that because I know the code:

  <div class="row">
	<div class="card"
             style="margin-top:1rem;
                        margin-left:2rem;
                        margin-right:2rem; width: 18rem;
                        box-shadow: 4px 4px 4px 1px rgba(0, 0, 0, 0.2);">
	  <b class="card-header text-center bg-primary text-light">
            Calculator</b>
	  <div class="card-body">
	  	<textarea class="form-control"
                          id="calc_input"
                          rows="1" cols="20"
                          style="text-align: right;"
		          oninput="output.innerHTML = eval(this.value)"
                          ></textarea>
	  </div>
	  <div class="card-footer text-right">
		  <b id="output">0</b>
	  </div>
	</div>
  </div>
  

Yes, you see this right. The entire code is just look-and-feel. There is only a single executable statement: "eval(this.value)", so we don't have a truckload of branch, path, line, statement coverage and whatnotever that we need to cover:
All relevant failure opportunities are already covered by JavaScript's own tests for its own eval() function, so why would we want to test it again? 

The actual failure scenarios

Seriously, this code has only the following opportunities for failure:

• Javascript not working (in this case, no test case will run anyways)
• Accidentally renaming the "output" field (in this case, all tests will fail anyways)
• User Input error (not processed)
• Users not knowing how to use certain functions
  (which is a UX issue ... but how relevant?)

Without knowing the code, I need to test an entire catalogue of test cases.

Knowing and understanding the code, I would  reduce the entire test to a single Gherkin spec:

The only relevant test

Given: I see the calculator

When: I type "1+0".

Then: I see "1" as computation result.

So why wouldn't we want to test anything else?
Because: the way the code is written, if this test passes, then all other tests we could think of would also pass.

But why not write further tests?

A classical BDD/TDD approach would mandate us to incrementally define all application behaviours, create a failing test for each, then add passing code, then refactor the application. 

If we would do this poorly, we would really end up creating hundreds of tests and writing explicit code to pass each of them - and that's actually a problem with incremental design unaware of the big picture!

The point is that we wrote the minimum required code to meet the specified functionality right from the start: code that has only a single failure opportunity (not being executed) - and after having this code in place, there's no way we can write another failing test that meets the feature specifications!

And that's why a close discussion between testers and developers is essential in figuring out which tests are worthwhile and which aren't.