Agile Odyssey

Agile Odyssey

About the blog

We hope to be able to share insights and stories here that will help inspire you on your journey using agile principles.

To Join into the conversation, Sign Up Here! We'd love for you to participate!

Stockholm Syndrome

CoachingPosted by Shane Billings Thu, September 17, 2015 19:25:07
I've heard of the Stockholm Syndrome before, and like you, I have no idea what it is like. It makes no sense to me. Why would someone sympathize with a captor? Why would they align with someone who is causing them harm and keeping them captive? Of course, if it makes no sense to us, it has to be because we have never experienced it before. If we had, it would make complete sense.

What sets us apart? Well, first, we've never been captured and held against our will. That solves that. But wait! This would be a short post if that was where the discussion stopped. What if I told you that each of us can have a sort of Stockholm Syndrome at work?

Every day at work, we are held captive to some degree or another. Each of us is limited by the system, the bureaucracy, the environment, the rules, the politics, the monotony. It holds us back and prevents us from experiencing the true freedom that we enjoy. Happiness comes from autonomy, mastery, and purpose, and autonomy is the easiest to lose.

Let's first look at the captor. The captor is a an organization or person who needs control to feel comfortable. The company had a failure that cost them money so they made a rule about increased testing. The manager was yelled at by his superior, so she must manage everything you do so as not get in trouble. The society is having a moral breakdown so we have to add legislation that makes something that should be dictated by common sense illegal.

Now for the captive. In most cases, they may not even know they are captive. "This is just the way things are," they say. It's hard to see the alternative when we can't even imagine what it would be like. They've forgotten what freedom was like. It is easier to just keep going as if there were no alternative. Before long, there is no drive or ambition. It's gone, and so is the light that was in them. This type of captive is dead inside. In Scrum, they are zombies.

But Zombies can get even worse. They can become zombies with Stockholm Syndrome. Not only have they become dead inside without creativity or improvement, they begin to sympathize with their captors. The rules, micromanagement, and laws make sense to them. They employ them. They add to them. They make it worse.

There is usually a reward that exacerbates the behavior. First, there is the reward of feeling in control. Next, others who exert control, like the control shown by others. Raises come. Promotions come. And captivity flourishes. After all, they can control everything around them. Aren't they the smartest?

Contrast that with the captive who try to break free. They are always on the edge of what is acceptable. They push boundaries. Even if the group eventually goes the way they were leading, they are still outside the norm. Groundbreakers rarely are rewarded for bringing about change. Rewards seem to be more difficult to come by. Every day can seem like a battle to escape. It can be lonely and difficult sometimes.

But here is the difference - they are free! Free to innovate; free to experiment; free to teach; free to enjoy themselves. Freedom is a joy in and of itself. I'm here to tell you it's worth it. I'm here to tell you that there is no reason to give up your freedom to those who would take it from you at work.

  • Comments(1)//blog.agileodyssey.com/#post4

The Power of Stupid Questions

ScrumPosted by Shane Billings Thu, September 10, 2015 19:38:47

There are no stupid questions. But wait. Yes there are. You and I know it. We've all heard them. "Wow. That was a stupid question," you have often thought to yourself.

Most of the time the questioner of stupid things doesn't know the question was dumb. Yet here we are listening to the absurd and trying to make sense of it.

Let's consider this. What makes the question stupid? Why do we think it was dumb?

It has been my experience that stupid is in the eye of the beholder. One man's stupid is another man's genius. Usually the derogatory label is placed on the question because it is so far out of our paradigm that certainly there is information missing. If all the information was had, this question could be avoided. We could have continued on our merry way.

And there it is - the reason we don't like the stupid question. We could have continued in our bliss and not had to answer let alone consider the topic. We are too smart to have to waste our time on the issue.

I have been witness to many dumb questions.

"Why do we do that?"

"Can we just skip that step?"

"What should we do about this problem?"

"Do you want fries with that?"

"Can this be fixed?"

For the seasoned Scrum Master, there is power in the stupid question. It may sound stupid, but its real intent is to get people to think differently than they have in the past - to consider the possibility that the real answer might be "I don't know." After that answer, the real truth can come out.

The observant Scrum Master is wary of answers like,

"We've always done it that way."

"That step can never be modified."

"There is nothing we can do about the problem."

"If I wanted fries, I would have ordered them."

"No one can fix that."

I have recently come to appreciate the stupid question more as a Scrum Master. In fact, it's my main tool now. I have been asked to be a Scrum Master for a team that is building hardware for test equipment. I know little about what they are doing and even less about their process. So all my questions are stupid. But the answers are worse. They are worse because they don't help improve. They keep the status quo.

I told that to a friend at work.

"I think it's important to ask stupid questions."

"I'll bet you do really well at that."

