When I was in high school, I remember seeing a poster saying, “Math is not a spectator sport”. The obvious meaning behind it is that you do not learn mathematics simply by listening to theory, but instead by applying the concepts you have learned to solve problems. Simply put, you learn by doing. The same principle can be applied to other applications in our lives, like improving our soft skills or learning how to write code. Fortunately, the current head of the Computer Information Systems (CIS) program at Ferris believes in this approach too, and has crafted our final courses so that we are forced to apply everything we have learned over the last few years to solve a real-world problem. Some may call it a trial by fire, but I call it a learning experience.
If you are a resident of West Michigan, you have no doubt heard that human trafficking has become an epidemic in the area. To help combat this problem, a local non-profit teamed up with students and professors at Ferris State to raise awareness on the issue last year. The students who took the final courses last year were given the task of designing a website for the non-profit from scratch. The university and non-profit are continuing their partnership this year, and my class has been given the assignment of improving and adding more features to the website.
How the Project is Structured
The students in the final courses have been split into separate groups with the intent of using the SCRUM framework to produce the desired deliverables. The team whose deliverables impress our clients the most get to have their changes added to the website that is currently in production. It is up to each team to decide what each person’s role is and what tools they will use.
My Role on the SCRUM Team
Since I had a reputation for coaching/encouraging my classmates and solving problems on the fly, I was elected to play the part of SCRUM master. My current responsibilities are as follows:
– Organize sprints.
– Remove any obstacles the SCRUM Team encounters.
– Host regular SCRUM Meetings.
– Act as a coach and guide for each member of the SCRUM team.
– Regularly check in with each team member to ensure deliverables are completed and ready on time.
Throughout the remainder of this post, I will discuss each responabillity and the actions I have taken to fulfill them.
The most important aspect of organizing sprints is to first listen to what your team has to say about the required deliverables. What I appreciate the most from my team is that whenever they have a question or concern, they immediately express it to me. Not only does this help mitigate risks we could have with a sprint I am planning, but it also allows me to determine where their strengths lie.
Next, I work to determine the assignments for each team member. This is where our methodology somewhat deviates from the traditional SCRUM framework, as the Product Owner would generally handle this, however in our case we feel having the SCRUM Master handle the assignments works best for us. This can be difficult at times, as I strive to give an assignment to someone that I know will work best with their strengths without depriving any team members from any learning experiences.
For example, we recently had a sprint where we needed to design use cases based on our functional requirements. Ideally, I would want the team members who already work in an IT profession to take upon the more complex use cases, as they would have the best idea how many actors are involved in the system and how they interact with each other. This would leave more simplistic use cases to the team mates who do not work in the industry yet, but giving out work that each team member does not find challenging is not what this project is about. In the end, most team members had a functional requirement assigned to them that I was confident would challenge them enough to learn. I am pleased to say we earned high marks on that sprint from our instructor.
A SCRUM Master should always ensure that his or her team does not face any road blocks that would prevent them from doing their work. You may not know this, but even technology professionals experience technical problems from time to time. It is times like that where I dust off my Desktop Support hat and put it back on.
One of our recent sprints required us to create GUIs and sequence diagrams based on the deliverables from the use case sprint I spoke of earlier. Since each of us had a Dreamspark license from Microsoft, we all felt it best to use Viso to accomplish this task. I informed my team to install the software if they had not already, and to contact me if they had any issues. Not long after, I had messages from two team members concerning trouble they were having with the software (we will call them Ned and Fred). Ned had the software installed, but could not use it, while the Fred was having trouble mounting the Viso ISO file so that he could run the installer.
First things first, ask open-ended questions to help diagnose the issues:
– Ned, what do you see when you attempt to open Viso?
– Fred, happens when you attempt to mount the ISO file?
Ned was being prompted to login to Office 365 after opening Viso, while Fred could not see the option to mount the ISO file (yet somehow opened Visual Studio after double-clicking on it).
Solving Ned’s issue did not take much time at all. As I mentioned earlier, we had licenses provided to us by Dreamspark, and this did not include access to Office 365. This meant that they only other way we could validate we had legitimate copies of Viso was to input the product key! In a little less than a half-hour I provided my entire team with documentation showing them how they could login to Dreamspark, retrieve their key, and apply it to their copy of Viso. Ned read it and was up and running in no time!
Fred’s issue was slightly more complicated. To diagnose his problem, I would need to see exactly what he was seeing. I instructed him to download and install Teamviewer so that I could remote into his computer and help him out. Once I was in, I immediately identified the issue. His file associations had somehow become mismatched, and all ISO files were set to open in Visual Studio by default. This also meant that there was not an option to mount the file when right-clicking on it. After changing the association back to Windows Explorer, we were able mount the file and install the software successfully!
Hosting SCRUM Meetings
Our team has two meetings per week. The first takes place immediately after our night class, and usually involves discussing the objectives laid out by our instructor for the sprint. Assigning work typically does not happen at these meetings, rather we strive to ensure that we all understood the lecture and what is required from us. Additionally, we brainstorm ideas for what we would like to see come out of the sprint, what we do not want to see, and the standards each team member will follow when working on their portion of the assignment (i.e. Using Viso to design GUIs, using a base table created by the PO to design our use cases, etc.). Any additional ideas, questions, or concerns that come up after the meeting are then shared with me on Slack so that we can discuss them at the next meeting.
Our second meetings for the week are done over a Skype conference call two days after class. We give each team member a chance to discuss their feelings on the sprint we are working on, and what methodology they think would work best when tackling it. Myself and the PO will listen to how the team member feels about each suggested process and decide at the meeting which one is the best.
It is difficult for us to setup a virtual meeting that everyone can attend, as we all have different work and class schedules. To overcome this problem, the audio from each meeting is recorded and posted on Slack a few minutes after each meeting has ended. Anyone who was not able to attend the meeting will be expected to listen to the audio file and then “like” the post so that we know they are on the same page we are. I also post summaries of each meeting so that we have a brief record of what we spoke of.
Coaching/Guiding the Team
I have been in the workforce for about 10 years (about 4 of those spent as a technology professional). Over that span of time, I have worked with many teams and under multiple styles of management. In my personal experience, I have found teams that understood their functions and have a high moral perform the best. I have decided to utilize this approach in hopes that I could maximize my team’s potential.
Ensuring that your team understands what is expected from them is easy enough; If they have any questions, you answer them within a reasonable amount of time. Each member of our team is expected to respond to a message on Slack within 24 hours of being sent, but I try to make sure my responses get back to them within 2 to 3 hours (assuming the message is sent during waking hours). If I do not know the answer up front, I will either consult with the PO or have them ask the question to the group in our next meeting (that way we can gauge everyone’s input).
Increasing morale is a simple process too. We have a rule that if someone displays stellar performance, they are praised in front of the whole group. This allows us to show our team that doing their best is recognized and rewarded. But what happens if a team member is not performing as well as we would like them to? Nobody works to their full potential if their feelings are hurt, so if myself or the PO have any concerns with performance, we handle it both privately and constructively. In some cases, we find that team members have additional constraints we were not aware of, or simply were not aware of resources available to them to help increase their performance. From there, we make suggestions to help the team member overcome the issue and move on. This method of handling concerns allows us to correct issues without damaging anyone’s pride or feelings.
Checking in With the Team
Whoever came up with the term “SCRUM Master” apparently did not like the name “glorified nag”. Okay, so being the SCRUM Master is much more than that, but ensuring the customer’s deliverables are ready on time does require a bit of “nagging”. Fortunately, my team is excellent at letting me know of problems they are having right away. However, there have been times where I have messaged a team member privately to make sure they understand the requirements. Remember how I mentioned that some team members listen to recorded versions of our meetings due to schedule conflicts. I have an expectation that these posted recordings are acknowledged so that I know they have listened to them. If I do not see an acknowledgement, I need to confirm with the team member that the recording has been listened to, otherwise they may work on deliverable without fully understanding what we expect them to do.
As of the time of this writing, we are halfway completed with the first half of the final courses, and will be working on the second half from Christmas break to graduation this Spring. I still have much to learn about SCRUM and the SCRUM master role, but feel more confident about my understanding now that I have had the opportunity to get my feet wet. I can see why many organizations utilize an agile methodology, as it has helped us create high-quality deliverables while allowing us to accommodate for any changes to our scope. My final semester will be a true “trial by fire”, as we will be focusing on making the required coding changes to the site. I am hoping what I have learned so far will serve me well in the months to come.