In organizational change, culture comes last

Last Updated on Tuesday, 2 April 2013 07:25 Written by Jesse Fewell Friday, 22 February 2013 12:00

courtesy @opensourceway

Here at LeadingAgile, we have a specific cycle for achieving organizational transformation. In short, to make real substantive change, you need to attack the following dimensions

1. Organizational Structure: 
2. Processes, Practices, Policies
3. Cultural Beliefs

…in exactly that order. That’s right, when you go to change an organization for the better, you need to do the culture part last.

“But wait, Jesse. Isn’t culture the most important ingredient of an organization? What about the phrase ‘Culture eats strategy for breafast’? Why not do the most important thing first?”

I’ve been coaching this to my clients for a while, but in the past few months it has become painfully evident to me that Rule Number Zero for “going agile” is to have stable team rosters. One of my clients has the habit of shuffling people from one project to another, with no notice. When I started talking to them about the mechanics of user stories or other such details, they simply couldn’t care less; they were overwhelmed and tired from getting yanked around. A different client actually KNEW they had to re-organize their teams to be more focused. But while senior management was busy socializing the new org chart for 4 months, the teams were thrashing, fully convinced that management didn’t have the fortitude to effect any kind of real change.

Some of my colleagues think that if you go straight to modifying the cultural mindset of the leadership team, you will get the momentum you need for lasting results. But the problem is you can’t get there from here. There is a known, methodlical process for changing people’s mental models. Specifically, consider that the same process applies for people struggling with personal dysfunction. Think about it. To achieve behavior modification,

1. First, get out of the environment that enables the dysfunction, and get into a support structure
2. Then, leverage that support structure to work through a 12-step program
3. ONLY THEN, can you introspect and self-actualize yourself as the new person

Granted, it is an iterative cycle:

• Change one small environmental thing =>
• to create the space to change one small process =>
• which slightly shifts my confidence based on a known track record =>
• which motivates me to make another environmental tweak…

But the point here, is that the iterative cycle of behavior modification is that you can NOT change a belief system, until you first have some positive behavioral evidence, which only happens after you create a safe and stable operational environment.

What about you? Have you seen the latest mission statement, management fad, or feel good effort yield zero results in your day to day work?

Transforming Mountains

Last Updated on Monday, 26 November 2012 07:49 Written by Rick Austin Tuesday, 6 November 2012 09:42

In early October my wife and I vacationed at Cape San Blas, FL and I was struck by the beauty of the brilliant white sand on the beaches. They are impossibly white and it made me wonder how that sand came to be. I became fascinated by the time it took and the processes that made it so. I learned that when walking on that sand, I was really walking on ancient material from the Appalachian mountains. Eons ago the Appalachians were taller than the Himalayas but through the ages they have continuously been worn down and transformed. All of that material flowed towards and was deposited into what is now the Gulf of Mexico. The continuous motion of the waves deposited quartz that came from the Appalachians onto the beaches of Cape San Blas and other beaches on the Emerald Coast.

This extraordinary amount of time made me think about the time it takes for any type of change, including transforming an organization to work in an agile manner. Change is difficult, and much like the weathering away of the Appalachians, it takes patience, persistence, and focus on changing the right things at the right time. Successful agile transformations include elements of the following:

• A clear understanding of the existing organization: The landscape if you will.
  • What is driving the desire to move to agile?
  • What structures need to be changed?
  • How does the organization deliver value?
• Are there capabilities in place to deliver value: Are the right processes in place to turn mountains into sand?
  • Does the organization have appropriate skills in place?
  • Are practices in place that are required for agile teams to deliver value?
  • Is strategy connected to team’s ability to deliver value?
• Are the people aligned and wiling to change: Are forces working together and persistent?
  • Are people willing to work in ways that are different than what has made them successful in the past?
  • Is there a commitment across team members to collaborate and work together more frequently?
  • Do people understand the time needed to change and are willing to have the patience to see it through?

