Category Archives: Transformation

I was listening to a TED talk and the speaker threw out the word “Dormant”. He used it to describe Death Valley which is named Death Valley because, well, nothing grows there. No rain=No growth. However, something happened in 2004….it rained (7 inches in fact) and in the Spring of 2005 Death Valley was having quite a hard time living up to the name. The floor of Death Valley was covered in flowers. Turns out Death Valley isn’t dead. It’s dormant. Underneath the barren landscape was loads of potential just waiting for an inviting environment.

I’m a little obsessive about environments – specifically environments for teams to be successful. Today, more than ever, there are companies, consultants and coaches out there trying to crack the Agile nut in order to deliver value more frequently, efficiently and of higher quality. It’s a HARD nut to crack. The frameworks, Scrum, Kanban, XP and the consolidation of them in SAFe provide the manual and direction for companies to take. Yet….they’re [still] not seeing the expected and much-desired results and I believe, with every nook and cranny of my heart, the reason lies in the environment.

DORMANCY: The state of quiet (but possibly temporary) inaction. – Definition from http://wordnetweb.princeton.edu

Underneath the surface of the frameworks we’re using or, if you prefer, the foundation, are the Agile and lean values and principles. But, I don’t believe the appropriate amount of time and attention is spent on teaching these. Certainly not to the point where they’re understood well enough to be put into practice. What’s more, I don’t believe most environments are suitable for the demonstrative manifestation of these values and principles. So then what you end up seeing are the process side of frameworks in action – not people. The frameworks are designed to bring the values and principles to life. Frameworks need people to bring THE FRAMEWORK to life. So, really, you need people to bring the values and principles to life and the environment, generally, just isn’t conducive.

Occasionally, there will be a micro-climate where, somehow, a team is flourishing. I’ve heard these teams referred to as “magic teams”. The magic of them is they created their own environment or micro-climate and bucked the odds – kind of like the Spring of 2005 in death valley. Which, goes to show you, it’s not actually magic…it’s the environment. Creating the environment is the key to unlocking the potential of people to bring the framework and the values and principles to life which will then bring the amazing results we’re all searching and striving for. Oddly enough, those micro-climates are noticed by others as well. The magic team is sought after and asked about their secret and the magic team will gladly, willingly give it away and, then, those seekers will tell you all the reasons why replicating it just aren’t possible elsewhere.

Maybe we just take for granted the environment will be there or it will evolve to meet the changes in process and approach. Or, perhaps we don’t even want to think about the environment because changing or creating environments is difficult, hard work. Also, there’s nothing telling you that a framework NEEDS any certain type of environment. All of that said, I can’t think of a single organization who isn’t fully capable and up to the challenge of creating an environment to enable success. Especially if, at the end of all that work, the results would be nothing short of spectacular. I would go so far to argue that the environment of every organization is dormant….quietly inactive. I may even take it a step further and say the “environmentalists”, or those with the ability to be, are complacent. Meanwhile, there’s all this potential just there, waiting for the right environment or a very persuasive environmental activist to get the ball rolling.

One of the keys in Agile is an empowered team. Empowered to make decisions, self-mange and self-organize. In order for a team to be empowered, they also need to be trusted. Trusted by their teammates, their managers and their stakeholders. I bet if you were to ask HR what kind of attributes they looked for in employees, they would tell you they want intelligence, creative thinking, a team player, a self-starter, one who has and takes initiative…..all attributes which, really, should make it very easy to trust that associate. If you ask managers about the attributes their direct reports have their list would likely look a whole lot like the one from HR. So, when it comes to empowering teams, why is it so difficult to relinquish control? And, if managers aren’t willing to relinquish control, what happens? I’m getting ready to make some guesses and assumptions here and would LOVE to hear your thoughts. I don’t believe I have the whole picture myself, I’m just starting to dig in to this challenge more deeply.

WHY IS IT DIFFICULT?

