In my last blog post I wrote about the way in which moving to SCRUM teams fosters communication, transparency, and trust, both internally among team members, and externally with customers. Achieving open communication like this is one of the main goals of Agile, but just as important is the development of leadership within the SCRUM teams.
Ideally, every SCRUM team is self-managing in regards to their own work. The Product Owner determines what will get done, the tactical decisions about how it gets done should be left up to the team. There is a simple philosophy behind this: those whose work focuses on a specialized area of the product know better how to improve it, and how much work will be involved, than anyone from outside of that group. The product owner within the team is there to advocate for the customer, and to decide when a minimally viable product is ready for release, but they don’t tell the team what to do or how to do it.
Open communication, transparency, and trust are essential for teams to become self-managing, because these are the foundational conditions that are necessary for the emergence of leaders. Leadership in SCRUM teams is not about titles, it’s about ideas. It’s about contributing to team communications, making decisions based on those communications, and then being able to execute. Because SCRUM leadership is based on an individual’s ability to listen, exercise judgement, and communicate, anyone can emerge as a leader, regardless of whether they have been doing software development for two years or twenty.
When I started at Sauce Labs, there were clear leaders in the Engineering organization, but their efforts were spread thin because they were the obvious leaders, and everyone turned to them for solutions and expertise. One of my top architects was the “official” owner one major infrastructure component of our service. He was also the “unofficial” owner of a second service. In his “spare time” he had developed a customer facing app, so he was de facto owner of that. And, since he had knowledge about other components of the service, he was constantly interrupted with questions from junior developers. For us to move further down the road with our development goals, we not only needed a way to give these leaders focus to their work, but we needed to develop new leaders, and provide the junior members of our organization with opportunities for growth. This was one of the main reasons for implementing SCRUM; while one goal was to bring a more rationalized approach to our development efforts, which we could quantify to management, the larger qualitative goal was to create an environment that would foster innovation and the emergence of a new cadre of leadership.
Naturally, not everyone adapts to this kind of cultural change. Those who have worked in a Waterfall, or even a Fast Waterfall, methodology, are used to being handed instructions, executing on those instructions, and moving on to the next task. If this is the way you have been trained to do things, SCRUM can seem like chaos – where are the functional specs, the technical specs, how am I supposed to know what to do? When we implemented SCRUM at Sauce there were a lot of questions, some resistance, and even some defections. This is all to be expected. Some personalities work better as individuals than as members of a team, and some are more comfortable with self-direction than others. What’s important is that implementing SCRUM helped all of us learn where we are as individuals when it comes to our professional activities, what gives us satisfaction and purpose in our work, and what we are really like within our teams.
Joe Alfaro is VP of Engineering at Sauce Labs. This is the fourth post in a series dedicated to chronicling our journey to transform Sauce Labs from Engineering to DevOps. Start from the beginning and read the first post here, or read the next installment in the series.