The secret to handling development teams who dislike Scrum

It can be challenging to be a Scrum master when your team is skeptical of the Scrum methodology in the first place. This attitude can hamper your project progress, erode developer trust, and distract from your goals. But approaching Scrum issues the right way can help bring the project back on track. 

Why Scrum is “bad” 

Scrum has developed a certain reputation among developers, whether it’s deserved or not—many view it as “pro-management” and inherently anti-dev. At some companies, toxic management practices such as micro-management and the use of arbitrary deadlines were labeled as Scrum or advocated by coaches claiming to practice Scrum methodology. 

As a result, a lot of developers equate Scrum with taking shortcuts that create excessive technical debt, constraining development activities with red tape, or rushing to finish work too quickly. 

Potential problems with Agile and Scrum 

Although Agile and Scrum began within the programming world, they were soon popularized by project managers. Scrum and Agile are often used interchangeably but are in fact distinct: Scrum is a way to implement Agile, so there is overlap, but we shouldn’t always generalize Scrum to represent the full breadth of Agile. 

In a similar vein, you might want to remember that many of the complaints and concerns about Scrum and Agile are intended as critiques of unhealthy business and project management practices. These critiques are not intended for the positive and practical attributes Agile and Scrum can bring to development. After all, these did both originate in the developer world as solutions to development-centered problems.

Regardless, there are a few areas companies practicing Scrum and Agile should be aware of: 

Shortchanging slices

Managing dev teams by the “slice” of time can fall short if it just becomes a way to give your developers less time to accomplish a large request. 

Hiring or promoting inexperienced coaches or project managers

Eager to build a career in the new Agile world, a large number of project managers saw Scrum as an opportunity to pivot into consulting for work they themselves lacked real-world experience in. This has occasionally subjected developers to project managers who didn’t know enough about software development or the Scrum practices they were advocating for. Since few teams enjoy working with project managers who are inexperienced in the industry, this situation understandably led to some resentment.

Micromanaging smart people

For some, Scrum’s push for accomplishing goals within limited deadlines seemed like permission to enshrine micromanagement inside the organization. Instead of promoting communication, daily Scrum meetings were blame sessions. Some developers saw these meetings as stifling communication and creating additional red tape that hindered their work. 

Setting arbitrary goals

Agile and Scrum often do help companies accomplish more in a shorter period of time, but this may encourage managers to believe that any arbitrary development goal can be achieved with a bit of project management magic. If managers set arbitrary goals, development teams can become discouraged and frustrated. This is particularly true when goals are impossible or impractical. No one likes to be told they’re not doing their job well. 

Of course, many (if not all) of these criticisms are well-founded and present real risks for your organization if you’re not careful. 

How to approach development teams who dislike Scrum

With a team that’s opposed to Scrum, you may have your work cut out for you. Your developers are likely to instantly detect bad Scrum and voice their opposition to it. 

This resistance, though, should actually be welcomed as a sincere interest in improving your development processes. If you have a development team that cares about quality and values writing excellent code, then that’s truly a blessing for your company and your business goals. 

To reframe and improve how you use Scrum in your organization, consider how these ideas may help. 

1. Determine if Scrum is really the best fit 

If your application of Scrum techniques doesn’t feel like it’s working or it isn’t resulting in tangible value for the organization in some fashion, perhaps Scrum isn’t really the right fit for your team’s projects. 

One important point to keep in mind: Scrum is not one-size-fits-all. Not every project, team, or company fits Scrum or should use it. Consider asking yourself pointed questions to make sure Scrum is right for you: 

• Product lifecycle stage: Is my project related to a new product or feature? Scrum works best with products that are early in their lifecycle. If your product is reaching maturity, Scrum might not be the best fit because mature products have less uncertainty and fewer unknowns. Early in the lifecycle, the iterative nature of Scrum methods provides a much-needed structure to help you ask the right questions and lead the discovery process with a new product.

• Team size: How big is your team? Is it small enough to be engaging in ongoing, direct communication? Larger teams may struggle with Scrum because it’s designed to foster that iterative process associated with new product development and fast-growing new teams.

