If you have to run all decisions through management, you may be a Scrum-but.
You won’t achieve hyper-velocity if you’re constantly waiting for management. Scrum Teams need to be empowered to be effective. At the very least, this means the organization needs to define the limits of their authority so they can move quickly within that authority and escalate quickly outside of that authority. A better approach would be to empower the team almost completely with respect to software design and implementation decisions, and only involve management when decisions might alter the direction of the project or involve a great expense. If members of the management team are checking in, they can quickly catch mistakes in the decision-making process. They can also reward teams that make decisions and escalate correctly. With practice, the team will achieve hyper-velocity and make very few mistakes.
If your Team is afraid to try new ideas because they might fail, you may be a Scrum-but.
Nobody has ever achieved great things without failure. Put another way, you can’t find out what your limits are unless you exceed them now and again. Effective Scrum teams are always doing as much as they possibly can, and they know this because sometimes they try to do too much. They’re always pushing the limits of their expertise, and they know this because sometimes they try things that are beyond their limits. But they feel comfortable trying to do so much because they know their leadership has their backs. 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 they will amaze you with what they can accomplish. If “can’t” kills innovation, then “better not try” paralyzes it. Never let your Scrum Team become afraid they might fail. They need to spend their time imagining what it will be like when they succeed.
If your retrospectives focus on who rather than what, you may be a Scrum-but.
It’s important to find out if you have team members who are not capable of accomplishing the team’s tasks, but that should not be a focus of the team. The Scrum Master and the line managers can take that up when there is evidence of a lack of ability. Your retrospectives should focus on the way you work together and the tools you use to accomplish your tasks. Sometimes they will look at how you interact with other groups within your organization. Those areas you can change within your team, you change. Those areas that need cooperation from outside your team, you escalate to the ScrumMaster. But be careful of letting your retrospectives turn into witch hunts. As I described above, you can’t afford to let your team members become afraid to try. And if you fall into the habit of finding people to blame, your team members will be afraid.
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 how Scrum helps you implement the principle. If you’re making the transformation to being Agile, you’re making these principles part of your way of thinking, not memorizing elements of a “to-do” list (or “not-to-do” list). While these mistakes are common, there are lots of ways to implement Scrum without truly becoming Agile. There is no comprehensive list, and if I could write one then the list would destroy your ability to remain focused on achieving the goal of your Scrum Team. It would be the opposite of lean. It would be self-defeating. I hope you enjoy this list. I hope this presentation helps you to understand Agile and to be Agile within your Scrum team. But once that goal is achieved, forget this list. Trying to remember it will only weigh you down.