Blog Archives

Scrum Mastery
Everyday Life Kanban

The car manufacturer Toyota developed Kanban as a methodology to help teams work on their assembly line. Currently, it is popular with engineering teams working within an Agile environment. Typically, the work being done in Kanban is easily visible and communicated on a Kanban Board. Kanban also helps keep work being done in a reasonable state. A simple Kanban Board has three columns; To-Do, Doing, and Done. As the work is processed it goes through each column state. Throughout the time working on delivering functionality, the work can be brought to a halt to fix an issue. Kanban does not allow for defects and issues to move forward.


Kanban can be present in everyday life. Sometimes you may not even know it is happening. Even if you are not there are simple ways to introduce it. When most people think of Kanban they think of many engineers working together off of a shared backlog. To an individual everyday life, this means you may be playing multiple roles.


Installing a Closet

I recently installed a closet space in my bedroom. I took a look at the space and realized that this was going to be a project that spanned multiple days. So, I put my knowledge of Kanban to work.


Established a Backlog

I started by defining my backlog. I needed to clean the space, move the clothes to a temporary location, measure my area, and the list goes on. After a while, I had my “complete-ish” backlog. At the end of each day, I reviewed the backlog to see what remained and what was missing.


Once I had established the backlog I broke out the post-it notes. I wrote down my “tasks” and put them up on the wall in priority order. By limiting the work in progress I avoided burnout and completed something tangible each day.


Getting to Work

The project began. Each night, I picked out tasks. Then, I started working. Each day I widdled down the backlog task by task. In the spirit of Kanban, I was able to stop my work at a moment’s notice to adjust.


After a few days, I had moved almost all my tasks to “done” and a complete closet. There were a few leftover stories that I found I didn’t need. I thought I needed to go buy a piece of wood to act as a shelf. It turns out, I already had one.


Retrospective

With my project complete I could help but have a mini retrospective. I thought to myself, how would I do this differently? How could I apply this to other aspects of life? As it turns out there are many ways to leverage this. Looking back on a project or period of work, you can decide on what works best for you and refine your approach.


Daily routine for an individual or family


Routines

There are certain acts in everyday life that we repeat over and over again. These acts could be things like taking your vitamins, eating certain meals, or taking a walk with your dog.


With these in mind, you can make a Kanban board. Put these activities on note cards and stick them in your to-do column. From there pick them off one by one when you need to do them. Finally, if you get to the end of your day and there are still cards, have a mini retro and decide how to approach them differently.


Chore Lists

Chore lists are another great example. You and your family complete certain chores that need to get done throughout the week. Set the expectation that family members each pick up a task to start with. Next, when it is time to do the task they move the card to “Doing” and begin. Stories move to done once the family member has completed them. Then, the family member picks a new task.


If you are doing this with your family, you might establish a few rules along the way. You may say “Do not pick up only easy tasks” or “Try to complete at least one task a day”. Along the way, you can change your approach to better work with everyone.


In the end, the only thing that limits you is your creativity and imagination. Do you have other examples? Post them in the comments below.


Further Reading

Backlog Refinement a Conveyor Belt

What is Your Agile Sound

Scrum Master: The Basketball Coach

by Philip Coler

scrum master the basketball coach
Scrum Mastery
Scrum Master: The Basketball Coach

Imagine this, you are watching your favorite basketball team in the championship game. There is 1 second left on the clock. Your team is down by 2 points and has the ball. They move towards their basket and your favorite player takes a 3-point shot. IT GOES IN!!! Your team has won and the coach has Gatorade poured on them.

After the game the team celebrates and the coach gives an interview. They say that the team put forth a great effort and truly deserved the win. They take no credit for the success. The coach does not brag about how their coaching made the team what it is. They point to the team and say “That is who you should be celebrating”.

Now, I am a fan of the Minnesota Timberwolves basketball team so the above scenario has not really played out. I recently read an article (found here) on their head coach Chris Finch though. He has been with the team for roughly two seasons. In that time the team has had its ups and downs. To the fan base, the downs are reason to call for his firing.

You may be wondering why I am bringing up a professional basketball coach. In the article in question, the columnist took an interesting perspective on how people judge a coach’s effectiveness. I found there to be many parallels between being the coach of a basketball team and being a Scrum Master.

 

