Scrum Methodology: Ingenious Evolution or Progress For Progress Sake?
Mark DiPietro
Technology Editor
For about ten years, Agile Project Management, and it’s famous brainchild Scrum Methodology, has dominated the software development industry. Some hail them for their innovative concepts that have jumpstarted teams to new heights. While others argue that it breeds micro-management and inefficiency. Over the course of this article, we will delve into this framework and try to identify strengths and weaknesses.
Agile is a set of principles and values that direct teams to conduct work more efficiently and has been an essential development for project management. Its innovative and customer-centric approach has driven teams from across the IT industry to forego traditional and linear planning, also known as the waterfall approach. Agile development projects deliver value early and often, adapt to change, and work closely with the customer to ensure that the project meets their needs. This makes projects more flexible, collaborative, and iterative.
Scrum is a common framework within the Agile development set of principles that can be used to manage project development. Instead of making the process a single step-by-step procedure, Scrum focuses more on a quick succession of repetitive development processes called “sprints” that aim to deliver a Potentially Shippable Product by the end of the process. By adopting a Scrum approach, the team can more effectively analyze data to gain insights and make data-driven decisions. The Scrum framework involves a set of predefined roles, events, and artifacts that help the team manage the project effectively. The roles in Scrum include the Product Owner, the Scrum Master, and the Development team. The events in Scrum include Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. The artifacts in Scrum include the Product Backlog, Sprint Backlog, and Increment.
Scrum begins with the Product Backlog, or a prioritized list of the features and requirements for the project. As the person who defines the goals and requirements of the project, the Product Owner is the role responsible for the production of this.
Then, the development team begins Sprint Planning. They produce a list of the tasks and activities that the Development Team plans to complete during the Sprint called a Sprint Backlog. This is developed using User Stories. User Stories are defined using the “As a ____ I need ____ So that _____” structure to properly determine what is needed for the end product. The team then begins developing the product while meeting every day in what is called a Daily Scrum. This is a meeting, facilitated by the Scrum Manager, that tracks the progress as the team works through the Sprint.
Once the Sprint is complete, the work done is evaluated in a variety of steps. The Sprint Review is when the entire scrum team inspects the sprint’s outcome, with stakeholders to determine future adaptations. The Sprint Retrospective is when the scrum team inspects how the last sprint went regarding individuals, interactions, processes, tools, and definition of done. The team identifies improvements to make the next sprint more effective and enjoyable. In other words, the Sprint review determines the efficacy of the products while the Retrospective determines the efficacy of the process. This concludes the sprint and an artifact called the Increment is produced. This tracks the sum of all the completed work during a Sprint, which provides value to the customer and demonstrates progress towards the project goals. From this, the Product Owner and other stakeholders can determine whether the process needs to be repeated in another Sprint.
Overall, Scrum claims to provide a flexible and collaborative framework for teams to manage their projects effectively, prioritize work, and deliver high-quality results. But some do not agree. A common argument against Scrum is that it is introspective and does not take into account the needs of others outside the organization. It focuses on the Project Owner only and cannot take into account any stakeholder beyond that person. This also often means that there is too much responsibility on the Product Owners, which is underestimated most notably by the Product Owners themselves. The situation is made worse when Product Owners or Scrum Masters are under qualified, which some assert happens often. Scrum also ignores practical leadership roles like lead developer, causing Sprints to sometimes be disorganized.
Other critiques have a problem with the “innovative” ideas that Scrum promotes. Critics claim that Daily Scrums very likely will lead to micromanagement since the team has pressure to only pick tasks that can be completed in one day. Another criticism is how Scrum deals with bugs. Developers prioritize getting something “done” as opposed to doing things well, meaning they put out a flawed product over robust solutions since bug work is classified as work for the next sprint.
Whether Scrum is efficient or dangerous depends very greatly on the team implementing it. It must fit the team’s abilities, culture, and mindset. Also, the team must be willing to buy in for best results. While the criticisms against Scrum are fair in nature, its immense popularity indicates that something in this recent development has resonated amongst teams. At the very least, Agile and Scrum should be considered for any software development team hoping to root out inefficiencies.
Contact Mark at markdipietro04@gmail.com