By Marko Majki
When I was first introduced to Scrum, I thought "What an easy and beautiful way to be efficient!" After years of doing Scrum, I found that it’s not that easy. It was easy to learn. And, as many times before, “easy come, easy go” was true. It was very easy forget easily learned facts of Scrum. I’ll tell you about some of the traps me and my friends experienced during Scrum implementation. Solving these was more or less successful, but if you recognize at least one of them in your environment, which you weren't aware of before, my article was a success. I will tell you five real stories about people who were on the edge of Scrum and how they succeeded in avoiding Scrum traps. My Scrum heroes' names have been changed to protect their identity. Let's begin.
Proxying Product Owner
"Beware of the ScrumMaster who thinks that he can permanently assume the Product Owner role," I would say. I've heard a similar saying before, "A good ScrumMaster can handle two teams and a great one can handle only one." If you try to do the ScrumMaster and Product Owner role at the same time, you're doomed. You won't be able to perform both roles correctly – that’s certain.
One day, Scott was told at the very end of a Sprint that the Product Owner on the project had to move to another project that had stalled. He was told to act as Product Owner proxy for some time. Scott and the team were in a highly dynamic and quickly changing business, and it was a pretty tough period for the team. The first issue Scott was facing was time. The Sprint was one week long, and he did partially succeed in resolving impediments and barely succeeded in preparing acceptable user stories during the first Sprint. The second Sprint was a total disaster. Impediments started to pile up, and Scott didn't succeed in preparing acceptable user stories. The Product Backlog was filled with a few essays, without good, smaller user stories. And Scott was a pretty good problem solver. He would have certainly been a great Product Owner, if he was focused only on this role. Simply, Scott didn't have enough time to do both roles well for the team. Another issue Scott experienced was context switching, but maybe this is the wrong term. A better term is perspective switching. That was very stressful. At one moment Scott was trying to solve impediments and at another trying to figure out which story would return the investment in the best way. How did Scott deal with this? He didn't. He told the stakeholders to delegate a new Product Owner. Even a non-experienced Product Owner is a better solution than a ScrumMaster acting as Product Owner proxy. Luckily, Scott's Product Owner returned and he was able to keep Scrum on the track.
ScrumMaster as a Team lead
Claire had a pretty strong technical background on system administration, networks, and Java software architecture/development. Top management considered this to be a great asset to the team she was supposed to serve as a ScrumMaster. Because top management had a foggy understanding of Scrum, Claire was considered to be a “Team Leader.” Claire was the most experienced programmer in this team, but didn't even have the role of developer. The other team members were really great developers and quick learners, but new to Scrum. They didn't quite understand the nature of her engagement in the project, even though she had tried to be pretty clear about her role. They knew Claire before this project and had respect for her as a developer. I suppose they expected her to deal with technical issues using her remarkable experience. This asset started to become a great burden for the team and for Claire personally. She knew that if she got deep into coding she wouldn't be able to act as a good ScrumMaster. The first Sprint Planning Meeting started, but when technical debt was discussed, everybody looked at her, expecting her valuable opinion. She remembered something that she heard once from a more experienced Scrum Coach. She asked the team to excuse her for some time and to continue the technical discussion without her. They were surprised, but after she left, they did continue. After some time she returned and they barely noticed her. She was satisfied with the result. When the meeting was finished, she asked the team if everything was ok and how they decided to address technical solutions. Everything was fine and the team was satisfied because they handled everything themselves. She suggested that they would feel better if they made decisions on technical stuff, and that they were very good developers. “Of course,” she said, “I'll give suggestions if needed, but I'm not supposed to make decisions. The team has the power to decide. My job is to serve the team and to be sure that the project and work are running smoothly.” Claire made an "impediment list" sticky note on the wall and asked the team to give her tasks whenever they wanted, no matter what issues they might have. Then they really understood her role on the project.
Support Departments Don’t Use Scrum
Robert was a Scrum Coach for a software department that developed in-house projects. They had used Scrum for almost a year, and were doing a great job. When Robert came to the company, the department was pretty messed up, but in a few months everything fell into place and the teams became hyper productive. This was recognized by top management, teams were regularly awarded, and everything was fine. But Robert was a little worried. At first, he was focused on the teams, and wasn't able to see the whole picture. Using Scrum, real issues were surfacing, but he was focused on the issues he had influence over, and the team was solving them. So, when impediments inside the department were minor, other impediments became visible. The first sign of trouble was that the Product Backlog was pretty empty. He talked with Product Owners and discovered that they couldn't get enough information to create acceptable user stories. “Why?” he asked. Simply put, nobody from other departments had the time to define what they needed, and when they needed some functionality, they needed it immediately. From his perspective, communication with other departments was an impediment, but he felt responsible to initiate the solution. Now, because teams were pretty self-organized and doing well, it was time to spread Scrum to the other departments. First he talked to top management about the situation in other departments and presented the idea about introducing Scrum. They hadn’t originally considered it, but were pretty satisfied with the re-organization of the software department, so they agreed. Robert explained that he didn't want to make this transition top-down, but would try with volunteers. He invited heads of each department to a working breakfast and explained Scrum, presenting potential benefits for the department using its principles. He asked them to bring a few team members to the next three meetings about Scrum. They were pretty shocked when he introduced some of the Scrum games, expecting a PowerPoint presentation. “Hey, you didn't even bring your laptop,” they said. “I don't need it,” Robert replied. After playing two games, he conducted a practice retrospective meeting, allowing the teams to reach their own conclusions. Then he helped them to make parallels with real situations that they were dealing with. It was quite refreshing and revealing for most of them. Then, he explained that Scrum was not a silver bullet, but a tool that could help them to understand the impediments and to enable them to work better. He asked them to consider it and to let him know if they would like to try Scrum in their environment. The next day, the chief of the technical support department contacted Robert, claiming that his team was overwhelmed and eager to try Scrum. "Great!" Robert said. "Let's start preparations for our first Sprint."
Disputed Definition of Done
Ulrich was a pretty experienced Scrum Practitioner. He knew that coaching a new team was going to be tough. They were all experienced programmers, but new to Scrum. Initially, coaching was tough, with much resistance and conflicts; a bumpy road that was now almost behind him. Eventually, things were much smoother because he knew the team's velocity and the team knew their velocity, which was much more important. Velocity was regarding to “DONE DONE” user stories. He remembered the issue the team had with this, their definition of done (DoD). As he explained at the very beginning, the team and the Product Owner had to reach an agreement on this. One of the guys came up with a DoD proposition, and the team and the Product Owner were ok with it. One of the items in this list was "unit test coverage of 80%." After the first few stories were "done," he asked the Product Owner to test the items from these stories. With the tool they had, it was easy to see a unit test coverage of 23%. Ulrich asked the Product Owner what he thought about that. He answered that he wasn't satisfied with that the result. "Why?" asked Ulrich. "Because these stories are not done," replied the Product Owner. "Do you need a unit test coverage of 80%?" asked Ulrich. "No, I don't know why they chose these figures, but if the team defined these, I expect them to meet these criteria," answered the Product Owner. And he was right. The Sprint ended the next day, and during the Sprint Retrospective, Ulrich announced that the Sprint had failed, which provoked a very emotional response from the team members. He explained the reason and showed them real figures on test coverage. "But why is this important? We did all the necessary tests. We didn't want to waste time unit testing trivial methods, such as getters and setters, and we didn't want to test something covered in integration testing," screamed the guy who purposed the DoD criteria. "Yes, you are completely right, but you promised something about unit testing and this was not accomplished. Could you tell me how you determined the proposed DoD?" Ulrich asked. "Well, I didn't know what criteria to propose, so I copied some from a Scrum blog, which looked great at this time." "Ok, guys," Ulrich said, "this is my failure as Scrum Coach as well and it's my fault that you didn't understand the meaning and importance of DoD. DoD is different from team to team and project to project. This is not a general standard that should be implemented in all situations. And Scrum is not a standard that can be implemented the same way in all situations. Those are tools, which help you make better software, but you need to involve your intelligence, energy and creativity to make it happen. Ok, let's do the job. Let's create a DoD acceptable to us and our Product Owner. You are experienced developers and you know everything about good programming practices. You've seen one of many possible DoD's. Let’s make new a DoD we can commit to."
Estimations in hours
Marianne was inexperienced, but passionate about Scrum. She started her first Scrum project with the team and was thrilled, anticipating her first ScrumMaster job. The team knew about Scrum and was interested in trying it. Before the first Sprint Planning Meeting, the Scrum team agreed on some conventions and one of them was estimating user stories and tasks in hours. This was the natural choice for the team and Marianne agreed with that. Estimating in user story points was awkward to the team, since they couldn't figure out how to correlate this to some real measurement unit. So they started their Sprint meeting and started estimating. They estimated all user stories and chose ones they could commit to finish until the end of Sprint. Then, the Product Owner stood up and spoke. "Well, guys, you just committed to finish user stories worth 230 hours and you have 400 working hours in your Sprint. Even if we add 30 hours for the meetings during the Sprint, still there's 140 hours in the Sprint you should commit to. Is my math correct?" "Yes, you're right," said the senior developer, "but a working hour cannot be equal to a development hour. We have to have time to think about the story, business process, architecture etc. So, coding functionality is not the only job we're working on. Development is the intellectual process, not an exact, simple operation. We really didn't underestimate, in my opinion, and we didn't want to „steal‟ some time. I just feel that we cannot commit to more than we already did." "Ok guys," continued the Product Owner, "I believe you were honest with the estimations and I think that this is a fine velocity if you meet those commitments with your definition of done. I just can't figure out this difference and it would be difficult for me to explain this to the stakeholders." It was good timing for Marianne to do some facilitation work. "The way I see it," she said, "we have a problem with the measurement unit. The Product Owner is satisfied with the features to be developed in this Sprint, but somehow user stories measured in hours don't provide the real information, correct? Furthermore, this difference in time is causing confusion. If developer hours cannot linearly correlate with real time, why don't we say points, not hours? After a few Sprints, we will be better in our estimations in these points, correct? And there will be no confusion with working hours and time. After a few Sprints, we will know our velocity in these points and will have more experience in estimating work. Stakeholders will get their graphics in these points and will be able to monitor progress daily. What do you think?" The Product Owner was delighted with this idea, knowing that he'd be able to show diagrams to the stakeholders in real time, and the team was relieved from the pressure they felt after Product Owner's speech. Marianne scored her first small victory helping her team to overcome its first impediment and potential conflict. After a few Sprints, they got used to estimations in user story points, so it came naturally to them.
I hope that you enjoyed these real Scrum stories and that you can recognize some of the situations in your everyday Scrum practice. Please comment on them and comment on how you would deal with these situations.