Parallel 1: Calls plays but is not the one to run them

In a perfect situation, the coach calls a play, the team executes, and they score. As with Agile, there are many different nuances that a basketball play has to take into account. What is the defense running? Which players are on the floor? How much time is left in the game? The list goes on.

Even with all that taken into account, the coach is not on the court passing the ball or taking the shot. If the defense decides to switch things up or does something unexpected, the team needs to adapt. This goes for the Scrum Master and engineers as well. The Scrum Master can coach the team to their heart’s content but the engineering team executes the play. If a sprint does not go according to plan, the Scrum Master can help remove impediments, but in the end, the team needs to be able to adapt.

 

Parallel 2: Does not construct the team but works to bring out their strengths

In the example with coach Finch, he inherited a team that did not have anyone to protect the basket at close range. He does not make the final call on who makes the team either. Rather than roll over and see the season go down the drain, he worked with what he had and found their strengths. He started coaching the team to play a faster defensive style to make up for the lack of rim protection.

Like a coach, the Scrum Master needs to help the team adapt to different situations. If a situation comes up that the team is ill-equipped to handle the Scrum Master can help the team adapt. For instance, let us say that during a sprint a bug comes to the team that is high severity. This team is full of newer engineers and the most senior engineer has their hands full. This bug will take the effort of multiple engineers. The team does not want to say “no”. The Scrum Master helps the team determine the importance of the issue and works with the Product Owner to determine if this is worth interrupting the sprint. The Scrum Master helps the team adapt.

 

Parallel 3: Has a style of “play” they like to run (not always a great fit for the team)

Most, if not all, professional basketball coaches have their own style of play they like to implement with a team. Truly great coaches can adapt and change their style based on different scenarios. Scrum Masters must be able to do the same. Each team a Scrum Master works with is different. Even if they only work with one team, there is a chance that the team does not remain the same over time. A great Scrum Master can change their style.

 

Parallel 4: If the team does well, the team looks great. If they do badly, the coach can take a big hit

As seen in the Timberwolves article, coach finch gets a lot of flack for the team’s underperforming. Remember he has been with the team for roughly 2 years. In terms of NBA teams that may be going through a rebuild (I think the Timberwolves are doing some form of rebuild), 2 years is not enough time to know if the changes made are successful.

Agile journeys take time. Picking up Scrum takes time. These are not drag-and-drop philosophies that will instantly fix your problems. Agile is a shift in mindset and behavior. Scrum, shows you the issues and you have to change them. Being quick to blame Agile and Scrum for failures can be catastrophic for a team. They may have been on the verge of turning the corner to great things but were stopped short.

 

Be patient, adapt, learn, and grow. And maybe you and your team will win the championship.

(I have no idea what an Agile or Scrum championship would be… maybe releasing a successful product?)

Additional resources:

https://conceptsandbeyond.com/product-owner-case-studies/
https://conceptsandbeyond.com/what-is-your-agile-sound/
https://conceptsandbeyond.com/utilizing-your-scrum-masters-to-the-max/

 

by Philip Coler

Agile Sound
Scrum Mastery
What is Your Agile Sound?

If you’ve ever read the Agile Manifesto you’re familiar with these four lines.

“Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan”

You are also familiar with this line.

“That is, while there is value in the items on
the right, we value the items on the left more.”

It can seem easy to interpret the manifesto as a software company. If the choice to take on a new tool will dampen the interactions of individuals then pick the individuals. Pick the software if your software is not working and your documentation is lacking. See, straight forward. Now those are limited examples.  Numerous aspects aren’t included. What industry are these examples part of?  Are the customers internal or external to the company? Is the tool essential for progress to move forward? That interpretation is also rigid.

 

Agile Audio Mixer

When listening to your favorite song, you probably never stop thinking about someone mixing the sounds. In the studio, the artist records the music and the audio mixer puts it all together into one cohesive sound. The sliders on an audio mixer are called “Channel Faders”. They allow the person editing the song to turn up or down certain sounds in the music.

The four tenants of Agile are the team’s and/or company’s faders. The rigid examples from before do not allow for adjustment. Thinking of the tenants as faders allow more flexibility with an Agile mindset.

 

Working software over comprehensive documentation

