ODO Part 1: The Transformation

Aug 1, 2014 in Uncategorized by
ODO Part 1: The Transformation

Outcome Driven Organizations Part 1: The Transformation

“Once we accept our limits, we go beyond them.” — Albert Einstein
 

Let’s start by taking a look at what typically happens on the ground with an Agile Transformation, told in a story format.  This is based on a true story, or more specifically a select compilation of experiences from our many years of consulting and leading transformation initiatives – the company and peoples’ names are not real.

Once upon a time, in a place not so different than our own…

Deb started her new job as Director of Engineering at Sildexa, a company that focuses on cloud-based disaster recovery solutions.  She’s excited to start this new chapter of her life and take what she has learned from past companies and apply it to Sildexa.

In her interview with Chad, the CEO, he had told her “Sildexa is at a pivotal point in our life.  We are still successful but our market is getting more competitive by the day.”  Chad continued, becoming very serious. “We are starting to see that these new upstarts are getting things out to market much faster than we can.  Right now they are still only grabbing the small customers, but they are growing and if we don’t do something now we risk losing a large share of our customers base.”

When he hired Deb, Chad had been very clear that he expected her to lead the changes within Sildexa needed to keep them successful and on top.  “Deb, a large part of why we hired you is what you were able to achieve at Lexetech.”

At Lexetech Deb had taken her company through an adoption of Scrum along with some development practices and seen firsthand the results.  “That’s right, we had teams working well together, collaborating and learning through iterative development, and overall quality and quantity of work had increased several times over. If you want that, then you want Agile. And, the way that we were so successful over at Lexetech is that we brought in a professional coach and trainer, Adam, to work with us and the teams.  That made all of the difference.”

“I’ve read up on Agile and so I know a little about it.” Chad said.  “The results touted by the books are very interesting, but wholesale changing our software development process seems very risky and very pricey.”  Chad finished with a “you better know what you are doing” look on his face.

“Chad, I lived through the whole thing at Lexetech and Adam has done this successfully at numerous companies”  Deb assured.  “A wholesale change at one time is extremely risky and that is why we aren’t going to do it that way.” Deb said with a smile.  “Let’s identify just a couple teams to run a pilot.  Then you and the rest of the company can see how successful this can really be.  At that point you’ll have teams lining up to change over.” She said excitedly. “And, if it doesn’t go that well, then we have contained our risk to only those few teams for a short period of time.”

With that, Chad agreed.  The pilot approach was a good way to test this out and see if this was really going to provide the results they were hoping for.

“This is going to be awesome!”  Deb thought as she left Chad’s office.  “Agile is really going to turn this place around.”

Right when she got back to her office, Deb reached out to Adam.  He was a well known and well respected coach in the Agile community so she had to get on his calendar as soon as possible.

Let the changes begin! Bring on the coach!

A couple weeks later, Adam arrived at Sildexa and immediately got started.  “As you know Deb, the first thing we have to do is to develop a rollout plan.”

Deb and Adam started working to identify the teams to form, determine roles for Product Owner and Scrum Master, schedule the teams go through foundational Agile and Scrum training, and plan workshops to help the teams develop enough of their backlogs to start their first Sprints.

There was one thing that nagged at Deb in the back of her mind throughout all of this planning. “How are we going to know if the pilot is successful and show that to Chad?”  But she didn’t put too much weight on the concern.  As Adam had been saying, “The most important thing is to get started and people will experience how much better it is.”

A few weeks later and Deb was feeling really good.  The three pilot teams were starting to get into a rhythm and people were noticing.

Even Sally, one of the toughest stakeholders in the group, had gone out of her way to tell Deb “I’m really impressed!  So much is being delivered by the team in such a short amount of time!”

Deb was excited to see how much more focused the teams were.  While quality could always be better, there was a growing buzz of interest and enthusiasm around the change.

Deb had noticed that many of the team members still seemed a little shell-shocked with the changes, but Adam assured her “This is totally normal.  We are not just changing the process they use, but changing their mindset on work.  Don’t worry, they are really starting to get more comfortable with how things work in this new world.  And if the interest and excitement around here keeps growing we aren’t going to be able to hold back on kicking off other teams!”

A couple days later, Chad grabbed Deb after attending some of the Sprint Reviews.  “Deb, I am really impressed.  It looks like the teams have come a long way in a short time.” Chad said.  “There were a couple things that were nagging at me while I sat through those demos though — are the teams really better for the improvements made and is it impacting the bottom line of our profits and customer satisfaction?”

“As you said Chad, it is still early and we haven’t really released much yet.  But, everything we are seeing is pointing to great things.  Have you ever seen your people this happy and feel so good about the results?”

