Addressing the “Certainty Bias”: Core Principles to the Rescue


Certainty bias?

Indeed. Certainty bias is the term we use in reference to organizations’ tendency to demonstrate overconfidence in desirable outcomes while in fact operating in an environment of uncertainty. A lot of organizations are exposed to this phenomenon. Yours too, most certainty… no pun intended. The problem has some typical symptoms:

  • Assumptions are perceived as facts
  • Organizational behavior is predefined and over-constrained
  • The gap between reality and plan is never properly understood

As a result, we get a whole bunch of “funny” things happening in the enterprise; and those are not exactly “ha-ha”-funny. We see product management that obsesses with scope while there’s no evidence of its value whatsoever. We see long-term, fairly detailed organizational plans that span unimaginable amount of time and cannot be delivered in principle the way it was intended. We see budgets that are tied to detailed scope and we see capacity expectations which never work out. But despite all that, what’s much worse is that the organization continues to live under the impression that it’s actually all working out just fine. The organization de facto loses its ability to learn. The gravity of a fine-elaborated plan with scope and budgets attached to it takes huge toll: people at different levels tend to acquire political skills much rather than the ability to problem-solve and as a result, often chose not to raise systemic issues even if they happen to stumble upon them. Everyone becomes a hostage of the system, which is a result of the flawed thought process.

Okay, but what’s the right thought process then?

I will try to briefly summarize it as a set of principles, a vector in the direction that provides a better toolset for dealing with systems of uncertainty. Here they are:

  1. Aim at business outcomes
  2. Minimize unmanaged assumptions
  3. Align individual motivation with value delivery
  4. Provide room for emergent behavior
  5. Exploit cross-level learning


1. Aim at business outcomes. Hmm… Of course everyone aims at business outcomes, what else should they aim at?

Well, while it really sounds simple and obvious, it doesn’t mean that it actually takes place. What do you think a product manager is aiming at when they demand “all these features” from the team, having no idea whether any of it will produce business value? Or a team that is obsessed with cycle time. Deliver more! Deliver faster! …Does it produce more loyal customers or more revenue or significant long-term competitive advantage? Are those questions even being asked when making scope, quality, schedule or cost decisions?

2. Minimize unmanaged assumptions. Assumptions inevitably arise when we are operating in the environment of uncertainty: we don’t posses full knowledge over organizational behaviors and outcomes. Therefore we assume. The problem comes when we assume this and assume that every step of the way, while pretending that those are not assumptions but rather firm facts. Why do we think this scope will have the anticipated business impact? Will the other team provide the functionality that our team needs? Will this data connector work? Will this funding be sufficient for the initiative? Assumptions are everywhere: in business and technology strategy, in requirements, in implementation approach, in team and skill-set structure, in funding, in interpretation of the company’s bottom-line and more.

On the one hand, the problem is in that we don’t acknowledge assumptions and don’t manage them as such. On the other hand, due to ineffective process and structure, we tend to spawn assumptions in large quantities where they could be avoided in the first place. So, for instance, a rigid structure of teams that have significant dependencies on each other creates unnecessary assumptions that could have been avoided should the teams be more flexible and organized to better contain the dependencies rather than have them scattered across the organization. Similarly, rather than having requirements trickle down the long organizational hierarchy, which ironically enough, bypasses customer every time and generates more and more bold assumptions (of both what to build and how to interpret the requests from above), it would be a lot more productive to provide each team or a small group of teams with a stakeholder with the sufficient requirements decision-making authority who directly interacts with the customer and a few key internal stakeholders.

3. Align individual motivation with value delivery. The type of motivation that dominates across the industry, is usually only loosely connected with value delivery. Organizational leaders should be the ones to take care of this problem, but they are themselves subjected to the same blind spots as everybody else and, as interesting as it sounds, can hardly be blamed for anything. To best illustrate the detail behind this principle, we need to ask ourselves, what organizational behaviors and qualities are we after when we talk about value delivery. Well, we are looking for collaboration along the pathways of critical dependencies, we’re looking for flexibility to be able to respond to new facts, we are looking for openness and transparency for communicating and eliminating impediments. But is that what we usually see? Managers that are overly possessive of “their” people, even though another team or program badly needs help with high-priority work, are hardly a good example of a collaborative spirit. Similarly, who would be motivated to respond to change when the top leadership creates an immense pressure to deliver according to a master plan and measures everyone’s “productivity” based upon that? Finally, what manager would like to be known as the barer of the bad news, given that mostly the “yes-men” and the “happy land” folks get promoted in their organization; no wonder that systemic impediments remain forever unaddressed. The right motivation model has to found human motivation upon adequate thinking and seek to enable the organizational qualities, some of which we mentioned above.

