Anytime a team embraces a new agile process a critical question comes up — must they rigidly adhere to the process guidelines or can they make adjustments to fit their needs? Even Scrum, with its simple rule set, falls into this unending debate.
You won’t find a strong consensus answer. The compulsive agile practitioners will claim that you must abide by the published rules. In the case of Scrum, they will tell you that if you don’t implement the standard Scrum rules as defined, you are not using Scrum and you can’t call your process Scrum.
The less compulsive (but no less agile) among us will tell you that it’s okay to adopt and adapt. The agile process you adopt must work for you; it must feel right and that usually requires that you adapt it to your situation.
Too much advice? What should you do? Consider this:
- It is usually best to start out following the agile process guidelines exactly. If you adopt Scrum, stick to it. Try to make it work. If you strongly believe that an aspect of Scrum is not suitable to your team situation, why not? What is the smallest change you can make that will adapt Scrum to your needs?
- If the agile process you select doesn’t seem to be working, why not? What is it — exactly — that is not working? Is it really a process issue or is it a people issue? What is the simplest way to address the issue?
- Who is most resistant to the new process? There is always someone who wants to see the new agile process fail. The resistance may be obvious but it could also be subtle. Appeal for cooperation. If that fails, get the resister off the project. I know that sounds harsh but the alternative is team failure.
Many agile process failures are a direct result of failing to implement the process as defined. Your best chance at success is to play by the rules. Adapt it if you must, but recognize that changing the rules often makes the job harder.