Leaving that discussion though, Deb was nervous.  “We have to show Chad some real results.  When do we call this pilot a success?”, she asked Adam.

Adam thought about it and came up with a plan, “We will provide an assessment across the teams focused on how well they are applying Scrum.  If the results are that they are following Scrum well, we know it’s time to move on.”

The assessment was conducted and while the teams had mixed results, overall it was positive that they understood Agile principles and Scrum practices and more importantly were following them.

Deb went to Chad with the assessment results.  “Based on these, I believe we are ready to call the pilot a success and move forward with other teams.  I would like to refocus Adam on kicking off new teams in the same way we did the pilot.  As we move forward we can continue to evaluate our progress using the assessments.  We can use them to manage which teams we are focusing on and eventually, once we have determined that all teams are doing well, we can declare this a success!”  Chad agreed to move forward with both of them feeling confident that this would be declared a resounding success.

Or so, they thought….

The next few months were a blur for all involved.  Teams were coming on board at an amazing rate.  Adam as coach and trainer was furiously trying to get the new teams up and running while supporting the other teams through attending their Scrum ceremonies.

Deb was starting to see some of the great things happening as in her previous company, but also starting to see people be weary of the change.

“Oh, that’s ok”, she tried to convinced herself, “I’m sure things will settle down and people will be fine.  This is just the normal, initial reaction to change.”

The teams, being encouraged to be self-organized, started to try to make improvements that might help them overcome obstacles they were running into.  They started to look out in the Agile community and found a wealth of practices that they could try out – Lean, Kanban, TDD, Lean Startup, Continuous Integration.  Teams started to try different things, some things helped, some didn’t.

Things started to get confusing since different teams were reading and hearing different things out in the community.  There were a lot of different and often contradictory opinions about which practices were right and how to do some of these practice the right way.

Seeing signs of confusion, Deb sat down with Adam to discuss her concerns.  “It seems like things are getting a little out of control here.  The teams seem to be doing very different things.  Its getting more difficult for teams to work together and for us to get clarity on how things are going across teams.  I’m feeling like we need more consistency.”

“I’m seeing that too, but this is a pivotal point in the adoption.”  Adam responded.  “What you are seeing is the teams taking ownership of their process and really trying things out for themselves to see what works best.  This is exactly what we want.  As they continue forward, they will realize that the significant differences are causing issues with cross-team collaboration and organizational communication.  The difference will be that they recognize this and then they own the solution.  It will be true ownership versus compliance.”

Deb believed in Adam and believed in empowering teams, so she backed off but she was going to keep a close eye on all of this.

As this continued, she started to see other signs of concern.  Team members seemed to be complaining a lot.  Some very openly but most quietly in small groups during lunch or in the kitchen.  Deb realized she had a situation on her hands when she found out that people were asking to step out of the ScrumMaster and Product Owner roles and that even some team members were leaving the company.

Deb was determined to find out what the problems were first hand.  So, she started seeking out people who were unhappy: asking to change roles or planning to leave the company.

The first person she got to talk with was Patricia, one of the Product Owners for the pilot teams.  “What’s going on Patricia?  I heard you are asking to be moved out of the Product Owner role.  It seemed like things were going so well…”

“Yes, at first they were going really well” replied Patricia.  “We were able to do things differently when you and Adam were working with us.  But as time went on after you left I started getting a lot of heat from the PMO around budgeting and planning.  They were still needing the business brief, business case, and proposal for their quarterly and annual budgeting.  This didn’t match up at all with how we were working within the team.  Not to mention the pressure that we were getting from Chad to get everything done for each release before quarterly earnings calls.  The pressure of trying to fulfill all these external expectations while also supporting the needs of the dynamic nature of the product development in the team was just too much.  I’m really sorry, but I couldn’t keep working 60-70 hours per week trying to keep up with all of these different expectations.”

Deb was getting even more worried now but she only had one point of reference, so she sought out more people to hear their experiences.  The next person she spoke with was Steve, an old timer that has been in development for many years.  “Yup, it’s just time for me to find a new home.” Steve told Deb. “Things are just changing way too much around here all the time and I feel like a rat in a maze but ya’ll keep moving my cheese over and over again.  Every time I think I have figured out how to work in the ‘new way’ it gets completely changed again.  I really just want to develop good code, I don’t want to have to constantly be figuring out the 10 new things that the company now wants me to do that takes me away from that.  I do have one question for you though.  If this Agile thing is this much chaos, then how in the world do you actually expect to get things out the door faster?”

