Skillshare: SCRUM Framework

What is Scrum?

Scrum is an agile framework that supports individuals and teams to create value while strategically executing complex projects. Scrum is a process focused on continual inspection and adaption.

People in the tens of millions use scrum every day to tackle their creative projects. It is primarily used in software, research, marketing, government, production planning, as well as development of ideas, systems, services, and products.

Why use Scrum?

How many times have you planned out a detailed project well in advance, investing many hours in execution, perhaps months later only to find yourself at the finish line with a result that is no longer relevant? Perhaps you lost your original passion for the project, parted ways with team members or dropped the project completely due to the weighty pressure of continually missed deadlines?

You’re not alone in your experience with traditional projects, also known as “waterfall projects”. The 2020 CHAOS report from the Standish Group continues to confirm that the agile method produces a higher success rate than the traditional waterfall model. Read more about the pitfalls of waterfall at the end of this article.

The need for scrum came from the waterfall model’s longterm fixed-delivery resulting in wrong products, results that were delayed and detached from the here and now. As the world is constantly changing, it makes sense that right products are the result of an adaptable framework.

Scrum asks us, how do we deliver small things, in a short period of time? In order to deliver more value, it asks us to learn in the moment and adapt during the process. This empirical learning process allows us to build things that require constant adaptation instead of adhering to long-established deadlines and rigid delivery expectations.

In 1993, scrum was first implemented by Jeff Sutherland, John Scumniotales and Jeff McKenna at the Easel Corportation, a software company. The latest guide to scrum is available at scrumguide.org and is translated in over 40 languages.

Scrum is not a methodology, it’s a framework focused on transparency. All team members know what is going on and they are never asked to jump through irrelevant hoops. The team’s time and energy is optimized from the work’s transparency, as they are constantly inspecting and adapting based on the here and now.

The process is simplified to the point where the only questions teams are expected to answer are: What are we doing? How are we doing it? and what do we need to do to get to where we are going?

The team collectively knows:

• If we deliver the wrong product, it does not matter about speed, what matters is quality and value
• Due to short term goals, we determine if we can deliver the right thing, if not, then we try again and focus on one month at a time

Scrum Values

A strong scrum team benefits from team members having the courage to bring up problems, activities, and all concerns. In addition to being self-empowered, team members need to focus on the sprint goals at hand, with a personal-level commitment and the respect to share information with other members throughout the process.

The transparency assists self-empowerment as it allows each team member to instantly see what is going on and rapidly address obstacles as they arise.

Consistent with the Agile pillars of transparency, inspection, and adaption, Scrum has three inspection points baked in:

1. Progress
2. Product
3. Process

Scrum Framework

1. A set of Artifacts
2. A set of Events
3. A set of Roles

That’s it, it’s a fairly simple framework. Now, let’s take a closer look…

1. Scrum Artifacts

• Product Backlog: holds all requirements for the product/project, managed by the Product Owner.
• Sprint Backlog: holds all tasks for the Sprint Goal, managed by the Development Team.
• Increment: a completed task, a concrete stepping stone toward the end product/project, potentially releasable.

2. Scrum Events

1. Sprint
2. Sprint Planning
3. Daily Scrum
4. Sprint Review
5. Sprint Retrospective

3. Scrum Roles

• Product governor (AKA product owner)
• Facilitator (AKA scrum-master)
• Development team (AKA scrum-team)

• Product Governor: maximize value, protect and extend product longevity. Their focus is to understand and work with different stakeholders, internal customers, and gather feedback from members. They are responsible and accountable for that product but that does not mean they work alone. They are the ultimate owner of the product owner of the product backlog. Product by committee does not work, it needs to be protected and guarded by one person who cares about delivering value back out. 
• In terms of ETC, we are operating as a co-operative organization. We prefer the term “governor” since we mutually “own” the products we create. There are also several Product Governors within our partnerships and these roles can change depending on project scope.
• In a club or student organization setting, this would be a president/vice president or organization shareholder.
• In a production setting, this would be a producer, in the same way, there are often multiple Product Governors working together on one Project at a time.

• Facilitator: ensures the team understands how the team is working and removing any impediments that the team might have. Their focus is to help the team to lead itself, they are not there to tell them to do, it helps them figure out what the right thing to do is. to guide them to self organize and do the right thing.
• They need to cut out dependencies if things are not working well together, they are not a project manager, they are there to help support the team. It’s a rather difficult role.

• Development team: they are all about getting things done. They create the product individually within their own roles, at certain points they check in with the product governors and stakeholders to make sure they are delivering the products, they are self organized team that has everything they need to deliver that product.

Ready to see the entire process in action? Check out the video below!

Agile in a Nutshell (video)

Principles behind the Agile Manifesto

Read here for the original manifesto source:

“Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity–the art of maximizing the amount
of work not done–is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.“

The Waterfall Model, continued…

Traditionally, products are created using a “waterfall” methodology. Requirements are defined upfront and the budget is allocated on a per-project basis. As a result, by the time a version of the product gets to an end-user, it could be months or years with requirements that were possibly never revisited. Today, more and more competitors are coming to market trying to do what you do, but better and quicker. Customers can end up leaving you for competitors that provide the same services and products but are more responsive to their users’ immediate needs. 

The challenge with the waterfall methodology is its focus on having a fixed budget, scope, and schedule. Once the project nears completion, your development teams can be pressured to participate in death marches that require them to work nights and weekends, leading to major employee burnout. They have received little to no feedback from the end-user and you now have a product that no longer matches the current needs of the user.

Major changes to requirements require you to restart the entire waterfall process again or drop the project completely. This creates unnecessary waste of time and money and can have a negative impact on the morale of your employees who may be deeply invested in the success of the project they just finished.