When you take into account a company’s industry, fader levels may change. Take for instance a medical device company. The “working software over comprehensive documentation” slider might lean a little more towards the documentation side in comparison to a company developing applications for a refrigerator. With a medical device, lives may be on the line. This justifies a higher level of documentation.

 

Responding to change over following a plan

Teams making tools that are under government regulation may need to adjust their “responding to change over following a plan” fader. New regulations could be going into place on a certain date and they have until then to shift their software. Once that date has passed they can readjust their fader.

 

Individuals and interactions over processes and tools

Taking a look at the “individuals and interactions over processes and tools” slider, a pandemic may cause processes and tools to take a higher priority than they usually would. Teams needed to adjust to new tools to communicate effectively while out of the office. The slider adjusts when the team can meet back together face to face.

 

Putting it All Together

One thing that is common among the images above is that the slider never goes past the middle. This ensures the “over” is still true in each tenant. Remember there is still “value in the items to the right”.

Combine the pictures to get the current state of the audio mixer. Like any song, your Agile sound will change over time. The tempo might pick up. It might get louder. There may be an impromptu guitar solo. On an Agile journey keep your sound in mind and know adjustments may need to be made from time to time.

by Philip Coler

Our stories  ·  Scrum Mastery
Story: The Sticky Teams Initiative

Back when I first started as a Scrum Master, in 2014, I was given a chance that some Scrum Masters are rarely given. I was given an opportunity to do an agile experiment. When I say “experiment” I do not mean make incremental change. I was able to take a team and try something that their managers were not exactly comfortable with. I called it The Sticky Teams Initiative.

 

Setting the stage

I was working for a medium-sized company that had recently started its Agile journey.  Quite a few concepts had been taught and were in practice. Scrum was all the rage here and so was velocity. I was working with a couple of different teams at the time One of those teams was a quality support team that would take in tickets from customers and resolve them as soon as they could based on priority and severity. I was there to help the team establish their practices and gain an understanding of Agile.

 

Note: You may have noticed two items above, velocity and working with multiple teams. I do not like leveraging velocity and feel that a Scrum Master working with too many teams is detrimental. For more read: The Scrum Master and Too Many Hats 

 

The Problem

As I worked with this team I started to notice that their throughput fluctuated quite a bit. They had been working together for some time but could never seem to settle into a groove.

So I took the stance of an observer. I watched the team closely to see their day-to-day work. I noticed something rather strange. The team never stayed consistently the same size.

Due to being a quality assurance team they were well-versed in numerous aspects of the products the company made. Typically this is a good thing. In this case, it was both good and bad.  On the good side, the team functioned well as a quality assurance team since they could take on a vast spread of work without having to go to other teams for assistance. On the bad side, the knowledge and skill the team had caused members of their team to be periodically pulled onto other teams.

 

The Experiment

Enter The Sticky Teams Initiative. I was fortunate to have a manager who knew the importance of trying new things and experimenting. I worked with them to make sure that my sticky teams initiative was accepted not only by the engineers taking part but by the engineering manager who did not see the benefits. We worked out that the engineering team would be trying this out for 3 months. If we were unable to show positive results, they would go back to functioning as they had before the experiment.

To begin the experiment I worked with the team to establish that no one was to leave the team to work on another team. There were circumstances where a team member may need to move to another team. Those circumstances needed to be a bit extreme. Once we established that, I made it known that should any requests come in that would involve a team member leaving that I would be happy to be the one to review the request. I would be “the bad guy” who says no.

The experiment carried on for 3 months. Throughout that period the team continued to take on work as they had before. They would also run bi-weekly retrospectives to see what they could improve upon. (These retrospectives were a part of their routine before the experiment) While all this was happening I was collecting data.

 

The Results

After the 3 months were done there was only one thing left to do. Pull all the data together and present my findings. Sure enough, the team showed steady improvement in comparison to the time before the agile experiment. Prior to the 4th sprint (when the experiment began), the team’s average velocity was never what they actually got done. Either they would get more done or less done. It always fluctuated from above to below.

After the start of the agile experiment, their velocity normalized and even started to level out. That may not seem very exciting but back in 2014 this was very exciting for the team and management to see. They felt more confident in their ability to deliver and saw that they could steadily improve over time.

