Showing posts with label TOP Structure. Show all posts
Showing posts with label TOP Structure. Show all posts

Thursday, July 27, 2023

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.

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.

Sunday, June 25, 2023

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.

Thursday, May 25, 2023

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.

Monday, April 3, 2023

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.

Friday, January 20, 2023

What's the value proposition of Agilists?

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


The role of Agilists

Many Agilists think that their role is a subset of:

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

Even the people doing these three are often different folks:

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

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

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


The Value Proposition

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

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

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


Learn about the TOP Structure

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

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

Friday, December 16, 2022

Optimize at the Constraint - only!

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

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


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

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

This simple truth has tremendous consequences:

Don't work more than necessary


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

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

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

And that brings up an important question:

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

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

Where's your Constraint?


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

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

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

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

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

When optimization doesn't work

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

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

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

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

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


What now?

Here are four simple checks you can do:

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

Monday, November 21, 2022

The TOP Structure - how it all started

As you may already be aware, my latest project is the "TOP Structure." Let me give you some insights into how it all started. Back then, it wasn't very refined, just some thoughts in my head.



The world of traditional IT

Traditional IT organizations typically separate themselves into a development and an operational area. To execute, they again separate into line and project - commonly resulting in matrix organizations. Requests for delivery of new stuff are typically thrown over the fence by "business," or - in more advanced companies - negotiated by Business Analysts. In any case, once a project was scoped, we task a Project Manager with ensuring delivery in TQB. That leaves Project Managers with a wide range of work: setting up a capable team, prioritizing and distributing work, coordinating schedules and tracking progress. Unfortunately, as the proverb goes, "if everything is important, nothing is." Many project managers drown in schedules and tracking, leaving them little time for taking care of the people doing the work.

Scrum changed the game

The move to "stable teams" and continuous "product development" led to the need for a different way to structure teams, and Scrum provided it. In a Scrum context, the line no longer "provides resources" to "projects." And there's no more a final delivery thrown over the fence at the deadline - software in an agile setting is never "finished." Features become available in a continuous flow of value.

Still, line managers have a role - and oftentimes, business initiatives are still funded as pre-packaged projects scoped for "Agile Delivery."

Why is all of that relevant? Because of the resulting interactions.

Scrum teams learn to self-organize themselves, and how to manage their interactions with their surrounding organization. The person accountable for this is the Scrum Master. Often being neither technical nor understanding the product in depth, Scrum Masters focus on Organization. Their value proposal isn't in any code they write or anything sold to customers - it's enabling their team, focusing on "Who" and "How." (i.e. people and process)

The second key of a successful Scrum team is the Product Owner, focused on the Product. Both organization and implementation aren't their concern, only ensuring that the "What" and "Why" are clear and prioritized, so that stakeholders are happy and the team does the most valuable thing at the most suitable moment.

And finally, what would be a good Scrum team without competent developers? They take care both of development and outcomes, that is: they do everything technical. Developers own their Technology.


SAFe repeats the same

Let's do a simple relabeling exercise to demonstrate how SAFe copy+pasted Scrum in this regard, at a level of abstraction.

Competency Scrum Role SAFe Role
Scope Scrum Team Agile Release Train
Technology Developer Agile Team
Organization Scrum Master Release Train Engineer
Product Product Owner Product Manager

(Now - we could formidably debate whether SAFe's copy+paste approach at scale is appropriate and smart, but that's not my point.) I'd like to highlight that if we gloss over implementation details, then Scrum succeeds most likely when there's sufficient attention being paid to all of Technology, Organization and Product (TOP) - and SAFe must repeat the same thing at a higher level of abstraction.

From this, the idea was born of the TOP Structure as a universal pattern: To succeed with a sustainable software organization, you must ensure that all three domains receive sufficient attention.
Thus, the idea behind TOP is first and foremost that we have to build a structure that pays appropriate attention to all three domains, staffs them with sufficient competency, and doesn't force us into making either-or choices between them. Which is what often got traditional Projects into trouble - a PM rarely has time to fix organizational issues, as deadlines are constantly pressing.

TOP Dysfunctions

Let's turn this around, and take a quick peek at what happens when we pay too little - or no - attention to one of the core TOP competencies:

