I've just given a a Scrum training course to the team because most of them have never been on a Scrum project before. This is the same training I've presented several times. It is a distilled version of what I learned in my ScrumMaster training and is based on the Redistributable Intro to Scrum presentation. Typically the best part of these training sessions, for me, are the discussions. You learn a lot about people and the team and how responsive to change they are by these initial discussions in the training class.
Several members of the team had a few revealing comments. They are born from preconceptions, pessimism, ignorance of the process, and old waterfall habits, and typically start with,
"The problem I have with Scrum is..."
"... daily scrums seem like they would be a waste of time."
Daily scrums can be a waste of time if people are allowed to drift off topic or try to resolve issues in the meeting. The meetings are timeboxed to 15 minutes and seldom take that long if everyone sticks to the 3 questions, "What did you do yesterday?", "What are you going to do today?", and "What impediments are blocking your progress?". Are daily scrums more of a waste than not gathering empirical data on where the team is and where they are going every day so any necessary course corrections can be made? How much time would be wasted if we found out a week or month after-the-fact that we were going in the wrong direction? A lot -- and that's not agile.
"... if I wanted to be responsible for other people's work, I'd be a manager."
My response to this was, "So you don't want to be on a team?" To which they replied, "No no, I want to be on a team, I just don't want to be responsible for the work of other people on the team."
A little confused by this statement, I dug deeper, "Could you describe a scenario that would make you feel uncomfortable?" They thought for a moment and said, "Let's say we hire a bunch of green developers that don't know anything and put them on the project and they aren't able to produce."
Now I understood their concerns. They didn't want to be held accountable when the team changed if they were expected to produce more. I explained that we don't add people to the project in the middle of a sprint and expect them to produce. The team makes the commitments to the work they are going to do during the Sprint Planning and no work nor people are added in the middle of the sprint. The team is responsible for delivering their commitments each sprint and the commitments don't change during the sprint. Also if you add people to the team, during the next Sprint Planning you will make new commitments based on the new team. The commitment shouldn't be a linear factor of their velocity. For example, let's say there are 4 people on the team and their velocity is 40. No one should expect if we add 3 people to the team the should be able to commit to 70 story points next Sprint. The team would have to go through the Forming, Storming, Norming, Performing phases again, which takes time and should probably not commit to over 40 points. They may even commit to less at first because the stronger team members are helping the weaker team members get stronger which may take away from their work. This may seem counter-intuitive to say, "Our velocity went down because we added more people." But it's just like the first sprint when you didn't know what the team's velocity was until they completed a sprint together.
"... use cases are better than user stories."
My response to this was, "What do you get from use cases that you don't get from user stories with acceptance criteria?" Their reply was, "When we write use cases we can see the 'big picture' of the entire project because we can connect them with lines and see how they relate. We don't get this with user stories." I argued that the lines don't come from the use cases they come from the tool that you use to write the use cases. You can achieve the same thing with user stories by putting them on a whiteboard and drawing lines between them. User stories have the advantage that they include acceptance criteria so the team knows exactly what to create, and they have benefits so the team knows why. Comparing use cases and user stories is like comparing apples and oranges. Use cases define how users will interact with the software and user stories describe a business need the user has that the software will accomplish. If you feel the exercise of writing use cases provides value to the project then do both. If you get in the habit of writing good user stories you can probably skip use cases and go directly to user stories... and spend less time doing it.
"... user stories shouldn't be negotiable."
When we reached the section of the training on writing good user stories I discussed the I.N.V.E.S.T. criteria for a good user story. User stories should be Independent, Negotiable, Valuable, Estimate-able, Small, and Testable. All of theses were pretty easy to understand for the group except for negotiable. The Product Owner argued that user stories should not be negotiable and what's written should be done. What is meant by "negotiable" here is that the story is just a short description and does not include details. The details are discovered during the conversations with the customer. Too much detail can limit conversation with the customer. User stories should be able to be thrown away or changed if need be. Recall in the Agile Manifesto we value customer collaboration over contract negotiation. If the story is too detailed you may shortcut necessary conversations.
These are just a handful of great statements that come from people that are new to Scrum. What sort of preconceived incorrect statements have you heard from people that are new to Scrum and how were they corrected?
No comments:
Post a Comment