Agile Odyssey

Why Retrospectives?Scrum

Posted by Jim Palmer Mon, May 09, 2016 06:59:27

I've heard it way too many times, "Why are we doing a retrospective? What's the purpose anyway?" As the Chief Agilist / Release Train Engineer for a half billion dollar program, I have nearly 40 scrum teams that I'm working with. Many of the teams get it, but many of the teams are still becoming familiar with the Scrum practices and how these practices may benefit them. If you struggle with this, hopefully I can shed some light on it for you.

Retrospective, as defined by Google, is "looking back on or dealing with past events or situations." So, how does that apply to Scrum. A Retrospective, in the Scrum context is one of the fundamental meetings in the Scrum Framework. Its purpose is just like the definition says--an opportunity for the team to look back on and deal with the past events that occurred during the past Sprint. But "why?" you ask? It's simple--to "deal with the past events". Even if you have a "perfect" Sprint, where you completed every single story you and your team signed up for and met the expectations of the Product Owner in delivering quality value, there are always things we can do to improve; speed things up and / or improve product quality, team cohesion, individual fulfillment. Retrospectives are an opportunity to take a step back and evaluate the events over the past Sprint and identify / celebrate successes, as well as help identify those areas where we could do better.

A retrospective is only as good as you make it. Scrum Masters should take time to identify retrospective activities that will help engage the team and best bring out their honest, constructive feedback. Team members need to come in to the retrospective with the pure intention of making their team and product better. Most often, the output from a retrospective is a Kaizen Story. Kaizen is a Japanese term coined during the early Toyota lean transformation that means "Improvement". We should identify an improvement story that we, as a team, can do to improve our team and/or process. Typically, this isn't ways to improve the product, that would be a regular story. But it might be something like, "As a team, we want an automated command line executable build so that we can deliver faster". Yes, this does feed into the product, but its focus is on the process. Another example might be, "As a team, we want everyone to show up on time to Scrum, so that we can be done quickly and get back to work." It really is up to the team to figure out ways they can become better.

Often overlooked as a huge benefit to having a retrospective, is the team building aspects of it. Anytime you can openly share thoughts and feelings in a safe environment, you grow close to those you share with. The more comfortable and trusting you are with your team, the easier it is to execute as team. The more you truly execute as a team, the faster you will be able to deliver a better product!

Find ways to make your retrospectives better... sounds like a good retrospective topic?

If you need help making your retrospectives better, please feel free to reach out to me. (jim@agileodyssey.com)





I Wrote a SequelAgile

Posted 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.]



We Wrote a PlayAgile

Posted 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?



Agile Elevator PitchAgile

Posted 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.

Where can we use scrum?Scrum

Posted 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?

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

Posted 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.







Dual Personality?Scrum

Posted by Jim Palmer Wed, October 07, 2015 20:26:13

This past week, I taught a couple of Scrum classes on the fundamentals for teams, Scrum Masters and Product Owners. We had quite a diverse group come through. Some had been working as Scrum Masters for a while and some had just recently been thrown into a Scrum team without a basic understanding of Agile Principles or Scrum Practices. We had some great conversations.

During a break, one of the students came up to talk with me. "I'm the Product Owner and the Scrum Master for my team," he blurted out. Based on the training we'd had up to that point, he realized that being both might not be the best approach.

"Really? How's that working out for you?"

So, why would that cause issues? To really understand that, you need a clear understanding of these two different roles.

To completely over simplify it a Product Owner owns the... uh... product. They have responsibility of the content of the product. The Scrum Master owns the process of executing the Scrum framework. One of the big conflicts of interest that may occur is when the Product Owner is tempted to add more work during a sprint. If the Scrum Master is a different person, then they can push back. But if the Scrum Master and the Product Owner is the same person, where is the balance of power? Who will protect the team?

"But Jim," you ask, "what if that person can be both? What if they can protect the team and still drive value into the product?"

I'm reminded of a scripture that says something like if all men could be great and righteous, then a king would be good... But how often is the reverse been proven? How often does too much power, without balance, caused "corruption"?


When I was a Product owner, I think I had the right attitude and skills that I probably could have pulled off being both... Well, the reality is that no matter how proficient I thought I was with Scrum, it was great to have a competent Scrum Master. I could focus on the product and communicating with the customer and other stake holders as well as being available to the team to clarify expectations. Our Scrum Master could focus on coaching the team--and me--on proper Scrum techniques and keeping the roadblocks out of the team's way.

So, even if you "could" be both, the Product Owner and Scrum Master have to be different people to maintain the balance.



Own it!Coaching

Posted 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!