1. Fear. Managers are afraid if they empower their teams, they won’t be as necessary. If teams are identifying, designing and implementing their own solutions and they work…..why, then, do they need a manager? What happens if the solution an empowered team implements doesn’t work? Will the manager be blamed?

2. Communication or lack thereof. I see managers who don’t feel comfortable communicating the whole picture to their associates. They operate in a mind-set of “need to know”. When associates don’t have the complete picture, they can’t possibly design a complete solution. They only have a fraction of the information. A manager is needed to review and expand on the solution using the remaining information.

3. Job Description. Managers are held accountable to the performance of their associates. Also, they are expected to manage work, find ways to improve the work and make the company overall, better. Is the same true for those who aren’t managers?

4. Trust. Managers don’t trust their associates enough to empower them. Managers also don’t trust those above them enough to realize the value and benefit of empowering their associates. They may be worried it will look as though they’re not contributing themselves.

5. Lack of Safety. The environment isn’t one where it’s safe to trust those beside, below OR above the manager. The “system”/environment is so fraught with booby traps, inefficient processes and fragility that it’s not safe to do anything without understanding the safety procedures and having a buddy or entourage.

WHAT HAPPENS?

1. Disengaged associates. If they aren’t trusted, don’t have the whole picture, aren’t expected to really live up to the HR job description and can’t implement any solution that isn’t fraught with risk there’s no reason for them to engage. Their contributions aren’t valued, recognized or rewarded.

2. Angry associates. You ask people to give Agile a go. You train them and emphasize empowerment, self-managing and self-organizing then, they’re not allowed to walk the walk. It’s all just talk EXCEPT there’s an expectation of more, better and faster.

3. Frustrated associates. Tired of feeling they’re not valued and angry at the bait and switch move, they struggle to do as asked and told and don’t see any progress.

Now, the funny thing is, most managers were once regular associates and, I’m pretty certain, it would not have been acceptable to them if any of the above possible reasons were truths for them. Managers grew into their position because they exhibited those attributes most companies seek and seem to value. It is probably also due to….THEIR MANAGER. Great managers exploit the positive of their associates. They develop their strengths and find opportunities for them to shine. They seek the input of their associates and teams because they know it’s not possible for them to have all the answers themselves. They know the better their teams does and the more they grow can only reflect well on them and, ultimately, contribute more value to the company. They know that being a barrier to their associates success serves no practical or valuable purpose. They aren’t afraid of one of their associates surpassing them organizationally.

So, now I’m stuck. What do you do to help overcome this challenge? Ask provocative questions – there are so many! Reveal the picture to them through questions. They may be able to see it but, may also still be resistant. It’s easy to help people who are aware and open…how do you help people reach awareness and openness?

I chose the title “Monkey in the Middle” because it’s one of the MOST frustrating games I can think of. In the situation I have begun to lay out here, there are several possible monkeys. The associates who are just waiting for an opportunity to grab the ball. The manager who wants to be secure enough to empower their associates but doesn’t feel empowered themselves. Then there are the people passing the ball, trying desperately to make sure the monkey in the middle never gets it. Dropping the ball would mean giving someone else an opportunity to play and that would be????

So, you think you want to “Go Agile”? The very first question I have for you is: Why?

Before you embark on a path as challenging as an Agile adoption be very sure, from the outset, of your goals. And, let me be very clear here, the goal cannot be “To meet a mandate from our <insert title here>”. It also cannot be “We just need to deliver more, faster.” There’s no doubt there are benefits to be had through an Agile adoption, but you will need to know WHY you want to take this journey. More importantly, the people you will be asking to embrace, support and implement this change will need to know why. If you’re not able to explain it – to put your goals out there – STOP. Don’t take one more step or have one more conversation about it until you do. Then, once you’re clear on those goals look to see if there’s anything about people on them. The heart, soul and awesomeness of Agile lies in people. If there’s nothing in the goals about people, STOP. You will not realize the goals you have laid out without considering, paying attention to and cultivating your people.

