How to Justify Scrum to Senior Management

Often many people say that it is difficult to justify Scrum to the senior management. I think there are two alternative approaches you can take to justify Scrum:
If the senior management is willing to listen , you can tell them about the following scrum benefits:

• None of the software development methodologies can predict the exact date of software completion with exact amount of resources. In most cases where inputs and outputs are not well defined, empirical process control model is the only workable model for software development. Read chapter 5, Agile Software Development with Scrum.

• Prioritized product backlog ensures that 80% of the business value is delivered in 20% of the time. Read Appendix D, Agile Project Management With Scrum.

• Product gets a legitimate chance to change their product based on sprint demos. There is no need to file a change request and charge more in case of a fixed bid and/or fixed date contracts. Scrum being a transparent process, it gives more visibility to the management than waterfall, which provides no visibility till the time the product is finally released.
  

• Once Scrum is in place, it is possible to estimate release dates roughly based on historical velocity data. In fact, you will be able to predict release dates of the current project with 80% probability after 20% of the work is done - within 3 to 5 sprints based on the project size.

• Scrum exposes problems earlier, there by giving a chance for management to cancel the project if necessary.

• If you are a high maturity company, then using Scrum will improve productivity and performance significantly as concluded by Jeff Sutherlands's paper - Scrum and CMMI Level 5: The Magic Potion for Code Warriors
  

If the senior management is not willing to listen, you have no choice but to do the analysis first and give them a date. You may not be able to score with a management not willing to listen to new ideas.

Point Score and Work Remaining in hours

A day before sprint 1 was about to end, the scrum master, team manager and scrum-trained developer were sitting in a meeting room trying to figure out the co-relation between velocity and estimated hours. The question in front of them was - What is the guideline for the team to choose stories? Should we give them a velocity number or the team should make a decision based on total number of available developer hours?

If we are going to use the total number of available hours for picking up stories from the backlog then what is the purpose of velocity? Why do we estimate stories in points? Why use different units? Why not just use hours so that this whole estimation is uniform in hours ?

They had only one sprint worth of data. The team was new to Scrum. The manager felt strongly that they should give some guideline to the team so that the team does not overburden itself or does not take up little work. He also wanted to know the correlation between points and hours.

Here is what Ken Schwaber says in his book - Agile Software Development with Scrum "This (in our case the questions raised above) question indicates the difficulty shifting from a pert chart-based, time reporting structure to an empirical approach"

There is a difference between assigning a point score for a story and estimating hours for a story. Point score is the effort. Work remaining is the time (hours). The point score for a story is an approximate score. This score is used in velocity calculations. Product owner and the scrum master use this for release estimation and planning.

The team only uses estimated hours while picking stories for a sprint. They pick a story from the backlog and estimate the number of hours after clarifying requirements with the product owner. Estimating hours require more understanding of the story than assigning a very rough point score. Furthermore, estimation should be preferably done for tasks - at a finer granularity than story. A story should be divided into multiple tasks such as testing, coding, writing unit tests, coding UI layer etc. That makes a story more predictable. The team only deals in number of hours and specifically remaining number of hours. On realizing this, the manager stopped deriving the correlation between effort and time.

Why Agile is hard?

I was talking with some developers and a manager of a company in LA about their Scrum implementation. They told me about various problems they faced - no buy in from business, inability to estimate exact dates etc.

Interestingly, at the same time, I happened to listen to Why Agile is Hard - The java Posee round up 08 podcast. Same problems were discussed in the podcast. The podcast mentions many interesting books and websites for agile followers. If you are an agile devotee, you should definitely listen to this podcast.

The developers from the company also talked about implementing Scrum only in the engineering team without getting buy in from the business. The business will give them a document of requirements which will be translated into user stories by a team lead.

One developer even told me about doing database design out of scrum sprints to avoid future changes. I think this is fundamentally wrong and against the spirit of Scrum. This is a typical case when unit tests are not implemented. Code without unit tests is difficult to re-factor hence developers tend to think about future requirements; there by defeating the purpose of iterative and incremental approach

Their other problem was accommodating QA in a sprint mainly because the testing was manual. I tried convincing them QAing within the sprint instead of doing staggered QA sprints. I suggested that they should try to automate the tests. While developers are working on the code, QA should work on creating / changing the automated tests.

They hadn't read the bible - Agile Software Development with SCRUM (Series in Agile Software Development). I suggested them to start with the book. Careful reading of this book will answer many of their questions. I also agree with one of the person in the podcast - start with small changes. Specifically for people who don't have unit tests. They need to start with unit testing first.