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:

 

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”…

 

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.

 

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 www.stateofagile.com, 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…

 

Optimization Cycle We So Badly Need

I can’t think of any large organization that wouldn’t aim at optimizing business outcomes; all of them have such intent. But boy, those improvement initiatives fail almost every time. I was always very curious as to why that happens. And then, upon examining a number of optimization initiatives I had access to, I found one common underlying cause: wrong mental model of reality. Moreover, it is highly divergent across the board: engineers think the problem is in one place, middle management sees the root cause elsewhere, their bosses, in turn, see it in a whole different way… No wonder positive change does not happen because it’s a divergence fest.

Therefore, our general concept of continuously optimizing the outcomes (namely, the simple “Optimize – Repeat” process) needs to change. The fundamental process extends to the following three steps: 1) Refine shared mental model, 2) Optimize, 3) Repeat.

Step 1 is tough, however, and it doesn’t happen on its own in organizations that lack effective information flows across different layers (which should read as: most organizations). But as soon as some facilitation is being done around step 1, bit by bit the organization acquires a better picture of reality and step 2 stops being a constant miss.

Climbing the BS Mountain: Agile for the Sake of Agile

 

“Why did you start your Agile transformation?”… That’s a darn good question that many change agents and organizational leaders should ask themselves every now and then. That’s the question you should ask yourself and if you feel like you don’t have a good answer or if your answer is just fuzzy, sweet corporate talk, your organization is in trouble. Here’s why…

Most organizations adopt Agile because a company across the street does

That’s a very poor motive…

Every real change is hard. You can say that you transformation is on the right route if it ends up being the transformation of the people’s minds. Anyone can declare a new process; that’s the easy part. What is hard is shifting from the old thinking to the new one and without such a shift all process changes will have marginal impact, if any. As a part of transformation, the enterprise will have to go through a lot of real struggle as many “established” ideas and ways are simply incompatible with Agile. Some examples of that may be current org structure, funding model, HR practices, customer engagement, user interaction, leadership behavior and so forth.

It is very easy to put a bunch of stickies on the wall and start doing stand-ups, retros and things like that. But unless the thinking begins to change – especially on the management side – nothing good is going to happen. And guess what, it takes courage to abandon old fundamental concepts; it requires a real sense of urgency behind the transformation in order to do so. And adopting Agile for the sake of Agile gives your organization zero sense of urgency. It’s a one-way trip to the BS Mountain, which once climbed to, holds you a hostage of false sense of Agility from there on out.

Every transformation needs a set of clear business goals

On the one hand, this is the path to raising the sense of urgency around the transformation itself. This will fuel the journey, especially will help you getting through the hardships of the mindset change, which is the toughest and the trickiest part of the ride.

On the other hand, Agile is too broad a notion that provides certain optimization tools for your enterprise, but you have to decide what and where do you want to optimize. And for that you need a clear problem statement. This is not as simple as it seems, because you may easily get it wrong. Remember: when formulating the underlying problems, the organization will be fully exposed to all possible misconceptions and cognitive bias. Here’s a simple example of how this clouds the judgement and makes the enterprise myopic… Many organizations come to the conclusion that their software delivery function is slow and that’s the big problem they need to solve. What a great example of honest, self-crtitical reflection, isn’t it? Surprisingly no, it isn’t, in most of the cases. What organizations usually fail to see is that they deliver software that isn’t fit for purpose (AKA “crap”). Building it two times faster? What noble goal! The only outcomes of that will be a) more customer frustration and b) even further bloated codebase. I sense you started wondering: why don’t they see that the problem is not in the speed of development and delivery but rather in what is being delivered? Well, to arrive at that conclusion would require acknowledging that basically “we don’t know what we are doing”. That usually is a politically dangerous topic, unless again, the sense of urgency is high enough to overcome it. It’s a whole science (and art) of how to arrive at the right understanding of the problem and probably is a topic for a future post. But for now, let us assume that somehow magically we have arrived at the problem statement that will guide us through this journey.

