To explain Scrum Management, you first need to understand the Agile Methodology in project management. Agile emerged out of the failure of some major software development projects.
Like most manufacturing projects of the past, software tended to be developed by putting effort into a single end date when a complete product would be delivered to market – often over budget and way behind schedule.
The conclusion drawn about the failure of these projects is that there was a limited chance for reflection on progress and limited access to customer experience data that would improve the desirability of the product.
This means that Agile is a philosophy focused on flexibility and reflexivity. The advantage it offers is the ability to change the scope mid-project and the chance to respond reflectively to real-life customer interaction with the product.
Scrum is the framework that is used to implement this philosophy of project management.
Scrum Management comes from an analogy used by Takeuchi and Nonaka in a Harvard Business Review article linking the work of a team to a scrum in Rugby. Here a small team push together in the same direction in short bursts of strength.
Scrum Management emerged out of this focus on inspecting and adapting, in a series of feedback loops, that break down the complexity of a massive project into a series of iterations.
The flexibility of this approach also requires a re-definition of roles. There is no longer distinction between business, design, customer experience and technical functions.
A scrum team would be a collaboration of these specialists, all of whom would accept responsibility for doing parts of the role of the other depending on the needs of the project.
The tasks are mostly delegated to the most appropriate person or people depending on the context of that work – rather, the traditional inflexibility of a specific role does a fixed job description.
What Are The Roles in Scrum Management?
There are three distinct roles within a Scrum Management approach to project management. There is the Product Owner, the Scrum Master and the Team.
Depending on the size of the project, the Product Owner and Scrum Master may be the same person, even though the roles are distinct.
Product Owner is the person with the vision of the overall project. They also have the authority and ultimate accountability for the outcome of the project.
They should also be available to the Scrum Master and the Team when needed.
The skillset will focus heavily on strategising and communicating this to the Team. However, they will also play a significant role in dictating the priorities of the project and redefining the scope when reflection dictates this is needed.
The most significant question for the Product Owner is: how involved should they be in the day-to-day running of the project?
There is an emphasis on self-organisation and the independence of the team to make decisions based on feedback. But, and it is a big but, the Product Owner has the answers to the more significant questions about the overall vision and scope of the project.
First things first, a Scrum Master is not a team leader. They are not there to manage the team but instead act as a facilitator.
In practice, this means running between the Product Owner and the Team making sure everything needed is in place. The Scrum Master is the person who is entirely focused on removing obstacles to achieve the sprint goal.
What are sprint goals? Well, a sprint goal is a step along the way to achieving the primary goal of the project.
These sprint goals are reviewed in 5-minute meetings at the start of the day, and it would be the responsibility of the Scrum Master to speak to the Product Owner if more time or resources are needed to fulfil the next set of outcomes.
However, the Scrum Master is also responsible for getting the best return on investment from the team. So, technically, although not a team leader, the Scrum Master does have some responsibility for keeping the team focused on the goal.
The Team is everyone – including potentially the Product Owner and definitely including the Scrum Master.
The difference between a standard team and a Scrum Team is the level of self-management expected.
For each sprint, the team is responsible for working out how to make sure the goals are delivered. The Scrum Team should be autonomous, working on the vision of the Product Owner.
How Does Scrum Management Work?
There is some debate whether this is an approach, a methodology or a framework. It is difficult to understand why it matters which one it is – but here is a general summary of how it works.
First, a Product Owner creates a wish-list and puts these in order of priority. This is called the Product Backlog and is presented to the whole team.
From there we move to Sprint Planning, this is where the team pull out the smaller deliverables from the higher-level priorities listed on the wish-list. This is called a Sprint Backlog.
Sprint Backlog defines how the team are going to implement the smaller goals that would build to make up the whole.
The sprint is a designated period in which the work defined in the Sprint Backlog should be completed. This is usually about two to four weeks.
The team will have daily scrum meetings to gauge progress and set priorities for the day. These are sometimes called the daily stand-ups – but essentially this means everyone stands up and says what they have done and what still needs to be done.
These meetings are meant to be quick – no more than 5 minutes to check in on the progress of the whole team.
At the end of a sprint, there should be a deliverable that could go to the market to receive feedback from customers. This might mean presenting something to a stakeholder to receive feedback, but in its purest form, it is a product on the shelf ready to use.
The end of the sprint also prompts a review, and from this report, a new sprint begins.
The next chunk of the project may require a new product backlog, or it may mean beginning work on the following highest priorities defined by the Product Owner.
What Makes Scrum Management Successful?
There is not a whole lot standing in the way of any company moving to Scrum Management from this point forward. There is no particular equipment and no significant need to reorganise your office furniture.
It is essentially a whole lot of complicated terms which suggest breaking a goal down into smaller deliverable, producing, reviewing, re-planning and repeating.
However, realistically, the move to Scrum Management requires a company to think differently about how it organises its staff.
The traditional model of company organisation requires specialist teams to work independently of each other and meeting occasionally to negotiate the details.
Scrum Management, to be done efficiently, have teams made up of these specialists all working in the same room together. To be successful, Scrum Management needs a commitment from the leadership of the company to try doing something different.
Another essential principle of Scrum Management is transparency. All team members should be aware of what everyone else is doing and what progress is being made.
The end goal should be visible to all, as should any changes in scope or general direction. Best practice would be to have a Scrum Board.
Scrum Board is a place where the Product Backlog is organised. It might be a digital record of the Product Backlog, as published on software such as Trello. It could be as simple as a whiteboard in the office, covered in a sea of post-it notes. The point is that the whole project should be viewable by all members of the team.
The method works because of the iterations and improvements. The “old” methodology arguably fails to reflect effectively until the project has finished.
Under Scrum Management, the reflection happens at the end of sprints, giving room for change and improvement of the original vision. It is, therefore, best practice to draw in user response to the product/ service being developed by the Scrum team.
Scrum Management Explained In a Nutshell
The point of Scrum Management is to work smarter. The idea behind all this reflection and iteration is to make sure that everything being done is purposeful, so no effort, or indeed money, is wasted.
Agile is the philosophy for which Scrum is interpreted into practice. The idea is to create a list of priorities and empower the team to get these priorities delivered.
The focus on short sprints of work to smaller deliverables means that there is an opportunity to change the plan and change the scope before work is done that is not required or is ineffective.
The most radical element for the manufacture of products, other than in the realm of software, is delivering a product to the market before the whole vision has been accomplished to receive customer experience feedback.
If you understood the Scrum Management Methodology, but you’re still confused about the roles, read our analysis of a Product Owner vs Scrum Master.
[…] And lastly, attending a CSP-SM workshop. This certification is the zenith level certification in scrum management specially designed for educators, professors, and high-level scrum […]