Could you identify a great scrum master? Are you one?

I am huge believer in the scrum master role as a leader without authority.
Strong scrum master(s) can change the world, or at least the organization. Bad scrum master(s) team can keep the organization standing still, or getting worse..

During my work as an agile coach I have identified certain things that many great  scrum masters / people leaders do.

While writing this blog post, I wanted to make you, the reader, think on the following questions:

  1. Are my scrum masters / People leaders fit this description?
  2. Do I fit this description?

If the answer is “Yes”: Great! You have been reinforced.

If the answer is “No”: Where is the gap? Would you like to improve in this area? (If yes, I probably can help you here, let’s talk). Maybe you disagree?

I would be happy for you to share your thoughts, and receive feedback, after you complete this 3 minutes read.

Is your intuition sufficient to succeed?

Yes, this blog post is going to talk about agile. But, first, let’s talk about money – who doesn’t care about how much money does he have in his bank account.  

If your income is significantly higher than your expenses – you have nothing to worry about.
However, in most cases this is not the case. My life has taught me that no matter how much my incomes increases, my expenses increase accordingly. I am putting more money in savings, I travel more, and in general I enjoy life more. 
Once in a while I notice that I am losing it. Enjoying life costs me more than it should, so I either need to cut down on my savings or put more control on my expenses… 

Usually, what happens at that point is that I am trying to pause my intuition. I believe that I have a really good idea where my money goes (restaurants or cloths) and I try to cut down on my expenses there. Surprisingly, nothing changes :). So, I am taking the situation seriously, and I begin to collect the data. Every day or two, I write down what did I spent the money on. Now, I can easily understand two things:
1) What I am really spending so much money.
2) The trend – What’s my status going to look like at the end of the month if I will continue with this trend.  

The big pro of basing my decisions on statistics is that I can easily adjust my behavior immediately based on empirical data compared to my goals. It takes me only 2 minutes tops (every day) to do it, and in the end of the month I am still smiling.

So, why did I tell you all of this and how it relates to agile and scrum? 
This is exactly what frequently happens every time with many scrum teams.  

Burn Downs Chart

Every day, during the daily meeting, the scrum team is gathering up in order to answer the following questions: “Are we going to achieve the sprint goal? If not, what do we need to / can do differently?”

Most of the scrum teams I work with, answer the first question based on intuition and not based on real data and statistics (which would be very easy using a burn down chart).

  • For some teams it works well  – and then great, continue exactly as it is! 
  • For some teams it works really bad. We can compare it to a family with a big debt on their bank account, who will do whatever needed in order to survive. Then, they will do whatever is needed in order to track their progress out of debt and back to credit. 
  • For many teams (maybe even most), they believe it works very good (some will call it “wishful thinking”), when actually every time in the last two days of the sprint, they shockingly get surprised of the remaining work they still have to do in order to achieve sprint goal.

Here is a real  life example of one of a scrum team board. I would like to examine your intuition vs. statistics: 

* The team had 7 working days in that sprint 

Let’s see what your intuition will say after 2 days into the sprint (out of 7)?

 

I would say, it seems good. The PBI #1 almost done, and it took us only 2 days. PBI #2 is already half way, and we already started PBI #3.
Now, let’s look on the burn down chart after 2 days into the sprint:  

 

* The red line is the team’s remaining work over time. The green line is the theoretical ‘perfect’ progress rate.
You can easily understand that if they are not going to close up the gap they will not achieve their sprint goal.

Now, let’s take another look on what happened after 5 days (we have left with only 2 days till the sprint ends):  

Based on the Scrum board I have a great feeling… Look at how much work they completed in 5 days. What’s left is about a fifth of what we already completed so my intuition says that we can make it! 

However, what my intuition doesn’t take under consideration is the amount of work that was added during the sprint. Also, sometimes, we are biased by the first column and don’t take into account that the intuition that neglects work that is already in progress but not done.

While looking at the burn down chart, in one second we can see there is no way we are going to complete all the 3 PBI’s (Actually, we could tell that to the PO already on day 2).

Combining the scrum board and the burn down chart, we can also understand why this happened. There is a lot “unplanned” worked that was added to PBI #2, mainly during day 3 (great input for retrospective). 