As soon as we have the problem statement, it instantaneously creates the right focus for the entire organization. It actually makes Agile transformation a meaningful process. Now, instead of fuzzy “let’s be Agile”, we are aiming at very specific things, which in our case could be “effective cross-cutting feedback loops” that would allow the organization to effectively validate product assumptions with the customer and therefore prevent from building volumes of expensive poo-poo. Interestingly enough, such focus and specificity eventually leads to truly “being Agile”.

So, is Agile a mindset or just a set of tools?

I’m glad you asked…

It certainly is a mindset. But the trick is that you cannot directly “wholesale purchase” a mindset. You have to grow it through solving specific problems and for that, concrete tools are necessary. In fact, abstract talks about Agile never result in anything useful to the organization. All it does is only hiding the real problems deeper under the thick layer of false expectations.

So how would you know if you are on the right course? The answer is pretty simple and I will describe it as two mutually exclusive scenarios:

  • If all you do is working with the teams while assuring the management that the transformation goes well, and in doing so the management is being constantly delighted by your effort, you are on the wrong path! The organization is not pivoting to a new thought process; otherwise the management wouldn’t be all that delighted every step of the way. If this is the case, you should stop and rethink your transformation strategy immediately. My assumption is that you take the job of the change agent seriously, therefore will take action without hesitation or remorse…
  • If, on the opposite, you are actively working with the management and together you are going after specific problems; if those conversations are not always smooth and pretty, but the management begins to understand that the enablement they create is the ultimate success predictor in the transformation, then you are on the right path. You will definitely notice that you are moving in the right direction because the right path is pretty bumpy.

Ok, so, solving specific problems means we should aim at specific benchmarks, correct?

No, absolutely not! What are we… trying to “waterfall” the adoption of Agile? As hilarious as it sounds, it’s actually not as useful. We certainly have to focus on specific problems, but that doesn’t mean that we know how exactly we will solve them or in which exact state will our system (the organization) end up being upon solving them. The complexity of the environment in which we operate, does not allow us expect deterministic outcomes, in principle. We can only know the general direction, the vector. But any effort in saying, for example, that three quarters from now we will get customer satisfaction up 60%, is total BS and for that matter, it is precisely what you do if you are a citizen of the BS Mountain. It is critical that you don’t shoot yourself in the foot with speculative goals.

Remember: your transformation will constantly require a certain degree of intentionality. But since mindset and new habits are emergent in nature, you have to let them find their optimal growth pattern. Just like you do with your garden…

Good luck with your transformation!

 

Org Mindset Podcast. Metrics: Leading and Lagging Indicators.

I had a wonderful conversation with Sunil Mundra, Agile Evangelist, Principal Consultant at ThoughtWorks, on metrics… More specifically: Leading and Lagging Indicators. Metrics are always the representation of current organizational thinking and therefore become a very important aspect of the Lean-Agile transformation, often representing a lot of challenge to the change agents. This conversation is a 30-minute dive into the realm of indicators that track the organization’s success.

You can listen to the podcast here: Metrics: Leading and Lagging Indicators.

Beware of “Hybrid Agility”. It’s a Gift from Hell.

How about destroying the transformation effort before it even started? You wonder how? There are many ways, but today we are going to talk about one that is a classic example of the old mindset mercilessly taking over and driving you back into the Stone Age.

I’ve been observing a picture like this quite a few times: an organizational leader (let’s call him Josh) offers suggestions to his subordinate change agents and managers with respect to the Agile transformation:

“We are starting on a new journey called ‘Agile’. This is an exciting opportunity to improve our development speed, quality and much more. We aught to be aware, however, that the change has to be taken in baby steps so as to not disrupt our business. With that in mind, our current direction will be towards Hybrid Agility…”

…Silence in the room. Josh continues:

“What this means is that we will continue to define the requirements the way we used to do it before, but now we will have all the power of Agile at our command to improve the implementation of those requirements by teams.”

Still deafening silence in the room… but now with some disturbed expressions. Josh proudly drives his speech to conclusion:

“Our common goal will be to help the teams adopt the new ways of working as quickly and as smoothly as we can…”

Now, let me translate what Josh just said. He said: good bye, Agile! It was nice knowing ya, even though, not for too long!

But words are just words. Let’s patiently break down what really happened here and see what leads to such thinking.

Looking at Agile from a traditional management point of view

