RSS

Category Archives: Coaching

Are leaders and the company culture the real problems to agile adoption?

Most surveys about the state of agile, point to the existing culture and leadership as the primary causes of agile struggles. But are those two, and their derivatives, really the culprits?

Isn’t it curious that our goal, as agile coaches, is to deliver value by ascertaining how best to meet the needs that are determined by the organization, and yet we consider the organization itself to be the biggest impediment to doing so. Is it possible that the problem is not in the organization’s culture and management structure but in our own assumption that there is a singular definition of value and our determination to deliver on that definition despite the organization we are trying to transform? Could it be possible that the client organization understands what is value in ways that we do not?

G. K. Chesterton in this 1929 book, The Thing, said:

In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.

This paradox rests on the most elementary common sense. The gate or fence did not grow there. It was not set up by somnambulists who built it in their sleep. It is highly improbable that it was put there by escaped lunatics who were for some reason loose in the street. Some person had some reason for thinking it would be a good thing for somebody.  And until we know what the reason was, we really cannot judge whether the reason was reasonable. It is extremely probable that we have overlooked some whole aspect of the question, if something set up by human beings like ourselves seems to be entirely meaningless and mysterious.

There are reformers who get over this difficulty by assuming that all their fathers were fools; but if that be so, we can only say that folly appears to be a hereditary disease. But the truth is that nobody has any business to destroy a social institution until he has really seen it as an historical institution. If he knows how it arose, and what purposes it was supposed to serve, he may really be able to say that they were bad purposes, or that they have since become bad purposes, or that they are purposes which are no longer served. But if he simply stares at the thing as a senseless monstrosity that has somehow sprung up in his path, it is he and not the traditionalist who is suffering from an illusion.

In other words, an organization’s culture has evolved for a reason and has likely been strongly influenced by what the organization has found to deliver value in the past.

Culture is a pattern of shared tacit assumptions that was learned by a group as it solved its problems of external adaptation and internal integration that has worked well enough to be considered valid and, therefore, to be taught to new members as the correct way to perceive, think, and feel in relation to those problems. ~ Edgar H. Schein

Since it’s inception, any organization has had to learn what strategies, values, procedures, behaviors, and norms work within its environment. Those that do not further the company’s mission are discarded; those that do are retained and progressively improved over time. This history of learning, by trial and error, is rarely written down but forms the basis of tacit assumptions and norms — the collected wisdom about what leads to success within the organization. What is valued by the organization, then, gets encoded in the company’s culture and their bureaucracy. To the uninformed, this bureaucracy may at first glance seem capricious, brutal, and wasteful, but it is simply a way for the organization to ensure that people pay heed to what is considered important in that organization. For example, the “burdensome” security scans, reviews, and audits in some financial institutions only point to the organization’s belief that doing right by the client is important and that their personal data must be protected at all costs or that our brand is everything to us and we shouldn’t needlessly take on risk that might harm our brand image and reputation.

The Chesterton’s fence principle applies to agile introductions as well. Again, Chesterton’s fence is the principle that reforms should not be made until the reasoning behind the existing state of affairs is understood. Just because there doesn’t seem to be a readily apparent reason for this fence to be here doesn’t mean there isn’t a reason. What this means is that Agile coaches must first come to understand those values, strategies, and goals that are embedded in the client organization’s culture.

Most agile proponents however, are far too eager to tear down what exists, without first understanding why that exists, in order to put in place what they believe is “agile” and “better.” It is the rare agile coach that takes the time to first understand what the company values — most coaches are aware of one way of doing things (insert the name of your go to agile framework here) and want to jump straight into the mechanics of implementing it. They often do this because they want to demonstrate, to the client, that they themselves are adding “value.”

The result of not heeding Chesterton’s fence is that the agile coaches frequently run into “resistance.” This resistance is chiefly due to the client management’s perception that what they value and what their concerns are aren’t being considered.

Agile proponents come in and say we should discard X and do Y instead in order to not have to deal with the negatives of the existing X.


X     |       Y
|
+                |
-----------------|---------------
-                |
|
|

But clients believe (whether incorrectly or not) that the benefit of the agile evangelist’s point of view (Y) leads directly to a loss in what the client believes is important to her (X). In addition, they perceive that the new approach simply swaps in a different set of negatives.