Question: How long does it take to create and update the burn down chart? 
Answer: Create about 5 minutes (if we want the lines to be straight). Update – it is maximum 2 minutes (we need to count all the work in the “To do” column and in “In Progress” column).

Let’s go back to our money again. When we are talking about our money, I can understand why we wouldn’t want to face the hard facts as soon as possible. When we do that, we might need to skip the next vacation, not to buy this beautiful shirt, or even (heaven help us!) starts to cook at home. However, when we are talking about our day to day work: If we do the burn down chart, we are gaining  the ability to adjust our plan, improve our predictability and transparency, and bring back the smile on our manager’s and PO’s face. When we do not visualize both our work and trend-over-time, we miss all of that, and earn nothing instead.

So I have this question for you – how come there are still so many teams that perform poorly, and yet are not using burn down charts? Could you please help me understand that fact? 

P.S.
Here is a link to view the entire 7 days sprint – Please use it in order to explain your team members why a burn down chart is a great idea.

Spoiler: In my next blog post I will explain the additional data which we can collect from the different types of burn down/up charts 

Facilitating vs. Coaching – what is the difference?

The scrum master has multiple responsibilities. Here are two of them:

  1. Coach the team, the PO and the organization with scrum.
  2. Facilitate effective ceremonies.

When you facilitate a great retrospective meeting does it mean you coach the team with scrum? The answer is no. Facilitating and coaching are two different things.

Coaching and facilitating are both widely-used term with various meanings. In this blog post I am focusing on those terms in a work related context.

Let’s start with definitions:

Coaching: A form of personal development, The act of helping others (can be more than one person) to learn their way in achieving a specific personal or professional goal. It differs from training and teaching which are focused on knowledge transfer.

Facilitating: The act of helping other people to deal with a process without getting directly involved in the process, discussion, etc. himself.

Let’s take it into the scrum world:
The scrum master coaching individuals with scrum means he helps the team, PO and organization to learn their way to be more agile, using the scrum framework.  Examples:

  • Lead by example: It means, he himself lives by the agile and scrum values and principles.
  • Pull and not push – he is always there, waiting for someone to ask for help. He recognizes and creates opportunities for learning. He is doing that by listening, asking questions, and challenging.

In order to do that he must master Agile, Scrum, coaching, influence techniques, organizational behaviors, system thinking, and more.. This the same as being agile, it is endless journey – you need to keep learning all the time.
Let’s demonstrate using a coaching opportunity: We are in a backlog refinement meeting, the team velocity is 18 SP (Story Points). The team estimated a story as 21 SP and continues to the next story. The scrum master asks the following question: “Can you finish this story in one sprint? When will you know that? When will you be able to get feedback on the work?” “So, what can be done in order to increase visibility and shorten the feedback loop?”

The scrum master as facilitator. In Scrum framework, we have 4 ceremonies and one backlog refinement. So, it is easy to understand when the scrum master can help in facilitating. Facilitation has one rule you need to master and multiple skills to practice. However, this one rule –  not get directly involved in the process – for most people is really hard to follow. The happy news is, that after you embrace this rule, it is easy to learn facilitation skills. There are a few tricks, and the internet is full with ideas. All you need here, is a leap of faith that you can do it, and it is going to uplift your team agility.
One example for facilitation: We are in backlog refinement, the team is playing planning poker in order to estimate the stories. Each time there is one person, Jack, that shouts his estimation. The scrum master asks everyone if they agree to play with one new rule. The rule: Everyone will expose the cards only after the question: ”Is there anyone that did not select a card?” was answered. Using this specific question, and not “Did everyone select a card?” makes a big difference. The first question, you feel comfortable to say yes, because the question is directed to each one of the team members. To the second question, it is directed to the team – and most people don’t want to be the exception.

Note: Now,  a good scrum master will recognize this as an opportunity to individually coach Jack on team-work and scrum (What is his positive contribution in the planning poker game? How does he get that goal?  What are the negative results of his behavior? What he is afraid of? What can he do differently now? Be curious!).

As with other Scrum Master skills, this is simple to explain and very hard to do. Just recall that “everything worth doing is worth doing poorly”, as Marshal Rosenberg teaches us. Try experimenting with being a coach and a facilitator, see how your team reacts, and then tunes and adjust. Success will follow, so long as you don’t give up too soon.

