Scrum is simple, yet I see, many teams are struggling with getting the full benefits of Scrum. I hear teams saying – “too many meetings, time-boxing is too much, we never get to rest - it is sprinting, sprinting, and sprinting.” What's even worse is that they feel awful when they don't get to finish what they plan to do for a sprint. That doesn't sounds like Scrum is working for them. Why would that be the case?
Like I said, Scrum is simple and it's almost a perfect framework for a NEW product development. It has three pillars - Transparency, Inspect & Adapt. Three pillars hold Scrum together. It has one product backlog and 4 meetings, 3 to 9 people developing ONE product within 1 to 4 weeks. Simple, right? It is so popular. Some people use it to plan for a family vacation. Although, these days, I hear people complaining about Scrum. They say it is not working for them and they think Kanban might work better for them. Really? I ask Why?
Does your team have a shared understanding of Why Scrum, Why Working Agreement, Why Sprint Goal, Why Def of Done, Why Velocity, Why Daily Standup, Why Burndown Chart, Why Transparency, Inspect & Adapt? Why having a shared understanding of all these is so crucial to a successful Scrum adoption. This in turn, helps them build awesome products.
Let's first see - Why Scrum?
Does your team have a shared understanding of Why Scrum? Why did they employ Scrum? I've seen many organizations send teams to a 2 days Scrum training and expect them to understand what Scrum is about and ask them to start using Scrum without asking them why Scrum. What can be so difficult? But it can be. If it is imposed on them, they don't really see the benefits of Scrum. They don't really see why they need to use Scrum. They feel that what they used to do worked fine. So, why do they need to change?
How can Scrum work for them if they don't know why Scrum and if they don't know whether it will work for what they do? After all, Scrum is for the team, no one else. They need to understand the benefits of Scrum, what impacts it will bring, how to measure whether Scrum is working for them, most of all, whether Scrum is the right framework for what they do.
Scrum is not for everything. It is certainly not suitable for bug tracking, call centers, and maintenance. Although there may be some benefits, it tends to waste the team's time. Especially, in sprint planning, daily standup, sprint review, people tend to waste time since not everybody has to be there. You don't need the whole team to fix a bug that can be done by one person. What do you review during a review, all the bugs fixed in the sprint? It becomes quite inefficient since the work does not require the whole team's collaboration. They will find all the rituals are a waste of time. So, if the organization enforces Scrum to the maintenance team, they will hear teams saying - there are too many meetings. But, if you hear team’s complaining that there are too many meetings even for a new product development, in that case, I believe, the team has to have a conversation of "Why Scrum?'' So, have a conversion, and find out what benefits, impacts Scrum will bring & have a shared understanding.
Why Working Agreement?
Does your team have a Working Agreement? The whole team is building a product together, right? It is not one person building it, it is the whole team. If that is the case, the team needs to know how they work together, how to communicate with each other, what not to do, (I think what not to do is more important than what to do), what is the team's mission, what do they value? How do they respect each other? A phrase like “Be curious, not judgmental” brings the team together, as it binds them building the product together.
Does your team have a Working Agreement? Does your team stand behind it? If not, why not? Have a conversation, and find out Why Working Agreement & have a shared understanding.
Why Sprint Goal?
A sprint goal binds the whole team together for a sprint. It is something that the team agreed and planned for the sprint. A sprint goal saying "get everything done for the sprint" is not a good sprint goal. It doesn't really inspire the team. A good sprint goal is like a beam coming out of a lighthouse. It guides them when they are in conflict and when they are not sure of which direction to take. It also helps them to be self-managed since it can be used to make the decision rather than waiting for the product owner to make the decision for them. Most of all, a good sprint goal inspires and motivates them to march toward achieving it every day.
Does your team have a sprint goal that motivates and inspires them? If not, why not? Have a conversation and have a sprint goal that inspires and motivates them.
Why Def. of Done?
Def of done is what it means by done when the work is completed. One's 'Definition of Done' can be different from others. So, it spells out what a product owner(PO) says by DONE is the same as the team's Done. Without knowing and agreeing on what it means by done, how can the team know when the work is done? How much work is needed? Make sure the team knows how to verify it and validate it. The best way to define the Def of Done is through test cases. So, having acceptance test cases and conditions spelled out, helps the PO and the team to be on the same page. I hear lots of time, the team saying – “how can I know what to test before coding?” Perhaps there are cases where it might be difficult. But I ask you, how can you estimate anything if you don't know how to test what you are going to build. It might be difficult in the beginning but find out how you can. Test cases I talk about here are functional test cases.
Now, in Scrum, it suggests that the team develops a potentially shippable product at the end of the sprint. Now, I ask you? Is that feasible? If the team is new to Scrum and if the team doesn't have an underlying architecture nor a devOp environment to support it, is it possible to have a potentially shippable product at the end of the sprint? If not possible, have an honest conversation with the team, and find out how it can be done. Have a plan so that your team can build an env incrementally to ship a potentially shippable product at the end of a sprint.
Is that how your team understands Def of Done? If not, why not? Have a conversation and help them understand Why Def. of Done & have a shared understanding.
Why velocity?
Velocity is for the team, not for the Scrum Master, nor for managers. Oftentimes, this is used for managers to compare one team's performance to the other team to see if one team is performing better than the other team. It is not meant for that. The purpose of velocity is for the team to know how much work they can get done for the sprint. I think “Velocity” is like “WIP” in Kanban. WIP is the work limit in progress and Velocity is the work limit for a sprint. This is how the team can control the flow of the work for a sprint. The team constantly inspect and adapt it, so that they can plan for the sprint realistically. Don’t fire Scrum but adjust Velocity before hiring Kanban.
Is that how your team understands velocity? If not, why not? Have a conversation and help them understand why velocity and have a shared understanding.
Why Daily Standup?
Everybody seems to know this. The team answers three questions - what you did, what you will do, and impediments. Now, the key objective for a daily standup is to find out whether the team is progressing toward achieving the sprint goal. This is more important than answering those three questions. The team does a daily check against the sprint goal. If the team deviates from it, they need to talk about it and make a proper course correction. Now, if your team answers these questions exactly as planned and they report no impediment, perhaps everything is going perfectly. Perhaps not. Ask the team if they are achieving the sprint goal. Daily stand up is a daily "inspect and adapt" against the sprint goal.
Does your team have this type of daily standup? If not, why not? Have a conversation and help them understand why Daily Standup and have a shared understanding.
Why Burn-down chart?
A burn-down chart tells how much time is remaining to complete a sprint. Now, I ask you, if updating the remaining hours for a task for a one-week sprint takes too much time, is it worth updating it? Perhaps not. Perhaps instead of looking at the burndown chart, look at how many user stories (backlog items) are done. Especially. look at whether the team is marching toward achieving the sprint goal.
Does your burn-down chart reflect the progress of the sprint accurately? If not, why not? Have a conversation and help them understand why Burn-down charts and have a shared understanding.
Why Transparency, Inspect and Adapt?
Why are they so important? Because they give the opportunities to learn and adapt so that you can improve the product as well as how you work together. Like I said, these three pillars - Transparency, Inspect and Adapt – hold Scrum together. Without these three pillars, Scrum breaks apart. It simply doesn't work. They provide feedback for the planning, execution, product, and how the team is working together. In Scrum, we have 4 explicit ceremonies that give us the opportunities to get feedback. Sprint planning against the planning of what the team will be working on; Daily stand up against the sprint goal; Sprint Review against the product; and Sprint Retro against how the team is working together. Through these ceremonies, we continuously learn about the product as well as how we work together and make proper adaptations continuously. I believe this is the essential ingredient that we need in a new product development.
Does your team understand the purpose of Transparency, Inspect and Adapt? If not, why not. Have a conversation and help them understand Why Transparency, Inspect and Adapt and have a shared understanding.
So, why is having a shared understanding so important?
Why Scrum? What benefits & Impact? Is it the right framework for what they do?
Why a Working Agreement that all can stand behind?
Why does an inspiring Sprint goal bind and glue the team together?
Why an agreed Def of Done?
Why Velocity is for the team not for managers?
Why Daily Standup? It is not a status meeting for managers nor for a scrum master.
Why Burndown chart? Does it take too much time to update it every day? Is it a waste of time?
Why Transparency, Inspect and Adapt – Are the team learning from what they did and continuously improving?
Why understanding the purpose of these and having a shared understanding of these are essential to get the full benefit out of Scrum? Because it creates an env. for the team to be self-managed and autonomous.
Daniel Pink in his book - Drive, says
"Hundreds of research papers… point to the same conclusion. Human beings have an innate drive to be autonomous, self-determined, and connected to one another. And when that drive is liberated, people achieve more and live richer lives."
So, through understanding these and having a shared understanding, it binds and glues the team together and helps them become a self-managed and autonomous team.
I also believe that autonomous teams can put valuable products out to the market faster, not because they work faster but because they can make decisions faster and cut down the decision bottleneck and deliver valuable products through incorporating feedback early.
So, have a conversation and help them understand the purpose of "Why Scrum" and have a shared understanding so that they can build valuable products that bring joy to all!