Traditional development based on specialized groups, weak or late feedback cycles, predictive “a priori” planning and sequential flow from analysis to testing is not having much success in today’s changing world. This development strategy delays feedback, learning and the potential return on investment due to an absence of software working until the final phases of the project, which causes a lack of transparency, a shortage of possibilities to improve, reduced flexibility and an increase in technical and business risks. Jose Duarte, an entrepreneur and Scrum Master from Costa Rica, offers a basic introduction to Scrum theory and how it is beneficial.
Scrum is a framework in which cross-functional teams can create products or develop projects in an iterative and incremental way. Development is structured in work cycles called Sprints (also known as iterations). These iterations should last no more than four weeks each (two weeks being the most common duration) and take place one after another without pause between them. Sprints are time-bound – they end on a certain date regardless of whether the work has been completely completed or not, and are never extended.
During the Sprint, no new elements can be added; Scrum adapts to the changes in the next Sprint, but the current small Sprint is designed to concentrate on a small, clear and relatively stable goal. Duarte explains, “Every day, the Team meets again to inspect its progress and adjust the next steps needed to complete the backlog. At the end of the Sprint, the Team reviews the Sprint with the different Stakeholders (interested and involved in the product) and makes a demonstration of what they have developed.” Feedback is obtained that can be incorporated into the next Sprint. Scrum emphasizes a product “working” at the end of the Sprint that is actually “finished.” In the case of software, this means a system that is integrated, tested, with generated user documentation and potentially deliverable.
A recurring motto in Scrum is “inspection and adaptation.” Since development inevitably involves learning, innovation and surprises, Scrum takes small steps in development, inspecting both the resulting product and the effectiveness of current practices, and then adapting product objectives and process practices. Repeat indefinitely.
In Scrum there are three roles: Product Owner, Team and Scrum Master. They all form what is known as the Scrum Team. The Product Owner is responsible for maximizing return on investment (ROI) by identifying product functionalities, moving them to a prioritized list, deciding which ones should be at the top of the list for the following Sprint, and continuously enhancing and improving that list.
The Team, or the Development Team, builds what the Product Owner indicates; for example, a website or an application. The “cross-functional” Scrum Team encompasses all the experience and knowledge necessary to develop a potentially deliverable product in each Sprint and is “self-organized” (self-managed), with a wide margin of autonomy and responsibility. The Team decides how many items (from the set offered by the Product Owner) will develop during the Sprint and how best to achieve that goal.
The Scrum Master helps the product area learn and apply Scrum for business value. The Scrum Master does everything in its power to help the Team, product owner and organization succeed. The Scrum Master is not the team’s head, nor is he a project manager, team director or team representative. Adds Duarte, “The Scrum Master serves the Team; helps eliminate impediments, protects the Team from external interference, and helps them adopt modern development practices. He or she trains, trains, and guides the Product Owner, team and the rest of the organization in the proper use of Scrum. The Scrum Master is a coach and a trainer and ensures that everyone (including the Product Owner and managers) understands the principles and practices of Scrum.”
There is no type of project manager role in Scrum. This is because it is not necessary at all. The traditional duties of the project manager have been distributed and reassigned between the three Scrum roles, particularly between the Team and the Product Owner. One of the myths around Scrum is that it doesn’t allow you to write complete specifications. In reality, it is up to the Product Owner and the Team to decide how much detail is necessary. This may vary from one element of the Product Backlog to another, depending on the Team’s observations and other factors. The objective is to express in the smallest possible space what is important or, in other words, not to describe all the possible details of an element but to clarify what needs to be understood and completed through a continuous dialogue between the Team, the Product Owner and the stakeholders.