What coaches could do instead, is to work together with the client to come up with a solution that explores how to get the “new” benefits without losing the benefits of the existing approach/culture. Instead of approaching the transformation in a “big bang,” where the existing culture and structure is swept away in one fell swoop, a measured incremental approach where we learn as we go might be better. Agile coaches could take an agile approach to agile adoption — drive organizational change incrementally and make course adjustments based on what they learn about the organization’s true needs and dynamics.

But clients believe (whether incorrectly or not) that the benefit of the agile evangelist’s point of view (Y) leads directly to a loss in what the client believes is important to her (X). In addition, they perceive that the new approach simply swaps in a different set of negatives.

What coaches could do instead, is to work together with the client to come up with a solution that explores how to get the “new” benefits without losing the benefits of the existing approach/culture. Instead of approaching the transformation in a “big bang,” where the existing culture and structure is swept away in one fell swoop, a measured incremental approach where we learn as we go might be better. Agile coaches could take an agile approach to agile adoption — drive organizational change incrementally and make course adjustments based on what they learn about the organization’s true needs and dynamics.

 
Leave a comment

Posted by on August 25, 2018 in Agile, Coaching, leadership

 

Tags: , , ,

Being a Discerning Thinker (aka Understand the Mental Models that Drive Your Thinking and Behavior)

What goes through your mind when you hear or read a statement like, “Change is hard?” Most people simply take it at face value, mindlessly add it to their belief system, and move on. There is little thought given to the conditions that might make it true (or false) and whether the statement agrees with or contradicts personal experience, observations, and beliefs. A more thoughtful person, however, would take a different approach and examine the statement in light of his mental models to determine if the statement holds up or if his mental models are outdated and need to be changed.

A mental model – or paradigm – is a framework or worldview that helps you understand life, make decisions, solve problems, interpret the world, and understand the relationship among things. Mental models are deeply held beliefs about how the world works and they guide your perception and behavior.

Most lean and agile coaches (and other consultants) unsurprisingly operate from the “change is hard” mindset — the metaphor they use is that change is a long arduous journey. The start of the journey is the client’s current state and the destination is the eventual end (desired) state. Sometimes, the journey is envisioned as one without an end — a distant ideal state or north star. Of course, the journey isn’t expected to be easy; it’s supposed to be hard and that’s why consulting help is highly recommended — a “good consultant” can show the way by producing plans and schedules and highlighting future expected impediments and countermeasures. This leads one to believe that transformative change is a linear, staged, and controllable process.

People with a different set of mental models, however, can view change differently:

  • Continuously unveiled: Instead of change being controllable, it can be viewed as being continuously unveiled wherein every intervention and interaction gives rise to new circumstances that have to then be addressed or skirted, ad infinitum. These new circumstances and their order cannot be preconceived; change is, therefore, a series of ongoing adjustments to what is being observed. Non-trivial change is, therefore, contextual, non-linear, and impossible to be staged.
  • Instantaneous: Instead of change being long and hard, it can be instantaneous like adding milk to hot tea. Just like the drops of milk diffuse through the hot tea, the right change interventions can smoothly, continuously, and effortlessly ripple throughout the organization. The operating belief is that a small amount of change in an important habit can cause a disproportionately large transformative effect. Charles Duhigg, the author of “The Power of Habit,” calls these “keystone habits.” This change is permanent — you can’t easily separate the milk and tea once mixed.
  • Easy: Change can be easy. Effort doesn’t have to be a matter of gritting one’s teeth and willfully forcing oneself to act. Effort arises naturally once you establish the conditions that generate it.

The “long and hard journey” metaphor often leads to the belief that people are “change averse” — they neither like change nor the effort required to make that change. But there is enough anecdotal evidence that people make drastic changes willingly — we all leave the comfort of our parent’s house, go out into an uncertain world, change jobs, get married, have kids, etc. We are not averse to change; however, we are suspicious of change efforts that do not make sense from our point of view. Calling someone names, like a “resister” is so much easier than getting out of our own comfortable echo chamber and dealing with the vexing and even annoying challenges raised by the person who disagrees with your narrative. “Resistance” isn’t due to a lack of desire to change, but due to lack of information, skills, or insight and due to a fundamental disagreement with the change approach or desirability of the result. Change agents need to focus on people’s concerns, interests, desires, and bandwidth for change instead of lazily lumping people in a “change resistant” bucket.

Having a point of view is good, but believing that your mental models are the only true ones can blind you, make you inflexible in your thinking and approach to work, and preclude available options. The more we rely on outdated mental models even while the world around us is changing, the more our mental “entropy” increases. Mental models are imperfect and only provide partial explanations; however, good ones have the most utility and help you make wiser choices and take better actions.

