"The problem I have with Scrum is..."

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?

It's Not an Ideal World

I am the ScrumMaster for a  new software development project at a large oil and gas company. The project is a re-write of several disparate process control applications into one cohesive suite of applications. The project has been going on for several months but I just joined recently and there was no other ScrumMaster on the project before me. All the decisions up to now have been made without my input.

Let me lay out the scenario for you and see if you can spot any red flags.

I will also be a development resource. I am expected to split my ScrumMaster and developer responsibilities 30% and 70% respectively.  The Product Owner attended a Scrum overview course and is confident in his knowledge of Scrum.  For the past few months the Product Owner and group of subject matter experts have been meeting to discuss the requirements.  They have come up with over 700 requirements.  The requirements are very high-level with almost no detail and require a lot of domain knowledge to interpret.  They have also documented all the use cases they can foresee. 

The Product Owner decided that each sprint is 18 days long, and each release is 5 sprints long.  In an effort to provide a high level estimate for initial budgeting, resourcing, and scheduling purposes, the subject matter experts, the team, and I met several times over a week to try to assign relative complexity scores to the use cases.  Even though I convinced them to use the Fibonacci sequence for relative complexity scores, I won't call them story points because they weren't user stories that we were estimating and none of them had acceptance criteria.  We then took a random sampling of use cases and detailed them out further and provided effort estimates so we'd have a rough idea how much effort each "story point" wound take.  Then we multiplied that by the total story points and came up with close to 100,000 person hours. 

We are partnered with another company's development team in Japan that will be developing a portion of the application. Our releases will need to coincide with theirs. The project is expected to be complete in 2 1/2 years.  The Product Owner created a project roadmap that breaks down what he thinks should be in each release and details what should be in the first few sprints.  There is no link between the Product Backlog, the use cases, the roadmap or the first couple of sprints' worth of work.

In order to complete the 100,000 hours in 2.5 years it will take about 25 people.  Currently the team is made up of 4 developers (3 local and 1 in the Netherlands) and 1 tester and me.  There are three other "testers" that are from the helpdesk that can commit 30% of their time to the project.  Two of them are local but they work remotely and one is in Malaysia and they have no testing experience.  The tester and one of the developers have been on a Scrum project before and I'm confident they understand the methodology but the other 3 have not.
The first sprint planning meeting is today and the first sprint starts in 2 days.

Anyone see any problems here?  Ideally there would be a lot of things I would change about this project. But we don't live or work in an ideal world.  We live and work in an ever-changing chaotic world.  The best we can do is to be agile and to make the best of the situation.

• Ideally a ScrumMaster should have been involved as early as possible in the project in order to coach everyone on the process.  I was on another project until recently so they couldn't use me and the product owner felt they knew enough about Scrum to get started.  From now on, I'm in every meeting  and discussion regarding the project.
• Ideally I should not be splitting my time between being a ScrumMaster and a developer.  However, I do have some domain knowledge and I'm a good developer resource.  We probably don't need a full time dedicated ScrumMaster right now, but I expect that my responsibilities will shift more toward ScrumMaster and less development as the project goes on, especially if we have more than one Scrum team on the project.
• Ideally the Product Owner and everyone on the team should have already had some sort of Scrum training.  On a project of this size I would recommend that the Product Owner be a Certified Scrum Product Owner.  This may happen later but initially he felt that his overview course was sufficient.
• Ideally the requirements should have been written as user stories.  I wouldn't expect all the requirements would have much detail now. The time spent on the exercise of going through the use cases was probably not entirely wasted, but it would have been easier and clearer if, rather than writing requirements then writing use cases then writing a roadmap, they had just started with epics, narrowed to themes, and then narrowed to user stories.
• Ideally the Product Owner, the team, and the ScrumMaster would decide the length of the sprint together based on how long they think the team can work without being interrupted.  However, the decision by the Product Owner to make the sprints 18 days long is probably a good one.  It's good the Product owner did a Product Planning in the form of a roadmap, but it would have been better to involved the team and the ScrumMaster.
• Ideally several months wouldn't have pasted before the first sprint.  There has been quite a lot of time spent and no business value realized yet.  Had the Product Owner spent lest time on the requirements and the use cases, then the team could have begun work sooner and the project would already have business value.  Since the Product Owner and the subject matter experts are used to working in a waterfall project it is natural to them to spend a very long time gathering requirements for the whole product.
• Ideally the effort estimates should have come after the first sprint when the velocity of the team is known but for budgeting purposes we had to estimate at a high level based on the complexity.  Future estimates will be quicker, easier, and more accurate after the velocity is known.
• Ideally we would only plan one release at a time, but since we are partnered with another company on development we needed a high-level product plan that lays out what the releases will contain so we can coordinate development efforts between the two companies.
• Ideally the team would all be collocated and no one would work remotely.  However, this is often then case and the challenges of a distributed team are not that difficult to overcome.  Remote workers will participate in the daily scrum meetings via conference call and visit the office frequently.  We are using Team Foundation Server with Visual Studio Scrum 1.0 process guidance template and the Urban Turtle plugin to help with team collaboration so we will have a Burndown chart and a virtual taskboard visible to everyone.
• Ideally people's time would not be split with other projects.  Since there are several issues around the testing staff, (i.e. no testing experience, remote locations, and time shared with other projects) we will probably make some changes here. Training, time commitments, rotating one resource on to the project full-time each sprint, have them only responsible for running manual tests, hiring another full time experienced tester, could all help the situation.

In an ideal world, on smaller projects, or projects for smaller companies, you might have everything setup exactly the way you'd like to follow all the principles of Scrum.  But in the real world, we work on large projects for giant immutable corporations and we have to play the best we can with the hand we're dealt.  Obviously we have a lot of challenges ahead of us on this project, but if we keep to the principles of Scrum and the spirit of an Agile progress we will be successful.