In my last blog post, I described the first step on our journey from Engineering to DevOps, which was the formation of project-focused SCRUM teams. SCRUM brings many opportunities for improving the development process, but it’s wise to keep in mind the old saying “SCRUM doesn’t fix problems, it points them out.” This means that the very first thing to emerge from SCRUM is transparency, because it requires us to examine how our teams and processes actually function on a day-to-day basis, and through ceremonies like stand ups and retrospectives, we are asked to clarify our goals and purposes to our colleagues, our customers, and ourselves.
The essence of SCRUM ceremonies is communication, and communication leads to transparency. In standups, making a statement about what you plan to do that day, and what is blocking you, provides a simple way to bring transparency about your work to your team. But it also forces you to be introspective, to be clear to yourself about what you are doing, what the blockers and issues are, and what it is that you can accomplish. More than anything else, stand ups are opportunities for reflective communication that surfaces problems at the same that it seeks to resolve them and move the entire team closer to their goal. The same can be said of retrospectives, but here the emphasis shifts from internal to external communication. From the internal perspective, retrospectives are useful for documenting issues and how they were met, and then using that information for iterative improvement. But they are much more important for communicating to customers that we understand where our challenges are, and that we have ways to deal with them.
The ultimate outcome of transparency is the development of trust. A recent New York Times article described the efforts of Google to find the formula to create the perfect team, and what they found was that, above all, a sense of psychological safety among team members was critical to the overall team success. Team members had to feel that they could bring up issues or ideas without being steamrolled by other team members, or subject to harsh criticism for admitting to mistakes. SCRUM ceremonies provide the opportunity for communication, but for it to be effective communication, you have to trust that your colleagues will really listen to what you say, and they have to trust that you are being honest and open in saying it. This is why one of our core values at Sauce is “It’s okay to be wrong, but not stay wrong.” This is how we try to foster a sense of psychological safety, and trust, among our team members. At the same time, we need to build trust with our customers, which requires that we be open and honest with them, even when it comes to making painful admissions.
This was all put to the test during the Great Holiday Outage of 2015. In the midst of a highly stressful situation, our team was able to root cause the issues and develop a solution because we encouraged open communication, rather than trying to find someone to whom we could assign blame. Without trust and open communication, teams fall apart under stress, because everyone is ultimately forced to look out for themselves. A history of open communication is also essential to maintaining the trust of customers in these situations. Because of these outages, we were threatened with the loss of several major renewal contracts. What saved them was publishing a retrospective that made it clear to our customers that we understood what happened, but, more importantly, that we had taken steps to make sure it wouldn’t happen again.
Communication, transparency, trust – these are the qualities that SCRUM brings to the development process that helps create the environment for successful teams. There are other qualities, like individual empowerment and improved collaboration, that I will write about in future posts, but these are the qualities that are most important in taking the first step in the evolution from Engineering to DevOps. They are the foundations upon which everything else is built, because ultimately they are about discovering who we are, as an organization and individuals, and using that knowledge to build our internal and external relationships.
Joe Alfaro is VP of Engineering at Sauce Labs. This is the third post in a series dedicated to chronicling our journey to transform Sauce Labs from Engineering to DevOps. Read the first post here.