At any given moment, we are a hostage of our current mindset, be it Agile, Waterfall or even something completely different. Having said that, every time we encounter a new idea, concept or phenomenon, we are going to reason about it, evaluate it and operate with it, using the thinking tools that we currently have at our disposal. Now, if you carefully think about it, this is exactly what happens with any organizational leader who was primarily exposed to the traditional development model, before they first encountered Agile. Their thought process is a selective mechanism that picks what makes sense from their perspective and ignores everything that doesn’t. But even those things that appear to “make sense”, get interpreted in the manner that comfortably fits their current perspective. So, let’s see, what usually happens when someone like Josh makes their first encounter with Agile; how exactly those focus areas interpret in their established system of coordinates:

  1. Customer collaboration. Well, that sounds good, but it’s absolutely unclear how that would work. Simple ideas of proxy roles (like Product Owner) seem to be quite satisfying, even though more often than not, do not facilitate any communication with the customer. But even worse: Josh doesn’t really understand what’s such a big deal; you just carefully define the requirements and that’s all you need.
  2. Business and Development constantly work together? Why? That sounds an excessive waste of time to Josh.
  3. Iterative and incremental development. Bingo! This makes total sense. We will figure out some adjustments as we go… in fact, this is a perfect way to speed up the development of the projects we planned to execute this year.

You got the logic? Good… So, now you understand why Josh, even though is going to undermine the organization’s ability to benefit from Agile, cannot be actually blamed for it. Let me explain why…

Agile is a radical shift of mindset that cannot be achieved incrementally

Okay, not incrementally, but how then?

Here’s the important thing to remember: different people have different ability to part from their old thinking and embrace a whole new paradigm. Moreover, they need different type of a driving force to do so.

There are people, whose cognitive abilities allow them to shift their thinking simply as a result of one single thought experiment, triggered, for example, by reading an article or even a short tweet. But such individuals constitute a rather small fraction of the whole. Others pivot in their thinking as a result of an extensive training or workshop. And yet others need a bulk of empirical evidence, opinions of multiple other people within the organization,  exposure to other enterprises that have succeeded with the transformation and more.

All three categories are different and yet they all have one thing in common: they need their “a-ha” moment to embrace a new concept.

The only difference is in how they arrive at that “a-ha” moment. For you as a change agent, this means that you will have to apply a combination of different methods to achieve the required shift in thinking. Should you arrange a training for the leaders? Yes, absolutely. But don’t stop there, even if it seems that “they get it now”. You will be quickly disillusioned when the time comes for them to “apply” the knowledge to their actual activities. Assume by default that coaching will be required, sometimes a lot of coaching. You will need to seek additional exposure to facts that eluded their attention so far. That’s a lot of work, but that’s what it takes to do one of the hardest things out there: helping a person grow a new mindset. As a change agent, that’s what you’re after.

Still, what to do with the “Hybrid”?

Under no circumstances should you settle! The problem with a hybrid is that it’s actually an easy way to cement the old thinking under the layers of new Lean and Agile terminology. And when that happens, you have even less chance to get everyone on the right track. To you the fact that Josh tends to still think this way, means that the currently applied methods did not yet lead him to the a-ha moment and that you need to double-down on that. More coaching, more exposure to Gemba and other things that will eventually help. We will go over these techniques in much more detail at some point in the future. For now, however, it’s important to remember: don’t settle with “Hybrids”. It can be a necessity sometimes, to let Josh finish his talk uninterrupted. You, as a change agent, may elect a tactical retreat as a means to regroup and attack the issue when you’re better tooled up for it. But you cannot fundamentally accept it. If you do, you are going to be part of the problem!

 

No Single Answer: How Organizational Context Impacts Lean-Agile Transformation

Every transformation effort that does not take into account the unique organizational context is destined to stagnation. Join Alex Yakyma and Audrey Boydston to learn more about how to use organizational context to your advantage as a change agent and coach. As part of their webinar they will discuss the following topics:

• What makes organizational context a critical factor in the transformation?

• Importance of context in building sustainable practices

• Problem-oriented approach to context exploration

• Avoiding blind spots when operating with unique context

• Building shared mental model across the organization

• Exploiting context to optimize organizational outcomes