Leading by Absence

You may be familiar with classical leadership approaches - such as leading by doing (being in the trenches, doing the same as you expect others to do), or leading by example (which is slightly different, as you show patterns for others should follow) - but have you ever thought about "leading by absence?" This technique is very important for Scrum Masters and Managers alike to grow teams and personalities. If you're a parent, you may be familiar with how necessary, yet difficult this approach is.

Let's explore how this approach can positively impact leadership dynamics and enhance team dynamics.

How to Lead by Absence

The concept of "leading by absence" refers to a leadership approach where a leader intentionally creates space and provides leeway for their team members to take ownership and make decisions in their absence. Leading by absence means you steps back and allows others to take the lead and responsibility, while still providing guidance and support as necessary.

Leadership by Absence is a delicate act of balance

"Leading by absence" recognizes that effective leadership isn't about being at the forefront or making decisions. Instead, it acknowledges the importance of empowering others and fostering a sense of autonomy, trust, and accountability within the team. By giving team members the opportunity to lead and make their own decisions, leaders focus on nurturing their growth, developing others' skills, and building a more self-reliant and resilient team.

These are some key aspects of leading by absence:

Delegation

To lead by absence, team members need to be clear which tasks and responsibilities they are expected to take over. The leader trusts their team's capabilities and gives them the autonomy to make decisions within their assigned roles.

Support and guidance

Those who lead by absence deliberately step back and create space, while still providing support and guidance when needed. They offer assistance, clarify expectations, and provide resources or feedback to help their team members succeed.

Empowerment

Leaders who choose to be absent aim to empower team members by fostering a culture of ownership and accountability. It encourages individuals to take initiative, make decisions, and contribute their unique perspectives.

Trust-building

Leaders who practice leading by absence build trust with their team members. They demonstrate confidence in their abilities and create an environment where individuals feel valued and supported, which increases motivation and engagement.

Continuous learning

This leadership approach relies on opportunities for learning and growth. Leaders encourage their team members to learn from their experiences, both successes and failures, and promote a culture of ongoing improvement and development.

Conclusion

Leaders who practice "leading by absence" promote collaboration, innovation, and individual growth within their teams. They leverage the diverse skills and talents of their team members while fostering a sense of ownership and shared responsibility for achieving goals.

Note of caution:

Despite the similar name, "Leading by Absence" is the opposite of "Absence of Leadership:" It's a deliberate choice that requires careful consideration and patience. Wheras it empowers and enables teams, an absence of leadership implies a lack of guidance, direction, and support.

To put these into contrast: Leaders who lead by absence create a space for others to step up and become more successful, whereas an absence of leadership puts others into turmoil and endangers their success. Effective leaders strike a balance between providing autonomy and support, ensuring that team members have the necessary resources, guidance, and clarity to thrive in their roles.

Flush the System for Agility!

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

Areas of investigation

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

Work

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

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

Calendar

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

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

Roles and Responsibilities

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

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

Incentives and Measurement

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

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

Take action!

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

Navigating Hidden Agendas

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

How are the pieces and the Big Picture connected?

The problem with hidden agendas

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

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

The Impact of Personal Agendas

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

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

Why are there Personal Agendas?

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

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

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

Can't we eliminate Personal Agendas?

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

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

The consequences of suppressing Personal Agendas

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

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

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

Permitting Personal Agendas

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

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

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

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

The Growth of Hidden Agendas

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

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

The effect of Hidden Agendas on decision-making

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

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

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

Repairing Systems Dominated by Hidden Agendas

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

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

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

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

Conclusion

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

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

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

Little's Law and the Hidden Variable

Did you know there's a hidden variable in Little's Law, and that the traditional equation L = λW - is missing something?
Well, it doesn't tell you something important, and it used to bug me a lot until I could pinpoint it - so let's explore.

What Little's Law says

Quoting Wikipedia: "In mathematical queueing theory, Little's law is a theorem by John Little which states that the long-term average number L of customers in a stationary system is equal to the long-term average effective arrival rate λ multiplied by the average time W that a customer spends in the system."

