Dealing with Organizational Debt

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

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

"Organizational Debt" image created with craiyon.com

How can we deal with
Organizational Debt?

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

How to identify and address Organizational Debt

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

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

Why Agile Coaches need to care about Delivery Speed

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

An Agile Coach setting themselves up for failure

Cycle Time Matters

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

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

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

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

Don't make it a false dichotomy!

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

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

Verdict

Agile Coaches who discount speed of delivery will struggle

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

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

Conclusion

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

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

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.