What about people is important to an Agile adoption? Well, all process and structures/frameworks depend on the people working within them to bring them to life. In an Agile adoption, people and their ability to trust you and your ability to trust them is vital. There will be things you learn about your company that will be uncomfortable and they need to be able to bring them up to you, their leader, to help change them. Additionally, they will need an environment where they really can live the Agile Values.

When I reflect on the goals an Agile organization should consider they’re, actually, rather simple.

Are we delivering more value to our customers? How do we know? Your customers will tell you. Ask your customers prior to your effort to tell you how they feel about the services and benefits you provide and, then, continue to ask them.

Are our operating costs going down? Is your call center experiencing less call volume? Is it easier to resolve an issue when they do call? Do you need less and are able to deliver more?

Are our associates reporting a higher degree of engagement? Do they feel empowered? Do they feel they have real, true ownership of solving problems? Do they feel their managers are, more than ever, focused on their development over their work?

Agile alone isn’t a Silver Bullet. Maybe it seems that way OR someone is positioning it that way to you but just “doing Agile” will not deliver the results you’re probably looking for. “Doing” Agile will get you some improvement – in the 25%-35% range. “Being” AND “Doing” Agile has the potential to deliver exceptional (400% improvement) results. Being Agile depends on you, the leader. When you announce the intention of an Agile adoption, you’re making an agreement to adhere, as closely as possible, to the Agile Values. What’s more, your people will believe you and it’s critical you mean to live the values and you’re asking them to do the same. Your actions from that point forward will confirm (or not) your commitment to those values and, essentially, your people. So, WHY do you want to go Agile?

Some time ago I heard about a trend of “No Estimates” and, have to admit, was not happy about it. The reason I wasn’t happy about it had nothing to do with understanding the velocity of a team. It had everything to do with the team missing out on critical conversations that occur when arriving at an agreed upon estimate. I love watching new teams estimate stories. When someone throws a 20 and someone else has a 5, the discussion that takes place – THE LEARNING – is pretty powerful to observe. Estimating is a way for team members to get to know one another better and understand how they each view things differently. Eventually, they start applying others’ perspectives to their own and the team truly finds a voice as a single entity.

Dan Mezick wrote a good blog post recently and pointed out “One may say with some certainty that the estimation task is actually a ‘cover story’ for the wider task of team learning. If estimates are 100% eliminated, how is this team learning replaced? Team learning is obviously essential. Discussions during the estimation task create many team-learning moments.”

Frankly, I believe a team, who is committed, will get to a point where estimates are not required. This will happen once they learn – not before. Scrum has estimates and the concept of velocity there for a reason. A team must go through Shu (Follow the rule) before they can muck around with it and find something else that works best for them or reach a state of Ri (Make the rule). If you start a team out with no estimates, I believe the learning curve and reaching a performing state will be delayed.

Some teams use relative estimation. Others will use Planning Poker. Heck, I have seen a team estimate in “farm terms”. Seriously. A duck is less than a cow which is less than a barn and so on…. It worked for them. Who am I to question it? So, yeah, maybe this idea has merit but, I really would caution against giving it a go with a newly formed team. Sound snippets like this one make me a little nervous. You can’t place a value on the conversation that takes place during estimation. You CAN place a value on a team taking twice as long to reach a performing state.

When you’re transitioning to Agile, there’s a lot going on all at once. It occurred to me it’s similar to home renovation – a really, really big home renovation. Personally, I LOVE old homes. I love going to see them and, one day, I want to buy one and fix it up. Sometimes, I walk into a house and while I’m oohing and aahing my husband is groaning. He’s groaning because the houses don’t generally meet any criteria he has for a home. I’m oohing because I can see the potential a house has. All you need is some imagination, good bones and time. That’s what an organization needs to create a great environment for Agility too.