Thanks. That was a softball to be sure. What I meant to tell him was that I've finally made headway with this team. I've asked enough questions that they have finally begun to question themselves. Now we are making progress.

Maybe there aren't stupid questions. Maybe there are only stupid answers.





  • Comments(0)//blog.agileodyssey.com/#post3

The Parable of the Jungle Yard

AgilePosted by Jim Palmer Fri, September 04, 2015 18:26:33
I live in Southern Arizona... hot, desert, prickly everything... right? Well, mostly. There are a couple of months of the year, called the Monsoons, when it rains a lot. The desert is actually a very fertile place, as is evident by my back yard. I literally have weeds that are 11 feet high--no exaggeration. Prickly everything still everywhere, just now it's green.

I'm a busy guy, with 4 kids, all in sports. I don't have a lot of time to spend on the yard. However, today I happened to have only 2 mid day volleyball games and a Friday Night Football game. So, in the drizzling rain, I decided to attack the jungle with gusto.

My team was made up of my 10 year old daughter, her 9 year old cousin, my 13 year old son and myself. I didn't totally geek out on them and create a backlog, estimating the effort for each stick note on the wall, but as I pulled out tumble weeds, gourd vines and mini mesquite trees, my mind was formulating this blog post. Though my written word is never as good as it sounds in my head, here is my attempt to share with you the Parable of the Jungle Yard...

A man had a vision of what his yard should look like. He gathered together his children and painted the picture for them:

"We are going to have a beautiful yard once again!" the man exclaimed.

"We will fix the gates so they hang straight. We will trim up the trees, pull the weeds and level the ground. Once we reclaim the yard from the overgrown jungle, we will finally be able to plant grass and have a place to play and enjoy."

As the children stared out at the trees that Dad called weeds, they couldn't see it... the vision he tried to paint was just too far fetched! How could they possibly get there from here?

In spite of their doubts, they grabbed gloves and went to work. The daughter started hacking away at the thorn encrusted mesquite trees that had grown from nothing to taller than the eaves in such a short time. She trimmed a little here, and she trimmed a little there.

"Dad? Can you come here please and see what I've done?" she called to the man.

The man came and inspected her work. Not bad for a 10 year old.

"Go ahead and cut it back further. Let me show you." He took the pruners and cut one of the bigger limbs about shoulder height to his daughter.

"That far?" she asked.

"Yes, you are doing a good job. Nice first round. This time you can take even more off. No matter what you do, you can't kill those things!" So, she went back to work.

The man then noticed how his son was doing.

"Good job!" The boy was working hard, but leaving quite a lot of smaller weeds as he attacked the big ones.

"hmm... should I tell him to make sure he gets all the little ones to?" the man thought. "Nah. The first priority is to get the big ones down, then we can move to the smaller ones... baby steps!"

"Your doing it right. Keep on crankin'." He told the boy.

Let's stop there... what are some of the lessons we could learn from this parable, and apply to the business world we live in? Clearly, in this situation, Dad is the Product Owner. It was up to him to create the vision for his children, the team. Also, what about the big weeds vs the small ones? It was up to the Product Owner to define the priorities... getting the big weeds out was more important to the customer (Mom) than getting everything perfect. Let's pull that thread a little... how could that be applied to a technology industry? Maybe, a low fidelity simulation with only a little functionality would be better to deliver, in a short time, to the customer rather than never getting anything done to deliver perfection. Deliver working product in smaller chunks is good.

So, what can we compare the conversation about how much to trim off the trees? This was kind of like a mini review. The team was able to demonstrate to the Product Owner their working proto type. Because the short amount of time that the daughter was working on the tree, it was easy to course correct and provide clarity to her to help align with the vision.

Ok, so call me crazy, but that is where my mind was as I got soaked...

Oh, one more thing. How could we have prevented the jungle in the first place? Obviously, if I had been pulling weeds a little at a time, as they sprung up, my nice green grass yard would have stayed a nice green grass yard. But how does that translate into the business we do? From my Software/Hardware integration background, I compare this to continuous integration. Pulling the little testing weeds out instead of waiting for the epic multi-month Formal Qualification Testing that we all have seen. If we stay on top of our testing, and constant integration, there will never be a need for the big bang at the end of a release. We'll already have the beautiful green grass release.

What can you learn from the Parable of the Jungle Yard?

  • Comments(0)//blog.agileodyssey.com/#post2

The Comfortable Lie

ScrumPosted by Shane Billings Thu, September 03, 2015 07:54:23

I've been doing this scrum thing for a while. At times I am encouraged by those who readily accept the changes presented to them. Other times I find it discouraging when people reject the benefits provided by scrum. Culture change is hard with whatever you are trying to do, and this is no different.

