Removing roadblocks and write code. Can one individual be expected to do both? This report describes a Scrum Master that also took on the role of a Team Member where he was required to lead a team with little to no Agile experience or knowledge. The role of a Scrum Master has definitely changed since the inception of Scrum. Today’s Scrum Masters are pushing teams to be more self-organizing than ever to the point where they may no longer need a Scrum Master. On the other end of the spectrum, Scrum Masters are filling voids wherever they may appear (i.e. removing roadblocks). This should not be a surprise considering we expect Team Members to build up their T-shaped skills. Should we not expect the same from Scrum Masters?
1. INTRODUCTION
This experience report explores a project where the Scrum Master (the author of this paper) also participated as a Team Member. While some would disagree with this approach, we did not feel this went against the generally accepted role of a Scrum Master. Furthermore, there are documented experiences where this tactic has worked well.
In 2017, a 10-month project was undertaken for a client in the United States. Their industry is power utilities and they required the assistance of our 7-person team to re-align their power accounting system with the business. Their application got to a point where it was riddled with technical debt mostly because it had been neglected by a previous software vendor. The Scrum Team was employed by the newly hired vendor to fix the existing defects and introduce new functionality to accommodate the changes to the business. Furthermore, the team was formed based on availability and having worked together on a previous project. The client was not looking for a re-write of the software and our early analysis agreed with their direction. Most of the project team (on the vendor side) was located across Canada with the exception of the Project Manager who was located in Winnemucca, Nevada. Myself along with our collocated team members were based in Calgary, Alberta and the others resided in Edmonton, Alberta; Vancouver, British Columbia; and Toronto, Ontario.
Having participated in previous Agile projects I was excited to proceed with this endeavor. The team looked to me to educate them on Agile and Scrum. At this point in my career I felt this was a good challenge. I would have preferred to have the team formally trained on Agile prior to the start of the project. However, I felt that my request for training would have been denied mostly because our Project Manager was not in support of Agile. Trying to instill the Agile mindset, I held short sessions with the team to introduce some of the concepts. One of the things I focused on was the importance of continuous integration (CI). In the beginning, the team had a hard time understanding why it was important and were frustrated by the additional tools that are required to make it work effectively. After the first few sprints their opinion changed as they were able to deploy to production multiple times during a sprint with the click of a button.
Prior to the start of the project, the team decided they would like to try Agile because they were unhappy having worked most of their careers in a Waterfall fashion. The idea was presented to the Project Manager (also employed by the new vendor) who did not agree and felt that Agile would fail and the client would not be accepting of it. Regardless, the Project Manager allowed the team to present the idea to the client. Even though the client was unfamiliar with Agile they were enthusiastic about the concept and very eager to see progress every two weeks. The client immediately agreed to take on the role of the Product Owner. The team decided to use Scrum, mostly due to its popularity and recommendation from myself. I felt the prescriptive nature of Scrum would be a good fit because the team was inexperienced with Agile.
2. BACKGROUND
Whether you are using Scrum or not, the Scrum Master role is one of the most recognized in all of Agile. It may also be the most controversial. Some believe the Scrum Master should also facilitate the Project Manager role. While others believe the Scrum Master and Product Owner roles should be filled by two different people. It is not uncommon for some organizations to mandate that each Scrum Master be responsible for just a single team. So, what is the right answer? What is the role of the Scrum Master?
The Scrum Guide indicates that the Scrum Master is a servant-leader for the Team but also serves the Product Owner as well as the Organization. The Guide depicts 17 bullet points containing verbs such as; helping, facilitating, coaching, leading, etc.
Mike Cohn describes the Scrum Master as a process owner who is responsible for making sure the Scrum team follows the Scrum values and practices [2].
While Bass identifies 6 Scrum Master activities including; Process Anchor: the process anchor mentors team members in scrum method use, Stand-up Facilitator: the stand-up facilitator conducts coordination,
meetings within a team, Impediment Remover: the impediment remover eliminates work blockages for team members, Sprint Planner: the sprint planner helps select and estimate requirements for implementation, Scrum of Scrums Facilitator: the scrum of scrums facilitator conducts coordination meetings between teams, Integration Anchor: the integration anchor facilitates amalgamation of software elements [3].
At first, the role of a team member may seem obvious. Some feel that the role of a team member in a software project is to simply write code. While that may be the case in Waterfall projects, the role of a team member is quite different when using Scrum. The Scrum Guide describes the development team as self-organizing, cross-functional, being accountable [1]. In terms of self-organizing, the guide further expresses that not even the Scrum Master can tell the team how to do their work. This suggests that in an ideal situation the Scrum Master is not part of the team. However, the guide does not specifically mandate that.
Prior to this project I had performed the roles of Scrum Master and Team Member. However, I had never performed both roles at the same time. Based on my research I knew it was feasible but I also knew there would be surprises as well as obstacles to overcome.
3. THE JOURNEY
The team was filled with senior resources with good experience. But not only were they inexperienced with Agile, they were also new to Agile tools and techniques. None of them had ever used a continuous integration server. Other concepts like relentless refactoring, test driven development, pair programming and collective code ownership were also foreign. Most of the team had recently worked together on a project (for the same client) that was run in a Waterfall fashion and I sensed they were dissatisfied with the way the project was run. To reaffirm my suspicions, towards the end of the previous project I asked the team if they were happy with the project. Even though we were on pace to deliver everything on time, everybody said “no”. They were unhappy being forced to follow an MS Project Plan that did not represent reality. They also felt that the weekly status meetings did not provide a lot of value and most things were just repeated. Next, I asked them if they were willing to try something new and there was a resounding “yes”. I proposed Agile, more specifically Scrum and everyone agreed.
Our next task was to convince our Project Manager that Agile was a good methodology for our upcoming project. The immediate response was not favorable. Our Project Manager was convinced that Agile could not be implemented successfully because she had seen it fail on previous projects. However, she was willing to let us proceed as long as we could get the client to agree to it (which she highly doubted). On our next visit to the client, we discussed it with them and the reaction was quite encouraging. They were open to trying something different and were very excited about seeing progress every two weeks. Also, they had no issues with performing the role of the Product Owner.
With everybody in agreement on our methodology, I proceeded to put together a release plan based on Mike Cohn’s recommendations [4]. The developers were busy wrapping up another project and were not available at this point in the process but would be available prior to Sprint 1. Working with the Product Owner, the requirements engineer and myself came up with user stories. Most of the stories were business stories but some were technology related based on our recommendations. Since nobody was familiar with Agile estimating I took it upon myself to suggest an estimating technique that would later be used to produce the project plan. The Project Manager was hesitant at first because she preferred estimates in terms of hours or days but ultimately agreed to use story points and remain hands off in terms of estimating. The Product Owner decided to trust our estimates before we provided them mostly because they had very little technical knowledge. In order to estimate, I needed to come up with a baseline. Essentially, two points referred to a minor change like adding a field to a screen, five points referred to adding a new read-only screen, and 20 points referred to adding a new screen with full CRUD [5]. The next step was to estimate the user stories grounded by the baselines I had outlined. Even though I was not considered a Team Member at this point, I came up with the estimates mostly because the rest of the team was busy wrapping up the previous project. With the estimates in place I now needed to lay out the user stories into sprints. In order to do this I needed to determine the team’s velocity. With no historical information to rely on I ultimately had to guess. I came up with 50 story points per sprint as our anticipated velocity. However, I asked the Product Owner to allow the team to take on an improvement story every sprint which would not exceed 3 story points. The Product Owner agreed to this request which meant we were committing to 47 story points of predetermined backlog stories. Our improvement stories incurred the same amount of time every sprint and introduced Java frameworks (e.g. Spring Data & JUnit) that increased our velocity in later sprints. With the metrics in place I was able to complete the release plan which presented a project plan over the course of 10 months.
It was never the intent for the Scrum Master to also function as a Team Member and it was agreed (by my direct boss and the Project Manager) that my job would only entail the Scrum Master role. However, the team realized their Agile inexperience would hinder their ability to get off to a good start and do Agile the way it was intended. As a result, they asked that I also participate as a Team Member. I had reservations at first mostly because I wanted to be sure I could perform both roles well but I ultimately agreed to the challenge.
With my newly combined role as both Scrum Master and Team Member, I insisted that the team incorporate various tools that would make us more productive. This began approximately one month before Sprint 1 (see Figure 1). I was concerned that we would not be able to get all the tools installed and configured before the first Sprint but having something was better than nothing. The complete list of tools can be seen in Table 1. The team was frustrated by the volume of tools and the required setup time. They were not convinced these tools were worth the effort but agreed to trust me and proceed accordingly.
Figure 1. Project Timeline
Table 1. Tool Listing
I have to admit that I expected Sprint 1 to be a complete disaster. After all, the team was new to Agile/Scrum, they were new to all of the tools, and they were still fairly new to me as a leader. I expected the storming phase of the Tuckman model to directly impact our velocity. In fact, I anticipated the first 3 sprints would result in storming. While there was some chaos the team persevered. Even though I was expected to contribute as a Team Member, I was fairly hands off in terms of coding. This was intentional as I wanted the team to fail, but more importantly I wanted them to fail fast. For instance, I constantly suggested they commit their code multiple times a day which was largely ignored. By waiting until the end of sprint, the team spent almost an entire day resolving merge conflicts. I predicted my hands-off approach would teach them a lesson early on that would help them in later sprints. But also, there just was not enough time to participate as a Team Member. I had to educate the team on how to do sprint planning, daily scrums, sprint reviews, and sprint retrospectives (see Table 2). Sprint 1 concluded with the team delivering everything they committed to in sprint planning and mildly exceeding 50 story points which included their improvement story.
Table 2. Sprint 1 Scrum Ceremonies
Having exceeded my expectations early on, over the next few sprints the team continued to perform well. They were able to present small pieces to the client for feedback early in the sprint (usually by day 2). I constantly wore the Scrum Master hat, reinforcing the Scrum rules and removing roadblocks. I also wore the Team Member hat by working on user stories and participating in pair programming when needed. During a typical day, I would rotate between the roles many times (see Table 3). During my coding blocks, I was always available to the team. It was often the case where I would stop what I was doing to answer a question, respond to an email, or pair program with a developer who was running into an issue. Even though this took time away from my tasks, it allowed the Team Members to be productive with little downtime. As for the team, they were largely immune from outside noise. When the Project Manager had a request, it typically went through me and I dealt with it. For the most part, I was able to shelter the team so they could focus on value-added work and not be bogged down with insignificant tasks.
Table 3. Typical Day
Trying to do both roles was quite time consuming. A 12-hour work day was quite normal for me and I knew I could not continue doing this for the entire project otherwise I would get burnt out. However, I felt that everything I was doing was necessary for the project to be a success. After the 4th sprint I decided that it was time to build the team up to not be so reliant on me. I felt my only two options were to have the team take on some of my Scrum Master tasks or I take on much less technical tasks. I decided that the team would be in a better position if they took on some of my Scrum Master tasks so I could continue to participate as a Scrum Master and a Team Member.
At this point in the project, I felt I had a lot more technical skills to teach them and it would be difficult to do so without being heads down in the code with everyone else. I proceeded by asking the team to volunteer to facilitate the next retrospective. Again, I wanted to give the team the opportunity to fail fast. If the retrospective turned disastrous it would only be visible to the team. Unfortunately, nobody volunteered to facilitate the retrospective. I was not surprised because I knew the team did not have much experience with facilitation. But I was not deterred. I brought it up again at the next after-sprint team dinner. It took some convincing, but I finally got a volunteer. Everyone enjoyed having someone else (other than me) facilitate the retrospective so much so that others started to volunteer. After that, there were few times where I would run the retrospective. However, I continued to put in 12 hour days because I felt it was necessary. The team recognized this because they would see my emails come in at odd hours and the build server was an indication of when my late night commits would occur. To my surprise, the team started to put in long hours as well (not quite 12 hour days but more than 8). This allowed us to accomplish more work than originally planned for. While this leadership style may be unconventional I do feel it encouraged the team to support each other even more because they were all enduring the same exertion.
I also wanted the team to get a feel for the Scrum Master role so I suggested that we rotate the role amongst the team every sprint. I felt this would help to enforce the Agile mindset and set them up for success on future Agile projects. The team was open to the idea so we began the transition in the very next sprint. Aside from enforcing the rules of the daily scrum, just about everything else still came back to me. Even though I tried to shift the Scrum Master duties to the acting Scrum Master, everyone was comfortable with me doing the actual work behind the scenes. They were particularly uneasy when it came to corresponding with the client directly. Even though we continued switching the Scrum Master title, I continued to perform the role. Looking back, I should have had the acting Scrum Master shadow me before they took on the role. I think this would have better prepared them and maybe the experiment would have had better results. With that said, at this point in the project I started to notice that team required less coaching than in the beginning. For example, they started to gain an appreciation of why estimating using story points was much more effective than estimating in days or hours.
I also felt it was my job to teach technical skills as well which probably falls under the Scrum Master and Team Member roles. I noticed we had very few automated tests and would benefit by incorporating Test Driven Development (TDD) [8]. I scheduled a meeting to show the team how to do TDD with actual code from the application we were working on. Everyone liked the idea but did not quite appreciate the value. Their argument was that TDD takes too long. I could not get them to see the time it would end up saving them. As a result, we did not do TDD and relied on minimal automated tests combined with manual testing as quality assurance. I was disappointed that the team would not perform TDD. However, this learning opportunity taught me that everybody has a different Agile journey and even though I accepted TDD early in my Agile development, I cannot expect everyone to do the same. Despite the reluctance to do TDD, the team did accept other extreme programming practices like refactoring and simple design. I was able to pass on this knowledge whenever I would pair program.
Another technique I tried to pass on to the team was mob programming [9]. I thought this would work well considering the team had adopted pair programming. In our first session of mob programming I started things off by taking the keyboard and mouse. As I coded, I asked others would we should do next and I passed the keyboard and mouse to the individual who spoke up. We continued doing this and were able to complete the user story in just a few hours. Despite the success, the team did not want to continue using mob programming. I never really understood why, but I got the feeling that some team members felt they were doing most of the work while others just sat back.
As we progressed through the project, the 2-week sprint cadence became a way of life. We knew our velocity was increasing and the stakeholders were happy so we continued with what we were doing. However, we did not realize how quickly we were burning through the backlog. In fact, we completed the project 3 months early. The client was so happy they did not want us to stop. Instead, they asked for more capabilities. They took our number one recommendation and we proceeded to replace the user interface (UI) framework. We replaced Google Web Toolkit (GWT) with JSF PrimeFaces. During this time, I was definitely more of a Team Member than a Scrum Master. I was heads down with the team resolving issues with PrimeFaces and pairing up with anyone who needed help. During this time, our velocity crept up to almost 500 story points which is 10 times what we started with.
By the time we finished the UI replacement there was 1 sprint left in the project. Again, the client asked our recommendation for additional capabilities. The team recognized there were few automated tests and wanted to add quality to the system. They asked to spend the sprint adding automated tests and the client agreed. Even though the team did not adopt TDD I was proud that they recognized the importance of automated testing. In this final sprint, I spent most of my time as a Scrum Master. I wanted to ensure we were handing off the project in good shape so my focus was on Operations. I considered the use of Scrumban as well as Kanban since the application would only be supported by one full-time individual. Ultimately, I taught the Operations personnel how to do Kanban because I felt that Scrumban was too heavyweight past project completion. I also setup a Kanban board in Jira and showed others how to use it. The focus on WIP (work in progress) limits allowed for fast cycle times. The client appreciated the fast turnaround time on simple tasks such as fixing spelling mistakes.
4. What I Learned
Performing both roles allowed me to do something I had never done in my entire career. It allowed me to build people’s skills. I was able to accomplish this by helping them learn and grow based on my understanding of the Agile mindset but also by listening and reacting to their reactions. Had I just performed either role, I do not believe it would have been possible to make everyone better and achieve the same level of success. Building people on this project was the most rewarding thing I have ever done in my professional career.
This combined role is not for everyone. To be successful at this you need to have some key attributes. There are two key attributes that stand out for me. Someone performing the role of Scrum Master and Team Member needs to highly sociable. That does not mean you must be an extreme extrovert. In fact, I consider myself an introvert that can be an extrovert when needed. Overall, the team needs to feel comfortable having discussions because they will require teaching, mentoring, coaching, and facilitating. The team also needs to rely on this person to bring the team together and social skills are often necessary to make that happen. The second attribute is technical expertise. The individual undertaking the combined role needs to have a high level to technical skills so that they can troubleshoot with the team and be able to take a systems view. Essentially, they need to be able to speak the same language as the team. I felt these two attributes were necessary because there were times where the team needed to speak to me as a Scrum Master and other times where they needed to speak to me as a Team Member.
Many leadership books indicate that one of keys to success is never asking people to do something you are not willing to do yourself. Undertaking these combined roles is definitely that. You are not only asking people to commit to doing something but you have to actively contribute as well. Because I was able to do both, this project made me a better leader.
If I could do it all over again I would try to do a better job of focusing on one role at a time. There were many times where I was trying to be the Scrum Master and a Team Member. In any given instance I think I would have been better off just picking a role and communicating in that manner. For example, if the team came to me with a technical issue and I was wearing the hat of a Team Member, I might offer to pair program with them. But if I was wearing the hat of a Scrum Master I might suggest they pair up with another team member or include a spike to do some research on the problem.
5. FINAL THOUGHTS
So would I recommend this approach? Absolutely. In fact, there are situations that require this approach. Sometimes people leave unexpectedly which leaves a gap or sometimes a project is not properly funded for additional resources. But keep in mind these multiple roles can be exhausting and there are times where it can consume your life. Leadership skills are a necessity while dictatorship skills will likely lead to failure. Think long and hard before you take on this type of endeavor. Also, this should not be a long-term approach. I would not recommend doing this for more than a year. At some point the individual should become a full-time Scrum Master or participate as a full-time Team Member.
6. Acknowledgements
A special thanks to my shepherd, Rebecca Wirfs-Brock, I could not have done it without you!
REFERENCES
[1] Scrum Guide | Scrum Guides. 2017 [Retrieved 02/21/2018], Available from: https://www.scrumguides.org/scrum-guide.html.
[2] The ScrumMaster. 2018 [Retrieved 02/21/2018], Available from: https://www.mountaingoatsoftware.com/agile/scrum/roles/scrummaster.
[3] J. M. Bass, “Scrum Master Activities: Process Tailoring in Large Enterprise Projects”, Global Software Engineering (ICGSE) 2014 IEEE 9th International Conference on, pp. 6-15, Aug. 2014.
[4] M. Cohn, “Agile Estimating and Planning”, Massachusetts: Pearson Education, 2005.
[5] Create, Read, Update, and Delete. 2018 [Retrieved 03/02/2018], Available from: https://en.wikipedia.org/wiki/Create,_read,_update_and_delete.
[6] E. Derby, D. Larsen, “Agile Retrospectives: Making Good Teams Great”, Pragmatic Bookshelf, 2006
[7] SMART criteria. 2018 [Retrieved 03/02/2018], Available from: https://en.wikipedia.org/wiki/SMART_criteria.
[8] What is Test Driven Development (TDD)? 2018 [Retrieved 03/03/2018], Available from: https://www.agilealliance.org/glossary/tdd.
[9] What is Mob Programming? 2018 [Retrieved 03/03/2018], Available from: https://www.agilealliance.org/glossary/mob-programming.