Illustration Dysfunction Consequence
Exclusive Tech Focus Technical excellence disconnected from people and their needs - technological wonders that nobody needs.
Exclusive Product Focus Ephemeral, great ideas that eventually get killed by the inability to execute.
Over-focus on Organization Having the right people working effectively means little when it's not the right thing.
Lack of Product Focus An over-focus on methods and implementations could lead to missing the needs of the customer entirely.
Lack of Organizational Focus A "bias for action" mindset that bulldozes over people and their needs in order to "move fast and break things." Gets things done in early phases, leads to unproductive (and potentially extremely costly) chaos in the long term.
Lack of Technical Focus Emphasizing value generation and order, at the expense of technical sustainability. Most such products incur fatal technical debt at some point in the future.
(none) Technology, Organization and Product all get sufficient attention, nothing gets shoved under the rug and energy is distributed wisely in each domain.


The TOP Question

And thus, the idea of the TOP Structure was born as a simple, yet effective mechanism of asking the question: "We have 100% of our energy. We can distribute it in any way that we want. Where should we put how much?" There's no fixed or perfect ratio such as, "60% T, 10% O, 30% P" that would serve as a recipe for success. Instead, the first answer is often, "We currently spend too much energy on (X) and too little energy on (Y).
TOP thus started as a simple tool for teams, teams-of-teams and entire organizations to determine whether sufficient energy was invested into the different areas in the past - and whether we should redistribute that energy in the future. For example: "We'd need a bit more time for process improvement, and a bit more for Refinement. That's only possible if we invest a bit less of our time for development - can we do that? How? Is there something in any of the competencies we're currently doing that we could discontinue?"


How it evolved

As you can already see from the three circles - they overlap. Initially, I put "management" into the center, with the intent of stating that management has the responsibility that all three competencies get adequate staffing, funding and attention. Then I decided that this isn't what we'd like in self-managing teams. So I decided to put "Teams" into the center, indicating that a self-managing teams should do all of that. It didn't feel right, either. And thus, the current version of the TOP Competency Spectrum was born:

The TOP Competencies

The model of the TOP Competencies Spectrum is mostly a reshape of the circles into one segmented circle, giving names to the different intersects of the circle:
As you move further away from pure technology towards organization, you enter the domain of Architecture, concerned with the question of "Do we have the right means of doing what we do, and is how we do it the best way of doing it?" - Architecture, in the TOP Competencies model, isn't a separate thing from either Technology or Organization: it's the discipline that brings both together!
Likewise, Design fuses the question, "Why do people need it?" with "How do people need it?" - crossing the chasm between user perspective and technical implementation. Thus, the TOP competency of Design requires connecting technical and product competency for best outcomes. Which is needed to which extent at which time - may vary, and as the color indicates: it's a blended mix.
The other TOP Competencies are similar: At the outer part of the circle, activities are more "domain specific," and the closer we get to the center of the circle, the TOP Competencies blend and become indistinguishable. 

Quality, at the core of the TOP Competencies, is much more than "product quality" - it's quality of everything: how we communicate, how we work, what we produce, and any other outcomes we get (including, of course, satisfaction with our jobs.) As quality is everything in a TOP Structure, it's also everyone's responsibility, and everyone constantly contributes towards it, be it consciously or unconsciously, positively or negatively. The TOP Structure should remind us of this, and inspire us to replace unconscious poor quality choices with conscious good quality choices.



This extended model of the TOP Structure focuses less on the question of "Where do we assign our energy?" - somehow, the entire circle makes up for 100% of our energy, with fluctuating investments across the week - it focuses more on People and Interactions: In our current organization, how do we interact with ... Architecture? Is it smooth, do we have boundaries? Where is it: is it part of the team, or outside? Does information flow freely from and towards that domain, or is it thrown over the fence? 
Is there a continuous exchange between developers and product people, or is it a stage-gated Waterfall? What does our relationship between design and quality look like: Do we design for quality, or do testers consume the result of a design process for test case creation?

The TOP Structure, in this regard, makes no imposition of what you must do - much rather, it guides us in the questions we can ask to identify where we've got improvement potential and where we're potentially missing something important.

