Organizations that are trying to implement Agile may turn to Scrum. But unless you make the shift and become Agile, implementing Scrum won't let you achieve the success that Agile is known for.
I call organizations that implement Scrum without making that shift "Scrum-buts," because they're implementing Scrum — "but with tweaks for our unique situation." (I'd like to thank Joe Little for introducing me to the term.) In order to help you understand the difference between an Agile organization and an organization that's just implementing Agile practices, I'm going to borrow from Jeff Foxworthy, with apologies.
First, some team examples:
If your team reports its status to the ScrumMaster at the stand-up, you may be a Scrum-but.
In Scrum, teams don't work for the ScrumMaster; the ScrumMaster works for the team. The team has a goal of completing all the stories they've committed to in an excellent way. Teams commit to completing their tasks, but their commitment is to the team, not to their leader. If a person fails, she fails the team, not her leader. This dynamic creates an environment where team members can truly excel.
If your developers keep getting ahead of your testers, you may be a Scrum-but.
The goal of a Scrum team is for the entire team to complete the committed work by the end of the sprint. Team members do what it takes to achieve this goal. A team member who is getting ahead of the others will actually slow the team down in the long run. Each team member needs to assign himself tasks to help the team. This may mean writing code, running tests, writing automated tests, or writing a test framework to allow faster test automation. If the team is falling behind, every member is falling behind, no matter what he may be accomplishing as an individual.
If you're falling behind on the regulatory documentation, you may be a Scrum-but.
It's easy to think that the Scrum team only writes and tests software, but that's wrong. The Scrum team delivers working code. Code isn't working if it can't be used. If you build the most wonderful user experience, unbeatable functionality, and uncompromising quality, it's worthless if you fail compliance and your software can't be deployed. Make sure all required tasks are completed, including compliance documentation, during the sprint. Don't try to game the system by making compliance someone else's problem.
If failing a customer demo demoralizes your Scrum team, you may be a Scrum-but.
Of course the team would like to hit home runs every time, but that's hardly a realistic expectation. The ScrumMaster helps the team set realistic expectations, including expecting to fail at times. If you discover those failures early and fix them quickly, Agile considers that a success. Analyzing the failure leads to software and team improvements, so failure should never lower morale. This doesn't mean the Scrum team plans to fail; just that it needn't be afraid to fail.
If your team members are afraid to try new ideas because they might fail, you may be a Scrum-but.
Nobody has ever achieved great things without failure. Effective Scrum team members are always doing as much as they possibly can, and they know this because sometimes they overreach. They feel comfortable trying to do so much because they know they won't be faulted for trying to achieve the remarkable. And with that freedom, they will succeed more often than they fail, and amaze you with what they can accomplish. "Can't" kills innovation, and "better not try" paralyzes it. Never let your Scrum team become afraid it might fail.
If your retrospectives focus on who rather than what, you may be a Scrum-but.
Your retrospectives should focus on the way you work together and the tools you use to accomplish your tasks. The thing you don't want is your retrospectives turning into witch hunts. You may have team members who can't meet the demands of the team. Those members will be exposed without the retrospectives focusing on them. Let management focus on the team member skills. Let the team focus on removing the roadblocks to excellence.
Now for a few leadership examples:
If you insist on getting all of your stories defined in detail before you start your first sprint, you may be a Scrum-but.
Traditional organizations aren't comfortable starting until they've argued over every detail. Agile organizations get the stories into the backlog as soon as they have sufficient detail to estimate them and assign business value. The detail gets hashed out later by identifying implementation tasks during the sprint planning meeting. Waiting to define the detail until you're ready to begin work helps the team avoid waste. Why develop these details if they will only change before you get to that story?
If you focus on keeping to the original release plan, you may be a Scrum-but.
Scrum is designed to allow the team to produce excellent software, one sprint at a time. A good release plan is important to help the organization see the goal and prioritize the backlog, but a release plan is not a commitment on the part of the Scrum team. If you focus on guaranteeing the schedule of delivery of future stories, the team will lose effectiveness. If you focus on good backlog maintenance and sprint execution, you'll get the highest-quality software as fast as your team can deliver.
If you're focused more on metrics than on excellent results, you may be a Scrum-but.
There are lots of metrics a ScrumMaster and Scrum team can look at to determine how things are going during a sprint. The value in these metrics is helping the Scrum team identify blockers. The danger is that good metrics can become a goal in their own right. In the end, the team is only successful if the software is released and the customer is ecstatic. Use metrics to identify problems and again during the retrospective. Don't use metrics to try to game the system, which is the opposite of Agile.
If you have to run all decisions through management, you may be a Scrum-but.
You won't achieve hypervelocity if you're constantly waiting for management decisions. Scrum teams need to be empowered to be effective. Management needs to empower the team to make software design and implementation decisions. Management should only be involved when decisions might alter the direction of the project or involve a great expense. If managers are keeping up, they won't need to fear bad team decisions. Managers can also reward teams that make good decisions and escalate correctly. With practice, the team will achieve hypervelocity and make very few decisions management doesn't like.
If you assign the tasks to your team members based on their roles, you may be a Scrum-but.
Agile teams are self-organizing. Team members contribute as they are able, not according to a predefined role. During sprint planning, members assign tasks to themselves and commit to their completion. This gives each member ownership and a sense of responsibility to the team. When a team member takes ownership on his own initiative, he is set up to succeed. If someone else assigns task to him, he may be set up to fail.
If you're using this list to add rules and processes to your Scrum team, you may be a Scrum-but.
Agile is about principles. Scrum is about a lean framework for implementing those principles. Each one of the items on this list is intended to emphasize a principle and show how Scrum helps you implement it. Making the transformation to Agile means making these principles part of your way of thinking, not memorizing lists. While the mistakes I've listed are common, there are many more examples I haven't listed. I hope you enjoy this list. I hope this approach helps you understand Agile. But once you understand, forget this list. Trying to remember a list will only weigh you down.