The Agile Scrum methodology can work for smaller teams. Here are two real-world examples of how it was adapted for a Scrum team of 4.
There is a good chance that you have heard of or maybe even been a part of a team that practiced an agile software development methodology such as Scrum. One aspect of Scrum teams that is often overlooked is the size of the team. Historically ScrumGuides.org (1) recommended that the ideal Scrum team size is 7, plus or minus two members. The guide has since revised that recommendation to a range of 3-9 members.
Not all organizations or projects either require or have the resources available to staff a Scrum team with the recommended 3-9 members. In fact, smaller teams are often the way that many organizations or projects operate in reality. For example, given the short-term nature of consulting-based development projects, it is fairly common to staff a project with a smaller development team because it is a better value and fit for the organization’s (client) goals. While reality may warrant a smaller team, a recent article by Opensource.com found that “scaling down (below the recommended minimum team size) is not gaining traction, even though it is the way that many sectors operate.” (2)
So how can the principles of the Scrum methodology be best applied to smaller teams? I would like to share two examples of how my development team at Midtown Consulting Group implemented Scrum for a team of 3 developers plus a Scrum Master to achieve the goals of a few recent projects for one of our key clients.
Dialing in Communication – When, Who & What?
In a consulting-based development project, dialing in how best to keep the client informed of the team’s progress while still giving the development team the space they need to do the work can be a challenge. When you add client meetings to the 4 key meetings that the Scrum methodology is built upon (sprint planning, daily standup, sprint review, and sprint retrospective), the outcome that often occurs is a disruption in the amount of continuous time that the development has to focus on getting the work done on a day-to-day basis.
For example, in a recent engagement, our weekly cadence consisted of 5 meetings plus any “one-off” meetings that were needed to discuss project-related work throughout the week. Simply put, the number of meetings was impacting the development team’s progress towards the greater goal of releasing the application by an important deadline.
We found that by expanding the scope of communications we could reduce the number of meetings but still ensure that key stakeholders (both on behalf of the client and our firm) stayed informed of the project’s progress, successes and challenges. The development team continuously communicated throughout the day via a messaging application (Slack) which allowed us to streamline our morning developer-only standup to 5-10 minutes. We applied the same idea to our afternoon client-facing standup by including the key client staff that were involved in the development work in our conversations on Slack as well. This allowed us to focus the afternoon standup on specific questions or issues that were relevant to the work being done on that day. These adjustments in-turn allowed us to reduce the “all-hands” project status meetings to once a week on Tuesdays with a larger audience and hold another smaller status meeting with just client executive staff on Thursdays.
The key to understanding your communication patterns is to take the time to map them out – when are you communicating, who is involved and what is being communicated? Once you have a tangible understanding of your project communication patterns you will begin to spot opportunities for adjustment and improvement that enables the success of the project or goal.
Sprints – Only 1 at a Time?
Scrum prescribes that work is done one sprint at a time. Before we dive deeper into this notion, let’s first consider another scenario from a recent client project. In this scenario, our development team faced two workstreams that needed to run in parallel to meet the project goals. If the two workstreams could not run in parallel, the client (and their business stakeholders) would have to choose between doing development work that was needed so a new customer could use the application or work required for high-priority enhancements that were needed to win new customers in the near-term future.
It is highly likely that anyone who has been part of a development project that is racing towards a rapidly approaching deadline has dealt firsthand with the paradox that underlies the scenario above. That paradox is the set of tradeoffs between the speed of development and the quality of the software delivered - which is sometimes referred to as the "unattainable triangle” (3). Infographic designer Riccardo Sabatini illustrated this concept perfectly in his graphic "Good-Fast-Cheap” (4). The three tenants of the unattainable triangle are:
Good service Cheap won’t be Fast
Good service Fast won’t be Cheap
Fast service Cheap won’t be Good
Understanding the tradeoffs on each side of the unattainable triangle allows a project team as a whole to set and accept realistic expectations. We leveraged this concept to work with the project’s key stakeholders to clearly define and agree on the priorities for each of the workstreams. This process presented an opportunity to re-calibrate expectations via education. It offered the project’s business (non-technical) stakeholders a better understanding of why certain development tasks took longer than others. Having clear priorities for both workstreams enabled the development team because it was clear what tasks should be focused on in a given day.
Another way that this paradox can present itself is when either the team is small to begin with, or when resources leave the team for a given reason. The key to managing either of these situations is coaching the team members to stay focused on results - in the software development world that is delivering working software instead of becoming hostage to the “how are we going to do all of this work with our current team (or with fewer people) mindset.”
The results-oriented mindset encourages team members to figure out how to broaden their involvement in the project and “take up the slack” and share the additional responsibilities amongst the team. For example, a back-end developer may expand his or her skill set to take on front-end (UI) development tasks or the Scrum Master may work with the business analyst to better understand requirements on behalf of the development team.
The solution that we arrived at for the scenario I described above was to run 2 development sprints in parallel. We were able to deliver the functionality required for the new customer and also the application enhancements within a few days of the original deadline. This solution was possible because of the following reasons:
The project team as a whole understood (and accepted) the tradeoffs of the unattainable triangle
The project team as a whole bought into the idea that they were mutually responsible for the delivery of software that met the end user's needs
It’s All About…
Implementing Scrum or other agile development methodologies is about making adjustments and compromises where it makes sense. Sometimes that is best done by creating a hybrid approach that consists of aspects of multiple methodologies, and sometimes it is doing things “by the book.” In the two examples shared in this article, it was about understanding our communication patterns and figuring out how best to optimize them. It was also about understanding and accepting trade-offs and team buy-in to the larger goal. Don’t be afraid to try multiple approaches and see what sticks. Ultimately agile is about doing things rapidly, so keep trying new approaches with your small team until you figure out what works.