What's next


And that's how I formed the basis for the entire model of the TOP Structure you can now find on my official company page. I invite you to sign up to my newsletter and follow me, because I have big plans for the TOP Structure: I believe it should be a staple tool for any Coach and Consultant supporting organizations on their journey of Continuous Improvement - regardless of which framework, or no framework, or the approach they choose.

My own journey with TOP has just really begun to get exciting - you're still in time to be an early adopter!

Wednesday, September 7, 2022

Dealing with limiting beliefs

We often encounter that Limiting Beliefs are holding us back from achieving the goals we want to achieve, from doing what is right, from becoming who we want to be. So - if we know this, why aren't we changing our beliefs? Because, very often, our beliefs define who we are, and change is hard. But there is hope. What could we do?

Limiting Beliefs

Let's start by defining limiting beliefs - a belief confining us, or reducing our options in some way. We all hold limiting beliefs, and there are some of them that we shouldn't even change. So - when exactly are limiting beliefs an issue? A simple and quick answer: when we should be doing something that's hard or impossible because of a specific belief we subscribe to.

Let's use an example to illustrate our case:

Say, Tom is a manager and he believes that: "Developers can't test their own software." This belief is limiting, because it stops all beliefs, decisions and actions built on the idea that "developers do test their own software." 

The problem with limiting beliefs

As long as Tom holds this belief, he can't support the ideas of, for example, TDD or Continuous Delivery, because these are in conflict with his belief. And beliefs aren't like clothes - we can't change them at whim. Here's what we're dealing with:

Belief networks

Limiting beliefs don't simply stop one change, they are often part of a complex web of other beliefs that reinforce the limiting belief, and which would be incomplete, incoherent or even inconsistent if that limiting belief was changed - so we can't just replace one belief without examining its context: "Why do you hold this belief?" 

Supporting beliefs

In Tom's example, we might find other supporting beliefs - such as the Theory X idea, "Without being controlled, developers will try to sneak poor quality into Production, and then we have to deal with the mess."

Anchoring

Tom is probably a reasonable person, and his belief was most likely anchored by a past experience - there were major incidents when developers did cut corners, and these incidents forced Tom to adopt a policy of separating out development and test, and that ebbed the tides.

Negative hypothetical

Let's ask Tom, "What would happen without a separation of development and test?" - and he'd most likely refer back to his anchor experience, "We would have major incidents and wouldn't get any more work done because of continuous firefighting." - and it's hard to argue his case, because it's consistent with his experience.

Conjunction Fallacy

Let's ask Tom an inconspicious question to figure out what Tom thinks is more likely: "Which scenario do you think is more probable: that a developer creates a mess, or that a developer who tests their own code creates a mess?" - Tom will probably answer that it's the latter. This, however, is fallacious, because developers testing their own code are a subset of developers, a special case: if that was Tom's answer, he would (probably unknowingly) subscribe to the idea that developer tests increases the probability of poor results!

Confirmation Bias

Now, let's assume that we manage to convince Tom to make an experiment and let developers take control of quality - we're all human, and we all make mistakes. Tom will feel that the first mistake developers make confirms his belief, "See - we can't. I told you so." 

Selection Bias

Of course, not everything an autonomous developer will deliver is going to be 100% completely broken, but Tom will discount or dismiss this, because "what matters is the mess they created and that we didn't prevent that from happening." - Tom will most likely ignore all the defects and incidents that he currently has to deal with despite having a separate Test Department because these aren't affirming his current belief.


Changing limiting beliefs

Given all these issues, we might assume that changing beliefs is impossible.

And indeed, it's impossible to change another person's beliefs. As a coach, we can't and shouldn't even try to do this: it's intrusive, manipulative and most likely not even successful. Instead, what we can do is: support the individual holding a limiting belief in going beyond the limits of their current beliefs.

Here's a process pattern we could use to help Tom get beyond his limiting belief:

1 - Write down the limiting belief
When you spot a critical limiting belief in coaching, write it down. Agree with the coachee that this is indeed the limiting belief they're holding.