When there is organizational support for making structural changes, agile practices are embraced, and individuals are willing to change then conditions are suitable for a successful transformation. Just as suitable conditions were in place eons ago for the Appalachian mountains to be turned into brilliant white sand.

Even with conditions suitable for change, persistence and patience is required. Agile transformations in an enterprise are difficult because of the scale of change. Transforming enterprises, like transforming mountains, is difficult and takes time. Agile transformations don’t take eons, though they may feel like it, but they don’t’ take weeks either.

I often hear that we’ll just send some folks to a class or two and we’ll be agile. Just taking a couple of classes with no other transformation strategy is like banging on a mountain with a hammer, it may be a good way to start but much more is required. Your organization must have a real commitment to change and the patience to see it through if you intend to create your own white sand.

Here’s to improving your organization’s ability to deliver value, to your ability to create your own version of Cape San Blas’s brilliant white sand.

Beware of Common Sense

Last Updated on Monday, 19 November 2012 11:15 Written by Dean Stevens Thursday, 20 September 2012 08:00

When working with organizations in Agile transformations, I help them to do what makes sense. I encourage them to challenge me when they think I am suggesting something that does not make sense.

Do what makes Lean-Agile Sense
Here is the rub. When I explain what makes sense, I talk in terms of “principle based” sense. Agile Sense provides a set of values and principles to guide our decisions and actions to achieve an Agile mindset. Lean Sense explains some of the process science of flow embodied in Agile methods. It is surprisingly easy to loose sight of this at key moments. Education and training on the Agile Manifesto and Lean Thinking is critical early on.The rest of the coaching engagement is a pragmatic application of Agile and Lean sense in decision making. This is a great way to help them learn and for me to make sure they understand.

Beware of Common Sense (and Be Aware of Culture)
Organizations and individuals will face challenges in an Agile transformation. They will struggle with decision making to solve these challenges. This struggle is good. But if they are not intentionally doing what makes Lean-Agile sense, they will inspect and adapt away from Agile. Teams tend to revert to solutions based on common sense in the organization. Common sense is the knowledge and experience most people have. It is based on what has “worked” in the past. It is remarkable how fast a group can slide back to what they did before based on common sense.

A Bias for Less
Common sense tells us we need more of the things on the right of the Manifesto. More documentation and following the plan. These are comfortable and safe. Agile sense encourages a bias for less on the right. Encourage a bias for less of the items on the right instead of more.

For example, as teams struggle understanding what to build, some managers want to solve the problem with more documentation. Agile Sense encourages progress towards working software. Start with getting getting better at collaboration to demonstrate software sooner.

Common sense tells us big batches lead to efficiencies of scale. Lean sense explains big batches lead to expensive delayed feedback and wasted effort that out weigh these efficiencies. Without fast feedback, we do not learn as we discover the solution.

Be Vigilant

Stay engaged in retrospectives and decision making. Look for common sense solutions.

• A bias for more of the things on the right side of the Manifesto
• A bias for bigger batches
• A bias for delay in feedback

Change the conversation with Agile and Lean sense. Promote a bias for less, not more.

Getting Started

Last Updated on Monday, 19 November 2012 11:15 Written by Dennis Stevens Monday, 25 June 2012 12:41

Synaptus and LeadingAgile came together in January. It is pretty compelling. Mike and I are both in Atlanta. We enjoy hanging out together. We have been collaborating on content, supporting the Atlanta Agile community, and sharing clients for a few years. We have started to build toward our vision in a way that would be challenging individually. The future for LeadingAgile is really exciting.

One of the outcomes from coming together was that I would start contributing to the LeadingAgile blog. I know how write blog posts. I have over 200 blog posts from my last two blogs – around a blog post a week for almost 4 years. Mike is a great model of successfully building a strong community by writing here. I have the access to post anytime I want. And I believe that it is important for me to start posting here to accomplish our vision for LeadingAgile.