IMAGINATION: To begin, you need to be able to ooh and aah instead of groan. You need to be able to see what is possible for teams, management and your users. If you don’t have imagination absolutely everything about the process will frustrate the hell out of you. You can’t hire someone to “take care of it” for you or oversee it. Nope. You need to be willing to be architect, general contractor and all the subs. If you have imagination and can envision what it will look like you have an open mind. An open mind is necessary because everything you thought you knew about “how your house was built” is going to get thrown out the window.

GOOD BONES: There are some things that just need to be in place. It’s no good and not practical if you have to bulldoze the house and start from scratch. You need smart people who are willing to opt in and give Agile a serious go. You need managers who are way more into the products their company produces than they are into their “turf”. These managers must also understand how to support, motivate and develop people. You need a culture of drive and commitment. You need a business who will look at the business differently. You need a company that invites people to opt in instead of mandates. OPEN MINDS are essential.

TIME: It took a long time to build what is, arguably, good enough. To change, grown, learn and be great you need time. You know the saying “Rome wasn’t built in a day”? An Agile transformation doesn’t happen overnight either. This renovation is going to take time. Since you know that, you also need to know to be patient. Also, you should know that you will never be “Done”. You will always and you should always look for things to improve on.

In my vision of a great Agile environment there are spaces for teams to work together, as a whole team and places to pair or collaborate with a smaller group. There’s technology available for distributed teams to use. People laugh! Anyone walking by can see what the team has going on and how awesome they are. There’s some corporate furniture around but teams can put their own identity on their spaces too. There’s a wall for anyone who wants to put an idea up to try and others can join in the effort. Directly opposite is another wall that celebrates the successes and failures (learning) from the efforts of these self-organizing teams. The environment is safe for everyone to be open, honest, disagree and try anything they think will be for the good for the team, the company or the user. This safe environment also has a hum – there’s energy and people are genuinely happy to be there and be a part of it. There’s also an endless supply of post-its (all colors & sizes), sharpies (all colors), magnets and flip charts.

As with any major project, you’re bound to hit some snags. That’s OK. It’s all part of the adventure. You have no idea what you will learn along the way and the creative solutions you will find. The time, thought and care you put into creating this environment will be huge. If done well, at the end, you have teams of completely happy and motivated individuals. You have a safe environment where learning, trying and trying more is encouraged. You have users who are loyal and more than satisfied with the products you are producing. All this because of the environment. There’s no need for razing the house to get to the land. Keep what’s good and useful, ditch the rest and strive for the perfect environment.

In an Agile transformation we all focus on getting the teams set up, training them and get them working in Scrum (or whatever). Then, you have these teams going and you see some improvement but maybe not the BIG BANG improvement you thought you would see. So, you start looking into what the teams are doing.

Are they having stand up? – CHECK!

Are they doing Sprint Planning? – CHECK!

Are they having Retros? – CHECK!

Are they using a Scrum board and burning down daily? – CHECK!

Is it effective? – Ummmmmmmmm

The thing is, the tactical parts of Scrum are in place to teach the teams how to think and work differently. A team can only get so far with the tactical elements alone. In order to realize the benefits of Agile, a team needs to shift their mind set and so the all the people outside of the teams. The tactical part of Agile is easy. It’s the Cultural part that’s really difficult.

If teams are having challenges breaking down the work into small enough increments, you may be able to address it with some training and hands on guidance during planning. However, if the business cannot think differently and insists or MORE it may be that the team isn’t empowered to break it down smaller. Or, maybe, in demo, stakeholders are critical of the “little” the team has ready and pressures for MORE.

If teams aren’t continuously improving and having their retros, it could be that the team needs some instruction/coaching on what continuous improvement means. Maybe the Scrum Master isn’t leading effective retros and needs some help there. Or, maybe, the team isn’t given the time for retros because of some outside forces insisting they do something differently. Maybe the Scrum Master doesn’t have time to learn how to be a Scrum Master because they’re busy writing status reports, going to status meetings and completing documentation for an organization that hasn’t embraced Agile yet and relies on Project Management artifacts and methods.