4. Provide room for emergent behavior. One of the deadly sins that stem from the certainty bias is the idea of preprogramming the enterprise. We aim at preprogramming the organization because we lack the right model for thinking about organizational behavior; something that would show us how flawed is that idea in the first place. We tend to believe we can preprogram market conditions, customer needs, scope, team behavior in implementing it, etc. It’s the “clock mechanism” model. Instead, it’s better to think of your organization’s ecosystem as of a city or a garden. You can never direct a specific way in which a city or a garden evolve. You can influence them, of course, by affecting various enablers but never to expect the exactly predefined behavior. A city may decide to sell some land to a hotel chain to attract more small business to the area, but which business will end up there and what other enablement will they require – there’s no way to know upfront. You may decide where to locate different plants in your garden but you can’t expect them to grow precisely like you want. You will know more as you go, but to respond to new facts, you need to preserve flexibility for behaviors you don’t yet know. So, how exactly is an enterprise supposed to provide flexibility for emergent behavior? Well, how about creating plans that explicitly contain the unknowns, multiple possible solution options and experimentation required? How about the funding being detached from exact scope expectations? How about team and department boundaries being a bit more flexible for people to be able to swarm around the problem, when needed?

5. Exploit cross-level learning. It is impossible to establish any of the above, if this aspect of the organization’s life is not in place. See, it’s very easy to believe in long-term fixed scope commitment or in scope-based funding or in the detailed upfront architecture or in the flawlessness of your team structure, when there’s no information flows in place that would demonstrate the gap between those beliefs and reality. Every organizational layer lives with their own sweet, comfortable version of the truth. The idea behind the principle is very simple, there needs to be a mechanism that, in a sense, “collapses the pyramid”. This does not necessarily imply that organizational levels should be abolished, but they have to start to operate differently, overlapping a lot more across multiple levels at a time and immersing themselves into the rich context of experimentation, execution and validation, rather than staring in their dashboards filled with vanity metrics.

This may be enough for the initial discussion on the topic, enough for you to start thinking about it in the context of your organization. Start by asking yourself how your current organizational reality support the principles above.


By Alex Yakyma, Org Mindset.

Lean Portfolio Management Conversation

