Scrum: The Key to Reducing Complexity and Cost in Product Development
Scrum? What is it? When, where, and how does it work?
Scrum aims to get feedback faster, and its effective use is in complex situations, but complexity does not mean difficulty! It means the extent of ignorance that arises over time and under different conditions.
Scrum helps reduce the cost of these complexities, and the Scrum strategy is to take quick feedback to prevent costly mistakes from happening (that is, take action before it is too late, not after). For example, we may create features that stakeholders do not want or use, or that we misunderstand. The quicker we understand what is happening, the easier and less costly it will be to provide feedback.
In addition to an initial plan (based on what we know), we plan along the way based on the feedback we receive. You may have an initial story and path, but during the journey, issues arise due to changing market conditions, user needs, etc., which require a change of course. By “issues,” I mean those that fall into the category of “ignorance,” and are sometimes unpredictable. Moreover, there is a difference between a plan and planning: a plan means a “set of activities” based on what we know, and planning means a “map” for the unknowns that arise and cannot be predicted in advance.
Here is a simple example: when you choose a route with Waze, the starting point and destination are clear. Waze provides you with a plan from point A to point B (of course, this plan is based on the data you already have). Then, as you move, Waze updates the route based on data and feedback from other users and suggests a new path based on a shorter route, less time, or faster speed to reach your destination.
Now, Scrum has defined a series of roles such as product owner, Scrum master, and development team to solve these complex problems. These roles are arranged in a way that they affect both the complexity of the product and the complexity of human relationships.
Product Owner: Specifically answers the question of whether we are making the right product. They focus on this complexity and are constantly in touch with customers and business stakeholders (marketing, sales, support, CEO, and user) and manage these stakeholders until we reach a common understanding of what we want, what is correct, and what the roadmap is. (The PO helps us overcome the complexity of the product.)
Scrum Master: Works more on the human aspect. They handle communication between different stakeholders, team members with each other (developers together, developers with the product owner), and policies within the organization.
So we have two individuals with two different approaches to stakeholder management:
Product Owner: Identifies the market and focuses on the business aspect of the product.
Scrum Master: Focuses on whether we are making the product quickly and correctly, meaning that they concentrate on the method of work. (They don’t really care what we’re making, they care about how we’re making it.)
For example, the CEO of a company wants a feature to be implemented in the software. Well, the right way to do this in Scrum is through the product owner (because they are the ones who collect and bring requirements to the team), but the CEO wants to call the developer and ask them to do this until tomorrow. Here the Scrum Master comes in to create the process correctly, to understand why the CEO is bypassing the process, and to ensure that the product owner does not become weak. (So the Scrum Master implements the right way of working.)
This is a very general view of Scrum. To use any tool or employ any method, it is obvious that we need to obtain information, study and research, and with sufficient knowledge, experience it within a specific timeframe to be able to have a correct judgment of its usefulness or uselessness for us.
