Inside the Scrum Team – Part 1

Today, I recorded the sound track to go with the video version of the Inside the Scrum Team info-graphic! Here is the script for Part 1, which is is about how the Scrum Team interacts with the outside world. Part 2 will be about the interactions within the Scrum team.

My goal is that anyone will be able to use these videos to train and share Scrum. They strives to be up-to-date and correct, while giving the flavor of a good Scrum implementation. Aside from author credits, there is no branding, and both the graphic and the video are reusable under a Creative Commons license.

The video will premier on October at the Regional Scrum Gathering in Sri Lanka. Follow me on Linked In for updates, and please support this video by contributing to my gofundme to cover production costs.

Script for Part 1 – Interactions with the outside world

Hi! I’d like to take you Inside the Scrum Team. In this video, you’ll discover how a Scrum Team interacts with the outside world to create great products! So here we go!

A simple framework

Scrum is a simple, team-based framework for solving complex problems. If you only remember one thing about Scrum, remember this: “Inspect and Adapt at regular intervals… and tell yourself the truth.”

Scrum was created for software development, where it is widely used, but today it finds application in many other complex domains, like corporate transformation, hardware development, and education, to name just a few.
The definitive description is found in the Scrum Guide. This is both the reference and the place to start. With this video, you can discover how Scrum guides interactions and relationships with the Scrum Team, so you can apply Scrum effectively in real life.

Product Increment

Scrum was modeled on patterns of successful product development, so let’s start here: The product.

How it works

Scrum works in short iterations, called sprints. At least once per sprint, the Scrum Team produces a new version of the product with a few new or upgraded features.

This is called the “Product Increment,” but I like to call this a tangible result: Each Sprint produces a tangible result that supports the overall goal: Something you can use, something you could sell, something you can test in real life; most importantly, something the Scrum Team can review together with its stakeholders.

Whether your team is developing software or doing something else, the idea is to produce tangible results, every sprint. You can produce increments more often, even deploy them continuously, if that makes sense and your team has the technical excellence to do it.

Stakeholders

A product is built for its stakeholders, and most development efforts have many of them.
Two of the most important are the users, that is the people who will actually use the product, and customers, the people or entities who actually pay for the product, but many other people could be involved. Without stakeholders there would be no product!

Frequent Delivery

Stakeholders usually appreciate having a working increment frequently! This virtually eliminates Delivery Risk. Direct interaction with stakeholders builds trust and reduces Market Risk, that is, increases the likelihood that the product will be a success!

With a working product in hand, you can have good conversations about what you have, what changes are needed, and how best to move forward. You can also identify work to delay or skip entirely, saving both time and money.

Done

This is possible because each “Product Increment” works. It is “Done!”

“Done” is a quality gate: nothing enters the Product Increment unless it done. Every Scrum team has a definition of done, and it is applied to every feature and every increment.

The definition of Done does not address whether the product is complete or “finished.” As long as a product is viable, its development never really ends.

The Definition of Done is often a simple checklist that covers both acceptance criteria and quality control. It ensures that features from previous sprints still work and that the team maintains its quality standards.

The Scrum Team

The Scrum Team is accountable for creating a valuable, working product increment every sprint. Ideas come into the team, the product owner sequences them, and the Scrum Team commits to do its best to turn the most valuable of those ideas into a working solution by the end of the sprint.

Accountabilities define each member’s contribution to the overall result. Scrum forbids hierarchies or sub-teams within the Scrum Team. There is one team working toward a common goal.
The Scrum Team consists of Developers who are accountable for creating the increment, a Product Owner who is accountable that the increment is valuable, and a Scrum Master who is accountable that people can work and collaborate effectively.

A Cross-Functional Team

The Scrum Team solves the problem together. They organize and manage themselves. A Scrum Team is cross-functional, that is, it has all the skills and authority necessary to transform incoming “ideas” into something that is “done” and valuable. This includes making decisions about the product.

Typically, a Scrum Team has 10 people or less. The limit is not rigid, but if the team gets larger, effectiveness usually declines, and performance suffers! Conversely, a small team may not have all the skills needed to build the product, especially if someone goes on vacation, gets sick, or is otherwise unavailable.

Overview

Product development in Scrum is a continuous cycle of generating ideas, collecting feedback, creating new product increments, and self-improvement. In Part 2, we’ll zoom in on the Scrum Team to see how each member contributes to the whole. I hope this is useful to you!