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.

The begining - Sprint 1

The team has been carved. The team seems too large to me. It has 2 QA persons, about 8 developers in one location and 5 developers from another location. There is a team of 3 product managers. It is decided to conduct daily scrums using video conferencing. Furthermore these developers are not dedicated the project alone. They are going to work on this project along with fixing maintenance issues. The scrum master and one of the developers from the team are Certified Scrum Masters. They are eager to implement scrum as they have been taught in the class.

Obviously, there are two problems with this setup. The team is too big and people are not dedicated to this project.

The chosen sprint size is 3 weeks.

The team attends the planning meeting. Maintenance issues are assigned weekly. The developers only know about their next two weeks load. They don't know their third week load. Everybody picks up stories considering their other commitments. The team ends up picking work worth only 150 hours for three weeks! Going by 6 hours per day per developer (if they were dedicated), they should have taken up at least 1014 hours worth of work!

The trained developer and the scrum master then walks up to the team's manager and requests him to do the following:

1. The team should have dedicated developers as much as possible. People should be freed up from their other tasks if possible or else, people should be aware that they can delay / refuse to accept fixing any maintenance issues if they have picked up more work from the sprint.
2. The team size should be reduced

The manager first tells the Scrum Master that he is putting everybody on it so that they learn the new product we are developing and they get trained on Scrum.

The trained developer and Scrum Master keep pursuing this issue with the team's manager. They tell him that without having dedicated developers the team will never gain momentum and if they don't know about their other commitments at the time of planning meeting, they are likely to take little work because of unknowns. The Scrum Master also shows him his training manual that specifies the ideal scrum team size to be 5 to 7 members. Finally the manager agrees with this and promises to correct it in the next sprint.