Lean Mastery Collection

by Jeffrey Ries

  Being Empathic: Being Empathic involves deeply connecting with the emotions of the other individual without judgement and critique. It is an essential behavior of Servant-Leaders. Empathy starts with listening. Genuinely being present at the moment with somebody and listening with your whole self helps to understand the other person's situation. Here the aim is to slow down and listen with the intent to understand the meaning behind the words, the meaning of what is being felt, and what is not being said. Empathy connects two people by heart. Connecting with someone by heart is much more powerful than connecting only through the brain.

  For Scrum Masters who are not naturally empathic (count me in with you), being aware of and caring about others' emotions is the starting point of developing empathy. Empathically listening to what your team members say and acknowledging what you sense + hear.

  Such as:

  Elena, you seem to be worried. How can I help?

  David, I hear you are concerned about Matt's behavior. What would you like to happen?

  When you lend someone your empathic ears, they get it. They feel safe and comfortable to share even more. Scrum Master through Empathy builds relationships, heals the team members, earns trust and gains influence.

  Being Ethical: The moral component of the Scrum Masters must be strong. Being ethical relates to the way in which a servant-leader makes choices, disciplines himself or herself and chooses the right thing to do in the service of the team. The Scrum Master may also encourage the team to self-reflect and establish high standards of moral and ethical behavior.

  The team members constantly observe the moral basis of the servant-leader's actions and organizational goals and relate to them. If you as a Scrum Master have ingrained integrity and professionalism in yourself, it'll be possible to bring it to the team.

  Often times, the Scrum Master may realize that the team needs to mature and they must be empowered, educated to handle their own meetings, hold each other accountable, collaborate with users and PO and deliver value. And if the time comes when the Scrum Master may not be providing the best value for the team and hence should decide to either step down from that role or move on.

  Chapter 6: Making the Scrum Transition

  While there are any number of reasons, that have already been discussed, that could be the turning point when it comes to your decision to transition your team to the Scrum framework, it is important to keep in mind that it’s not without its share of difficulties as well. This chapter will look at many of the most common difficulties often associated with the transition and discuss the easiest ways to avoid them.

  Team members resisting change: When it comes to the challenges that are often going to be faced when making a Scrum transition, perhaps the most frustrating for a future Scrum master is the covert, overt, passive and active resistance that you will likely face from the team. While the best way to deal with this resistance is likely going to vary from team to team, it is important to know what to look for so you can nip it in the bud as quickly as possible.

  For starters, active resistance is the easiest to spot as it is often limited to a handful of jaded and grumpy individuals who don’t like anything that gets in the way of how they do things. However, if this issue is not dealt with on a one on one, personal, level then these agitators could generate a galvanizing message that could spread to other team members until there is an active block to prevent the change from moving forward.

  This will generally go hand in hand with overt resistance in which those who are against the change are actively bad mouthing the process and trying to talk even more team members out of participating. About the only good thing when it comes to overt resistance is the fact that it is easy to determine who is doing what so that you can get to the root of the problem as well. When you do deal with these individuals it is important to do it in such a way that you turn foes into friends as opposed to doing something that could further damage morale.

  Unfortunately, overt resistance is not nearly as common as passive resistance which is far more difficult to pin down, and far more harmful to the cause as a result. While they may learn what to do, they will only ever do the bare amount of testing that they really need to do in order to get by without embracing the process to the extent that the process as a whole is likely to actually improve. This then leads to an even greater issue as it can mean errors aren’t caught and other team members have to waste time covering for the person who resists.

  Perhaps the most challenging part of dealing with resistance, however, is that it might be a subconscious response that occurs in a team member who appears to have completely bought into the process at first glance. Remember, just because a team member might know that Scrum is the right thing to do doesn’t mean that it is the easiest thing to do, which is where the mental disconnect might come into play.

  In order to break through this mental disconnect, the goal should be to create the sort of feeling within the organization that this type of change is inevitable. If team members understand that Scrum is already a done deal then they will be more likely to spend time fighting it and more time learning how to make the change as easy to handle as possible.

  Motivation is another key factor in this instance as it is important to create a sense of urgency in the transition as well. Selling Scrum as a way of helping the company which is struggling, whether this is actually the case or not, can be an effective means of quelling doubt very quickly.

  Misunderstanding of the process: As the Scrum process is so very different from many of its alternatives, it is extremely easy for team members to become confused, despite their best intentions. In fact, it is quite common for team members to assume they understand Scrum only to find out that they are actually mixing up a host of different, similar, processes.

  In order to help get them in the right mindset, the first thing the team needs to understand is that what is occurring amounts to a true culture change for the company that will alter how every member of the team spends at least a portion of their day. One of the most common misunderstandings that are sure to arise is the idea of deadlines as opposed to estimates, which are very different things and can take some getting used to. It is important to keep in mind that true reeducation involves learning to think of production as a process which means learning to think in increments and manage expectations differently as a result.

  Meetings: Depending on how the workplace was previously broken down, getting used to the idea of a cross-functional team where everyone understands the project can be quite a lot to swallow. If a strict policy on meetings isn’t implemented early then you will find that people still attend far too many meetings each day and the team’s productivity suffers as a result.

  In order to properly address these issues, it is important that the team does a full transition to Scrum all at once as trying to go slowly will only further complicate the issue. At the same time, however, it is important to understand that the team will likely need some time to get comfortable with the lack of control from the top down and you will need to provide support during this time as well.

  Intimidation factor: When teams start managing their own work, it means that each member will naturally have much more responsibility when it comes to decision making, prioritizing and scheduling which can feel like a lot of extra pressure. To counteract this fear, you need to make it clear that nearly all of these decisions are going to be made by the team as a whole. Another way to make this part of the process seem more manageable is to start with smaller teams right off the bat. This will keep the individual number of moving pieces quite low which, will, in turn, make the entire process seem less intimidating right from the start. If you have a larger team and you are starting off with smaller teams to make the process more manageable then it is important to also ensure that they always remain as cross-functional as possible.

  Chapter 7: Tips for Success

  Make a Point of Not Planning Up Front: Many teams, especially when they are first getting starte
