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!

Why Retrospectives?

ScrumPosted 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. (

  • Comments(0)//

Dual Personality?

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

  • Comments(0)//

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)//