Recently I had a great conversation with Marshall Guillory ( on Lean Portfolio Management. We talked about quite a few topics: the general idea of Lean-Agile Portfolio, common systemic impediments in implementing it, the connection to strategy and structure, organizational learning and more. You can find the video on Marshall’s blog (click on the picture to go to his original post):

By Alex Yakyma, Org Mindset.

Org Mindset Podcast: Key Constructs In Organizational Agility

We took a liberty to go a little bit beyond regular time box as the conversation evolved toward some interesting aspects of organizational agility. We talked about constructs that support responsiveness and flow (as well as anti-patterns to be avoided). We finished by touching on organizational learning and what’s needed to enable it in your enterprise.

Michael mentions two books in this podcast. Here they are with the corresponding links:

Extreme Agility:

Spirit of Scrum:


Enjoy the podcast and the books!


By Alex Yakyma, Org Mindset.

A Misconception of Workload in Complex Systems

Most organizational leaders are concerned with how work is done in their organization. This is indeed a very important concern but despite all the attention, it is most often addressed incorrectly. Today we will dig into this topic a bit deeper.

The Army of Walking Capacity Buckets

Organizations usually rely on the concept of “capacity” to plan and execute work. The idea is very simple at its core, which in part explains its widespread adoption. If you have 120 people, for example, you get 120*X capacity within a time box of size X. You can now plan new initiatives by matching their size against this number.

Here’s a big problem with this logic. Assume we have two teams: A and B, 5 people in each. Team A generally gets backlog items that create a pretty even load distribution across the team members. Team B, on the opposite, has a person (who we will name Olga) with a unique skill set. In this time box most of the backlog items involve Olga and she’s quickly becoming a bottleneck. So, in case of Team A, the throughout is high and can be well predicted by the overall team capacity. In case of Team B, however, the capacity of the team is absolutely useless. The throughput basically depends on Olga’s individual capacity, making the rest of the team run idle for the most part. In fact, it’s usually a lot worse than that as they, instead of going idle, keep creating more “stuff” that will pile up for Olga. So, in one case you have 5 people that move at the speed of 5 and in the other, five people that move at the speed of one person. If by any chance you think that Team B’s case is some sort of exotic mishap, I would encourage you to think again.

This logic scales further up by considering teams instead of individuals and so forth. The main takeaway is this: capacity is a very poor predictor of throughput. It’s not just inaccurate, it’s dangerous as it leads to unreasonably optimistic estimates for the delivery capability and, as a result, leads to substantially overloading the people. It’s counterproductive to view an organizational unit (a team, a team-of-teams, etc.) as a collection of “capacity buckets” that one could uniformly use to deliver value. Instead the structure of dependencies, knowledge pathways and skill sets are primarily responsible for the outcomes.

But Wait, There’s More: Variability

Business demand doesn’t stand still over time. The new backlog items at some point begin to require a different skill ratio and induce different dependency structure within the group. Team A in our example above, despite their prior stable record in terms of individual workload, may suddenly start to experience quite a turbulence with the new scope. Suddenly, there are significant bottlenecks and constraints that couldn’t have been predicted based on prior periods. The problem, therefore, is farther complicated: the internal structure of the workload (which primarily determines the outcomes) turns out to be a moving target.

Wow… Just when we thought we approached the solution…

You Have To Stop Fighting the Physics… It’s Not Helpful

The workload, by it’s nature, is heterogenous and variable. This makes it practically impossible to effectively plan and execute work based upon a “wholesale” capacity approach. It’s not that you will be “a little off”. Your calculations, depending on circumstances, will be way off the target. This is the way things are and it’s up to us whether we want to accept the reality and exploit the underlying forces to produce better economic results or we keep fighting the reality and continue to pretend that workloads are homogenous and predictably stable. The latter means that the organization is losing an opportunity to improve its performance. But what’s even worse, the organization fails to arrive at the right mental model of reality and continues to “optimize”, driving itself into even more trouble.

We have to think carefully what do we like better: the illusion of predictability and uniformity of workload or the actual business outcomes, because these are completely different things.

The Solution Is Not an Improved Mousetrap

This problem solves at the fundamental level. First and foremost, the obsession with capacity and utilization has very clear roots. It’s in the flawed assumption that once you’ve defined a boatload of scope, the success of the initiative equals to properly implementing that scope. This is not how product development works. This is a misapplication of manufacturing principles. We just take the ideas that guide the process of creating repetitive value and apply it to product development where we continually produce unique type of output. That “manufacturing” mentality has to go first, otherwise no method will ever produce good results.

Ok, so if that’s the wrong mentality, what is the right one? It’s actually very simple: in product development, learning and adjusting are the primary success factors. It’s not about the plan, it’s about your ability to quickly understand and properly interpret new facts and then adjust the course of action based on that. It is very easy to say whether an organization understands the nature of product development or follows the illusion of predictability. Simply look into the consequences of deviating from the plan or initiating change. If the organization welcomes change as a vital component of success, if the policies and rules (as well as the actual leadership attitude), make it easy to adjust scope and effort allocation then the organization obviously knows what it’s doing. If, on the opposite, changes are frowned upon, they are very hard to get approvals for and people prefer to rather go in a knowingly sub-optimal direction to avoid the hassle around implementing change, then you are dealing with an organization that treats product development as manufacturing.

So, This Is How It Works

Learning and adjustment. L-e-a-r-n-i-n-g and a-d-j-u-s-t-m-e-n-t…

This doesn’t preclude longer-term planning, but it definitely implies a fundamentally different treatment of planning and execution:

  1. The emphasis is on outcomes rather than outputs. This means more rapid, cross-cutting feedback loops and “value” rather than “scope”-oriented metrics.
  2. Planning and forecasting are informed by empirical evidence of delivery capability rather than capacity thinking, i.e. it should reflect the prior knowledge of constraints and bottlenecks within the system.
  3. It’s okay to plan but plans should not over-constrain the outcomes. Your organization wants to know how much (money, time, etc.) approximately it is going to require to build this and that? It’s totally fine to want to know that, as long as the following rule applies: the organization treats the plan as a collection of assumptions, some of which will play out as expected and others – not at all. This means that the organization will welcome new information and will be looking to adjust the course of action correspondingly. Re-scoping and highly incremental implementation of large initiatives is rather a norm: scope is an important variable, by changing which we can optimize the value delivered.
  4. To be able to quickly learn and adjust, self-organization is vital. Indeed, given the heterogeneity and variability of workload there’s no chance to apply top-down approach to most of the tactical decisions. This shifts the role of the leadership quite a bit and gears them up for addressing the impediments to self-orgnizaiton, collaboration and fast learning.

Wait a Second, But We Are Special…

Who isn’t? I can tell you though that there are two types of “special”:

  1. Certain planning and workload management requirements are externally imposed. That’s, for example, when you are a contractor whose contract agreement uses scope as a key “currency”. Let me be clear about something here. For starters, just because you are operating under such constraints, doesn’t mean that those constraints are helpful to either of the parties. This topic deserves it’s own big article (or articles, rather). I hope I’m not creating an impression that we are dealing with some ideal scenarios here. I happen to have a very good understanding of what contract work is like as that’s the environment where I started my career and worked in multiple different capacities, on both sides of the business: as a contractor and also as a customer, at different times. So, I don’t underestimate the case. At the same time, while it’s the customer who originally imposes the constraints, it’s the contractor who fails to make the leap towards a better collaboration model by demonstrating an alternative approach in action and gradually taking the customer on this journey that will benefit both parties.
  2. The constraints are self-imposed. Well, no excuse then. You are doing it at your own expense. Time to pivot and start treating workload in product development the way it should be treated.

Lastly, the usually superficial adoption of Agile and Lean practices unfortunately does not prevent from capacity thinking as a primary workload management tool. You need to address the root causes of the problem, some of which we discussed above, for Agile and Lean to actually work in your environment.

So… how is workload managed in your organization?


By Alex Yakyma, Org Mindset.

Anti-Pattern: Anemic Transformation

Driving a successful transformation is a tough task. It takes skill and courage on behalf of the change agents in charge. More often than not, however, the journey leads to a pretty undesirable destination where the organization assumes they have succeeded with the job while in fact they got hopelessly stuck, unable to achieve any significant improvement whatsoever. We call this state an “Anemic Transformation”, a transformation that fails to achieve any tangible result.

A Lot More Companies Are Subjected to Anemic Transformation than You Think

Why? Because for many organizations it is hard to even properly evaluate where they stand. See, whether a transformation is successful or not, usually ends up being a subjective call for an enterprise. Part of the reason for this ambiguity (and therefore enough room for subjectivity) is that the transformation has no shared, viable business goals in the first place (read more about this in the post: Climbing the BS Mountain: Agile for the Sake of Agile). While there’s often no evidence of systemic improvement, there’s always plenty of local parameters that seem to have improved and are often interpreted as evidence of success.

At the same time, things that really needed to change, did not change (find out more on this subject here: This Is Why Your Organization Can’t Be Agile). One common manifestation of this: the engineering teams’ operating model has changed while the mindset and the habits of the organizational leaders remain unaffected.

So, How to Bring It Back to Life?

A couple things are important in bringing your transformation back on track.

First, for a change agent it’s vital to not fall into a status quo trap where all they do is seek the path of the least resistance. That’s a route that certainly leads to transformation anemia. It is critical to refocus on things that constrain the transformation. Typically the problem lies in the mindset of the leaders and in the established practices of enterprise planning, execution and measurement. None of these are easy to change, but for a change agent, continuing to pretend that local advancements will get the organization to desirable outcomes, is highly counterproductive. If you want to really change something to the better, it’s time to start doing what really matters as opposed to what’s easy to do. There’s no easy pill that will magically help you acquire the right attitude, overcome your personal fears and focus on the right thing. But it needs to be done: it’s your transformation and you need to make it work…

Second, prioritize the systemic impediments to your transformation and focus on one or two things at a time. Is it current rigid planning procedure or misguiding metrics or something else that creates the problem? Focus on that specific thing. Think about the plan of attack with specific action involved, be it training and coaching the leaders, involving an external party, exposing the leadership to new empirical evidence, etc.

Lastly, work to make the transformation everyone’s business, don’t hold it exclusive to the original transformation team (or center of excellence or whatever you call it). Nobody likes to be changed by somebody else. People like to be in charge of their own fate, not to mention that the outcomes will likely be much better this way.

The Timeless Value of Time

Now, an important caution. Many transformations start on fire but quickly grind to a halt over time. There’s a powerful force behind this. Real behavioral change involves rewiring one’s brain and that takes time. Different people show different neuroplasticity. Moreover, there’s no definitive way to know “when” the shift happened. Therefore, there’s no easy way of telling whether certain people will not be falling back to their old habits… when nobody’s watching.

Overall, the goal of the transformation is to build new sustainable organizational habits, which requires specific enablement in terms of coaching. It may as well require establishing the “reinforcing” feedback cycles, the purpose of which is to provide continuous evidence that the new behaviors are producing value and so forth. Real change is sustainable change and that’s why the focus should always be on the long-term outcomes.

Finally, let’s close with a quick assessment process…

Is Your Organization Exposed to It Too?

So far we were talking about those… other enterprises, somewhere out there. The real question is: how about the transformation in your enterprise? Is it anemic, too? Here are some typical symptoms to check against. If your answer is “yes” to any one of the following bullets, it’s a strong reason to be cautious. Here they are:

  • Our transformation is not linked to business objectives that would be unambiguously shared across the board
  • People at different levels of the organization have significantly different opinions regarding the transformation success
  • No substantial change happened in ways of working of the organization’s leadership
  • The change is mostly “contained” within the lower levels of the organization
  • Depending on circumstances, people may feel uncomfortable sharing their opinions regarding the transformation results
  • Practices that we thought were adopted, turned out to be abandoned

I hope this quick self-assessment helps. Good luck with the transformation, the toughest task there is!

By Alex Yakyma, Org Mindset.

Recent Agile at Scale Austin Presentation

It was my great pleasure to present to the Agile@Scale community in Austin, TX. Our topics was “Enough Pointless Agility: Driving a Goal-Oriented Agile Transformation at Scale”. Here’s the PDF version of the presentation:



Photos: Leland Newsom, Leader for Agile Austin Agile at Scale SIG,

By Alex Yakyma, Org Mindset.

Unmanaged Assumptions Are Killing Your Enterprise

Most organizations view their optimization goals in faster delivery, higher quality and so on. There’s nothing wrong with that, as long as they align with the most pressing strategic objectives for the enterprise, of course. The real problem usually lies in how organizations imagine achieving the improvement itself, due to what factors they think they will get there. If the optimization paradigm is flawed, an attempt at improving the outcomes may lead to the opposite results. One such example is the idea that throwing more people at a problem will get it solved faster and better, which we know is not the case. Scaling any effort is an incredibly delicate business, and is most often approached incorrectly.

Today we are going to talk about one fundamental enterprise parameter that is at the core of organizational optimization and yet completely missed by both the enterprises and the multitudes of transformation agents.

Assumptions Are a Central Aspect of Every Complex Enterprise Environment

Every complex system has inherent uncertainty associated with it. This uncertainty manifests itself as a lack of viable knowledge at the point of decision-making and the variability in term of outcomes. This is, however, very different from how most of the enterprise leaders imagine the environment they operate within. They totally succumb to what we referred to as the certainty bias in one of the previous articles. What that means is that they tend to replace uncertainty with… guess what…? That’s right: with certainty, surprisingly enough. It has a lot to do with how our brain operates. It seeks to escape “incoherence” caused by uncertain expectations, in the words of a Nobel prize laureate Daniel Kahneman. So, long story short: we humans don’t like uncertainty and we are trying to fill the gaps with some specific idea of the future. This was a vital feature throughout the evolution. Imagine the opposite when you encounter, for example, a saber tooth tiger in the woods, but instead of running away, you give this creature a benefit of doubt: what if the tiger has good intentions? And why think stereotypes anyway? Well… I’m writing this article because my ancestors had the “certainty bias”. Problem is that in the much more complex reality of modern enterprises, the logic we owe our survival to, suddenly fails us.

The whole problem here is that instead of explicitly formulating assumptions, which sounds like a logical way to deal with the lack of knowledge, we implicitly substitute them with wishful thinking. Unmanaged, those assumptions affect every area of enterprise life.

The Key Areas Where Assumptions Arise

  1. Business strategy. Strategy is always a gamble, but even more importantly: it’s the most expensive gamble there is. Should we move to the cloud? Should we expand to international markets? Should we sell this division of our enterprise? Will AI deliver on promise? Will we gain what we want from digitization?
  2. Customer value. How do most enterprises express what they think is customer value? That’s right, they call it “requirements”. Only that those are often just mere assumptions, a result of speculation of what the customer would appreciate to have. Is mobile signup actually needed? Will the customers be willing to switch to a new subscription model? Does the self-service portal incorporate most of the key scenarios for the end user? Will the customers care about social network integration functionality? Does it matter to them that the screens take 5 seconds to load instead of 0.5 seconds?
  3. Technology. That customer value requires the technology to properly work out, which may or may not be the case. Will the OS container support the necessary performance benchmarks when running on our current hardware infrastructure? Will writing this module in Python provide the necessary maintainability over time? Will this fuzzy match algorithm be fast enough to be run on our multi-million-record datasets?
  4. Implementation. Finally, all of it has to be brought in motion by people that belong to certain teams, follow (or not) certain process and so on. Will the other team provide the required interfaces as expected? Will our branches integrate smoothly? Did we catch most of the critical defects in this release? Do we have a sufficient skill set to implement this functionality? Will the team in India be available 6 weeks from now to work on the BI functionality?

This offers some idea as to where the assumptions arise and even though the list is not exhausting, understanding these key areas is important.

So, What’s the Damage from Unmanaged Assumptions?

Well, we can definitely argue about how the examples above affect enterprise outcomes and clearly they will affect the organization to a different extent. But there are some interesting ways in which unmanaged assumptions may (and often do) produce really devastating effect. The trick is in… time. How? Very simple: the cumulative affect of an assumption gets more significant with time because more and more things begin to depend on that assumption:

So, for example, if we believe that we should move to the cloud, our authentication process will be reflecting that, we will be building user collaboration functions based on the cloud platform capabilities, and so on. Those decisions impacted by the initial assumption, will in turn inform the immediate future decisions and so on, branching further out to more and more dependencies bound to that initial assumption. In reality however, we have a chain of assumptions, each one, significantly adding to the overall impact on the enterprise outcomes:


Every next assumption makes the curve “steeper”. Just think about this for a second: how long can be the assumption chain in a plan that spans multiple quarters? How big the impact?

Okay, Got It: Assumptions Are Important… Now What?

For starters, it is critical to understand that making assumptions is unavoidable. Trying to eliminate all uncertainty prior to making decisions is incredibly counterproductive. We have to assume certain things we don’t possess the full knowledge of at the moment. The real question however is: are we conscious about the assumptions we make? Or are we making them implicitly left and right without concerning ourselves with the consequences? Do we really have reasons to believe that our idea of the future is correct and that the future reality will inevitably unfold the way we’ve anticipated? Many of your existing enterprise processes, practices and constructs are designed in such a way as to spawn multitudes of unmanaged assumptions and amplify their negative impact. A few examples:

  1. Every team has a product owner who never talks to a real customer. Instead the product owner is occupied by reconciling scope trade-offs between competing priorities from different internal stakeholders. The whole backlog is just one huge assumption (in this case representing Area 2 in our classification above: “Customer Value” assumptions). Such an implementation of the role is a problem by design.
  2. Component teams spawn lots of implementation assumptions. Instead of containing all work, the work gets scattered across the organization. For every two teams that have a hard dependency on each other, it creates unnecessary assumptions that could have been avoided by organizing differently.
  3. Rigid enterprise planning process creates huge resistance to change and makes the organization stick at all cost to the initial assumptions, oftentimes despite new, emerging facts.

This will be it for now. It’s an incredibly deep topic and is a result of a huge miss by most organizations. In one of the next posts we will provide a systematic overview of various structural problems that create unmanaged assumptions and how to deal with them. But don’t make any assumptions about the next article, okay? Please say “yes”…


By Alex Yakyma, Org Mindset.

This Is Why Your Organization Can’t Be Agile

So… your organization is on their “Agile journey” for maybe a year or two or five? A lot has been done already in terms of new practices, quite a bit of money spent and a lot of conversations about new stuff. But deep inside you know perfectly well that something is fundamentally wrong with this “journey” and despite all the financial and other resources thrown at the transformation, the enterprise itself has hardly changed at all. This is not uncommon to large enterprises. There are indeed fundamental reasons that prevent the organization from becoming Agile. Let’s talk about those:

  1. Rigid enterprise planning process. It’s delusional to think that there’s any room for agility when the master plans are carved in stone (often in excessive detail) for a year or more in advance. You begin to notice how soon the iterative and incremental process at the team level starts to contradict with the established enterprise planning routine. Moreover, rigid planning removes any need for hypotheses, experimentation and innovation. The call for “innovation” never gets beyond the enterprise wall posters and memos for the exact same reason. Due to the exceeding pressure from the leadership to follow the master plan, if Jonathan, a developer or an architect, wants to experiment with a new promising idea, he’s got to bend the rules to do so at his own risk. How about that…?
  2. Over-constrained funding model. The “over-constraining” part relates primarily to the following two aspects the funding happens to constrain: a) scope of work and b) effort allocation. Indeed, most of the organizations funding attaches directly to the scope of the initiatives being funded and in that way also contributes to the reason #1 above, leading to rigid plans. On the opposite dimension of the matrix, funds allocated to specific people, unfortunately serve as an impediment to cross-team (department or unit) collaboration.
  3. Fragmented, inflexible org structure. The problem often lies in the lack of cross-functional and cross-discipline orientation of the organizational units. On the other hand, there’s no such thing as a perfect long-term structure. That means that organizational units by design must be supportive of cross-unit collaboration. What we see instead in most instances is strong “ownership” over individuals and teams on behalf of the leaders and a strong preference for their own pre-palled work over cross-cutting emergent dependencies.
  4. Lack of critical feedback loops. Customer is almost never directly involved in the process. No, I don’t mean Marsha, a stakeholder from the Claims Department who allocates the money for the next set of software initiatives and therefore is a “customer”. I’m referring to Larry, who got into an accident on the icy road and is filing an insurance claim. I’m referring to Dana, the damage assessor, the bodyshop on the 3rd AVE that will fulfill the order… What we have instead is bunch of inside “proxies” that perfect their ability to speculate what the real customer actually needs. As a result, organizations spend tens of millions of dollars building a complete poo-poo. And what’s worse, they don’t have the ability to understand that for the same reason they built it in the first place.
  5. Misguiding metrics. With metrics there are two possibilities, as practice shows: a) a metric gets fully ignored or b) it doesn’t and therefore it produces a certain kind of motivation. There’s nothing bad with that, per se, if not one tricky problem: organizations tend to measure what’s easy as opposed to what needs to be measured. It is very easy to measure cycle time or throughput, but is a lot harder to do so for things like fitness for purpose, customer enablement, etc. As a result, the organization and teams get completely misguided by a biased set of metrics that eventually encourage local optimization. Also, importantly enough, some critical aspects of agility (such as the ability to respond to change, simplicity, collaboration, etc.) are fundamentally hard to measure and require additional means to raising the organizational attention to those and providing the necessary enablement.
  6. Leadership behavior that contradicts with Agile values. If you are an organizational leader, it’s not enough that you sign a check for training your teams in Agile, buy an Agile ALM tool and a couple more things to be fully happy. In fact, none of those will get you closer to organizational agility unless you start to fundamentally change your way of thinking and your actual way of operating. “How can we be Agile if despite the demos where we regularly produce executable increments, the leadership comes every Monday asking people for task progress in order to fill in their red-yellow-green status reports?” That was a real question I received from a Scrum Master on one of my visits to a large enterprise that was also “on their journey” for quite a while. If people continue to be micro-managed and held accountable to detailed scope planned for them by the “gods” that never even touch the ground, if people who follow the plans and the rules get promoted and those who break them to innovate and create more value, get reprimanded, the organization will never be able to instill the right culture.