Saying that, I am sure I can learn a lot from your experience. Do you have facilitation toolbox in your bag? Do you have any joker in your pocket? I will be happy to hear about it.

Why do I need to play games in retrospective?

Left and right side of human brain concept illustration

All of the teams I have worked with had come to understand that the retrospective ceremony is a necessary tool when wishing to increase effectiveness. However, many are still struggling to yield valuable action items in these meeting.

I (and every website on Google search) highly recommend using of games during retrospective meetings in order to achieve valuable results. And yet, I am often asked:
“How can I facilitate the retro meeting without these silly games? The team members find these to be a waste of time, and they are certain we can get the same results without them.”
The answer is Yes, and… You probably can, and in order to do that each team member needs to be skilled in creative thinking, able to stimulate and enrich his perspective on his own, as well as capable of challenging his base assumptions. Most team members are not skilled enough to do that.
Games helps us hone these skills, and here is the scientific explanation:

In the late 1960s Roger W Sperry, an American psychobiologic, discovered that human brain has two different ways of thinking. One (the left brain) is verbal and processes information in an analytical and sequential way, looking first at the pieces then putting them together to get the whole. The other (the right brain) is visual, and processes information in an intuitive and simultaneous way, looking first at the whole picture then the details. These halves are commonly called the right brain and left brain, but should more correctly be termed ‘hemispheres’.

Right-brain is often regarded as more ‘creative’ vs. left-brain is regarded as more ‘logic’.

For example: Let’s think about a cat.
The left brain analyzes this information as 4 legs, a head, 2 ears, 3-6 kg. The right brain analyzes it as an animal, kind of a tiger, indulges, selfish, Egyptian symbol. Do you see the difference?

While each person has a natural tendency towards one way of thinking, often the two sides of our brain work together in our everyday lives.
Ask yourself the following question: “How do I get to the nearest supermarket?”
A Person with a tendency towards left brain thinking will answer: “Go straight ahead 3 blocks (around 50 meters), then turn right on Diznigoff street. Advance another 100 meters, then in the corner with Arlozerov street – you will notice it on your right. The right brain will sound like: “Go straight ahead till you see the shake bar in front of you, then turn right (point to the right), pass the bank on your left, pass by the pizza restaurant and then it will be on the right.

Now, how is everything related?

I will take a risk and generalize that most of us (by us I mean knowledge workers) have a tendency toward left side brain thinking. It is important to understand that there is no right or wrong here; it is merely two different ways of thinking. By knowing what your natural preference is, you can pay attention to your less dominant side to improve the same. And this is where games, storytelling and metaphors can help – all of those are attending to our right side brain. Those games allow us to skip on what we have already known and analyzed (left brain) and open our mind to look at the situation from a different point of view (right brain). It also allows us to process new information that our left side brain literally can not see.

Let’s return to the main question: The answer is Yes. You can facilitate an effective retrospective without “silly” games – you just need to master your brain for that 🙂

What about you? Please share – Did you come across with similar situations?
How did you engage your team for game activity?
Have you done any exceptional retrospective?  I (and all the scrum masters in the world) will be glad to hear about it also 🙂

Recommended reading for Agile Team Member

“The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment. Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.” [Scrum Guide by Jeff Sutherland and Ken Schwaber]

We curated this list of that we feel is important and useful for every scrum team member.

It is not a complete or a final list, we try to keep it small enough to be digestible but not too small so that it is missing the major things. Your comments \ Suggestions are more than welcome.

The following books are specifically for software development teams. 
Whether you are a programmer, a tester, a UX-er, a business analyst – you’ll find them priceless.

Articles

The Scrum Guide by Jeff Sutherland and Ken Schwabber

The End of Software Engineering and the Start of Economic Cooperative Gaming – Alisrair Cockburn

Promiscuous Pairing and Beginners Mind – Embrace Inexperience – Arlo Belshee

Blogs

Giving Up on TDD [Clean Code]

Videos

A great 15 minutes intro to Scrum – Michael James

Recommended reading for Agile Change Agents

Whether you are a manager, a director, an architect or maybe some other influential role, you probably act as a change agent in your organization. Maybe you are a transformation lead and the source of your influence is embedded in the role.