Yet, here is it the end of June and I am just putting up my first post. It is interesting that I haven’t gotten started before now. What’s going on here?

Change Management

Last week I was in the office with Brian, the CTO at a client. We have had some challenges with a few of the Product Teams changing their behaviors to really be Agile. We were discussing strategies for getting the change we were looking for to take root.

We have told a compelling story and everyone is “bought-in” to the change. We have done training and provided one-to-one coaching so they believe they have the competence. The teams that have switched to Agile are having success and have been recognized as role models. The organization structures, goals, and incentives are aligned with the outcomes. Yet we still have a couple teams procrastinating in the desired changes. What’s going on here?

Resistance Management

The CTO and I recognize we are into the tough part of change management – resistance to change. After pursuing basic change management, resistance to change is personal. It involves individual’s WIIFM – “What’s in it for me?” It comes up when the person doesn’t feel dissatisfaction with the current state, doesn’t have a desire for the future outcome, and doesn’t sense safety in making the change.

Resistance to change is irrational. The compelling story, competency, role models and organization structures are external. But feeling, desire, and safety are internal to the individual. At the root of irrational resistance is an innate desire to be successful. Our brains remember that there was a time when being certain about the future meant staying alive. When the future is uncertain resistance is expressed as fear, embarrassment, and loss.

Just Get Started

Brian related getting past this resistance to change to his experience fixing the railing on his deck. He had talked to a guy at the local home improvement store and had been shown what to do. He was sure he had the right tools and materials. But he felt uncomfortable getting started. So he focused on a small task – creating one joint for the railing. Through this task he would learn if he could do the work, needed to ask a few more questions, or needed to hire someone. Once he got started he realized that while he didn’t have a perfect understanding from the local home improvement store – he was able to figure it out by trying some things. In the end it was a lot less painful than he had imagined.

As I was sitting in the office with Brian I had a “the cobbler’s kid has no shoes” moment. I needed to do some personal resistance management. We have addressed all the rational issues (compelling story, competence, role model, and incentives). My procrastination is irrational resistance.

Brian’s story demonstrates a proven pattern for addressing this resistance. Become aware of the resistance. Pick a specific behavior to work on. Make sure you have the right tools and skills to get started. Use getting started is the beginning of the process. Then get started and learn from the result.

The key is to get started. So I did. As I get ready to post this I realize it was a less painful then I imagined it would be.

Okay… Just What are we Transforming?

Last Updated on Monday, 19 November 2012 11:15 Written by Mike Cottmeyer Thursday, 8 July 2010 02:06

I’m constantly reminded that context is king… that words have meaning… and that the meaning of our words is almost entirely dependent on our context.

Last night I had coffee with an agile coach here in the Atlanta area. We got to talking about the idea of ‘agile transformation’. It became pretty clear, pretty quickly we were using the phrase in two very different ways.

His perspective was that ‘agile transformation’ involved taking a project team, teaching them agile values and agile practices, and helping them deliver better products to market faster, and with higher quality.

Worthy goals… no doubt.

My perspective on agile transformation looks a little different. To me, agile transformation involves influencing the structures and culture around the team. Only by influencing the systems around the team, can we achieve true end-to-end business agility.

Meaningful, long-lasting agile transformation starts by establishing a clear vision for the organization, and how we want it to operate when we get there. It involves creating a change management strategy that will get us from here to there as safely as possible.

Without transforming the organization around the team, the transformation within the team won’t be sustainable. The forces that act on the team are often too great for the changes to stick. It’s too easy to go back to the old way of doing things.

It helps to understand just what we are trying to accomplish with our agile transformation. If we just want to get a project team really humming… team transformation might be enough to meet our goals.

If we want ongoing, sustainable business benefit from our investment in agile, we are going to need to think beyond the team. We are going to need to think about the rest of the business and how we collectively deliver value.

No right or wrong here… you just gotta be realistic about what you are trying to accomplish.