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!

I Wrote a Sequel

AgilePosted by Shane Billings Fri, March 04, 2016 07:31:54

Scene: Shane, Jim, Marilyn, Barbara, Jennifer, Louisa and Stephanie sit around a table in a meeting room. They are anxiously awaiting for their new Product Owner to arrive. Stephanie is the Scrum Master and is dressed in Jedi regalia. The rest are team members. They are at sprint planning meeting.

Scrolling script: The galaxy is finally at peace after years of the Scrum Wars. Culture change is finally a reality as even non-engineering groups and suppliers have become Agile. In a time of unparalleled prosperity, even Darth Tod, the previous Product Owner, has become Agile and has been promoted. The Agile team called “The Padawans” are having a Retrospective meeting after a successful Sprint. They are eager to find out who their next Product Owner will be, unsuspecting of the peril that awaits them.

Stephanie: I have to say that I’m impressed. Velocity has over doubled since we started. You consistently complete all the work in the sprint and burn down reaches zero frequently. Roadblocks seem to be easier to overcome. The sky is the limit!

Marilyn: We owe it all to you. The Scrum Master can make a world of difference.

Barbara: A galaxy of difference actually.

[All laugh heartily at the cheesy joke]

Louisa: Things seem to be great. I never thought I would like work so much.

Shane: Yea. I’ll bet that our new Product Owner was very excited to be assigned to such a successful team.

Jennifer: I wouldn’t be so cavalier. A good product owner is hard to come by, yet they are worth their weight in gold. I mean a team is only as good as their backlog in a lot of ways. Agile isn’t only about scrum. It needs to be combined with other things to truly be successful – Continuous Integration, Test Driven Development, Paired Programming, Scaled Agile Framework, Model Based Engineering and other things should be considered. If you do stupid with Scrum, you’ll just do stupid faster.

Stephanie: That’s the point of this retrospective. We want to avoid stupid things.

Jennifer: I have a bad feeling about this.

Stephanie: That’s enough speculation. Let’s get started. Today we will be talking about our feelings. Engineers that are Agile have a lot of things to say about their feelings. Everyone take some stickies and get out a pen. I want you to write down…

[R2D2 beeps to interrupt Stephanie. Tod comes in along with the new Product Owner – Darth Vader]

Vader: Your thoughts betray you Steph.

Stephanie: Who are you?

Vader: Steph, I am your Product Owner.

Jim: Nooooooooooooooooooooooooooooooo!

Tod: Vader has some lofty goals, and I thought he would be a good fit, knowing what you are capable of.

Vader: The Agile is strong with this group.

Tod: Yes it is.

Stephanie: Have a seat while we talk about the last sprint and decide how to improve ourselves.

[Darth Vader sits down]

Stephanie: I want everyone to write a one word description of how the last sprint did on a stickie.

[Everyone writes on their stickie. Stephanie picks up the stickies and reads them one by one.]

Stephanie: Happy. Fun. Wonderful. Delightful. Exciting. Enchanting. Superb. Disturbing. Uhhhh. Okay everyone’s opinion matters. Would anyone like to elaborate?

Louisa: I had a great time during this sprint. Nothing seemed to slow us down. I thought it was “superb.”

Stephanie: Thanks Louisa. Anyone else?

Vader: I think the team could go faster. I find your lack of faith “disturbing.”

Shane: What?

Vader: You haven’t achieved enough of the Agile. You can go faster. In fact, the Emperor is coming to visit?

Marilyn: The Emperor is coming here?

Vader: That is correct Marilyn. And, he is most displeased with your apparent lack of progress.

Marilyn: We shall double our efforts.

Vader: I hope so, Marilyn, for your sake. The Emperor is not as forgiving as I am.

Stephanie: I sense darkness in you, Darth Vader.

Vader: Team, join me in the dark side. Use your fear to become powerful. Use your anger. Work overtime to accomplish your goal. Together we kill the emperor and rule the galaxy!

Jim: That seems extreme.

Barbara: Well, hold on here. Let’s hear him out. Vader, can your vision be broken down into smaller chunks that fit within a two week sprint period? Like maybe we could just take over a planet at first. Or maybe we just maim the emperor.