From here the team was able to stay relatively “sticky” throughout my time with them. Occasionally a team member would be promoted or would switch to a different team prominently. These are events that are difficult to avoid. But with their newfound confidence, they took each change in stride.

by Philip Coler

Scrum Mastery
Psychological Safety and The Scrum Master

Let us start off with a quick scenario around Psychological Safety.

New team member: "But why don't we use X as our new tool?"
Senior team member: *scoffs* "Why would you ask that? You should know that X won't mesh well with our current system."

In the above scenario, the new team member has asked a question. The senior team member audibly scoffs and questions why they would ask that question. By scoffing out loud and questioning them in return, the senior team member has started creating a hostile environment. This environment is not Psychologically Safe.

Psychological Safety is a term that you may have heard floating around. More and more companies are trying to make their environments Psychologically Safe. So what does that mean? Furthermore, what does that mean for a Scrum Master?

 

What is Psychological Safety?

In a nutshell, Psychological Safety means a person or persons feels safe from being reprimanded or teased for speaking up, asking questions, sharing ideas, or asking for help. Members of the team feel like they can ask any question without the question being deemed “stupid” or “silly” in a Psychologically Safe environment. Another characteristic can be people do not have to worry about being reprimanded for speaking up or disagreeing with someone else.

 

What does this mean for a Scrum Master?

For a Scrum Master, this means actively pursuing Psychological Safety. Reading this post alone will not make you an expert in all things related to Psychological Safety. You will need to foster a psychologically safe environment for your team. It will be necessary to get everyone on board. From engineers to managers of the team, they all need to be on board for the pursuit of Psychological Safety.

 

How can a Scrum Master foster a Psychologically Safe environment?

 

Lead by example – be an advocate for psychological safety

If Psychological Safety is not a topic that your team is familiar with, help them become familiar. You will find yourself in a “Teaching Stance” most of the time when educating your team. Once you have taught your team about you can mention that this is a psychologically safe environment when meetings begin. If a team member says “I have a silly question” or you see them cower from asking, help them out. You can say things like “there are no silly questions” or if they are shying away from asking you can ask them for their opinion on the topic at hand.

 

Leverage retrospectives to help find the pain points

This one has a caveat. For a retrospective to help the retrospective itself needs to be Psychologically Safe. When setting the stage be sure to mention that it is a space for expressing concerns and sharing thoughts. Team members may need reminding that your retrospectives are a safe space.

A retrospective can be tough as it can sometimes be a place where hot-button topics can get brought up. Be sure you are ready to intervene if necessary. Leverage your powerful questions to look for clarity or defuse the situation.

 

Watch out for issues

Retrospectives are not the only place where Psychological Safety is necessary. It can be harder to spot in other spaces. For instance, a standup may seem like a place where it may not be common. But using a keen eye you may see body language that suggests otherwise. Eye rolling when someone asks a question could be a sign that someone does not have Psychological Safety on their mind. It may seem like a minor gesture but doing so to a junior developer asking a simple question can be quite exasperating.

 

This is not a comprehensive list of ways a Scrum Master can help a team with Psychological Safety. If anything, this can be a launching point in a Scrum Master’s journey to create safe environments for their teams.

Lastly remember, not all of the responsibility falls on the Scrum Master alone. Gaining and maintaining a Psychologically Safe environment takes work from everyone.

by Philip Coler

scrum master does and donts
Scrum Mastery
Scrum Master Dos and Don’ts

As a Scrum Master, looking outward and seeing where people need work can be easy. You might find yourself helping the Product Owner better manage the backlog. The team may need your help sticking to goals. Looking outward can be easy. Looking inward, on the other hand, can be quite tricky. Inspecting and adapting do not only apply to the team and Product Owner. It applies to the Scrum Master as well. As a Scrum Master, you owe it to your team, your Product Owner, and yourself to be the best Scrum Master you can be. Here are a few Scrum Master dos and don’ts

 

Do

 

Keep an open mind

When looking at issues focusing on your own ideas too much can be problematic. You may have ideas on exactly how to solve a problem. But should you be the one solving the problem? When it comes to being a Scrum Master, you need to keep an open mind. Work with the team to come up with strategies to solve the issues. You are a guide for the team. Help guide them to a solution by listening to their ideas and working with them to bring them to life.

 

