Spartans — How we became a Team
How we as individuals got together to form a Scrum team destined for greatness.
Our journey began a few months ago when management requested that we divide our big team into two smaller groups to manage feature work and customer escalations more efficiently. So, we dutifully divided ourselves into two groups. When the whole thing was done, we started to wonder what do we do now and where do we go from here. Within our group, we were individuals who knew each other, but had never collaborated together on a single shared goal/vision. We all have varying work styles, outlooks & perspective towards work, acceptable levels of collaboration (or intrusion), some of us are introverts while others extroverts, all of us are experts in their own areas but some who yearn to understand different product features while others who want to do deeper into their subject matter of choice. But we all fostered hope to become one “Team”. This is how we, a group of individual developers, became “Team Spartans”, a well-oiled development machine who completed over five projects in one release spanning just 3 months & continue to churn out work at incredible pace in an open and collaborative environment, continuously tweaking the processes we follow as advocated by the scrum framework.
Here are a few things that we did as a team, that make us what we are:
Choose a Name for the Scrum Team
Although the scrum guide does not mention Scrum Team needing a name, we happened to think that it would be a good way to start our first Sprint Planning meeting by selecting a name for our team. Since most of us are really experienced folks there were multiple suggestions like Veterans, Quintuplets (team of five, including me), Titans & Spartans. The team finally agreed upon Spartans mainly because we are a small team but the expectations from us would always be sky-high. Another thing that helped was that we had quite a few of the movie buffs, esp. of movie 300. So the team thought of ourselves as a small army taking down large tasks with brutal effectiveness. The team gave the team an identity and purpose. It was clear, that the team already shared the vision of achieving greatness.
Insights: The idea here is not to merely do this as a chore but try to coax the team to come up with names that resonate with the new collective. One thing that helps everyone to start thinking is to remind the team that we don’t get to choose our individual names, but as a scrum team we have a choice to choose what others call us. The name needs to give the team a feeling of togetherness, pride and strength and spending some time on this activity really helps people to open up and share their ideas. Another benefit of this exercise is that this way we learn more about our new teammates. Before we started discussing names, we did not know that we had three fans of movie 300, that everyone liked mythology and that all of us hated being called Veterans.
Define the Story Point matrix
The Scrum Guide mentions that the Scrum Master helps in establishing an empirical way to manage the product backlog. It also mentions that the team can refine the product backlog items and select items based on past performance, capacity and definition of done. One tool that helps in sprint planning is story points estimation. It is recommended to use Fibonacci numbers (as stories are assumed to be additive in nature, making it easier to break a large story into smaller stories) or T-shirt sizes of XXS, XS, S, L, XL, XXL etc. We had tried this before and this still seemed too abstract to size up a story. This is where the team suggested that we create a matrix to map complexity, size, unknowns and estimated effort needed. The matrix was filled up with Fibonacci numbers starting from 1, 2, 3, 5 … 34. The team also decided that a story with size of 34 and above would definitely need to be broken up. The matrix also helps drive conversations around what is the not just the story point number but its perceived complexity, size and unknowns as well. This then helps the team to collectively decide on the appropriate Story Point for a given user story, making the discussions more involved and less abstract.
Example: The matrix drives conversation when, say, 2 people choose “8” as the Story Point for a given user story. Since, an “8” could mean an extremely complex work but one which would require less effort/time while it could also mean that the user story is not at all complex, but would require a lot of effort/time to complete. So, now during discussions, we do not try to justify a number, but rather discuss its perceived complexity & effort/time required to come up with the most appropriate Story Point for the given user story that the whole team would agree with.
Insights: Deriving a Story point matrix is the best way to drive conversation amongst the team and creating one for your own team would mean that the team would “own” the process of coming up with Story Points. As a Scrum Master, I am just happy to sit back and see my team use the matrix to drive the conversations amongst themselves during Story Points estimations.
Zoom calls while Working Together
Given that everybody is working remotely, it’s very hard to have time to interact with each other. Scum dictates that every meeting be time boxed and be focussed to avoid time wastage. This means that there isn’t much time to really interact with one another. Given the constraints of remote work, different timezones, there was a need to come-up with some ways to bring the team to work together. During a particular sprint, the whole team was working on manual testing, so I started having everyone in a zoom call, not meeting, just working together, at the same time, sometimes not even talking to each other. We were just present for each other so, if somebody got stuck they could talk and immediately get help, or get another pair of eyes to validate the results. Slowly, there was some chit chat or idle banter during these calls, as we continued working on our tasks. It really helped the team get a feeling of working together towards a shared goal. The team even mentioned this during the sprint respective meeting that this really helped bring the team together.
Standing up to Management to respect the team’s decision
Since our organization started following Scrum for development, it was felt by most individuals that a scrum team’s decisions, wants and thoughts were not presented to the management properly. They had felt that because of this, the team’s wants were ignored and the projects were still mostly assigned to the team rather than the team having a choice to pick up projects they liked. The team wanted to feel involved in the discussion on which project they would like to work on as well as have autonomy to decide who works on which tasks. And they wanted a Scrum Master to stand up for the team. Having been on the other side for so long, I was obligated to not let my team down.
Insights: The three pillar of intrinsic motivation are autonomy (freedom of choice), mastery (opportunity to learn)and purpose (impact). So, if a team picks up a project themselves they will own it completely and do it with full vigor and will not require any coaxing, hand-holding or push to finish things by deadlines. In our organization, there are multiple teams who look at the product backlog and sometimes a Scrum Master has to negotiate with other teams while picking up projects for the next release. The Scrum Master is the sole representative for the team along with strategy and management who oversee project assignments. Everyone there has an opinions on which team would be best suited for which project. I just wanted to make sure that I can represent my team’s wishes appropriately. I have also been very transparent when sharing the happenings of such meetings with the team. It has done two things:
1. The team believes that I as Scrum Master have their back, who will make sure that their autonomy is maintained
2. The team can focus on mastery of the area and purpose (meeting sprint goal) of the projects.
Taken together, this automatically provides intrinsic motivation for the team to excel.
Documenting all Scrum meetings, including daily Stand-ups
Although Jira makes it easy to track tasks, it still has no way to track any impediments. Plus there is no way to really track the daily progress towards the sprint goal and/or any impediments in achieving the same. Without documenting the answers to these, there is no way to really track and fore-see if someone is really stuck on some task.
Insights: Most developers are problem solvers, so most would not ask for help and would continue to work on ways to resolve any issue they face. By documenting the answers to the three daily standup questions, it was easy to point if someone was really stuck and could benefit by asking for help within the team, or if external help was requested but hasn’t been received yet and needed to be escalated. Plus, it helps build team experience on estimating time needed for similar tasks in future. I cannot stress enough, how helpful this exercise has been, even though it was extra effort for me as I had to maintain this and Jira simultaneously.
Conclusion
So far, the team has been very happy working together and this shows in the sheer amount of work our small team was able to complete. Even we ourselves were quite impressed with the progress we were able to make, not just with work accomplished, but with working together as a team and because of this the overall mood of the team was very upbeat. This is just the beginning of Team Spartans and our vision is: “Just as the small army that defeated the might Athenians, our small team plans to attack & complete projects & bugs with the same vigor, determination & fierceness.”