Shane: We can’t just go along with him. This is the dark side.

Jim: Yea! The Agile should not be used to kill people. It is powerful, yet we must use the power for good. This sounds like an ethics video. The next thing you know, we’ll all be interviewed one by one and I’ll say, “I guess I thought it couldn’t happen to me. I mean I’m a good guy right? I guess it’s all of our responsibility to stop and question what doesn’t feel right. If I had to do it over again, I definitely would not have killed the emperor. Hey guys they said, `Let’s kill the emperor.` Who does that? Then, maybe I’d still have my job.”

Louisa: The team is going as fast as they can. Your backlog may be in question, but not the capability of this team! Look at our burn down. It’s phenomenal.

[Vader stands and goes for his light saber]

Vader: I’ll show you a burn down!

Stephanie: Now everyone! Please calm down.

[Vader pulls out a paper and shows it to the team.]

Vader: Here are my plans.

Jennifer: Is that a moon?

Shane: That's no moon. It's a space station.

Jennifer: Alright, this has gone far enough. We are at a retrospective. I suggest a simple improvement story. “As a Padawan, I would like a new Product Owner, so I can get a proper backlog.”

Stephanie: Those in favor?

[Team raises their hands unanimously]

Stephanie: My apologies, but you must find another team for your dark plans.

[Tod escorts Vader from the room.]



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

We Wrote a Play

AgilePosted by Shane Billings Sat, February 20, 2016 07:53:52

Scene: Shane, Jim, Potts, Marilyn, Barbara, Jennifer, Louisa and Tod sit around a table in a meeting room. They are anxiously awaiting for their new Scrum Master to arrive. Tod is the product owner. The rest are team members. They are at planning meeting.

Narrator: We join our fearless development team as they await their new scrum master. Spirits are low and tension is high. Our heroes have been through many Scrum Masters over the previous months. None could bear the pressure and difficulty of working with the evil Product Owner, Tod. Each had left abruptly, and although the benevolent functional management provided more Scrum Masters, it seemed as though the team would never be as Agile as they believed they could be.

Tod: Thanks for coming to our Sprint Planning meeting. There is a lot to do and little time to do it. Let’s get started by taking a look at what we have planned.

Barbara: Shouldn’t we wait for our new Scrum Master? I would think they need to be here for this.

Jim: Yea. I hear great things about her. I hear she is a Certified Scrum Jedi!

Jennifer: That’s not a thing. There is no such certification.

Jim: No, really. It is. I thought it wasn’t real either, but it turns out it is. It’s true. All of it. They have years of experience and are trained from a young age. They have mentors. They bring peace to the Agile Galaxy.

Tod: We don’t have time to wait. In fact, we need to keep this meeting under 30 minutes. So I have created all of your tasks and assigned each of you the work you will be doing in the sprint. I haven’t prioritized anything because it all has to get done.

[Team groans]

[Enter Stephanie in Jedi regalia. She is hooded with hands in front of her in Jedi pose. She calmly walks up to the table. The team is in awe. Tod is scared. She lowers her hood to reveal her face.]

Stephanie: I felt a great disturbance with the Agile, as if seven voices suddenly cried out in terror and were suddenly silenced. I fear something terrible has happened.

Tod: Nothing terrible. We’re just planning.

[Stephanie sits at the table. She looks at the plan.]

Stephanie: What does the team think of the plan?

Shane: I find it confusing. I don’t think I can finish in time. Not to mention that my assignments would be better done by Potts.

Potts: Awww! But I was going into town to get some Power Converters!

Shane: Nothing has Acceptance Criteria, and we have no Definition of Done either.

Louisa: It definitely doesn’t seem Agile. That’s for sure.

Tod: Sure it’s Agile! Agile means we can deviate from normal processes because we are flexible in what we do. We are Agile. That’s what the word means, right? Do what we want because the rules don’t apply.

Barbara: I have a bad feeling about this.

Tod: My career is on the line here. If I, uh I mean, we succeed, then we are sure to get promoted. Look team. All you have to do is go faster than you have been. How hard could that be? I’m sure no one has come up with that idea yet.

[Tod Stands Up]

