Here at PagerDuty, our engineering teams are committed to Agile development principles that favor rapid iteration over lengthy periods of design, and favor direct communication between team members over reams of written specifications. There are countless articles that dictate how Agile teams should operate. Those guidelines are fine as a starting point and framework, but they don’t typically take into account the needs of individual teams. At PagerDuty, we recognize that there isn’t a one-size-fits-all approach to development, and we embrace differences.

Scrum as a Framework

For new teams, we generally start with the Scrum process. Scrum dictates some specific methods and rituals that we use for improved productivity. New teams need this structure for a while. For example, daily standups provide an opportunity for teammates to meet regularly, and those regular meetings encourage the team to operate as a unit rather than as a group of individuals. Another exercise we practice — sprint planning — allows the team to set shared goals and make regular course corrections. We also have Storytime meetings, which allow the teams to get familiar with future work (“stories” in Agile terminology).

But, we treat Scrum as a starting point, not the goal.

Scrum But(t)….

More than anything, at PagerDuty we embrace the idea of continuous improvement. This means that once teams become comfortable with the basics of an Agile environment, they usually start breaking the “rules” and start to make changes to adjust to their own particular style. In the outside world, some people will call this “Scrum But” or “Scrum Butt”  (“we do Scrum but we do/don’t do X…”) — which makes it sound like a disease. While Scrum purists argue that if you don’t follow the Agile manifesto exactly, you’re not doing Scrum at all. At PagerDuty, we recognize that every group of people will want to work differently.

Continuous Improvement over Following the Rules

In other words, at PagerDuty, we implement Scrum in the way that makes the most sense for our individual agile teams. Our engineering teams have retrospective meetings regularly (usually every 2 weeks). Arguably the most important part of those meetings are the changes that the team suggests to improve the processes to make the team happier and more productive. Those changes can be very simple, like making small tweaks to their workflow, or adjusting the time we meet for the daily stand-up meeting, or skipping stand-up altogether on self-imposed “meeting-free days”. Some teams decide they primarily work in a co-located office environment, but many teams value the ability to work from home and in some cases, most of the members of a given team will work remotely. Some teams find that sprint demos motivate them to complete their sprint tasks, while other teams will decide that staying focused is sometimes more important to them than demonstrating half a feature. In some cases, teams have decided to ditch Scrum entirely and have switched from Scrum to Kanban.

Empowerment is Key

Regardless of the nature of change, teams are empowered to adjust their processes and to figure out what works best for their particular needs. Our teams are not afraid to make a change to their processes. If it works, it stays. If it doesn’t work, we try something else. We’ve found that it’s more important to adapt processes to meet specific needs and preferences than it is to follow arbitrary guidelines.

Over time we’ve seen that every group of individuals will develop their own particular style of working, and just like individuals, every team is uniquely different. Every team has its own strengths and weaknesses but, most importantly, every team is the best judge of determining what process works best for themselves. While standardized guidelines can be a good starting point, teams must be encouraged to constantly look for ways that they can change themselves and their processes to be happier, and ultimately, more effective. Tools and processes should be implemented and adjusted for the purposes of empowering, not bogging down, the people using them.