Developing a broad base of mental models is critical for anyone interested in thinking clearly, rationally, and effectively. This is summed up nicely in the following quote from Timber Hawkeye,

“Our opinions and beliefs tend to change depending on time, place, and circumstance. And since we all experience life differently, there are multiple theories on what’s best, what’s moral, what’s right, and what’s wrong. Therefore, no matter how certain we are of our version of the truth, we must humbly accept the possibility that someone who believes the exact opposite could also be right (according to their time, place, and circumstance). Accept that other people’s perspectives on reality are as valid as your own (even if they go against everything you believe in), and honor the fact that someone else’s truth is as real to them as yours is to you.”

 

 
Leave a comment

Posted by on May 15, 2018 in Coaching

 

Tags: ,

Executive Conversations At the Start of a Transformation Effort Are Key

To have a decent chance of leading a successful change effort it is imperative to have the right conversations, at the start, with the executives and stakeholders who will be instrumental in the success of the transformation effort. While starting at the team level and focusing on the process introduction is far easier, it is also the riskiest strategy long-term.

So what might you want to do during the initial session:

  • Ensure that the executives and sponsors are clear on why they are embarking on their Agile journey. Remember that Agile practices and methods are just a means to an end and not the end itself. Additionally, most transformations fail because people treat them as transitions instead — you want to make sure the leaders understand the difference between the two.
  • The leaders also need to be clear on what outcomes (quantified where possible) they want to achieve.
  • Change efforts succeed when leaders actively lead the change and remove barriers to higher performance. You may want to talk about the three key components of organizational agility — (1) leadership agility (how leaders lead, inspire, direct, and motivate others), (2) organizational structures (structures, rules and policies that facilitate how work gets done and how results are produced), and (3) organizational culture (collectively held beliefs, values, and assumptions that determine how people think and how they behave) — and how they themselves need to approach the leadership work differently.
  • Ensure they understand the concept of looking at things holistically — discovery, development, delivery, and leadership and how each affects the other.
  • Lay out at a high-level what the incremental goals might be — moving from tactical to strategic to aspirational.
  • Check their level of commitment on a 1-10 scale, where anything less than 8 indicates wavering commitment.
  • If committed, introduce the concept of an enablement team and ask them for recommendations on who should be on that team.

Make sure you keep engagement high — have the leaders work through exercises that get them up and collaborating.

Bottom line — in my experience, two to three hours spent with the executives and sponsors early on will prevent hundreds of hours of pain and suffering later on. What have your experiences been?

 
Leave a comment

Posted by on November 9, 2017 in Coaching, leadership

 

Tags:

Misplaced Agile Transformation Priorities

Most companies that I’ve worked with begin their lean-agile transformation effort by attempting to fix/improve the development teams. However, the source of most of the problems lies either upstream (lack of sequencing of work, demand far outstripping capacity to do the work, suspect value of work requestsed, etc.) or downstream (lack of environments, wasteful and onerous deployment processes, etc.) of the development teams. And, of course, management struggles in creating an environment that is conducive for high-performing teams is well known and another area for improvement.

A significantly better approach would be to start with introducing the CALMS conceptual framework (culture, automation, lean, measurement and sharing) for driving the integration of development, support, operations and business. Over time, plan and prioritize initiatives and improvement efforts to move each of the CALMS elements forward. Simultaneously, work with the business and with stakeholders to better define and sequence customer-valued increments of functionality.

You have a higher probability of making meaningful improvements and moving the needle on the busniess metrics that matter by changing your starting point. What have your experiences been?

 
1 Comment

Posted by on May 15, 2017 in Agile, Coaching, Improvements, lean

 

Increasing Predictability

The previous two blogs (3 things that matter when embarking on an Agile transformation and five stages to organizational agility), listed Predictability as an important initial step on the journey to Agile at Scale, where, predictability implies the ability to accurately answer, “When will it be done?”

Smooth flow — the effective, efficient, and sustainable paced delivery of customer value — and predictability go hand-in-hand; you cannot have one without the other. Uneven flow is usually discerned, on your cumulative flow diagram, by large buildups of work somewhere in the process.