Tod: Work harder and quit slacking!

Barbara: Help me Harry Koehnemann! You’re our only hope.

[Stephanie raises a hand and lowers it. Tod is forced to sit against his will.]

Tod: What are you …

[Stephanie clenches her fingers as Tod is forced to be quiet.]

Stephanie: Agile is a way of thinking about the how we do work. Those who are truly Agile value working products, responding to change, customer collaboration, individuals and interactions. Close your eyes. Feel the Agile. For my ally is the Agile, and a powerful ally it is. Life creates it, makes it grow. Its energy surrounds us and binds us. Luminous beings are we, not this crude matter. You must feel the Agile around you; here, between you, me, the table, the chair, everywhere, yes. It binds the galaxy together.

Jim: I’m afraid.

Stephanie: Fear is the path to the dark side. Fear leads to panic. Panic leads to micro-management. Micro-management leads to suffering.

Jim: That seems extreme.

Potts: I’m not afraid.

Stephanie: Oh, you will be. You will be.

[Stephanie lets go of her Agile hold on Tod.]

Stephanie: Shall we proceed?

Tod [hesitantly]: Ok. The first story. As a product owner, I would like the team to go faster, so that I can get promoted.

Stephanie: This isn’t the story you are looking for.

Tod: This isn’t the story I am looking for.

[Fade to black]

1 hour later

[Fade back in]

Stephanie: The meeting is time boxed, and we are almost done. Does the team commit to the sprint stories and goal?

Marilyn: We can try. You never know what will happen.

Stephanie: Try not. Do or do not. There is no try.

Marilyn: I don’t believe it.

Stephanie: And that is why you fail. There is a long way to go before we become truly Agile my young Padawans.

Shane: Padawhats?



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

Agile Elevator Pitch

AgilePosted by Shane Billings Mon, February 08, 2016 16:12:04
In spite of the fact that we've made great strides in engineering technology, management of engineering projects has been slow to evolve to meet the needs of the customer. Businesses are driven by time to market and innovation like they never have been before. Which business will deliver value to the customer the fastest and thus gain market share. This is the focus of Agile.


Agile is a mindset that capitalizes on the knowledge of engineers to produce value rapidly. Instead of producing non-value added items such as documentation or studies, Agile focuses on releasing tangible business value rapidly and using the knowledge to quickly respond to current climates of change. Instead of producing a product over the course of years, the product is incrementally produced over time to meet the customer needs in the moment. After all, if you develop over the course of years, then you deliver what the customer wanted years ago.


Agile is a mindset that has been traditionally applied to software although it is growing into the hardware realm with great success. It's main tenants are that we value responding to change, people and relationships, customer interaction, and an actual working product. These principles may sound like common sense, but that hasn't been the case in traditional development. Compare them to following a plan rather than adapting, no matter how bad. Or maybe we value processes over people. Some developers never interact with a customer to determine their real needs. In the worse case, a working product is never produced at the expense of comprehensive documentation.


Agile helps people think about using these principles to deliver value. They apply it with practices such as Scrum, Kanban, paired programming, Continuous Integration, Test Driven Development, and others. Companies that apply these new methods of management are seeing fruits that far outpace their alternative methods. They are seeing a competitive advantage. They are seeing value.

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

Where can we use scrum?

ScrumPosted by Shane Billings Mon, November 23, 2015 17:18:53
I have friends that are as passionate about scrum as I am. To my utter delight, I hear stories about how they apply Scrum to the most unlikely places. One friend applies it in her home for their weekend chores. Another planned a wedding using it. I know she trusts the process because the wedding was her own!

I have been pleasantly surprised when we applied it to our hardware development. I guess I shouldn't be surprised. If you can break up your work into small groups, you can Scrum it.

So let me pose this question, where have you applied Scrum? Have you applied it to anything besides engineering?

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

Solve the world's problems. Just don't do it now.

AgilePosted by Shane Billings Tue, November 03, 2015 16:50:01

Recently I was invited to a meeting to discuss a problem. Actually, in truth, I was invited to be shown a solution. I suppose that the people attending wanted approval for their approach.

I guess the solution was a good one. It was to solve the problem of data organization. How would we find it? How would we deal with an audit?

