[Transcript]
These days we are exploring the Startup methodologies that have helped the software companies of Silicon Valley grow from two man teams in garages, to world dominating monoliths like Microsoft, Apple, Google, and Facebook. How is it possible that teams of engineers could completely revolutionize the way we interact with the world. Or at the very least, how can we organize our teams to solve problems as quickly and effectively as they have?
My name is Shaun McMillan, and this is the Best Class Ever.
Today’s lesson is part 2 of an explanation on Agile or SCRUM. To get the full picture I highly recommend listening to last week’s lesson which was part 1. If you missed it and want to catch up you can easily find it at www.BestClassEver.org.
So what is Agile, or more specifically, SCRUM?
Definition of SCRUM
“Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.”
Why SCRUM? SCRUM is far more agile and efficient than the typical working method which we refer to as waterfall. Typically a team would make a big plan, follow that plan, and deliver a version of it at the end of a long production period. Agile instead has short, repeating production periods, between which teams take the time to evaluate which work tasks they will and will not be working on.
Agile processes allow small teams to adapt quickly, and reduce wasted effort. It reduces the amount of time spent in meetings, allows time and trust for each teammate to do their work, but allows for just enough communication so that they can quickly determine how to do the right thing, do it the right way, and deliver value to the customers quickly and consistently.
[venn diagram of 3 circles]
So how does it do all of that? And why is it called SCRUM? A scrum is a reference to the sport rugby. In rugby there are times when you will see every player lean in with their heads and lock their arms forming a human basket of concentric circles. In the middle of this human entanglement is the ball, and each side pushes back and forth.
Design Sprints
In agile a team of 10 or less coworkers, collaborators, or developers will do a sprint. The sprint is a set of time, perhaps one to three weeks, in which the developers will do all of the work necessary to achieve an agreed upon product goal. The next sprint begins after the current one concludes. Each sprint will include the following events.
SCRUM Events
Sprint planning session
In this initial meeting everyone will agree on which changes to make to the product based on user feedback stories.
Daily Scrums
These are standing meetings which take place at the beginning of every workday. No one is allowed to sit because the meeting should not take more than 15 minutes. You simply explain what you achieved yesterday, what you will do today to achieve the product goal, and mention if there is anything blocking you from getting your work done.
Sprint Review
This is a full presentation of all the deliverables created during the sprint involving all of the stakeholders.
Sprint Retrospective
This is a small team among the developers in which you share what is and isn’t working among your agile team and whether or not to make changes to your working process.
Roles
Everyone on the team is responsible for making sure value is created for the customer by the work they do to create the next version of the product by the end of the sprint. Among the Agile team there are these three roles.
- The Product Owner
- The SCRUM Master
- The Developers
The Product Owner
The Product Owner is like a project manager to some degree. They determine the product goal. The product goal is the one key deliverable the team will work towards in this sprint.
The product owner manages the product backlog which is a list of all the possible improvements, features, and tasks that have been suggested based on user feedback. This list is kept visible so that the process of deciding what tasks will be done and which will be postponed is transparent.
The product owner can decide which of those tasks the team will work on as top priority or delegate this to another teammate, but ultimately the product owner is accountable. Ultimately the Product Owner’s responsibility is to determine WHAT the team will do.
The SCRUM Master
The SCRUM master is the expert on the agile process and you can think of this role as a coach. He or she answers to the product owner, but works to encourage the team and emphasize a healthy working relationship between developers and focus on the values of mutual respect, transparency, and effectiveness.
The Developers
These are all of the remaining teammates. Each are equally accountable for
- Creating a plan for the Sprint, the Sprint Backlog
- Instilling quality by sticking to the agreed upon Definition of Done which will be explained later
- Adapting their plan each day toward the Sprint Goal and,
- Holding each other accountable as professionals.
During a sprint it is important to remember that
● No changes are made that would endanger the Sprint Goal;
● Quality does not decrease;
● The Product Backlog is refined as needed; and,
● Scope may be clarified and renegotiated with the Product Owner as more is learned.
*Definition of Done
Each feature, product improvement, or task to be done in the product backlog needs to be done as quickly as possible but it also needs to fulfill a certain standard of quality. These two values, working quickly, and working perfectly tend to conflict. So everyone on the team and any other teams working on this product must mutually define how done is done enough to ensure certain standards of quality.
*Scope
Scope refers to the boundaries on any given project. Broadly speaking, projects often take longer, require far more resources, and grow much larger in scale than any one client or developer initially might guess. The agile process allows for the flexibility required for changes in scope because the team can decide how to adapt at the end of a short sprint and before beginning a new one. But once the team enters into a sprint they should focus exclusively on achieving the agreed upon product goal without making changes.
Agile is great because it allows for the flexibility to adapt to necessary changes, but also frees developers to do their critical work without distraction.
Better in Practice than in Theory
Agile is one of those frameworks that you can’t really see the value of until you put it into practice. It doesn’t look that mind-blowing on paper or sound so impressive, but they are revelatory in practice. Just look at how quickly silicon valley has been able to adapt, change, and take over human communication. Facebook now has 5 billion users. They are changing human communication so fast that researchers can’t even conduct experiments fast enough to find out what effects these changes are having on us. By the time any of these effects are measured the tech companies have already managed to further revolutionize human behavior yet again rendering those research findings obsolete.
We too can organize our teams to evaluate effectively. To see images related to today’s lesson, more lessons, or learn more about Startup methodologies you can find resources at www.BestClassEver.org.