Impediments are a major cause of uneven flow and lack of predictability; however, there are a number of other contributing factors. A partial list would include some of the usual suspects:

  • Backflows (defects and rework)
  • Starts and stops (do-wait cycles — delays between steps, task switching, people being pulled in multiple directions to work on different efforts)
  • Large work items and large batches
  • Work-in-process being canceled and being taken off the Kanban or Scrum board
  • Organizational silos and a lack of communication, cooperation, coordination, and collaboration across departmental boundaries
  • Lack of swarming within the “team” to complete work quickly
  • Scope of work being changed once it has been committed to (often by adding scope or acceptance criteria)
  • Dependency on external vendors or teams
  • Hesitancy in roadblock removal
  • Overtime (initial increase in rate of work completion followed by a decrease due to burnout)
  • Mismatch between available skills and the task complexity
  • Variability inherent in the work itself

To the above, you could also add a couple of other non-readily visible causes:

  • Expediting some items to the detriment of other items — e.g., items in an expedite lane being given preferential treatment, thereby, slowing down all the other work in-process items
  • Non-FIFO implementations (where teams cherry-pick items from their process queues to work on) prioritize some items over others. This results in the non-preferred items taking longer to complete than they would have otherwise, i.e., cycle times for preferred items have been artificially reduced at the expense of the other items.

And, of course, the biggest culprit of all:

  • Mismatched input and output rates that cause work-in-process (WIP) to constantly increase and Cycle Times to lengthen. Ideally, your CFD should have parallel and narrowly spaced, arrival and departure lines.

While one of the main tenants of Lean is waste removal, sustained waste removal is not possible without the ability to first see the waste. Similarly, improving flow is difficult without first being able to see what is impeding flow.

To start your journey to becoming more predictable, do the following:

1. Visualize the work flow

Understand the scope of your system and the activities that help convert the inputs into the desired outputs:

  • Create a flow diagram
  • Identify the boundaries of the system (the input/entry and the output/exit stages) you are concerned with improving
  • Identify the steps and each step’s input, output produced, and policies (conditions of doneness)
  • Identify the Definition of Ready, Definition of Done, cadences, and event triggers

2. Capture data

Agree on what flow and predictability related metrics make sense in your context and then determine what data to capture and where to get that data from. Understand where things currently stand by getting baseline numbers for these chosen metrics.

3. Implement tactics to limit causal factors

Brainstorm, discuss, agree, and implement tactics to limit causal factors to unpredictability and irregular flow:

  • Mismatched rates of incoming work and completion of work
  • Instability of teams (their composition and number)
  • Lack of clarity of requirements and when to implement them
  • Scope creep for in-process work
  • Starts and stops
  • Delays due to waiting (for work to be done)
  • Work being canceled while in-process
  • Arbitrary aging due to blocks, excess WIP, and poor pull (including non-FIFO and expedite)
  • Overtime to compensate for excess WIP and mandated artificial deadlines

An output of this step should be a list of explicit process policies that address the above mentioned. Additionally, an agreement on how the whole team will handle defects, rework, and canceled work on their Scrum or Kanban board will go a long way in reducing confusion and waste.

4. Get to a stable, WIP-limited, pull-based, system

Get to a point where your Cumulative Flow Diagram indicates smooth flow via parallel and narrowly spaced, arrival and departure lines. You do this by tackling the factors that inhibit flow and predictability (item 3 above).

Remember that some variation always exists (and always will) within your system and can be seen in your story completion time scatter plots. Your goal, therefore, should not be to drive out all the causes of variation completely, but to identify and understand the special-cause variations that make your process inherently unpredictable. You can then take actions to address these special causes.

5. Improve flow continuously (start reducing time to market)

Once you have a stable system, from Step 4 above, you are then ready to experiment to improve the process and to increase your ability to rapidly respond to change. A stable, well-running process is necessary even if you are in a lean startup environment where you are trying to figure out your market and making sure that you are building the products your customers want — a smooth and dependable process will give you the confidence to change direction quickly without worrying about delays. Predictability and Adaptability are not mutually exclusive – you can have one with the other.

While Step 2 provides an initial indication of where you are starting from, Step 4 provides a solid baseline for you to base your improvements on. Every improvement you now make should be to improve the baseline measures. For example, if you think that adding an Expedite swim lane is necessary to address emergencies you can track the change on approximate average cycle time and actual throughput to determine the efficacy of the intervention. Likewise, you can gauge the impact, on delivery, of introducing Classes of Service and treating them differently.

Hopefully, the above will help you in your agile transformation journey. Comments and further conversations welcome.

 
3 Comments

