By Tirthankar Barari
Most new ScrumMasters have a basic understanding of their new role. Many have been through training and received their Certified ScrumMaster designation. When their teams ask them to step in as ScrumMaster, they are often excited and eager.
But after the initial exuberance fades, a nagging doubt begins to form. Each day, while the ScrumMaster is listening to and facilitating the daily standups, a quiet thought begins to circulate in his mind:
The last day of my first Sprint is approaching soon. Are we going to deliver all the items we promised? What exactly do we demo, anyway? What if the thing crashes during the demo? Are we overlooking something? Did we misunderstand the requirements? Does the estimate of work remaining truly reflect reality? What if we hit a snag? Are we missing or overlooking any impediments?
Sound familiar?
If you are a first-time ScrumMaster it’s normal to have all of these concerns. Honestly, the more questions you have, the better. After all, while searching for the answers, chances are you will resolve issues before they bust, rather than after. From my own experience as a first-time ScrumMaster for a development team moving from a traditional software development process to Scrum, I have compiled a list of things you need to keep an eye on, almost all the time, during your sprints.
Bite off only what you can chew
During the sprint planning phase, as the team is committing to backlog items, help them question whether or not they can truly cover all the items. Typically, during planning, development team members have at least some tasks and items they know they will be working on. Individual team members will often know when they are being overloaded, but your job is to be an extra set of eyes. Make sure no one person is taking on too much and that the overall workload seems feasible. Ask questions and challenge assumptions. Bringing potential problems to light early helps mitigate the risk of over-promising and under-delivering to some extent.
You thought of apples, I gave you oranges
Many times, what the Product Owner when he wrote the user story is not at all what the UI designer or the developer understood it to be. Your job is to make sure they are all on the same page as early as possible in the sprint. As a follow-up to the marathon sprint planning meeting, make sure these players stay in sync and in agreement on each backlog item.
For complex backlog items or features, one of many ways to accomplish this is setup one or more mini demos along the way. These should be quick 10-to-15-minute presentations run from the workstation of the designer/architect/developer. Do not involve the whole team for this. Ideally, this mini demo should include one or two team members who have been working on the backlog item and the Product Owner. No fancy slides or preparation time. Keep it very informal. If it is difficult to get the Product Owner and others together for ten or fifteen minutes, you can accomplish something similar by circulating screen shots. The point is to keep the lines of communication open and receive feedback earlier rather than later.
Many people may have inhibitions against running mini demos, as opposed to one overarching demo at the end during review. But for large, complex features, periodic mini demos can be extremely helpful in catching discrepancies in understanding early on.
Plan to plan for the planning meeting
Issues that crop up time and time again during the Sprint Planning meeting include:
- The backlog item is not well defined, so how can we estimate?
- Is it really technically feasible?
- What is the scope of the work here? This, this and also that..? How about that other thing..?
One step that immensely helps in eliminating such drags during our planning meeting was to run a preplanning meeting. Certain things to keep in mind here.
- Do not involve the entire team in this meeting
- Try to schedule it as many days prior to the beginning of the next sprint as possible
- Include the Product Owner and some members of the team who might have more insight or prior knowledge on the features to be discussed
At the end of this meeting, the Product Owner should have shared many more specific details about the backlog items destined for the next sprint. These details should be captured and recorded so that when those inevitable questions about the scope of the work pop-up during effort estimation time, the answers are already there.
What we say standing up is what we do sitting down
Stress to the team that their fellow team members are depending on them to follow-through on what they commit to during the daily standup, and help them in their efforts to do that. I do not mean to imply that you should police or micromanage the team on what they do once they leave the daily standup. On the contrary, the team should manage itself. Team members will and should hold each other accountable to their public commitments.
So where do you come in? At times, team members become victims of external forces. They are pulled off to work on something else in parallel, or asked to start on something “more important.” It is your job to ensure that such distractions do not jeopardize the delivery of your sprint outputs. Other impediments can also stand in the way of delivery: maybe the machines are not in yet or the software or tools needed by development haven’t arrived yet. Sometimes the team members are shy or uncomfortable about bringing these kinds of impediments up during the daily standup meetings. Look for opportunities to encourage them to mention these obstacles. Once they do, help resolve them.
Plan the demo and demo the plan
If you happen to be the ScrumMaster of a team that is ushering in agile to the organization, your sprint plannings, standups, reviews, and retrospectives could garner interest and attention from many quarters. You may even have distinguished members of the organization sit in such activities occasionally. This is definitely good news, an indication that the organization is taking this new approach seriously. At the same time, though, it puts a little extra pressure on you to have your meetings, and especially your demo, go smoothly.
Just as actors have rehearsals before a performance, your team may need to practice before the live demo. Planning and rehearsing the demo would also help to uncover problems before they happen in front of a live audience.
Clearly, a rehearsal would be nice, but you do not want to spend much of the team’s valuable time on just this activity. They are busy executing the tasks in the backlog, right? So, spend some of your own time chalking out a plan for the demo. You have the backlog items already. Arrange them in a sequence you thing fit. Help setup a demo machine yourself, if need be. Then let the team members for each backlog item decide who will demo that feature. Since the members of a backlog item know the feature the best, they would hardly need any more time to prepare for the demo. You need to keep control on the sequence of the demo, the setup and the support. We have found a short plan that shows the list to be demonstrated and a quick meeting the day before the demo makes the review session a reasonably smooth sail. Also, keep backup plans, in case something fails at the eleventh hour (the “demo effect”).
Think end-to-end from beginning to end
Often during a sprint, all the individuals on the team are too focused on the immediate tasks in hand. There could be many interdependencies among features within your own team’s backlog items or with features from other Scrum teams. Issues related to these interdependencies may often get overlooked during the daily standup meetings or the scrum of scrum meetings.
It is vital for more complex system development that you (or another designee or even an end-to-end team for very large systems) keep track of these interdependencies along the way. It would serve you no good to learn on the last day of the sprint that a feature from team A needed a parameter to be passed by a feature from team B and it is not done yet. Many times, team B may not even be aware of the need, while it was quite obvious to team A. One way to bring these issues to the surface early on could be to visit and revisit the system flow in mini end-to-end review sessions (even by acting out the roles)
The organization is not for Scrum. Scrum is for the organization
Are we doing 100 percent Scrum 100 percent of the time? After all, according to line 7 of page 17 of this book from that author, we should complete this meeting within 3 hours, else we are violating the rules of Scrum. How many times have you, as the ScrumMaster, faced these questions, particularly during the early stages? Wish you had a scale to measure your ”Scrumness” that you could display on top of your desk or on your wiki page in real time?
Sometimes we forget the basic premise for doing Scrum. In the end, your customers will not pay the bills on how “Scrummy” you were. Certainly it is important to follow the guidelines defined in Scrum, but the ultimate goal is to deliver what you promised, within budget and on time. In that respect, Scrum is a great enabler and more of a means to an end rather than an end by itself. While you are helping your team follow the process, don’t get so caught up in the nitty-gritty details that lose sight of your organization’s goals.