d with Scrum, still feel the need to do some type of planning before they get started. This can, in turn, lead to what is known as analysis paralysis. This occurs when the planning stage of any given project will often grind progress on that goal to a halt as buy-in is obtained from several different sources over the course of days, or even weeks. Don’t forget, Scrum was designed to be an adaptable framework for inspection, which means that by its very nature it is antithetical to have several team members sitting around waiting for a single individual to finish preparing so they can get to work.

  It is important to remember that in order for Scrum to be used correctly, users need to value the act of creation and, as such, the potential for failure inherent therein, not just the documentation of the process. It also values the individual bonds that ensure individuals work well together as opposed to blindly following a set group of rules. This means that while there is no harm in a certain individual from doing some early legwork on a project before bringing in the whole team, the point that this starts to be a detriment is where waiting for this one person starts keeping a larger number of individuals from generating any real type of value for a prolonged period of time.

  While finding the right mixture of pre-production and production can be difficult at first as you don’t have a clear idea of what exactly it is you are looking for from your team, it will get easier to pick out with practice. A good rule of thumb is that if it takes you more than two days to fully prepare for the start of a new project, then your team might be suffering from analysis paralysis.

  Rather than taking the time to plan everything out up front, teams can instead simply get started and use the opportunities to provide feedback that is presented in the time allotted for Sprint Review to adjust workflow as needed. This can be even extended to the creation of the Product Backlog. What’s more, things could even go so far as for the Product Owner to emerge empirically from the available stock of stakeholders instead of being arbitrarily assigned.

  While you and your team may initially find that starting a sprint without first completing a product backlog can be difficult, it is nevertheless, completely possible assuming of course that the team already has at least a general idea of what is required in the business in question and a project or project charter to work from. Using this information, your team should be able to, at the very least, come up with a realistic idea of what their first Sprint should consist of prior to getting started. Remember, the key words here are getting started. The goal during this initial Sprint is to be able to come up with something that can be demoed, and possible even shipped.

  While sometimes this will result in things that are completely wrong or otherwise not shippable, the point isn’t to get everything right straight out of the gate but to instead get everyone working through the Inspect and Adapt cycle as quickly as they can. This, in turn, will require actual stakeholders to attend the demo at the end of the initial Sprint in order for you to determine how successful it actually is.

  Don’t Worry About Advanced Tools: It is common for new teams to put off starting the Sprint process while they look through the myriad of different types of tools that are available to help them make using Scrum as simple and easy as possible. While there is nothing wrong with looking into finding a good Scrum assistance tool, it is important to wait to do so until you have a clear idea of just what facets of the Scrum process that you need electronic help with.

  The impetus to do so is obvious, especially in teams that already work for technology companies. After all, why wouldn’t you use technology to solve this problem as well as all of your others? In reality, however, Scrum electronic tools can often be more difficult to work with then their more analog equivalents. This occurs for several different reasons that can generally be broken into three different categories. First, they actually make it more difficult to freely share knowledge. Second, they actually can make the information that is shared through them successfully less clear while at the same time they make the information that is shared available more slowly to interested parties.

  Looking into fancy tools this early in the process is akin to putting the cart before the horse, it is more important to get started at all then to get started in the perfect way with the perfect tools. Being extremely particular about a specific tool set is an easy way to put off starting to use the Scrum system while still feeling productive about doing so. Don’t let yourself fall into this trap, get started with what you have available and work on improving from there.

  When first getting started using the Scrum system, you should find that all of your tracking needs are easily met with a simple pen and paper tracking system. This will let you get started quickly and easily and get into your first Sprint without first ensuring that everything is as absolutely perfect as possible. Additionally, most of the time you will find that the simplest and most effective way of reliably improving communication within your team is by simply ensuring that everyone who is working on a given project is physically located near one another.

  Additionally, you are going to want to ensure that the space has plenty of whiteboards or other writing spaces and that everyone is facing the center as opposed to being segregated off into their own little spaces. Finally, you are going to want to ensure that the group is separated from the rest of the organization so they feel as though they have a bit of privacy.

  Keep your Product Owner Involved: A common problem that many Sprints face over time is a Product Owner who is energized and eager to contribute at the start of the Sprint, but who then falls off when the time comes to actually turn ideas into reality. A Product Owner is just as much a part of a Sprint team as anyone else which means they should ideally be present at every Daily Scrum as well as during the Sprint Planning Meeting and the eventual Sprint Retrospective and Review. The Product Owner will also need to be available during work hours to provide input as needed to team members with questions. Essentially, when the Product Owner is not actively dealing with shareholders they should be involved in the Sprint Process.

  Remember, the Scrum Team model was created with the express purpose of being as beneficial to productivity, creativity and flexibility as possible, but it can only do this when the Product Owner is as committed to respect, openness, focus, courage and commitment as the rest of the team. The only exception to this is if your team follows the strictest, most recent interpretation of Scrum which limits the Daily Scrum to the development team exclusively. There is still the option for others to observe the meeting, however, and this should include both the Product Owner as well as the Scrum Master.

  While early on in your team’s experience with the Sprint, it may be difficult to determine if your Product Owner is putting in enough time and effort, you will be able to tell if they added enough input, however, by how they respond to your Sprint Review. If during the Review, the Product Owner uses the time to provide feedback on the results then you will know they weren’t involved in the process enough. The sign of an involved Product Owner is when they are leading the discussion with stakeholders, users or customers during the Sprint Review instead.

  While the Product Owner needs to be as available as possible, there are numerous different scenarios where they may need to legitimately be absent from the process for a prolonged period of time. First and foremost, is when they are working with shareholders, though these types of meetings should be scheduled separately from Sprint based commitments in most cases. Regardless, it is going to be best for the Product Owner to leave a surrogate in place to provide their input for them based on the information that is already readily available.

  Don’t Use Stretch Goals: Stretch goals have long been used in many settings as a way of planning out additional goals that can be reached assuming certain conditions are met. They are antithetical to the Sprint methodology, however, and should never be used while on a Sprint for any reason.

  There are two different types of stretch goals that can try and creep into your Sprints, it is important that you are
