Scrum For Dummies
Book image
Explore Book Buy On Amazon

Scrum teams can make a number of common but serious mistakes when implementing scrum. Following is an overview of some typical problems and ways for scrum teams to turn them around.

As you may notice, many of these pitfalls are related to lack of organizational support, lack of training, and falling back on old project management practices. If your company invests in transition support and supports positive changes, if the project team is trained, and if scrum teams make an active commitment to upholding the scrum framework and agile values, you’ll have a successful transition.

Faux scrum (cargo cult agile and double work agile)

Sometimes organizations will say that they are “doing scrum.” They may go through some of the scrum events, but they haven’t embraced the principles of agile and are ultimately creating waterfall deliverables and products under the false scrum titles. This is sometimes called cargo cult agile and is a sure path to avoiding the benefits of scrum.

Trying to use scrum in addition to waterfall processes, documents, and meetings is another faux scrum approach.

Double work agile results in quick project team burnout. If you’re doing twice the work, you aren’t doing scrum, nor adhering to agile principles.

Solution: Insist on following scrum. Garner support from management to avoid nonagile principles and practices.

Lack of training

Investment in a hands-on training class will provide a quicker, better learning environment than even the best book, blog, or white paper. Lack of training often indicates an overall lack of organizational commitment to scrum.

Training can help scrum teams avoid many of the mistakes on this list.

Solution: Build training into your implementation strategy. Giving teams the right foundation of skills is critical to success and is necessary at the start of your scrum transition.

Ineffective product owner

No scrum role is more different than traditional roles than that of the product owner. Scrum teams need a product owner who is an expert on business needs and priorities and can work well with the rest of the scrum team on a daily basis. An absent or indecisive product owner will quickly sink a scrum project.

Solution: Start the project with a person who has the time, expertise, and temperament to be a good product owner. Ensure that the product owner has proper training. The scrum master can help coach the product owner and may try to clear roadblocks preventing the product owner from being effective. If removing impediments doesn’t work, the scrum team should insist on replacing the ineffective product owner with a product owner who can make product decisions and help the scrum team be successful.

Lack of automated testing

Without automated testing, it may be impossible to fully complete and test work within a sprint. Most manual testing is a waste of time that fast-moving scrum teams don’t have.

Solution: You can find many low-cost, open-source testing tools on the market today. Look into the right tools and make a commitment as a development team to using those tools.

Lack of transition support

Without the support of professionals and executives who can help guide scrum teams through new approaches, new scrum teams may find themselves falling back into old habits.

Solution: Enlist the help of an agile mentor — either internally from your organization or externally from a consulting firm — who can support your transition. Implementing process is easy, but changing people is hard. It pays to invest in professional transition support with an experienced partner who understands behavioral science and organizational change.

Inappropriate physical environment

When scrum teams are not colocated, they lose the advantage of face-to-face communication. Being in the same building isn’t enough; scrum teams need to sit together in the same area.

Solution: Take action to colocate the team:

  • If your scrum team is in the same building but not sitting in the same area, move the team together.

  • Consider creating a room or annex for the scrum team.

  • Try to keep the scrum team area away from distracters, such as the guy who can talk forever or the manager who needs just one small favor.

  • Before starting a project with a dislocated scrum team, do what you can to enlist local talent.

Poor team selection

Scrum team members who don’t support scrum, who don’t work well with others, or who don’t have the capacity for self-management will sabotage a new scrum project from within.

Solution: When creating a scrum team, consider how well potential team members will enact agile principles. The key is versatility and willingness to learn.

Discipline slips

Remember that scrum projects still need requirements, design, development, testing, and releases. Doing that work in sprints requires discipline.

Solution: Build in the habits of creating working functionality with the definition of done from the project start. You need more, not less discipline to deliver working products in a short iteration. Progress needs to be consistent and constant:

  • The daily scrum helps ensure that progress is occurring throughout the sprint.

  • Use the sprint retrospective as an opportunity to reset approaches to discipline.

  • Review and refine the team’s definition of done regularly.

Lack of support for learning

Scrum teams succeed as teams and fail as teams; calling out one person’s mistakes (known as the blame game) destroys the learning environment and destroys innovation.

Solution: Scrum teams can make a commitment at the project start to leave room for learning and to accept success and failures as a group.

Diluting until dead

Watering down scrum roles, artifacts, and events with old waterfall habits erodes the benefits of agile processes until those benefits no longer exist.

Solution: When making process changes, stop and consider whether those changes support the scrum framework, Agile Manifesto, and agile principles. Resist changes that don’t work with the manifesto and principles. Remember to reduce waste by maximizing the amount of work not done.

About This Article

This article can be found in the category: