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)
AgilePosted by Shane Billings Fri, March 04, 2016 07:31:54
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
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!
We owe it all to you. The Scrum
Master can make a world of difference.
A galaxy of difference actually.
[All laugh heartily at the cheesy joke]
Things seem to be great. I never
thought I would like work so much.
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]
Your thoughts betray you Steph.
Stephanie: Who are you?
Steph, I am your Product Owner.
Vader has some lofty goals, and I thought he would be a good fit,
knowing what you are capable of.
The Agile is strong with this group.
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.]
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.”
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
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
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
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.
stands and goes for his light saber]
Vader: I’ll show you a burn down!
Stephanie: Now everyone!
Please calm down.
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?
raises their hands unanimously]
Stephanie: My apologies, but you must find another team
for your dark plans.
escorts Vader from the room.]
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
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.
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.
Shouldn’t we wait for our new Scrum Master? I would think they need to be here for this.
Yea. I hear great things about
her. I hear she is a Certified Scrum
Jennifer: That’s not a thing. There is no such certification.
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.
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.
[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.
Nothing terrible. We’re just
[Stephanie sits at the table. She looks at the plan.]
Stephanie: What does the team think of the plan?
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.
Awww! But I was going into town
to get some Power Converters!
Nothing has Acceptance Criteria, and we have no Definition of Done
It definitely doesn’t seem Agile.
That’s for sure.
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.
I have a bad feeling about this.
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
[Tod Stands Up]
Work harder and quit slacking!
Help me Harry Koehnemann! You’re
our only hope.
[Stephanie raises a hand and lowers
it. Tod is forced to sit against his
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.
Stephanie: Fear is the path to the dark side. Fear leads
to panic. Panic leads to micro-management.
Micro-management leads to suffering.
That seems extreme.
I’m not afraid.
Stephanie: Oh, you will be. You will be.
[Stephanie lets go of her Agile hold on
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.
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?
We can try. You never know what
Stephanie: Try not.
Do or do not. There is no try.
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.
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.
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?
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.
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.
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
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
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!