I’m staring to think an Organizations transformation doesn’t start with teams at all. I think it starts with everyone else. Scrum and Agile are easily applied to any type of work. The Agile values and principles are also applicable to any type of work. Maybe the teams should be left alone until everyone else understands how to work in this way. In focusing the effort outside teams first, the culture shift could start with those who have the ability to stifle or supercharge the teams. Once everyone outside the teams are ready for the teams THEN the transformation can begin.

Because, until the culture starts changing – in earnest – an organization is really just going through the motions NOT transforming.

An Agile adoption has the potential to super-charge results. The methodology is simple, rational and makes complete sense. This is probably the reason why so many companies give it a go. Something that is often overlooked when considering Agile adoption is the fact that moving to Agile will, in addition to improving your ability to deliver value faster, expose the things in your organization that aren’t working. And, it won’t be subtle. As soon as you start moving, you will start hearing about the problems.

Organizations need to be prepared to hear these things. They cannot be defensive or try to hide or ignore them. They need to fix them….FAST. It’s a good idea for organizations to acknowledge they probably have opportunities and be open to hearing the reality from the team members who are feeling the pain. If you’re not willing to listen and act what will happen is apathy, disengagement and Agile Adoption failure. All the energy you had going into the adoption from the teams will fade. Team members will likely go back to the old way of doing business and feel resentful about having to fake Agile. They will stop telling you what is wrong because they know you either won’t act or they will actually get in trouble for raising the problem.

The organization may feel frustrated because they have all these Agile teams working on delivery. They have spent gobs on training and coaches. They have re-engineered their metrics. But, they are not seeing massive improvement. They will look at velocity. They will assess the teams. They will conduct focus groups. They may hire outside help. They will spend serious time and money to figure out what the heck the problems are and they will likely find the problems are the same as those they heard about in the first month of adoption.

There’s loads of information out there about the typical problems organizations face when moving to Agile. It’s not a big secret but, an organization has to go looking for it. There’s an opportunity to talk about this openly and candidly before pulling the trigger to set the expectations for leadership and define the behaviors leaders need to exhibit and demand from their management in order to create an environment for success. Delivery teams will appreciate it as will leaders who truly want to improve and be successful. It establishes openness from the very start as well as initiates the shift to servant leadership. Finally, it gets people thinking in terms of trying, failing, learning and trying again. Continuous improvement…

I hadn’t thought about it in this way before. Honestly, I figured it might be best to just get an organization started. Jump on in! But, I believe it’s a disservice to the people in the delivery teams who will be trying their best to make this work. Giving leaders visibility into the lessons learned by others and encouraging new behaviors and approaches is a good thing. Imagine how cool it would be for team members to hear leaders from the very top all the way down saying “I want to know what’s wrong so I can fix it for you. I don’t want you to have to focus on the problems or be held up by them. I want to know so that it’s easier for you to be as awesome as you can be.”

The minimum. If you wanted the minimum, then, congratulations! I’m pretty sure people don’t strive for the minimum though so what should be measured instead? Measure progress against the end goal. I know. I know. It’s crazy talk but, seriously, if there’s a goal you want to hit why not try to assess yourself against it? I guess the argument of “we want to know where we are against the least acceptable metric” may hold some water. However, I don’t want something that tells me 100% meet the minimum. I would MUCH rather know that 8% meet the target and 70% are pretty damn close. Those who are meeting the minimum now have a little competition and may actually kick it into high gear.

If I know who is closest to the target, I have a chance to leverage their insights and help those who are anywhere close get closer. I can see what everyone has in common (who isn’t excelling) and work towards identifying a root cause to help make it easier for them to hit the target. If 100% are meeting the minimum, what does that tell me? What can I do with that information? Reward it? Um……

I know! Let’s set an interim target! Guess what you’ll get? 100% are meeting the interim target. And it all starts again. Seriously, folks, let’s strive to meet the goal. Let’s not sell ourselves short and give ourselves crutches. People want to do well and if well means the minimum, that’s what you’ll get.