The fix was comprehensive. It took into account everything that could go wrong. Nothing was left out and it felt safe. The only problem was that it was complicated. As the whiteboard was filled with lines, boxes and diagrams, I realized that the solution would soon turn into a problem in and of itself.

Complexity leads to lack of use. It leads to adoption failure. And we were on that path.

I listened carefully to understand. Finally, I asked a question.

"What is the bare minimum you have to do now to solve the immediate problem?"

That changes the whole conversation. Bare minimum? What was that? What is the immediate problem? What is the real goal?

I've been in more than one meeting where we solve potential problems rather than actual ones. Problems seem to have babies and procreate faster than a rabbit on fertility drugs.

There is no need to commit to a solution for an imagined problem. There is no need to imagine problems. The 100% solution can solve all of the potential problems. But let's be honest; not all of the problems ever happen.

A better approach is to solve the problems as they come up. And this is what this team was now presented with. What was the real problem? What was the solution? What was the bare minimum to accomplish the goal.

I let the team talk about it. Honestly, when the meeting was over, I wasn't sure what they would do and I didn't want to overly influence them. The following week, they came to me and told me they had solved the solution much more simply. In fact, it was already in place and working; much easier than the weeks of development planned for the original solution.

And the best part - they can still evolve. There will be room for future growth. There will be time to experiment and evolve. There will be a chance to solve the world's problems. We just don't have to do it now.







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

Own it!

CoachingPosted by Shane Billings Mon, October 05, 2015 09:29:03


In my last post, we discussed the Stockholm Syndrome in which we may identify with our captors. There is another danger that can come to a team when they are not empowered - they own nothing.

The reason is simple. Because someone else has all the power and control, that person also has all the ownership. Teams that are not empowered simply have less skin in the game.

Why? Because it's safe. The cost is too high when compared to the reward. Teams without control are more interested in protecting themselves than succeeding.

The first thing they protect is their egos. They look at failure as not their fault. After all, they didn't make those dumb decisions. And they are right. It's not their fault. But the flip side is also true. It's not their fault if they succeed. Without commitment, there is no success or failure. Without that, there is no reward; no motivation; no true growth.

The next thing they protect is their careers. When power is in another's hands, so are the consequences. Rather than do the right things, they do things to please a boss. Don't get me wrong. That's not inherently bad - if the boss is always right. But they aren't.

If a boss rewards based on their desire, then the flip side is true as well. They can punish just as assuredly.

Which brings us to our next protection - alliances. Teams become divided as alliances can form. They align with those that are rewarded and shun the punished. Decisions are made based on politics.

All this ends up stifling creativity, inhibiting productivity, and destroying morale.

So how do we identify a team caught in this loop? In scrum it's easy - the burndown. I can guarantee that a team without ownership will not reach the completion of all their tasks. One time is alright. But look for a pattern over time. How many sprints have they missed? By how much?

Teams that don't hit zero will feel defeated. They will feel pushed around. They will feel that the failure is not their fault.

At that point you have work to do. There could be many issues at play here and the solution will take time. I can tell you that the team will feel comfortable and that breaking them free will take some work.

Recently I had a retrospective with a team that had no ownership. In this case, management was trying to give it to them but they were not taking it.

We'd an activity where we put up their burndown on a whiteboard and had them label it. I let them go and with very little prompting they identified that they rarely reach a completed burndown.

We listed the reasons for this. Then we voted for the biggest. At the top of the list they said was that they were waiting on others to deliver vital tasks before they could complete their items such as reviews.

"Oh!" I said. "Which teams are you waiting on?"

The reply, "It's not another team. It's us. We are waiting on each other."

Wow! Talk about a team with problems. Actually, it's hard to call them a team at all. They wouldn't help each other out like a team should.

We talked about prioritization and helping each other out. We talked about focus. They have a long way to go.

A couple of people came up to me and privately blamed other members of the team. No ownership. They blamed their difficult work, their management, the schedule, and the tools. No ownership. Never did they blame themselves. They took now responsibility for success either. Never did they take ownership.

There is a lot of work to do for them, but they can.

They can own it!




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

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
Next »