Go over the list and see which ones of the six check for your enterprise. Altogether, it will give you a fairly good idea about the impediments you have to deal with on your path to organizational agility. But please be warned: there’s no way your organization can become Agile if these problems continue to loom over its fate. It is far more important that you start addressing the issues above than, for example, teaching teams how to use story points or bringing in a new method for running retrospectives. It’s like doing plastic surgery on a patient with heart failure.


By Alex Yakyma, Org Mindset.

The Key Predictor of Agile Mindset


Who doesn’t talk about Agile these days? Who doesn’t mention that “Agile is mindset” lately? And why not, it’s a powerful statement. As it turns out, however, organizations are generally better with statements than with the actual action behind them. Multiple surveys consistently demonstrate that despite all advancements in new practices, the mindset and the culture of organizations remain largely unchanged and continue to negatively affect organizational performance (see, for example; also our recent survey). So, maybe not everything is so great? Countless enterprises in various industries report being on their Agile journey (some for a very long time) and the result is… what exactly? Yeah, I bet a lot has changed for them with respect to their regular routines (mostly for teams though, to be precise), but not so much seems to have changed in terms of the leadership thought process.

Wait, but changing mindset isn’t easy, is it? No, that’s right, changing mindset isn’t easy. Neither is… treating pneumonia, for example, especially when you don’t know how. Mindset shift, like every challenging task, requires knowledge, skill and mastery on behalf of the change agent whose job it is to facilitate the transformation. In this article we are going to talk about one key discriminator for Agile mindset, something that allows you to determine whether or not you are on the right path to organizational agility. But before we delve into that, my dear reader, I must caution you regarding something utterly habitual in the world of Agile…