Either way, as an agile change agent you can greatly benefit from deepening your learning into the agile mindset, theory and practice.

Product Owners

“The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.” [Scrum Guide by Jeff Sutherland and Ken Schwaber]

We curated this list of books that we feel is important and useful for any product owner.

It is not a complete or a final list, we try to keep it small enough to be digestible but not too small so that it is missing the major things. Your comments \ Suggestions are more than welcome.

The following books can enrich the project management aspects of any Product Owner:

The following books cover multi facets of agile product development

Scrum Masters

“The Scrum Master is responsible for ensuring Scrum is understood and enacted.” [Scrum Guide by Jeff Sutherland and Ken Schwaber]

Scrum Master must master the scrum framework. We have curated this list of resources with stuff we feel is important and useful for scrum masters.

It is not a complete or a final list. It will never be a complete list. We try to keep it small enough to be digestible but not too small so that it is missing the major things. Your comments \ Suggestions are more than welcome.

Standing on the shoulders of giants

Agile Fables and Novels

Complexity and Systems Thinking

Scaling Organizations

Personal and Team Development

Agile Team Members

“The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment. Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.” [Scrum Guide by Jeff Sutherland and Ken Schwaber]

We curated this list of that we feel is important and useful for every scrum team member.

It is not a complete or a final list, we try to keep it small enough to be digestible but not too small so that it is missing the major things. Your comments \ Suggestions are more than welcome.

The following books are specifically for software development teams. 
Whether you are a programmer, a tester, a UX-er, a business analyst – you’ll find them priceless.

Articles

Bloggers

Johanna Rothman – Johanna is a management consultant for software managers and leaders. 

Websites

  • LeSS – Large Scaling Scrum
  • Safe – isn’t good enough – Ron Jeffries, one of the founders of XP, compare between a scrum and SaFe, and explain why it is not good enough.

 

Base Assumptions for Being Agile

Last week, my colleague, Ilan Kirschenbaum, and one of my agile mentors, published in his blog post “Recipe for becoming a scrum master”.
I really related to his post, because it is actually tracing the steps I went through on the way to become an agile coach (and I continue repeating those steps every day, this blog post is an evidence :)).
Still, I have something to add – some base assumptions I have embraced during the way, which I think worth sharing.
A moment of honesty, the idea for this post came up during NLP lesson, I have recently started. The following base assumptions are also the foundation for the NLP, so I (or we) did not invent anything new here – it is just perfectly blended into being agile.

So, let’s begin with the first one, and for me, it was also the hardest one to acknowledge and embrace.

First assumption:

Everyone is doing the best they can (with the resources they have available)

I am going back to the days, I was a product owner. We are now a day after releasing a new version to our biggest customer, and the moment this version is installed for the first time, a new critical bug is introduced to me. Everyone is in huge stress. I am starting to investigate, and I come to realize that R&D knew on that limitation and did not bother to share this knowledge with me. Sounds familiar, right?

I was so furious! Immediately went to speak with my agile mentor (it was Elad Sofer), and told him: “They did it again! They knew about this bug, but of course, they chose to hide it, and hope that the customer will not find out – they are just playing it”. Elad then told me: “Come down, Always remember, people behave the best they can, no one purposefully doing things to upset or annoy us, or consciously trying to make mistakes or create difficulty”.

At that moment it was laborious for me to face it, I think I even was angry at Elad for protecting them. However, after some time, I cannot point to the specific moment, I became a system thinker and understood there is no point in blaming, the system is more complex than just the cause and result.
Unfortunately, we tend to take things personally that aren’t, look for what’s wrong, and critically judge the people around us and ourselves. The moment we realize that people always do the best they can, given whatever tools and resources they have, and the circumstances and situations they are experiencing, it usually calms me down and creates a sense of empathy and compassion for the people I’m dealing with and for myself – allow me to take step back and look for the causal loop diagram, find the arrow that can alter in a positive way. The power of this statement resonated with me deeply even in my personal life.

Second assumption:

In any situation you have at least 3 options

In whatever situation, no matter if it is a decision you need to take, or a path to select – you always have at least 3 options:

  1. To continue what you are doing
  2. To do the opposite
  3. To look on the situation from a fresh perspective and do something new

