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.