Posted by on February 8, 2017 in Agile, Coaching, Improvements

 

Tags: ,

Our Agile #transformation is struggling without #management support — can’t we just fire them all!

While nothing is easier than to denounce the evildoer, nothing is more difficult than to understand him. ~Fyodor Dostoevsky

A significant number of agile coaches and agile zealots often portray managers as evildoers. But, how often do these agilists:

  • Practice empathy and try to put themselves in the manager’s shoes?
  • Consider the very real fears that managers have to face — fear of looking silly, fear of all their effort over the years coming to nought, fear of being sidelined, fear of taking “unnecessary” risks, fear of not delivering and looking bad?
  • Say what needs to be said without embarrassing, humiliating, or otherwise offending the manager’s self-worth?
  • Make the managers “feel felt?” Not just heard, but also being aware of and demonstrating awareness of how the managers are feeling and the emotions they are grappling with.
  • Take the time to understand what managers want, what they feel, what they struggle with, what they enjoy, what irritates them, what they fear, what pressures they face, …?
  • Realize that managers feel lost in the new world and are asking for help in making the change stick?
  • Suggest approaches that works smoothly and take a load off managers’ shoulders?
  • Spend time 1-on-1 with the managers to guide them in impediment removal and more importantly in creating the right structures of fulfillment?
  • Spend time 1-on-1 with the managers in co-designing a step-by-step approach versus just talking in generalities?

Not very often, I presume. It’s so much easier to point fingers than to consider your own role in exacerbating an “unseemly” situation. So is it any surprise that a potential ally is often turned off by the behavior of the change agents?

 
1 Comment

Posted by on September 22, 2015 in Agile, Coaching

 

Tags: , , ,

Andon cord influenced DevOps 20/45 practice

Andon cord or call button influenced 20/45 rule — Problem Swarming

A few years ago, I coached a high-performing DevOps team. This was the company’s first foray into building a more collaborative environment between development (who built embedded software for slot machines) and operations (responsible for ensuring the slot machines worked flawlessly on the casino floor). Additionally, the technology stack was large and new to the company — they had wisely decided to move to a cloud based ecosystem for managing the slot machines and games on those machines remotely without having to send a technician to the casino every time there was a glitch or software needed to be updated. As such, yokotenkai (horizontal/lateral sharing of knowledge, ideas, best practice) was a very important secondary goal.

This group borrowed practices from Lean and adapted them to suit their purpose. One of the practices they made their own was the use of an “andon cord.” An andon cord is a way of signaling a problem (whether real or suspected) and alerting the team that they need help. This team implemented a “20/45” rule — if a team member was stuck for 20 minutes and didn’t have clarity on how to proceed, he was expected to pull the cord, i.e., ask for help. The team (and not just the team leader) would respond immediately and everyone would pitch-in to solve the problem. They had 45 minutes to determine a way forward before going back to whatever else they were working on.

This sounds like a very inefficient practice what with the constant interruptions. However, this turned out to have a number of beneficial side-effects:

  • Whole team attention was brought to bear immediately on a pressing issue.
  • By definition, in-process work is more important than work that hasn’t yet started; consequently, completing what’s in-process trumps new work. This ensured that team members were always focussed on moving existing work items forward.
  • Quality was built-in (team caught problems before they were cemented in place).
  • No one person knew the complete technology stack and experimenting and learning were critical to team success. Consequently, someone not pulling the cord for a week was a red flag. Either the person (1) wasn’t stretching and trying something unfamiliar and uncomfortable, (2) had a fear of being vulnerable and asking for help, or (3) had a tendency to work alone and figure out a solution by himself (wasting significant time, not utilizing the team’s existing skills and brainpower, and often ending up with a suboptimal solution).
  • Everyone’s level of knowledge increased every time the cord was pulled and team brainstormed approaches. Over a two-month period people’s understanding grew by leaps-and-bounds and team members became comfortable with being uncomfortable.
  • The agreed upon way forward was usually better as different perspectives and approaches were considered.
  • Everyone on the team knew what was going on and what challenges they were facing.
  • Team members felt completely empowered to determine the way forward.
  • Team members demonstrated vulnerability by asking for help and loyalty by helping each other complete their work.

It’s now been 2 years since I coached at that company. I recently heard that all Agile teams there are taking this approach — Yokotenkai at it’s finest!

 
Leave a comment

Posted by on September 22, 2015 in Agile, Coaching, Improvements

 

Tags: , ,