Over the course of the last decade, Scrum has gained immense popularity in the software development industry. As a result, businesses that have transitioned to Scrum have not only seen dramatic improvements in the business value delivered by their software development organizations, but also overall empowerment of teams thereby leading to a workplace that fosters creativity and productivity.
All that said, there are still companies that question if Scrum is the right SDLC methodology for their projects.
Advantages of Scrum
The most talked about advantages associated with Scrum include flexibility, iterative development, and empowered teams. While these items are the cornerstone behind the agile framework, this article will focus on two of the lesser known advantages.
Focus on Working Software
With Scrum, the focus is not on delivering detailed documentation (i.e. functional specifications, business requirements, etc.), but rather on delivering working software iteratively. By focusing on what the actual functionality of the software should be and delivering the functionality in small, independent pieces, the actual users of the system can see the results of their requirements and provide immediate feedback to the development team. This intertwined communication between the business and development teams naturally lends itself to delivery of relevant and usable features.
Scrum allows the users to actually see working pieces of software as they are being developed. Being able to tangibly see what development is creating rather than discussing requirements only in theories gives the business the avenue to course correct before it’s too late.
Transparency is a Key
How many times have you been involved in a project that is seemingly going well only to find out too late that there are issues, missed requirements, technical blockers, etc.?
In a Scrum environment, transparency is the key to the project’s success. This transparency happens via many various avenues:
- Daily Scrum Meetings
- Burndown Charts
- Backlog Grooming
- Sprint and Release Planning sessions
- Sprint Retrospectives
The intent in all of these activities is to focus on the work that is being requested, the work that is being done, and bringing to light roadblocks, questions, and conversations about the project early and often. It is paramount for the teams to constantly reflect on the work they are doing and look for ways to improve.
When following Scrum fundamentals and performing these activities regularly, the transparency radiates from the working Scrum teams out to the business and management teams. This leads to early detection of issues, less rework, and fewer surprises.
Disadvantages of Scrum
Organizations struggling to adapt to Scrum are often reluctant because they are concerned about scope creep, challenges of adapting to Scrum in larger environments, and lack of predictability. Two largely overlooked obstacles are interchangeability of team members and cultural fit within the organization.
Interchangeability of Team Members
Scrum teams are most effective and efficient when their size is 5-7 +/- 2 people. Velocity, the throughput of the team, is driven by the efficiencies gained when small teams work very closely together repeatedly to achieve a common goal.
When members of a Scrum team are displaced for any reason (i.e. extended absences, attrition, etc.), the velocity of the team can be greatly impacted. Even if you are able to quickly replace a team member, the synergy of the team is disrupted, and therefore the work the team produces is negatively impacted.
In textbook Scrum teams, every team member should be cross-functional. For example, the niche of a developer to only concentrate on development for the UI aspects of a project would not be commonplace on a true Scrum team. To further this example, developers should be trained cross-functionally and able to develop backend and UI driven requirements. Finding developers that are cross-functionally trained may not be as easy as it sounds in theory.
Having team members focus on a single functional area can lead to the division of work amongst the team and will eventually break down one of the foundational mantras of Scrum: “Begin as a team; Work as a team; End as a team”. The more breakdown and division of work amongst the team, the more likely for dissension amongst the team and ultimately creating a negative impact on the quality of work being developed.
Cultural Fit
Cultural fit should be one of the main areas of focus when determining the methodology to adopt within your organization but yet it is also the most overlooked. Many companies believe that the methodology utilized by the development teams only impacts development and no other areas within the company. In order for any methodology to succeed, it is important to understand the ability and needs of your business, management, and development teams. The decision on which methodology to adopt will impact the entire organization, not just the software development teams. Companies with strict policies and rigid procedures may not adopt a framework that allows for constantly evolving requirements.
Management teams that are hardcore reliant on singular developer metrics (i.e. defect ratios by a developer) may not adapt well to the new metric of a team delivering business needs via functional software features and not being able to focus on individual metrics. There are success stories where adaptation of Scrum has been a grassroots movement within the development team and socialized outward to other departments; but typically within those organizations, other departments and management are willing to adapt to the changes created as a result of the new Scrum methodology.
To Scrum or Not to Scrum
Scrum is not a silver bullet to solve all of the problems that can be encountered with software development projects within your organization. When deciding on whether to adopt the Scrum methodology, every organization should evaluate cultural fit, project life cycles, team performance, and adaptability.
The overall successes your teams achieve will greatly depend on the ability of the organization to fully understand and accept all of the advantages and disadvantages of the methodology chosen.