My discouragement is my problem though; not theirs. Putting my emotions aside, I have thought and pondered extensively upon why agile is so hard to accept. Certainly, there are as many reasons as there are people who are not going to accept agile methods. Not the least of which is simply an aversion to change.

Where does that leave us? What are some of the other big objections? Let's delve a little into the abstaining abyss embraced by the naysayers.

The most prevalent alternative to agile is the ever entrenched Waterfall Method. As one dives deep into the differences, the benefits of agile become readily apparent - except for one glaring omission. Even the Agile Manifesto speaks of it. "We value responding to change over following a plan."

Think about it. We value change. Who does that? Who likes change?

"Come join us," we say.

"Wait, this is way different than what I'm used to."

"Yea, but it's better."

"I don't know about this."

"That's okay. You don't have to know. We adapt to change. Not only that, but change comes so rapidly, you will never know for sure anything again," you explain realizing in retrospect that there probably was a better way of explaining this when you hear the reply.

"What?" Yup. There it is.

That's right. We tell them they will never know everything and, therefore, must adapt as necessary. Change when needed with no idea when or where the opportunity will present itself. And we want a lot of it-frequently in fact. Just keep the changes coming. So very uncomfortable.

Compare that to waterfall.

"I want to stay here."

"Why?" You're shocked, yet fascinated - like when you see someone running with a couch down a busy road at midnight. I'm speaking from experience here.

"I know this. But I can also plan out my entire development schedule." They seem pretty confident.

"Really?"

"You bet. As a matter of fact, I don't even move on to the next phase until I have the last one all figured out. This helps me predict exactly what I will do years in advance."

"Wow! How can I do more waterfall?" you respond.

Wait! What? You seem pretty easily swayed. I know it's tempting, but just hear me out. It's a lie! The comfort; the panacea; the peace; it's all a lie. No one knows the future no matter what. Everyone must adapt. They may think that they know everything that will happen to the project, but they don't. To be clear, I don't think they are dishonest. They believe it.

But it's not true. It's just a way to feel good. It feels good as they assure management that everything will work out as planned. It feels good as they control every move of the employees. It feels good as they try to work to the plan and make everything fit in a box. It feels good as they embrace the comfortable lie of waterfall.





  • Comments(1)//blog.agileodyssey.com/#post1

Scrum Zombie

AgilePosted by Shane Billings Sun, August 30, 2015 19:24:54
The other day, I had a direct encounter with a Scrum Zombie. Now, to be honest, I think he was an engineering zombie well before he became a Scrum Zombie. Nevertheless, as a zombie in general, he was afraid to make any decisions without having permission from his superiors. He was a hardware engineer designing a power supply for an embedded system. To say he was new to scrum was an understatement.

He told me of a time that he almost lost his job because he modified the process. He was now an automaton. Just like real zombies, this guy had his brain eaten, and now he was mindlessly going through the motions. Sad really. I had seen other hardware engineering teams really get it and succeed beyond expectations as they used scrum.

How did I recognize him as a Scrum Zombie? Was it the lack of life in him? Maybe. Was it the fear of management or the lack of satisfaction in his work? Could be. It wasn’t until he asked the following question regarding how to break up his work in a sprint backlog that I really saw it, “Isn’t that against the rules?” Wo! There he was right before me! Did I just see his arm fall off?

Don’t get me wrong. There are rules for scrum – strict rules – rules that must not be broken. We do not compromise on things like whether or not we have a retrospective meeting or if the backlog should be prioritized. Definitions of done are demanded. Velocities are vital. Product owners and Scrum Masters should not be the same person. And certainly there are best practices. But outside the core scrum practices, there is complete freedom to experiment and see what works for a team.

What would you say to this Scrum Zombie? You have to keep a poker face. The temptation to be grossed out must be subdued. Remember, at one time, this was a real engineer – with hopes, dreams, and desires. Not to say they had social skills, but to say they were once like the rest of us. We must reach into his soul and find those things. Where are they?

I told him he was a smart guy. What?! He lit up a bit. I doubt he had heard that in a while. We then discussed the fact that with his intelligence he could make decisions that would be well informed. If they were wrong, he could quickly change. We talked of the pros and cons of his approaches. In other words we talked about the “Why” of his decision.

Then it dawned on me! There was the cure for Scrum Zombies! Agile is the cure! Agile is a philosophy about how we approach development. It is empowering. Agile is a mindset for the mindless. It’s the reason behind what we do. Without Agile thinking, scrum practitioners just go through the motions. They are lifeless and dead inside. Ok, maybe not dead, but there definitely is something missing. I think it’s safe to say they aren’t reaching their potential.

When coaching and consulting on Scrum, I always try to teach the “why” behind the “what”. I always try to teach about Agile as well. Together we can fight the plague before us. Together we can cure the undead Scrum Zombie.

  • Comments(0)//blog.agileodyssey.com/#post0
« Previous