Challenging how some are using Scrum

Tobias Meyer is challenging how some are using Scrum and has proposed some different ideas based on his experience. His post called "When Scrum is not Scrum" is bound to generate some discussion in the Scrum community. I have summarized below each of his points, followed by my own experience around each:

1. Product Owners are part of the team. Product representative (not owner) should attend the daily meetings, retrospective, planning and review meetings.

Skip: There are a couple of thoughts in this bullet. Is the term Product Owner accurate? Do they really OWN the product? I have never liked the terms Product Manager and Product Owner because I don't believe that one person truly can own or manage a software product. Especially in an Agile environment where there is such emphasis on teamwork. In the training I recently attended, a new term called Product Champion was introduced. While this person does represent customers, their main role is to provide vision, passion and support of the team as the product is being developed. The other thought is How often should this person be involved in the team. People who play the customer role typically have limited time with the team (I would love to have a full-time customer available!), so we have tried to include them in just the planning and retrospective meetings. We have had some success but have also realized that something is definitely missing. We end up spending time discussing decisions that the team made on a daily basis on behalf of the customer. Not only does this take additional time (I would consider Waste in Lean terms) but also some rework if our assumptions were wrong. Perhaps there is a point that more involvement needs to be made.

2. Two-week Sprints. Teams are incapable of planning a thirty-day sprint effectively. It is overwhelming. Most teams I have tried it nail the first part of the sprint, but allow the second part to be vague and muddy.

Skip: I totally agree. In fact, it seems that most people using Scrum are doing 2 or 3 week iterations and those that are experienced are going with 1 week iterations. We tried one month iterations and experienced the same issues. We have found that 2 weeks provide the right amount of scope balanced against the right amount of workload/urgency needed.


3. Tasks are not measured in hours. Insisting on hours breakdown and having each team member continually update hours remaining on a task is often perceived as a sneaky, micro-management approach. In my experience team members find this practice frustrating and meaningless. Long ago I moved towards encouraging team members to break all tasks down as small as possible. A task must be completed in a single working day or it is considered an impediment, and should be marked as such.

Skip: We tried at first to use points instead of hours for tasks. And by we, we are talking Management not the team. It was actually the team who felt more comfortable with looking at tasks in hours. So, at least our experience is the opposite of Tobias. I also look at tasks as a way to identify how the team is going to implement a story. Stories typically are defined between 1/2 to 3 days. We find it has been easiest many of these times to define just one task per team member who is contributing to the story because the size really is manageable. I'm just don't agree that these tasks have been completed as part of a day.

4. Use of Taskboards rather than spreadsheets. Spreadsheets hide information, and they lie. The best way to create transparency is to display everything on Big Visible Charts. The interactive, collaborative nature of taskboards lends itself to the Scrum process, like no electronic tool ever can.

Skip: We have been using an electronic solution and are finding ourselves liking the Taskboard approach better for some things and more difficult for others. It's better to ensure that the team is collaborating and taking ownership of the board. If it's in another format the responsibility has fallen more on the Scrum Master to maintain. What we have liked about the electronic format is that it is more portable (we don't have a dedicated room for each team - yet!) and it provides a good archive and easier ways to calculate burn down charts than the taskboard approach.

5. Backlogs on the wall. At least the next 3-4 sprints worth of stuff should be displayed on 3×5 cards on the wall of the team room so the team can get look-ahead time. Backlogs much longer than that, containing anything more than placeholder items (reminders) can be thought of as wasteful, in any case.

Skip: We have talked about this, and may go in this direction but again it's a matter of having dedicated space to have this much information on the walls. Having backlogs for the product has been helpful storing in an electronic format so that we have records of things that we aren't doing in the next couple of iterations but plan on looking at beyond that. We don't release every iteration, yet we also don't plan the entire release at this point. We also need a repository for discussion of future releases at least at a high-level as a roadmap of where we are taking our products. Not sure all of these things can be accomplished with backlogs on the wall.

6. Estimation Meetings. Estimation is done before the first sprint, and then on a regular basis during each sprint. I have found that a 1-2 hour meeting about 2-3 days before the end of a sprint is the ideal time. Estimates are done in Story Points, as described in Mike Cohn’s books (not “ideal developer days” as described in the Scrum books).

Skip: Totally agree but we have not been consistent with this approach. I love the idea of using points to provide relative size of features or stories against each other. Better than t-shirt sizing, but not requiring the depth and time of getting to an hour estimate especially as you are looking at the next couple of iterations. I have also liked Mike's approach of using Estimating Cards with the team as a way for the team to come up with these estimates instead of individuals.

7. Insistence on Agile Engineering practices. It is essential to introduce some core practices such as unit testing, early acceptance test specification, componentized design, continuous refactoring and pairing from the start. Scrum itself says nothing about such practices, and that tends to give organizations a sense that Scrum is easy to do, and can simply (as many of it’s proponents state) wrap around existing engineering practices.

Skip: I never really thought Scrum was to address engineering practices. I'm pretty sure Tobias isn't saying that it was, but the point that is that is all you are doing with a software product you are NOT fully taking available of the benefits that Agile can provide. We are seeing this first hand as we have much work on the engineering practices side to allow us to be more successful with our iterations. So, I TOTALLY agree with Tobias on this point.

8. The Scrum Master role is not always necessary. An effective self-organizing team is exactly that: self-organizing. Leadership emerges from the team when the key Agile principles are adhered to. The Scrum Master role becomes superfluous in a healthy Agile organization.

Skip: I have been wondering this myself. I don't know if we are experienced enough to do this on a full-time basis, but I have seen evidence that this can work. We have had our Scrum Master out for periods of time either sick, training or vacation. On a couple of times, she has been out for at least half an iteration. So you would think that the iteration would have problems, right? Wrong! The team conducts their own daily meetings and figures out how to remove impediments and keep committed to the iteration. It's not the perhaps the Scrum Master role isn't necessary, it just means that it doesn't necessarily have to come from a particular person playing the role.