For example, if we take a restaurant - the average number of guests present (L) is equal to the average arrival rate of guests (λ) multiplied by the average time a guest spends in the restaurant (W).
Let's say, if the average arrival rate is 10 guests per hour (λ = 10 customers/hour) and the average time a guest spends in the restaurant is 30 minutes hour (W = 0.5 hour), then according to Little's Law, the average number of guests in the restaurant (L) would be 5 guests.

Sounds all good - so: what is missing?

When Little's Law doesn't work

A few years ago, I had a hunch that Little's Law was missing something: Imagine that our restaurant has 5 tables and one waiter who can serve 12 guests an hour. Guests take half an hour between getting seated and paying their tab.
Does Little's Restaurant follow the tradtional formula of L = λW, ie., W = L/λ?
Would a reduction of seats lead to guests dining faster?
Would a reduction of maximum dining time generate more guests, or would people dine longer if there were more guests?
Probably not.
Is Little's Law broken?

No. But it's missing something - it doesn't account for system capacity!

Fixing Little's Law?

This modified version of Little's Law accounts for capacity: L = λW / (1 - ρ)

Now, that alone doesn't make sense, so I need to explain this variable ρ:
ρ represents the utilization of the system, calculated as λ / μ, where λ denotes the average arrival rate into the system, μ is the service rate capacity of our system, i.e. the reciprocal of the average service time (1/μ = Ts), where Ts is the average time required to serve a single customer (note the difference between "service time (net time)" and "time spent in the system (gross time)" - it's critical!) The "hidden factor" that Little's Law hid in plain sight was the relationship between the average number of customers (L) and the arrival rate (λ) needs to consider the impact of utilization and system capacity on the system performance! In underutilized systems, an increase in arrival rates has no impact on queues - whereas in overutilized systems, a reduction in system load won't have a visible effect until we get close to the actual capacity limits.

Returning to our restaurant example: Our restaurant's capacity is currently constrained by our amount of tables. As long as we have empty tables, a reduction in customers will not speed up anything. As long as all tables are full, adding more tables to the restaurant won't slow anything down. This view is complete counter-intuitive with the original Little's Law - but it makes sense, even in real life. Oh yeah - at some point, the waiter will be overburdened. At this point, the system capacity is no longer defined by tables, but by the waiter. So it's still all about system capacity.

Some examples

Example values for our Restaurant

μ	λ	W	ρ	L = λW / (1 - ρ)
5	1	0.5	0.2	1
5	2	0.5	0.4	2
5	3	0.5	0.6	4
5	4	0.5	0.8	10 --> bigger than capacity!
10	1	0.5	0.1	1
10	2	0.5	0.2	1
10	6	0.5	0.6	8
10	7	0.5	0.7	12 --> bigger than capacity!
3	1	0.5	0.3	1
3	2	0.5	0.7	3
3	4	0.5	1.3	-6 --> negative!

What's important to note are the three invalid records: When the arrival rates get close to or exceed the system's capacity, the numbers "break down." The real-life effects we would observe here:

• When arrival rates start to approximate the restaurant's capacity, the number of guests present gets bigger than the capacity, which in fact can't be - these invalid numbers indicate that variability could cause a backlog (queue) to form at peak times which can only be serviced when peaks are over.
• Customers arriving to a full restaurant can't get serviced and might leave - i.e., the negative number hints at unserviceable demand, i.e. lost opportunity.

The important observation may sound trivial, but is often ignored in management: only when you have more seats than the arrival rate of guests can you avoid having to send anyone home. And the fewer tables, the more likely someone will have to wait. Which is why a WIP Limit of 1 is just as impractical as not controlling demand influx.

Conclusion

While Little's Law has its merit, and we've been using it for years in order to explain the relationship between throughput, cycle time and Work in Process - we can't use Little's Law to optimize our systems properly if we don't account for System Capacity.
Taking System Capacity into account allows us to predetermine whether increasing or decreasing WIP will have a significant effect - operating significantly below capacity is capacity waste, whereas operating above system capacity causes overload waste.
Thus, the "hidden variable" is more than just important to apply Little's Law - it's crucial!

Further reading

There's an interesting whitepaper by Dr. Little who also highlights the key point of my blog article: as arrival rates approach service rate capacity (as outlined in this blog article,) WIP and processing time skyrocket, "hitting a brick wall" close to the system's capacity as queuing overhead reaches infinity.

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.