Why is your team doing Scrum? Check the appropriate box below.

Somebody's boss someplace said we have to do Agile now.
Agile sounded like a good thing to have on my resume.
Our software has problems and Agile is the magic bullet solution.
Our team wants to get better at quality software delivery and estimation.

Those of you who chose the last option, keep reading. Everyone else, please click HERE.

We do Scrum because the process yields better results. We do it because we want people to think and be empowered as a team, rather than just being told what to do. We want our software to please our customers. We want to please our customers regularly and often. We want to be able to respond to changes in direction, changes in requirements, or just change in general - in a positive way and continue to deliver useful software. We like the notion of teamwork and collective ownership. We like collaboration. We like to get feedback often, and integrate it into our process so we get better, faster. We measure our success and progress only in terms of delivered, working software.

Scrum is more than a process for managing projects, it is a change in mindset. Just deciding to do mini-waterfalls in 4-week cycles isn't Scrum. And it isn't very useful or productive either. [BTW just so we're clear: A mini-waterfall looks like a 4-week "sprint" where the first week is design and specification generation, two weeks are coding, and the last week is testing and bug fixing.]

It takes a mind shift to a willingness to be a TEAM rather than just a bunch of people working on the same project. There IS a difference. Without an attitude of cooperation and collaboration, Scrum will not succeed (nor will any approach really), and Scrum will just seem to be an additional burden to those forced into it.

Don't mandate that your team adopt Scrum. Explain to them why it's better. (At this point I should probably mention that YOU should understand why it's better...) Convince them. If they aren't convinced, keep at it until they are. If they are skeptical, that's OK but they need to be open-minded enough to actually try it for a while. If they aren't truly open-minded, or can't be convinced - DON'T DO SCRUM. This kind of a process needs to have WILLING participants that are cooperative. It's not for everyone. Be prepared for the fact that some people just don't get it, or WON'T get it. They really need to find a different team to work on. Don't burden those on a Scrum team with members who don't want to be there.

Scrum is not a silver bullet. It's not always the answer, but it is ONE answer. Educate your team. Be supportive, and explain why the tenets of the Agile Manifesto and the twelve principles behind it are a good idea and that they can really work in your organization.

More advice. Have a Scrum master. This person should be trained in the role and understand it. Have a true Product Owner (NOT the Scrum master by the way) who represents [ALL] of the stakeholders. Make sure they really do identify and represent the real stakeholders, and have the authority to prioritize. Hire a Scrum consultant, or bring in an experienced person who has helped teams get up to speed on Scrum - and LISTEN TO THEM. Don't pick and choose which pieces of Scrum you like at first, just do them all "by the book." You can fine-tune your process in response to sprint retrospectives later.

Scrum can be a great way to develop software, or it can feel like a horrible burden. It all depends on the attitude and openness of the team doing the process. Make sure you make your experience the former instead of the latter.