Learn constantly

There is always time to learn something new. Scrum Masters need to iterate themselves like they would iterate a team. By learning new things the Scrum Master betters themselves. That self-improvement benefits the team. Learning takes many forms and does not always need to be a massive undertaking. It could be as simple as learning a new retrospective approach or finding new ways of asking questions. Find something that interests you and pursue it.

 

Get comfortable being uncomfortable

It may feel strange to say “get comfortable being uncomfortable” but that is only the beginning. Conversations in retrospectives might not go where you expect. Get used to it. Daily Scrums might take longer because a senior engineer likes to talk. Though you may not be comfortable doing it, be ready to talk to that engineer. There are many facets to being a Scrum Master which means going into the unknown more than you might think.

 

Learn about what the team is working on

When starting out with a team it is easy to get lost in all the jargon. There may be conversations around topics you have never heard of. Take the time to ask questions. Not only will you learn something new, but you will also show your team you are invested in what they do.

 

Don’t

 

Limit yourself to working with only the team

Scrum Masters all over may find themselves only working at the team level. Doing so limits the potential of the Scrum Master. Sure, the team and Product Owner will need help with things but the organization as a whole has a need as well. By working outside the team you can learn new things and grow as a Scrum Master.

 

Dictate exactly how to do things

Telling the team exactly how to do things can be a hard habit to break. You are the one with the training and the job title, so why should you not tell them exactly how to do things? If you find yourself doing this, stop. The team has a stake in the Agile journey and Scrum. If you dictate how they should be doing things they no longer feel any ownership of what is going on. By taking into account their opinions on how things should work they are more engaged and committed.

 

Sit and quote the Scrum Guide

If someone starting a sentence with “well actually…” gets on your nerves then you know why quoting the Scrum Guide is a don’t. Teams are on a journey that they lead. By quoting the Scrum Guide to a team you severely limit the creativity of the team. If you insist on doing things by the book you will lose out on creative solutions to problems you had not thought of.

 

Wait for issues to come to you.

You need to put in the effort to find things that may be causing the team pain. You can wait for a retrospective for issues to come up, You can wait until a team member comes to you with a problem. Or you can take a look for yourself. Many issues go unnoticed because the team has always worked this way. They may not know something needs to change. You cannot expect a team member to notice all the things that need changing and do their job developing the product.

 

This is not a comprehensive list of Scrum Master dos and don’ts. If you have more, comment below.

 

by Philip Coler

Backlog refinement Conveyer Belt
Product Management  ·  Scrum Mastery
Backlog Refinement a Conveyor Belt

If you have worked with Agile for a while, you probably heard of backlog refinement. For those of you new to this topic, in a nutshell, backlog refinement is a session dedicated to cleaning up the Product Backlog. Something to note is that the Product Backlog is different from the Sprint Backlog. The Product Backlog is the overarching backlog while the Sprint Backlog is for the Sprint increment. This is an everyday activity though it is not explicitly mentioned in the Scrum Guide.

A backlog refinement session is not the only time a backlog can be refined.  Nor is it a one-shot meeting. It is an ongoing activity. Some teams dedicate time to working through the backlog with a refinement session while others may choose to take a more organic approach. So when you think of backlog refinement, do not jump right to a meeting.

 

Backlog Refinement Value

The act of backlog refinement does not mean only the Product Owner/Manager refines the backlog. Backlog refinement is an activity for even the team working on the product. Refinement is not about telling teams what to do but showing them the direction in which the product needs to be taken.

By keeping teams involved in the process of refinement they gain a better understanding. They are able to communicate directly with the Product Owner and ask questions they may have. This is also an opportunity for the Product Owner to ask their own questions to the team.  Having a refined backlog helps clear things up before work is done. If the backlog were not refined, teams may work on something only to find out they were going in the wrong direction.

Keeping a backlog in clean working order keeps things running smoothly.

 

Backlog Refinement as a conveyor belt

One way to look at backlog refinement is to compare it to a conveyor belt. Some people think that the backlog needs to be 100% refined all the time. That approach causes teams to be less flexible and able to change should an issue arise.