• Customer involvement: How involved are your customers in the development process? Scrum needs frequent check-ins or feedback from end-users and customers in order to drive the iterative, experimental process behind development. A lack of customer feedback leaves Scrum projects with relatively little insight to guide development forward. 

There are alternatives to Scrum that might be a better fit if your project falls outside of the above characteristics. Consider one of these options if you’re looking for something new:

• Kanban methodology: A smart system for a variety of different types of projects, Kanban methodology is another means of implementing Agile in your organization. Kanban is based on visual project management principles used to improve car manufacturing in the 1940s. Since Kanban is very flexible and can also be used with elements of other methodologies, it may be a better fit if Scrum doesn’t work for your team. 

• Waterfall project management: If your project has few unknowns and follows a well-established process with specific steps, then Waterfall project management may be right for you. 

• Other Agile methodologies: Aside from Scrum and Kanban, there are many other flavors of Agile development. Crystal, Feature Driven Development Method (FDDM), Dynamic Software Development Method (DSDM), and Extreme Programming (XP) are all examples of other Agile methods worth considering. 

2. Invite more developer input 

With any software project, be sure to invite developer input on deadlines and other issues. If your development team is resisting your plan of using Scrum methods, it’s time to find out why. Their concerns could have merit and allow you to make valuable improvements. 

• Ask about deadlines: Find out what deadlines your team believes are realistic and why. These questions can help you identify potential problems earlier, too, and provide an opportunity to start brainstorming possible solutions. To do this, consider estimating story points, establishing the risk, complexity, and repetition associated with project sprints. 

• Find the right motivation: If your team isn’t connecting with the goals and direction you set, it’s possible that you need to dig deeper to find what is motivating your software team. Take the time to build better rapport, too. 

• Ask for feedback: Involve your developers and ask for their input not just on Scrum, but on important decisions you make as a team as well. 

• Give credit where it’s due: If your team inspired an idea for a new feature or unique approach, be sure to call this out and recognize it so your developers see the real impact they have at work. 

3. Cut unnecessary meetings 

The daily Scrum meeting is meant to foster communication and collaboration, but sometimes meetings are perceived as a waste of time and resources. 

• Meet when it’s necessary: Just like an awkward silence you’re tempted to fill, a meeting without a clear purpose could quickly take on an agenda, even if it’s not normally valuable content. Avoid meeting for the sake of having a meeting—keep meetings focused and save everyone more time. 

• Think outside 30-minute blocks: Although our calendars are in one-hour or 30-minute increments, there’s no reason you can’t have a seven-minute meeting or finish a one-hour early after 45 minutes if you’ve already covered the items on your agenda. 

4. Be flexible and adapt your strategy if needed 

Strategies are intended to move your business forward. If they aren’t serving your team anymore, it may be time to rethink and regroup. Cut your losses and don’t worry about admitting that a methodology isn’t a fit or no longer fits anymore. 

• Choosing another methodology: If Scrum is no longer fitting your needs, consider another Agile flavor (such as the other methodologies discussed in the section above). 

• Changing mid-project: If possible, you may want to stick with Scrum until you reach the next milestone or finish a project. Adjusting how the project is organized in the midst of working on it as a team may interfere with your goals. 

5. Seek experienced leadership 

Bringing in people who are experienced in Scrum can help you navigate new development journeys, but Scrum experience isn’t the only important thing. You also need leadership that knows the development process.

• Find experienced PMs: Project managers who have limited experience with technical projects or lack a software background may not be as successful with Scrum as those who’ve already been in the trenches.

• Be wary of those with just credentials: Scrum credentials indicate knowledge of Scrum methodologies, but you’ll still need to look closely at Scrum coaches’ backgrounds and experience. 

Use Scrum more effectively

Scrum is only effective if your team plays along, so do what you can to win them over and make your project a good experience for everyone. Don’t forget to embrace the Agile spirit of continuous improvement in the process.