For example: You are the scrum master, and you feel that the team performance are standing still. Your first assumption is that the action items from the retrospective are being ignored. At that stage you have already tried what you always do – gather the team and give them a motivation pitch with the feedback base on your observation. However, 3 iterations and nothing changes.. So what can you do??

  1. To continue what you have already tried before, another talk, another motivation pitch. Maybe you can even take this, 1 step forward, talk about this issue in 1:1 with the team members – maybe then something in their mind is going to change.
  2. Ignore it, do nothing, the team is tired of talking, they need to face the problem – the moment they will raise this issue, we will handle it in the retrospective.
  3. Look at the situation from another perspective – maybe your assumption is wrong. Maybe there is something that is not being talked in the retrospective. Maybe you need to go back to the books and look for a new way to do a retrospective.
  4. What can you, as the scrum master, do different?  Have you tried to add the action items from the retrospective as a user story to the sprint? Have you tried to use popcorn board? (If you do not know what is popcorn board – google it, or wait for my next post ;))

From my experience,  usually when you find the third option, you will easily, also find the fourth and fifth option.
When you have only one option in your mind – it means you do not have any choice (think of it as you are going into elections with only one political party :(. When you have 2 options, it is the obvious choice, what you know and the opposite.  With three options you can start seeing real options. The moment you are able to choose from a range of options, it means you are not forced to do anything. You are able to act from a place of autonomy and free will, which is incredibly important value for you.
The coolest thing about this practice – that it is the easiest assumption to embrace, you just need to remember to try.

Third assumption:

It’s Not Failure, only Feedback

As an agile coach, in order to gain a new customer I must participate in marketing meeting. Usually the customer prefers to continue with the same coach, he met in the first meeting  – don’t ask me why 🙂 I can be in the meeting and not saying a word,  just nod and smile, and still he will prefer to work with me than with other coach, he has never seen – this was just an example, who ever know me, knows that there is no way, that in one hour meeting, I will have nothing to say 😉
However, in the first time I went to a marketing meeting by myself, I really screwed it up. I lost my confidence, and the meeting lost its focus. I felt horrible, I failed.
At that moment, I thought to myself “what the hell happened there?” I could take it as one time failure and hope next time will be better, but instead I took it as a feedback. I told myself: “I know I am very good at what I am doing, so why did I lose my confidence?”
I understood, that even though I am an agile expert, I feel uncomfortable when I need to market myself as one, and I need to work on this. I started to view marketing presentation of people who know how to leave a mark, and decided to register to NLP course, in order to gain new skills that can help me feel more comfortable. I can assure you, in the next meeting, you have already been able to notice the difference.
It’s so easy for us to think that we’ve failed if we don’t get the result or outcome that we desire. That’s an effect of the black and white thinking that you’re conditioned to accept as a default. When you take any failure as a feedback, you can learn something in any situation, no matter how unpleasant. You acutely never fail, unless you gave up.

Although those assumptions as very basic, being aware of them had a big impact on my professional and personal life.
How did this post make you feel? Please share your thoughts with me, and write a comment. I will be really happy to read it – I promise to respond 🙂

Image by Manfred Richter from Pixabay

Let’s talk about MVP

I have a confession to make: My name is Anat, and I was infected with the agile virus while I was a product owner.
The first agile technique that made me look at the system differently was the minimum viable product (MVP). The moment I realized what it means, I asked myself: “why have I ever invested time in infrastructure that I do not know I’m ever going to use?”or “why have I ever invested 2 months on a feature that I do not know my customers even find value in?”
MVP is one of the most important techniques, and it’s important to notice that its power is matched only by the amount of confusion it causes, because it’s actually quite hard to do. It requires judgment to figure out, for any given context, what MVP actually means.

The MVP term was coined and defined by Frank Robinson as the unique product, that maximizes return on risk for both the vendor and the customer. Later it was popularized by Steve Blank, and Eric Ries (Lean Startup).

From the Agile product management perspective, MVP is the minimum features set to sell your vision.
Steve Blank claims you are selling your first version to the Earlyvangelists (= Early Adopter + Internal Evangelist). Hence, one approach to defining the minimum features set is to ask, “What is the smallest or least complicated problem that the customer will pay us to solve?”.

Let’s also examine the definition used by the lean startup movement: “The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort”.
Eric Ries claims that we have to be able to learn something from each product iteration. In many cases this requires investing a lot of energy in talking to customers, measuring stuff and analytics.
For the lean startup movement, the bottom line is that: An MVP is an experiment.
Lean startup and agile have some different purpose, however, both techniques can be perfectly combined. If I must choose, I am with Eric Ries 🙂

I remember the times when I started my agile journey as a new product owner, I was really excited when I first understood the power that comes with MVP.  I used MVP as “risk reduction” tool for cooperation with project managers. At that time, we worked in agile internally, however, externally, the project was still managed based on waterfall methodology: fully defined SPEC, and final deadline, which was based on long run estimation (on high-level features) that became commitments. Using MVP techniques allowed me 100% confident of delivering the most valuable features on time (I think it usually was about 60% of the features committed). Regarding the rest, I was able to recognize unexpected complexity in early stages of development, and either find a workaround or communicate it to the project manager when there was still enough time to manage it with the customer.

As I said before, defining MVP is hard, so I would like to share with you some common mistakes, I have seen during my work as an agile coach:

  1. MVP based on the waterfall model – for  example: first iteration full high level design, second iteration detailed level design, third iteration implementation. What is the value for the customer in high level design doc – Is the customer willing to pay for that? What were the experiment results?  What did you learn based on your basic assumptions? What did you learn from your customer feedback after the first iteration?
  2. Minimum does not mean imperfect, incomplete, or unfinished. It does not mean lowering quality or compromising standards, and creating huge technical debt. Minimum, as you should spend as little time and effort to create it, it means more with less.
  3. Minimum is not your goal. Furthermore, avoiding spending money is not your goal either. Your goal is to avoid wasting effort and cash as you search for a repeatable and scalable business model.
  4. It is not the first version of your product, that all your potential customers should want. Do you remember the Earlyvangelists?

In conclusion, MVP is hard, like prioritization – if it’s easy, it usually means that you are doing something wrong.

Retrospective from the movies

All the scrum ceremonies are designed to implement most of Agile values and principles. However, only the retrospective ceremony is specifically mentioned as a principle in the agile manifesto.

Principle number 12: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”.

In order to keep the retrospective valuable, it requires from the facilitator (usually the scrum master) to invest time in order to prepare himself or herself for the next retro. The preparation includes observing and taking notes during the iteration, learning new activities to spark ideas and encourage participates involvement, and creativity to keep the retrospective interesting and fun.

Recently, a scrum master of a team, within one of my customers I worked with during the last 3 months, had very good, valuable, and creative retrospective. I want to share this retrospective plan with you – it might help you prepare your next retrospective.

Some background: the team is within the “norming”stage. It has begun to be effective, and focusing on cooperation.

The scrum master shared with me that he feels that on one story the team preforms like in the movie “The Avengers”-  the team is collaborating together, and like a super heroes, they are getting the work done. However, on another story he feels the team performs like in the movie “The never-ending story” – it is being dragged from one iteration to another. This is how we come to the idea of retrospective from the movies.

This retrospective has 3 main goals – Find out:

  • What is done well in the “The Avengers” stories?
  • What is done poorly in the “The never-ending story”?
  • What will be done differently in the next iteration?

Opening (4 mins): Reminder – The wrong way of doing a retrospective

The facilitator welcomed the people in the room and shared the agenda with the time boxing for the meeting. Then he showed them the following movie, as a reminder of what should not happen in retrospective. Now, after everyone lough and forgot about their work they left behind, we can continue with the rest of the meeting. The wrong way to do agile retrospective

Gather data (15 mins) – Mix & Match (Stories & Movies)

The facilitator showed the team two lists: one of the stories they have worked on during the iteration, the other list is about movies. Then he asked the team to decide for each story which movie describes it the best. In the picture below you can see the results (in order to maintain secrecy – I changed the names of the stories).

From the picture you can understand how the team felt in each story. For example:

  • Story 1, was the fastest story ever, and felt like the shortest movie ever.
  • Story 2, which  was estimated at 21 story points, started as the series “X-files”, the uncertainty was huge, however, as the iteration progress, more and more team members joined this task, and they work together as an “A team”.
  • Story 3, it included support for customers, and hence, felt like survival, jump from one issue to another issue, and overall firefighting. They chose the Israeli version of Survival (the reality show).
  • Story 4 is managed only by one team member like in the movie “Waterworld” which was a one man show.
  • Story 6 & 7 – felt like the movie “Lord of Rings”, it started as a very interesting story, but in the middle it became boring.

Generate insights (5 min)

Following the mix & match discussion, the facilitator requested to perform a dot voting to determine what were the most interesting stories to discuss and generate action items for the next iteration – 2 stories were selected.

Decide what to do (15 mins) – Pair discussion

The facilitator gave each pair a memo note and a Sharpie pen, and asked them to discuss and write down action items either to keep doing in order to have more stories that feels like “The Avengers” or either action item to start / stop doing in order prevent from from stories to become “The never-ending story”. Then all the memo notes were displayed on the white board. The team were asked to do silent prioritization to the list, and the 2 action items with the highest priority were selected.
For those not familiar with silent prioritization (the same practice can be used for grouping and sorting): each team member in his turn can move one memo note to put on the priority list or to switch between two notes inside the prioritize list. The process continues till all team members agrees with the outcome. Why is it called silent prioritizing? Because during the process, nobody is allowed to speak 🙂

Closing (10 mins) – Review and grade past retrospective action items

To wrap up and close the meeting, The facilitator showed the team a table with all the generated action items from the past two months, and the team graded each item based on how it was productive and accomplished (maybe he will use it as data for the next retrospective).

This is just one idea for a retrospective. In our resource page “Reading list for scrum masters” you can find more useful information and links to other ideas for the retrospective.

Good Luck!

Image by Igor Ovsyannykov from Pixabay 

I am 50% scrum master 50% team leader – how to cope with that?

The most frequent question I run into is “Being a scrum master requires so much,  how would I have time to also stay part of the team and develop?” or in other words “I am 50% scrum master and 50% team leader – how do I cope with that?” The answer for both questions is you probably won’t.

Lately your VP R&D has noticed that something isn’t working.  Teams’  productivity and moral are low and product delivery is always late. Searching for a solution, he or she heard of the marvellous, universal remedy for failing software development projects called Agile,  and decides to implement it in Scrum flavour . Soon after, teams are transferred from being Component Teams to Feature Teams, and in addition, team leaders “lose” their title as managers and automatically are known to be Scrum Masters. In order to succeed in this transformation, the VP R&D even hires an Agile Consultant to help facilitate this recent change.

This agile coach mentors the scrum masters and explains their additional role and responsibilities. The following are only few of the issues scrum masters have to figure out throughout their workday:

  • Are we delivering working software frequently and fast enough?
  • Is the definition of “done” being followed?
  • Are the team members motivated?
  • Is the sprint backlog for the next sprint ready?
  • What is the team’s velocity?
  • Are we coming up with meaningful ideas for improvement in retrospective?
  • Do we review past retrospective action items?
  • Are the user stories for the next iteration ready?

and so on…

This is the point the scrum master turns to me, the Agile Coach, and says: “Ahhhhhhhh!!! What should I do? I do not have time for everything…” and then I smile, knowing that this is the stage scrum masters have to decide on a path – either to be a Technical Lead or a Scrum Master. There is not a right or wrong answer here. It completely depends on the person and what they are passionate about. However, being a scrum master is indeed 100%, full-time job.

Based on The Scrum Guide by K. Schwaber, I suggest the scrum master to experiment. Find what they are more passionate about. Is their tendency towards nurturing people and helping them reach new levels of self-development? Or is it toward programming and technology?

“Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk.“ [The Scrum Guide\ K.Schwaber and J.Sutherland]

In the next iteration try to be 100% scrum master and coach someone to be the technical lead instead of you. At the end of the iteration ask yourself how did it feel? If it felt like: “Well, that was fun! I want more of this, please”, I guess you know what path you should choose. If it felt horrible, something in the lines of: “I miss my IDE and can’t wait to code again”, maybe you should think if you want to hand the scrum master role to someone else – which will make you a great tech lead  🙂

I’m not saying that someone can’t be both…

maybe you are one of the chosen few.