By looking at refinement like a conveyor belt at any point in time the conveyor belt can be stopped and adjusted. If a feature is suddenly cut, it can easily be removed. If plans change the backlog can change.

As stories move down the conveyor belt they become more refined. A story at the very start might be very rudimentary and lack details. That is okay. As it works its way down the belt it becomes more and more refined through backlog refinement sessions and conversations around the story. The end of the conveyor belt is when the story is picked up. It has been refined to a point where a team feels comfortable picking it up and doing the work.

 

Pitfalls

Refining a backlog is not without its issues. Some common pitfalls are refining too much, leaving out essential voices, not removing items, and only refining at a designated time. This list could be longer.

 

Refining too much

If a team refines the backlog too much they could end up with wasted effort. Let us say that the team has a backlog with 100 completely refined stories at the beginning of the month. Some of these stories do not need to be done until near the end of the month. That sounds great. Midway through the month, a decision is made to change a feature. The feature’s stories had been refined significantly earlier. The team now has wasted effort from the beginning of the month. They refined a story that was farther away that ended up changing.

 

Exclusion

Too often a team can feel like they know enough information about a feature that they do not need to include the Product Owner. They have excuses like “the Product Owner does not need to attend another meeting” or “these are technical stories that they will have no input on”. By doing this the Product Owner misses on out insight into the inner workings of the product.

 

Backlog size out of control

It may be hard to believe but there are some pretty large product backlogs out there. That was a little sarcasm. Backlogs have been known to balloon out of control. Teams and/or Product Owners do not want to delete a story because they “might need it later”. They may leave stories in the product backlog because they simply forgot they were there. By letting the backlog grow too much they potentially can bury stories that need to be done. Finding stories becomes challenging. Prioritizing work becomes an issue because the backlog became so large.

 

Refining only at a designated time

Lastly, product refinement only at a given time can cause a team to forget exactly why some stories were needed. They can also forget important details that were discussed at the moment. By putting refinement off until the designated session they lose out on value.

 

In conclusion, product backlog refinement is a necessary action. Notice how it is an action and not an event. Calling it an event implies that it is a scheduled occurrence when in reality it is an ongoing action. The value it provides to the team is immense. But it is not without its pitfalls and traps.

by Philip Coler

A "Quick" Guide to Retrospectives
Scrum Mastery
“Quick” Tips for Retrospectives

If you have worked in the realm of software you have probably heard of retrospectives. Retrospectives are a way for teams to look back on their work and brainstorm ways to improve in the future. Retrospectives can range from a positive experience for all those involved to being downright boring. Below are a few tips for maximizing the value of your retrospectives.

 

There is no perfect retrospective

There are many ideas on how to run the “perfect” retrospective. Some people say you need to start off with an icebreaker. Then you should follow it up with a deep dive to generate ideas of what to talk about. After that, talk about those ideas and come up with changes. Finally, close out the retro by determining what needs to be accomplished next. This may sound like a lot. That is because it is. The perfect retrospective for one team may not be the ideal retrospective for another.

Figuring out what works best for your team takes time. One thing worth trying is doing a short retrospective on your retrospective.  As your team what they liked about it. Then ask them what they would change. Take those thoughts into consideration for the next retrospective. By doing this you will be able to zero in on the sweet spot for your team’s retrospectives.

 

You don’t need to come up with every idea

Each week you may find yourself struggling to think of how to structure your retrospective. You want to keep it interesting. Doing the same thing over and over becomes boring and disengaging. You do not have to be a treasure trove of retrospective ideas. Take a break and leverage other Scrum Masters’ ideas. You can even find a few ideas here at Concepts and Beyond. You could try the Lean Coffee style retro.  If you are heading into the December holiday season you could try the Agile Christmas Carol. If neither of those strikes your fancy the world is your oyster. There are a million (okay maybe not that many) posts out there on different retrospective structures. Remember, Scrum Masters typically like to share their ideas. So use those ideas!

 

Retrospectives are time-boxed

Depending on how long your sprint is, the retrospective should never be longer than 3 hours. If your team is running a one-month sprint, 3 hours may be enough time to unpack everything. If you are on the other end of the spectrum and your team runs a one-week sprint, 30 minutes to 1 hour may be your sweet spot. You do not need to jam-pack a retro with all the different tools and tricks you may have in your arsenal. There is such a thing as doing too much.

