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. (firstname.lastname@example.org)
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?
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.
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.
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.
"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.