Though Agile methodologies have been around for decades, more and more companies are adopting them as projects become increasingly technical and robust.

It’s easy to understand the shift. The traditional Waterfall approach isn’t nearly as effective as working in small iterations towards a product you can introduce quicker then use to learn from customers. The Agile process is managed by a ScrumMaster, instead of a traditional Waterfall project manager. ScrumMasters are team protectors and the occasional cheerleader. They are the go-betweens for the product owner and the team of developers. If deadlines set by a product owner are not attainable, it is the ScrumMaster’s job to protect developers from derailing the current sprint.

Alternately, when the team beats their deadline or completes a major product push, it’s important to draw attention to their successes with kudos. When goals aren’t met the ScrumMaster will investigate what didn’t work and change the process to create future success.

Here are a few principles I’ve learned about when to break the rules for the success of Scrum projects, and why I’ve seen them help teams and products to be more successful.

1. The Best ScrumMasters Know When to Be Agile Themselves, and Simply Break the Rules.

Traditionally, ScrumMasters are seen as influencers, with influence granted by the team they’re leading. The process can be altered to help shape results, but it’s impossible for the ScrumMaster to lay down decrees.

Their domain is the ability to guide, not control, process. (The Agile and Scrum experts at Mountain Goat Software believe a “ScrumMaster can also be thought of as a process owner for the team, creating a balance with the project’s key stakeholder, who is referred to as the product owner.”)

While developers should self-organize and assess the number of tickets they can handle within each sprint, the ScrumMaster investigates what didn’t work when goals aren’t met and modifies the process going forward.

That said, as a Certified ScrumMaster I have found that I am a bit of a rule breaker – and you should be too. Agile is very hard to maintain in its purest form unless you have the perfect environment. In software development, no environment is perfect! Ultimately, every good ScrumMaster must know when to break the rules to meet their environment. What’s typically considered best practice is not always best.

2. Don’t Let Process Get in The Way of Getting Work Done.

Many ScrumMasters believe that, once you hit “start” on a sprint, everything is set in stone and nothing can be done to alter it. There is some truth to this. Ideally, you don’t want to add large numbers of tickets to a sprint after you have begun. It reflects poor sprint planning and may allow for tickets that don’t match up with your current sprint goals. I do enforce the rule that, before any ticket is brought into a sprint, the ScrumMaster and Dev Lead for that team need to be notified. Two-part validation seems to be the ticket (pun intended) within my teams.

The caveat here is that, when you are dealing with any kind of major product release, rules sometimes get thrown out the window. As we all know, product launches are essentially controlled chaos. You have to be willing to flex. My mindset shifts from “we have to follow the process” to “we have to solve the problem.” Figuring out how to break the problem into manageably-sized tickets to pull into the sprint quickly can be a huge help to a team that is scrambling to determine the root of the problem.

3. When You Own It, Balance Your Project Management Duty with Your ScrumMaster Role.

I work, as do many others in our industry, with expectations around billable hours, real budgets, and timelines. These elements are sometimes anti-agile and allow for less customer discovery, but they are still a reality you can’t ignore. Budgets and timelines don’t stretch off into the sunset for most businesses. Rather, they come with deadlines! Being cognizant of what developers are working on toward a deliverable is important, tracking the hours is even more so. Velocity is a key component to this. Monitoring how much work is getting done against hours is a great metric for progress to report back to clients. Developers may not like tracking time or putting hours into a ticket, but it can be paramount for some projects.

Sometimes the “let’s try it and if you don’t like it we can discuss” approach can help the team get started until they realize the business value. It may not be a good fit for your team, but if you aren’t iterating on your own project management, you may ask yourself: Why not?

4. Know When to Push Back and Help the Product Owner.

Agile product management consultant Roman Pichler, whose agency has worked with companies like Adidas and Siemens, calls the product owner “the individual who champions the product, who facilitates the product decisions, and who has the final say about the product, for instance, if and how feedback is actioned, or when which features are released.”

I have seen scenarios unfold at other companies where the product owner is constantly shifting the tides on a sprint, and there are broader consequences the ScrumMaster can help the product owner understand. For example, this can be demoralizing for the team and make everyone else focus on objectives. Plus, planning for goals that are no longer relevant renders the backlog grooming and sprint planning ineffective. Finally, if you are working with billable time, regular backlog grooming and sprint planning are expenses to the client. It’s important to make sure that the financial and team impact is understood before decisions are finalized.  

In traditional Agile, the ScrumMaster has no decision-making authority. I bend that rule a bit to try and be more of a consultant. Unless there is a legitimate reason to alter the goals, it can be helpful to take a stand to help decision makers understand the big picture. At the end of the day, we’re managing the success of a product, plus the reality of a budget, and the happiness of a team.

The theory of Agile and the art of practicing Agile seem to be two different things. I don’t think they should be. Sometimes you need to be agile with Agile. Simplifying and modifying processes so that teams can deliver better products is what I strive to do. So go ahead…break the rules when they need to be. It may help you all succeed!