With all this talk of Agile Software Development and Scrum, it’s easy to feel like everyone has it figured out but you. You may be joining a team that practices Scrum, introducing Scrum to an existing team, or part of a practicing Scrum team that feels like it could be tighter. Whatever the case, here are some suggestions that may help you focus your efforts.
Start with Roles
The practice of Scrum benefits from clearly defined roles. Regardless of what your title might be in an organization, in Scrum it all boils down to the Scrum Master, Product Owner, and Development Team members. Members of the team can try on different hats, but should only wear one hat at a time.
The Product Owner writes user stories, communicates with stakeholders to understand business needs, and maintains the product backlog in order of priority. The Scrum Master organizes Scrum events and identifies and removes impediments to the sprint. The Development Team members commit to and deliver on the sprint backlog. Everyone has a role, and each is integral to a successful Scrum team.
Checks and Balances
A common mistake people make is to think of the Product Owner as the “boss” and to suppose that the same person might as well serve as the Scrum Master. Such a setup circumvents an important pair of balancing forces between the Product Owner, who always wants to see more of the items in the product backlog make it through development, and the Scrum Master, who makes sure a sprint is successful and the development team members have what they need to complete the sprint. Think of the Product Owner as Captain Kirk from Star Trek; he has his focus on a goal and asks his team to do whatever it takes to get there. On the other hand, the Scrum Master is more like Scotty, the ship’s engineer, who needs to make sure the ship is intact. Sometimes Scotty needs to remind Kirk, “She can’t take much more, captain!”
As you get settled into your roles in Scrum, you will likely find all sorts of other benefits, too. Once I was on a team that had started with no clearly-defined roles; we were just a few people trying to get something done. It was often hard to know who was working on what, and when we would actually be ready to ship our product. To make matter worse, because we didn’t have a defined Product Owner, lots of other people from the organization would stop by and offer their ideas. They would suggest, “Wouldn’t it be great if…” or, “Why can’t you just…”. This resulted in lots of little changes in direction and focus and made it even harder for the product to materialize. With clearly-defined roles, team members can remind stakeholders to take those ideas and requests to the Product Owner, who can discuss their relative priority with respect other items in the backlog.
Another benefit of Scrum is that it is made up of clearly defined activities, or Scrum events. These include sprint planning, the daily stand-up, backlog refinement, sprint review, and the sprint retrospective. If your team is just starting with Scrum, carrying out these events together will help you have success early. If your team has been using Scrum for some time, it may help to refocus on these events and ensure that you are getting the full value out of them.
Sprint planning is perhaps the most important element of Scrum, and one that makes Scrum stand out among agile methodologies. This is because the team commits to the work to be done in a sprint. In exchange, the Product Owner agrees not to change the scope of the work expected of the team during the sprint. When the team makes this “deal”, it empowers the team to take ownership over the sprint and its success. A Scrum team should be committed to the success of the sprint, willing to do whatever it can to carry it out effectively.
The next most important Scrum event is the retrospective. It is here that the team reflects on their practice, congratulates each other on their successes, and refocuses themselves on any improvements they can make. If the team honors the retrospective, they will continue to see rewards in their development as a team. Even when the team experiences setbacks, team members know they have a time to acknowledge that and identify ways they can work together to move forward.
This is perhaps the most subtle part of an effective use of Scrum, and you might even call it “Advanced Scrum”. You can do the above stuff and your team may be moving along just fine, but there may be a few questions that kind of nag at you and your team. For example, it may feel like there are always those one or two stories that you accepted as being done, but they weren’t really done. They may have had some tasks left over that someone still had to clean up or bugs that got deferred. Another example is that you did the next thing in the backlog, but the team didn’t really understand how it fit into the big picture of the product strategy or roadmap. Or perhaps the team did a bunch of work, only to have a stakeholder weigh in and say that isn’t really what they needed from you, and could you please do it a different way.
For the above situations and many others, I encourage you to think about sharing with others outside the team. If you are a Product Owner, talk to other Product Owners, either in the same organization or outside of your company. Talk to them about how they tackle these problems. You may come up with some interesting ideas or become inspired that your troubles are not out of your power to change. Spend more time with your stakeholders; try to understand what is important to them and make sure they have a good idea of what you are working on. Bounce rough ideas off of them and see if it causes light bulbs to go off in their heads, or if instead they look at you and scratch their heads. Sharing early with these stakeholders can help you avoid surprises, and bring you in better alignment with their priorities.
If you are a Scrum Master, share with other Scrum Masters. What are the challenges you face? How can you get better results? A really nice way for Scrum Masters to collaborate is to step in as guest facilitators for the sprint retrospective. It’s a nice relief for a Scrum Master to be able to add their own voice to the retrospective and let someone else carry out the conversation, and you can learn from each other about how to better facilitate one of the more delicate events of Scrum.
As a team, share with other teams. Share your Scrum artifacts. Share your struggles. Coordinate your efforts with other teams. The strength of Scrum is that the team becomes very tight and close-knit. However, it can sometimes seem to require more effort to reach outside the team for help. A “Scrum of Scrums” is a regular meeting where Scrum Masters in an organization take time to share what they are working on, and identify ways it might affect others (dependencies) and make arrangements to coordinate with those teams.
Hopefully, the above suggestions give you some ideas on how to get started with Scrum, or ways to improve your practice. As you can probably now see, nobody really has it nailed down, and for any team, there is change and opportunity for improvement along the way. If your team maintains a sense of curiosity and willingness to learn, you will develop as a team and find patterns that work for you. You may also find that those patterns need to change over time to respond to changes in your team. Fortunately, that’s all part of being agile!
If you are interested in learning more about Scrum, make sure to check out the Treehouse library in the upcoming weeks for a brand new course!