Careful with “Iterative and Incremental”

What? But that’s essential to agility. Plus all implementations start with it!

…And that’s exactly where the problem is. See, what happens is the following: we think that “Iterative and Incremental” is an eye-opening experience for leaders and they suddenly get it all. But in reality it actually isn’t. What happens instead is that “Iterative and Incremental” only camouflages the old thinking. If you expect that coming to a demo every once in a while is going to drastically change everyone’s thought process, I would encourage you to think again. In one of the previous posts (Beware of “Hybrid Agility”. It’s a Gift from Hell.) we touched upon the fact that traditional (reductionist) management mindset more often than not finds ways to survive despite the introduction of Agile practices. We also talked about the necessity of the “a-ha” moment and how different people require different triggers for that to happen. As for the iterative and incremental development, leaders often view it as just a “faster way to implement their master plan”. At the same time, however, they would never even possibly question the plausibility of the long-term plan itself. Those “demos” get interpreted exactly the same way as classic milestones in traditional Earned Value Management process. In other words: it changes nothing in terms of mindset.

A Solution to a Problem that Does Not Exist

The problem with most Agile implementations is that they offer a “supply” of practices where the “demand” does not yet exist. No wonder the mindset isn’t changing as a result of the transformation. The leaders are given, in other words, a solution to something that they don’t consider to be a problem. In their traditional view, the environment they operate in is governed by order and certainty. They produce detailed long-term plans, they bind annual funding to a specific scope of work, they hold their teams accountable to executing the master plan. In fact, their plan becomes their “reality”. In their belief system, there’s hardly any need for Agile; they go for this “Agile thing” because everybody else does, not because it is dictated by the actual need.