Deb was starting to see a pattern here, but the last conversation clinched it.  It was with Dimitri, a very successful tech lead whose announcement of leaving the company had made a big stir.  “To me, it is very simple.  What my boss wants is not what my team wants.  You come in and encourage collaboration, team mentality, unity, yet I am still judged on what I accomplish and how much I get done.  These things do not go together and I am forced into a horrible decision: 1. Do what my team wants and sacrifice my career; or 2. Do what will help my career and be ridiculed and patronized by my team.  I choose neither.”

At the same time, Chad is getting feeling increased pressure by the board of directors to see measurable progress.  They weren’t pleased with the results and were further worried about the competitive pressures taking away market share.

“Just give us a little more time as we are experimenting with a new process”, begged Chad.

“What can we do?  I’m running out of time and the board is getting impatient”, he asked to Deb and Adam after returning from the meeting.

Deb and Adam had already been working hard on the issues that Deb uncovered so they had a response ready “What we need here is a more holistic approach that scales Scrum beyond the teams.  This will help with much of the friction of conflicting expectations and inconsistencies across the organization that has been getting in our way.”  Chad wasn’t totally convinced, but something had to be done so he agreed.

Relatively quickly it became obvious that scaling Scrum across the entire organization was going to be a herculean task.  Not only were the teams still struggling with the new ways of working, new roles and new practices, but they now had to learn how to coordinate across release trains, manage their portfolios and keep up with the various levels of backlogs.  Deb and Adam now found themselves in a new situation as well, trying to influence significant change in business processes and organizations where they had little to no knowledge or power: finance, procurement, program management, portfolio management, infrastructure, operations, enterprise architecture, release management, and on and on…

There’s a new sheriff in town.

After a few more months and a couple releases later, the board had had enough. The financial and market numbers were trending in the wrong direction and the board did not see enough tangible evidence that Agile was making a positive difference.

Chad was asked to leave the organization, and they brought in another CEO to “fix things”.

Dan, the new CEO looked around to determine what was broken at Sildexa, and Agile seemed to be a key area of concern from those that had left the company. Those that remained were weary from all the change, and tired of the demands of Agile.  Dan, not familiar with Agile, had his own way of doing things that have been successful in his past. He saw little or no evidence that this way of working called Agile had been helpful; in fact, it appeared quite the opposite was true.

Adam’s contract was canceled and even the stalwart Agile champions in the company like Deb decided it wasn’t worth the risk of challenging Dan.

Even if there were pockets where Agile has been considered successful, all signs of the hard work of Deb and Adam were gone within the next year.

“It’s a real shame”, thought Deb, “there was something really special happening here despite the chaos.”

839064.jpg


Moral: We need to change the conversation.

This is a pattern that has been repeated from organization to organization.  Perhaps not as dramatic as a CEO replacement (though this example did actually happen to me as a coach), but it doesn’t take much these days before everybody is running for the hills away from Agile. If people were scared of change in the past, they’re positively terrified now. Not that Agile was a bad thing, but it was introduced into the organization as just something you implement.

The main failing in these all-too-typical attempts at transformation, like the one told in this story, is that the leadership focuses almost solely on delivery, to the cost of everything else – going fast, adapting quickly and changing the process to fit the needs, and all at record speed.  As a result, there is plenty of output but to what end? What are the outcomes that we seek? What does success look like for us?  Are we aligned to support these outcomes, or are our structures, culture, rules, policies, leadership, environment working against them?  If not addressed, organizations may get very good at delivering crap really fast while feeling overwhelmed and fatigued by the constant changes around them and fighting the never ending battle of misalignments.

We need to first focus on the problems we are trying to resolve and identify the outcomes we want to achieve. Next, we need to develop the capabilities required to achieve those outcomes and align the environment to support these.

Over the last 15 or so years that Agile has been in play, the focus has been mostly on delivery, execution and compliance to practices. Practices on their own are clearly not the answer.  What else is needed for an organization to achieve these outcomes? How can we know we are making measurable improvement?  How can we make it sustainable so that we can endure any storms that come our way?

Finally, how can we truly become resilient as an organization?

Agility is more than a set of practices, more than a mindset – if we are to realize the full potential of what it means to be Agile, we must change our focus. We must think more about what really matters – the outcomes of our work – and less about compliance to a process or a set of practices. These things have there place, but they should no longer be viewed as the prize. We need to break these patterns of limited change and impact within an organization, and look at a different model that is focused first on meeting the needs and addressing the problems that are holding us back from achieving the outcomes we want and need to be successful.

In the next post, “Part 2: The Naked History of the Agile Industry”, we look back on the golden years, retrospect on our performance to-date, and ask if continuing down our current path will likely result in the outcomes that we seek, or if it’s time to reconsider our options.

Leave a Reply

Your email address will not be published. Required fields are marked *