May 2005 (my first agile article; rough but from the heart)
Part 1 – The Sheepdog Unleashed
In late 2004, my company decided to adopt Scrum. We wanted to remain responsive to our customers as we continued to grow. A few of the engineers in the company had been experimenting with agile practices (mostly XP practices) and were willing to start pilot projects. My team consisted of 6 team members in Philadelphia and one other team member and myself in Orlando. For the previous year, I had been project lead and a developer on this team. As part of the pilot project, I would become the team’s ScrumMaster as I was the most knowledgeable in agile practices.
I was psyched! I was excited! I was going to be part of the revolution toward enlightened software development! I was going to be…a sheepdog? When you go through ScrumMaster training, you are quickly introduced to the metaphor of ScrumMaster as sheepdog. You’re not there to be part of the team. You’re not there to lead the team. You’re there to keep the team out of trouble and to keep the wolves of scope creep and interruption at bay. Occasionally, you may need to show alternate paths, but you are not there to tell the team the path to take. Agile teams are self directed.
I felt I was ready. I had facilitated and lead many groups with some wide ranging skills, personalities and backgrounds. I had introduced stand ups, pair programming, refactoring, continuous integration (and related tools) to several colleagues and my team. I had been serving as an agile coach and mentor. I was well read on multiple agile practices, and though not familiar with the details of Scrum, I quickly absorbed the philosophy.
Part 2 – Sheepdog Schizophrenia
One of the first challenges encountered was changing the team’s perception of my role as project lead to the role of ScrumMaster. There were three senior developers and some very talented mid-level and junior developers. But, all of us had become accustomed to the command-and-control role of a typical technical project lead. Even after a few training sessions, I still had some team members ask for approval on approaches to accomplishing tasks. I would often redirect them to the team for this approval. However, I found that I was having a difficult time changing my own thinking. When things became hectic, I would often find myself “strongly suggesting” an approach or providing “approval” of one developer’s design without consulting the team. I was developing the schizophrenic mindset of being project lead and ScrumMaster and not fully transitioning myself.
The other challenge was being the ScrumMaster of a team 1000 miles to the north. It was further complicated by having a customer that was roughly 1000 miles to the west. It was sometimes difficult to gauge the team’s real progress beyond the daily stand up meetings. I was not there to read their faces and confirm that body language was in agreement with spoken language. It was even more difficult to get a sense of the team’s energy level. Were they feeling burned out? Were they compelled to work too much overtime? Did they feel they had the information they needed to accomplish tasks? Daily stand up teleconferences and instant messaging helped, but it was no replacement for being there. It was also difficult to gauge how well our product owner was in sync with the team. He was an overtasked program manager with several projects to oversee across multiple cities. While he was based in Philly with the team, he rarely had the luxury of staying in Philly. He was the team’s link to the customer and user communities and set our priorities. But it was difficult for the team to check in with him when issues arose even though he did his best to support us.
These obstacles lead to numerous problems. One problem was the numerous interrupts the team received. As we were a growing small company, many of us were accustomed to wearing several hats. In a way, it made us feel more a part of the company. We were entrepreneurs. So it was not unusual for team members to receive requests to support marketing, business development activities, IT, interviews, and more. Sometimes the requests were with a day’s notice or less. Of course, it caused some non-zero burndowns in our first few sprints. Not being co-located with the team, it was almost impossible to intercept these requests and filter the “critical” from the “would be nice”. A sheepdog can’t chase wolves on the next hill.
This dislocated, schizophrenia became apparent when I realized the team and product owner was asking me questions on items in the sprint backlog and product backlog. I realized I had slowly taken control of the product and sprint backlogs under the guise of relieving the burden on the team and the product owner. The team would update estimates, but I was “helping” to define the tasks. I was performing similar oversight for the product backlog and felt I was helping the product owner. What I was really doing was being a project lead and not a ScrumMaster. I was not empowering my team. I was controlling them and the project.
Part 3 – Sheepdog Reloaded (or…what worked)
Some might feel that an agile team cannot operate in these conditions. All was not lost though. While the impediments described previously hindered our adoption of Scrum, there were also some factors in our favor. The company had many individuals, including senior managers, who were willing to experiment. Scrum was the suggested process framework, but the teams were allowed to make some alterations. In our company culture, expert meant “willing to learn more” and we were growing our expertise daily. Also, there existed a culture of building relationships. Teams were encouraged to build relationships with their customers; senior management worked to build relationships with the teams. We were all learning that if you don’t understand the person and their environment, you will likely not understand their requirements for success. Several of us worked diligently to gain this understanding of others’ roles and it was a key factor to adoption. We may not have always agreed on the approach, but we always listened to each and worked together on solutions.
I also employed some new practices. After reading a paper from Thoughtworks on their distributed agile practices, I adapted their concept of ambassadors between teams. I asked one of the more senior members of the team to serve as my proxy sheepdog in day-to-day activities where I could not be physically present. He would intercept the wolves of scope creep and interruption and redirect them my way. Once some additional trained ScrumMasters were introduced into the company, I asked them to assist in this capacity as well as help moderate reviews and planning meetings when I was unable to travel to the location of the meeting.
The personal practice that also helped in the transition was to not touch the sprint backlog. This included not signing up for tasks in the backlog. This was incredibly hard for me at first. What was I supposed to do? Everyone had tasking on the backlog but me. However, there were more than enough impediments for me to chase down each day and make sure they were either removed before they impacted the team or make them highly visible. This was not too different from some of the duties in my project lead role.
Retrospectives became extremely valuable to the team. It was our time to step back and see if we were effectively following Scrum practices, if certain practices were becoming more of an impediment than an enabler, and to come up with alternative practices to reach goals more quickly. This was where the learning really occurred for this team. Also, this is where I let the team steer themselves to new solutions and practices. Where a new practice was not easily conceived, I would suggest a practice. This is where being a member of the team was actually valuable. As a team member, I understood the pain the team was trying to resolve. I could then suggest a new practice and then sell them on the value of the practice by showing them how it could resolve the particular pain.
Seeking learning opportunities outside retrospectives became another key practice. Anytime I interacted with the product owner, the team, or someone outside the team, I would use the opportunity to find out what they did not know about Scrum and introduce them to a practice that would help them understand how to work better with the team. These just-in-time tutorials also became learning sessions for me. Two key phrases that I became constantly reminded of from ScrumMaster training is that “Scrum will not solve your problems; it just makes them highly visible” and “If a problem is causing you a headache, it’s probably not your problem to solve”. As I had more interactions with people inside and outside the project (the chickens and pigs), I learned to embrace these two phrases. In one Sprint Review, the team went in highly demoralized. The impediments had become insurmountable and very few stories were completed. We had a large audience of stakeholders (from senior management and sales) and there were many questions on “why was this not done?” I focused on making all the problems highly visible and our stakeholders soon realized that the team was not equipped to remove the obstacles in the sprint. The entire team had headaches, including the ScrumMaster. The stakeholders quickly resolved to alter the product backlog and agreed to a sprint that focused on getting feedback from the customer that would help clarify many of the issues facing the team. The sprint review shifted from very tense to very focused. Everyone had a sense of what needed to be done and the team was empowered to develop a sprint backlog that would help them focus on resolving the issues in the next sprint. Many of us were reminded that day that learning can often be painful, but is always valuable. The key is to maximize the value and minimize the pain with early discovery of non-optimal conditions and approaches.
Epilogue – Sheepdog at Home
By making some of the problems of remote ScrumMasters highly visible to my fellow ScrumMasters in the company and the product owner, I now have a new co-located ScrumMaster assigned to my team and I will serve as ScrumMaster for new projects starting in my office. While I feel a sense of loss in no longer working with my original agile team, I am also quite confident in their knowledge of agile practices and in self managing their way to success. I also am looking forward to being the sheepdog in my own pasture. Woof!
This article was previously published in the Summer 2006 edition of AgileDevelopment.com (no longer available). A shorter version appeared on Michelle Sliger’s site in 2010 at https://www.sligersolutions.com/lightbulb/mark-kilby/.