Teams that have to sit through a 3-hour retro when a 1-hour retro would have done the trick, will get bored faster and faster at each retrospective. Eventually, they will find it pointless to participate or even show up. You want to find the right amount of time to get a quality retrospective done without boring the team.

 

Come out of a retro with action items

So you have a few ideas on how you want to run the retrospective and how long it will be. What else could there be? It feels good to get some of the pain points off your chest. The team might feel relieved being able to air out some dirty laundry. That is great. There is more to a retrospective. Before concluding a retrospective you need to make sure that there are action items or stories produced by the discussion.

Team members may say that they feel like they do not need to be at certain meetings. What actions can be taken to alleviate that? Does someone need to ask, “should we be in this meeting”?  Some sort of action item needs to come from the discussion. If nothing happens after the discussion the retrospective’s value plummets.

 

Different coaching stances

The four common coaching stances of a Scrum Master are Teacher, Mentor, Facilitator, and Coach. This is probably the most challenging part of a retrospective. As a Scrum Master, you need to determine what coaching stance you need to take throughout the session. At one moment you may need to be a facilitator keeping the retrospective on track. Another moment you may find yourself coaching.

Further reading on coaching stances can be found here.

 

Additional resources:

Dot Voting – A Democratic Facilitation Tool

Facilitation Techniques

Coaching with Powerful Questions

by Philip Coler

So You’ve Achieved “Peak” Scrum? a truly “mature” Scrum team is a rarity
Scrum Mastery
So You’ve Achieved “Peak” Scrum?

You’ve heard it before. “Our team doesn’t need a Scrum Master or Agile Coach. We’re a mature Scrum team.” These words are rarely a reflection of what is truly happening with the team. Too many teams feel they’ve reached the end of their Agile journey and only need to go on cruise control. That mentality is a huge red flag that the team is not truly “mature.”

 

Do you think your journey is complete?

Agile journies don’t really end. Agile journies are like trying to reach the horizon. You never truly get to the end of that journey but you learn things along the way. Teams that think Agile journies come to an end are a lot like companies that think they can coast and not innovate. As soon as they believe they’ve got it made and don’t need to grow that is when they’ve failed. Innovation and growth are essential to success.

To help move away from this mindset be sure to call out that Agile is all about inspecting and adapting. This isn’t something a team stops doing. If it feels like the team is stalling during retrospectives, encourage them to dig deep. Try leveraging retrospectives like “5 Whys” to find the root of their pain points.

 

Do you think your team has worked together so long that there is no need to grow?

The team has been together for months or maybe years. They know one another well enough that they can communicate with ease. They haven’t added a new team member in a long time. They’ve been together so long that “we have always done it this way” gets used quite a bit. Does that make them a “mature” Scrum team?

A team member goes on a month-long vacation. The team needs to adjust. A team member gets promoted to a new level that shifts them to another team. A team member gets COVID and has to be out for two weeks. The team needs to adjust. A “mature” Agile team may be able to make adjustments to these scenarios but what if your team does add a new member? The working dynamic changes yet again. You can never account for every scenario.

 

Is your team’s “maturity” really a sign of being stagnant and bored?

Nothing is attractive or interesting so you think you’ve done it all. Your daily Scrum feels like you are going through the motions. The retrospective rarely has action items coming from it. Planning has become a meeting about checking boxes. To some, it may feel that they have gotten so good at working with Scrum that it feels boring.

When a team feels like they’ve done it all sometimes that means that they haven’t done anything new. A routine that is repeated over and over gets old fast. Liven things up with a different format of retro. Or ask the team what they would like to change things up. Pick their brains. A Scrum Master is not alone when it comes to finding creative ways of working.

There are many other red flags besides the three mentioned above.

 

Testing to see how truly mature a Scrum team is (Maturity Assessment)

See if the entire team thinks that they are mature. If the team struggles to share this or doesn’t feel comfortable talking about it, then the team may need to work on psychological safety. If the team is more than happy to share their thoughts, a Maturity Assessment can be leveraged. It is easy to find out how to build your own Maturity Assessment online.