As for the change agent, “Agile adoption” is not an immediate goal of the transformation. The initial objective is to go after a mindset that creates the “demand” for Agile practices; produces a “pull”, so to speak. So, what that kind of mindset is it that we are after? Expressed in a single statement, it’s as simple as this: the mindset that embraces uncertainty. It’s the mindset that accepts the fact that the enterprise reality cannot be “designed” or “engineered” in a predictable, up-front manner. In this new system of coordinates, we are reasonably skeptical about plans. Instead we accept that we operate in the “fog of war” and our visibility is objectively constrained by the nature of the complex reality we operate in. In this new perspective, we naturally arrive at things like iterative and incremental development. Indeed, if long-term plans don’t work and we know that the development process has inherent uncertainty associated with it, moving in short iterations and then reviewing the results and constantly re-planning, starts to make perfect sense.

Uncertainty: How Do You Get Them to Embrace It?

In a sense, the success of your entire Agile transformation is contingent upon the ability of the organizational leaders to embrace uncertainty. This is a deep topic and in this article we are going to touch upon some aspects of it.

For starters, I hope that our initial conversation about practices did not leave you with an impression that iterative and incremental development should not be adopted. The problem is not in the “Iterative and Incremental”, per se. The problem is that if the leadership mindset remains unattended, “Iterative and Incremental” will make the leaders believe that they “are already Agile” and it will be only harder for you to make the real change happen. The mindset gap in your transformation must be filled and that’s what we are after here.

Secondly, there are specific factors that rigorously protect the old mindset. Without going into much detail regarding those at this point (something we will definitely discuss in detail in the future), let’s just go over what they are. These are the key ones:

  1. Cognitive bias. A very strong force in this matter. Our brain is wired to favor certainty over variability, ambiguity and risk. We survived due to this bias. But when talking about product and systems development, the same bias that warranted our survival, does us a great disservice.
  2. Distorted empirical evidence. Due to fundamental structural flaws, most enterprises tend to favor good news over bad news being delivered to the leadership. This prevents the leaders from ever questioning their initial assumptions.
  3. Flawed motivation. In some cases, even the people that understand the problem with the current operating model, decide to play along rather than put their careers at risk by escalating systemic organizational issues.

All of these are serious problems that we will be addressing in future posts.

For now this is it. And before we are “done-done” today, I’d like to leave you with one important sentiment that every change agent should keep in mind at all times: your transformation doesn’t happen in cubicles, hallways, meeting rooms or corporate cafeterias. The transformation you are after happens inside a human brain. So, ask yourself: what exactly do you do to win that battle? How do you help trigger a new thought process in leaders? Where does most of your change agent effort really go?

Are you satisfied with your answers? … No? Good…


By Alex Yakyma, Org Mindset.