Personally, I love a challenge. When I’m not challenged, I get lazy. When you expect greatness from people you will get greatness. When you expect mediocrity you will get mediocrity. Shoot for the stars people!! Then, when you have scooped them all up, shoot for another galaxy. I DARE YOU TO BE BETTER THAN YOU ALREADY ARE!

I’ve been thinking a lot lately on where to focus. In a large transformation effort, there’s more than one area requiring attention: Teams, Scrum Masters, Middle Management, Leadership, Performance Management, Space, Culture….. You name it, it probably needs some care and feeding so, where’s a person supposed to spend time?

Initially, my thought was to focus on those people or places that were not far along the change curve. Then, I realized how much effort and time went into that category. We talk about empowering people and teams to deliver value. Why shouldn’t the same apply to learning and change? If you make training, workshops, blogs, books, coaches and every possible thing imaginable available, people who want to learn and change will avail themselves of those resources and more.

The time we spend “selling”, convincing, cajoling and, yes, begging people to give it a try is wasted. Those people will either opt in or not. I’m not saying zero time should be spent on this category. I AM saying it’s a pull system and, when asked or requested, some time should be spent there. Spending time pushing it isn’t valuable. As people are ready, they will pull – just like a team and a backlog.

Focusing on those who are opting in makes sense. Results will happen. People will be happier. Formerly opt-out people will notice and they will come. When they’re ready, you should be too. Be ready to help, coach, guide and keep the road as clear as possible for their own transformation journey. The cycle will continue. It just takes time.

In the last week I have been hit hard by the reminder of how powerful value is. There are two instances I want to highlight.One is related to people and the other related to stories.

VALUE YOUR PEOPLE

It’s important as a Scrum Master, a people manager or a leader to show the people you work with and for that you value them as a person and for the work they do. When a person feels valued, they are motivated. And, I know, everyone is motivated by different things. For some, it’s money. For others, it’s recognition. There are many things a person may be motivated by but, all people need to feel valued. If they don’t, they disengage and that isn’t good for anyone.

You need to find out what is unique in the people you are surrounded by. It doesn’t matter if you manage them, lead them or work for them. Identifying what makes an individual special is powerful…for them. You can find ways to build on it, leverage it, showcase it and help the person shine. When you make someone feel valued, they will return it with awesome performance and, even better, loyalty. If you’re not investing thought like this into your people, please, take some time to do so. Have a conversation. Find out what they’re passionate about. Discover what they’re good at doing. Learn about what they want to learn about. Invest in and value people and the dividends are endless.

VALUE STORIES

People want to be valued and they want to work on things that are valuable. In a SAFe release planning event this week teams had identified the features they were delivering and broken them down into stories. In SAFe, teams then specify their release objectives. It’s a layman summary of multiple stories which, Product Management then values on a scale of 1-10. Keep in mind teams are working in priority order so, the initial thought is their focus is on the right features. When you break a feature into stories and specify exactly what the objectives are for the release, what happens is amazing. A conversation with a group of Product Managers and the team takes place and, often, a high priority feature has objectives associated with it whose value is mixed. We’re all about delivering value right? Here’s an example over-simplified:

EPIC – Build house

Feature – Build Front Entrance (priority = 1)

Feature – Build a Deck (priority -2)

Objectives –

– Complete deck to hold more than 6000 lbs. – 9

– Complete steps to front porch – 10

– Complete front porch covering – 4

– Paint front door – 1

– Complete rails around deck – 8

– Build grill bump out – 2

When you look at it, there’s more VALUE in completing items associated with the lower priority feature. Good to know for a team. Very enlightening to Product Management. Awesome conversations and understanding generated between delivery and the business. All is all, just goodness.

In summary, there’s power in focusing on value – for the people and the work. See what you can do tomorrow for people. Make someone’s day.