Conduct the Maturity Assessment and see where the team needs work. But what if your Maturity Assessment comes back as 100% mature? Give your team the reigns. Let them sink or float with what they’ve learned. If you as a team member or Scrum Master fear this idea, then maybe the team isn’t as mature as you thought.

In conclusion, a truly “mature” Scrum team is a rarity. The journey is never-ending and there will always be unknowns. Do not fear the unknown but embrace it. Inspect and adapt. Find new ways of doing things. Let your creative juices flow. You or your team may surprise you with what comes next.

Scrum, Product Management, and DevOps: Simplifying the jargon

The internet and social media are full of Agile, Scrum, Product Management, and DevOps jargon, including incorrect and misunderstood concepts. This could be problematic for a learner seeking knowledge. Without a course with Scrum Alliance, Scrum.org, or DevOps Institute, this knowledge is difficult to achieve.

The Concepts & Beyond blog is a free suite of articles and videos packaged in tiny chunks. You will learn or refine your knowledge and skills to help your team and organization be effective. When you want to take your knowledge further, we invite you to join us for our  Certified ScrumMaster(CSM),  Certified Scrum Product Owner (CSPO), Certified DevOps Engineering Foundations (DOEF) and Training from the Back of The Room courses across the USA and Canada.

by Philip Coler

An Agile Christmas Carol Retrospective
Scrum Mastery
An Agile Christmas Carol Retrospective

A Christmas Carol is a classic holiday story written by Charles Dickens. There are spoilers ahead for those of you who have not read it. The story’s synopsis is that Ebeneezer Scrooge, a greedy banker, is visited by three ghosts. They are the ghosts of the past, present, and future. They show Scrooge the error of his ways to help him for the better. Ultimately, he wakes the following day, changed for the better and ready to take action.

Now that sounds like the basis of a great retrospective.

Like the story of Christmas Carol, the basis of this retro is that of the past, present, and future.

 

Past

Think of something from the past sprint, month, or year that you would like to “let go” and write down…

An Agile Christmas Carol Design

This is the time to look to the past. Work with the team to dig deep. What pain points did they have? When they look back on the year, is there any particular point(s) they wish they could forget? Have them write down these points. After reading through them, take some time to think of how they can do things differently in the future. Once complete, have the team member delete/erase the card. This lethargic experience can help put the past in the past.

 

Present

Who has been naughty or nice? Write down the nice ones…

Now is the time for praise. The naughty or nice list is a classic story told about Santa Claus. He makes a list and checks it twice. He keeps track of who has been naughty or nice. Focus on the nice. Find the moments in the past sprint that made people happy. Did someone help out on a tricky issue? Was there a moment when someone brightened your day? Did another team step up to make life a little easier? Have the team write these down. Talk about how they helped. Look at the positives your team has going for them right now in the present.

 

Future

All I want for this holiday season for our team is…

In this last section, think big. What actions can the team take to better their lives? Is there help from outside the team that would be beneficial? Does the team need all new laptops? Would additional team members help? Nothing is too big. Once you have written down and reviewed these wishes, discuss what can be done. Where can you ask for help? What do you have the power to control? Determine if there are next steps to be taken. Some of the big wishes may not be attainable at this time. That does not mean the team cannot take small steps to improve things.

 

As Scrooge steps out into the morning air after his ghostly visit, he takes action to right the wrongs of his past. He does not try to do it all at once. He takes small steps. Like Scrooge, the team needs to take small steps to make a long-term difference. As with all retrospectives, you want to come out of this one with action items. You can do action items in the short term to help achieve the goals of the retrospective.

Scrum, Product Management, and DevOps: Simplifying the jargon

The internet and social media are full of Agile, Scrum, Product Management, and DevOps jargon, including incorrect and misunderstood concepts. This could be problematic for a learner seeking knowledge. Without a course with Scrum Alliance, Scrum.org, or DevOps Institute, this knowledge is difficult to achieve.

The Concepts & Beyond blog is a free suite of articles and videos packaged in tiny chunks. You will learn or refine your knowledge and skills to help your team and organization be effective. When you want to take your knowledge further, we invite you to join us for our  Certified ScrumMaster(CSM),  Certified Scrum Product Owner (CSPO), Certified DevOps Engineering Foundations (DOEF) and Training from the Back of The Room courses across the USA and Canada.

by Philip Coler

Page 1 of 2