aware of both of them and where they come from so that the Scrum Master can ensure they stay away from the positive team-centric attitude that the Sprint is cultivating. The worst type of stretch goal that can often appear to ruin group cohesiveness is the stretch goal that is suggested by someone from outside of the team.

  Stretch goals that include a predetermined scope and deadline are the most difficult for Scrum teams to work through simply because it requires the team to start with a deadline and then work backwards to determine how to complete it, practically the opposite of how things normally go. What’s worse, when objections are raised, they are typically met with either a reaffirmation to “get it done” or by simply adding more people to the team which does nothing to improve the state of things if the new individuals don’t actually know anything about Scrum.

  Otherwise, stretch goals have been known to pop up from time to time when members of the team try and determine what the Development Team is capable of, despite the Development Team’s objections. It is important to keep in mind that the Development Team is going to have the best idea of what it can accomplish given various external limitations and wasting time disagreeing with them is, quite simply, time that can be better spent elsewhere.

  The solution to this common issue is exceedingly simple, let the team determine the amount of work it can realistically get done within the confines of the Sprint. This doesn’t mean that the first assessment of what is going to be done is going to be set in stone, but it does mean that no member of the team should ever feel pressured to commit to more work than they feel they can realistically complete. Forcing a team to commit to stretch goals is likely to build distrust among team members if the stretch goals are not met successfully. Distrust can lead to resentment and both will ultimately result in lower quality work being produced time and again. After all, if the stretch goal failed then there must ultimately be a reason why do your team a favor and avoid stretch goals and the witch hunts that they will always ultimately engender.