2 - Ascertain truth
Truth is a highly subjective thing, it depends on beliefs, experiences and perception. What we want here is not "The truth," but what the coachee themselves asserts to be true: "Do you believe this is certrainly true?" - "What makes you so sure it's true?" - "Could there be cases where this isn't true?"

This isn't about starting an argument, it's about getting the person to reflect on why they're subscribing to this limiting belief.

3 - Clarify the emotional impact

Let's ask Tom, "What does holding this belief do to you?" - and he may answer: "I know what I need to do, that gives me confidence." - but likewise: "I am upset that we can't trust developers on their quality."

We hold onto beliefs both because and despite how they affect us. There's always good and bad, and we often overlook the downsides. Most likely, Tom has never considered that he's carrying around some emotional baggage due to his belief. Until Tom comes to realize that this belief is actually limiting him, and also negatively affecting him, he has no motivation to change it.

4 - Clarify consequences

 Next, we'd like to know from Tom where the limiting belief will put him in the long term: "When we look back, 10 years from now - where will you be if you keep this belief?"

We would like Tom to explore the paths he can't go down because of his limiting belief - for example, "We still won't have a fully automated Continuous Deployment - and I will be held responsible for this." Tom needs to see that his current belief is going to cause him significant discomfort in the future.

5 - Surface the Cost of Not Changing

We're creatures of habit, and not changing is the default. We first and foremost see the cost of change, because that's immediate and discomforting. And we ignore the cost of not changing, so our default would be that we have no reason to change anything.

Tom must see the costs of persevering in his current beliefs, so we ask: "What's the cost - to you - in 10 years, if you don't change this belief?" - a mindful Tom might realize that he'll get passed up for career opportunities, or might even get replaced by someone who will bring new impulses. The more vivid Tom can paint the upcoming pain, the more determined he will be in wanting to change.

And that's the key: As long as Tom himself has no reason to change his belief, he won't. But we can't tell him what his reasons should be. Tom has to see them by himself, and in a way that is consistent with his other beliefs.

6 - Paint a brighter future

Tom may now be depressed, because in his current belief system, he's doomed: there's no hope. So let's change Tom's reality. Let's ask him, "If you change this belief, what would you be and do?" - Tom might be skeptical, but will tell us some ideas on his mind, "I'd give devs permission to test their own code." - "I wouldn't enforce strict controls on developers." - "I wouldn't be known as the only person in this company insisting on stage-gating." 

We can then follow this up with, "How would you feel if this could be you?" - if we get positive responses like, "Less stressed, more appreciated" - we're moving in the right direction. If we get negative responses like, "Stupid, Unprofessional" - then there's another, deeper rooted limiting belief and we have to backtrack.

7 - Redefine the belief by its opposite

Let's ask Tom, "What's the opposite of this belief?" - and Tom would answer, "Developers can test their own code." Tom needs to write this down on a card, and keep it with him all the time.

8 - Reinforce the new belief

Every day, Tom should read this card and look for evidence that this opposite belief is true. For example, Tom can find out which people hold this opposite belief, and how it works for them. 

At a minimum, Tom should just take a minute and sit back in calm, take out the card and read it to himself - and then repeat this new belief to another person.

As coach, we can challenge Tom to repeat the new belief back to us frequently, and to provide small stories and anecdotes about what he has said and done based on this different belief.

9 - Reflection

After one month, reflect with Tom what difference thinking and acting based on this opposite belief has made, and how often he lapsed back into thinking and acting based on his limiting belief. Under ideal circumstances, Tom will have success stories based on his new belief - these are a great basis for reflecting whether this new belief can serve him better than his former, limiting belief.

Even if Tom sees no difference, he already has evidence that his original belief may not be true.

If Tom is still struggling, he may need more time to be convinced. 



Closing remarks

Even with a formal process for belief change, we're not guaranteed to rewire or reeducate others. We respect and enjoy freedom of thought and differences in belief, and the best we can do is highlight consequences, reinforce and provide feedback.

If we see that people choose to cling to old beliefs and habits despite all our attempts at supporting them, we have to ask at a meta level what the difficulties are, and whether our support is even desired. We're not in the business of messing with other people's heads - we're in the business of supporting them in being more successful at achieving what they want, and in coming to realize what that actually is.