Scrum

Scrum is based on reflecting upon your current work & status and looking for ways to improve and do better. Agile is a set of values. Scrum is a framework to put them to practice. Jeff was involved in creating both.

In Scrum, management sets the strategic goals, but the teams themselves decide how they achieve them.

A task isn't done before it can be used by a customer. Half-done is not done. You still haven't produced anything of value yet. This is similar to reducing WIP in Lean.

Scrum doesn't focus on hours worked. It focuses on output. All that matters is how fast it's delivered and how good it is.

Rhythm is the heart of scrum. It's important because we're pattern seekers. We need rituals/rhythms in life.

Any process is wasteful - including Scrum. Ideally, we'd just always focus on producing exactly what the customers want. This isn't possible, of course, so we need a process that keeps us focused but otherwise minimizes process overhead.

Scrum planning doesn't happen all at once. You plan just enough to deliver the next increment of value, and estimate the remainder of the project in larger chunks. At the end of each iteration, you need to have some deliverable that you can show customers. You get their feedback and plan accordingly. If they like it, continue. If not, change your plan.

The key to getting faster as a team is removing waste. That includes removing impediments. (relates to Lean)

When you're building something, don't plan to just deliver value when it's done. Think about building a MVP. What's the least you can build yet still deliver value? At the very latest, deliver your MVP when it's 20% done. If you did it optimally, you'll have captured 80% of the value here. You want to start getting feedback asap.

Scrum was pioneered in 1993.

Sprints

A sprint is actually a time box. It's a fixed amount of time. And your sprint durations should be the same each time. When a sprint is planned, the tasks are locked in. Nothing can be added from anyone outside the team.

Sprint Planning

Teams members take on tasks by themselves; they aren't assigned.

When you're doing sprint planning, and if you've done some sprints already, you should take backlog items that amount to the same velocity as you had last sprint.

Once you've planned a sprint, it's locked in. No more tasks should be added or changed.

Daily Scrum

The Daily Scrum has a few rules:

• everyone has to be there (it's for communication! Hard if people aren't there).
• held at the same time every time
• ask the same three questions
• everyone stands up
• should never last more than fifteen minutes

During daily scrums, don't fall into the passive mode of just reporting what you did and what you'll do. It should be more like a football huddle where team members say what their situation is and if they're having issues

Sprint Retrospective

During the scrum retrospect, ask these questions. How can we work better together? What was in our way during the sprint? What impediments are slowing us down?

Sprint retrospective should include:

• "What can we change about how we work?"
• “What is our biggest sticking point?”

During the Sprint Retrospective, the Scrum Master should ask each team member what would make them happier (with the process, etc.) and deliver on it. Make acceptance tests for it. It needs to be delivered on.

The Scrum Master

The scrum master guides the team towards continuous improvement; and this is by regularly asking, “How can we do what we do better?”

The Scrum Master should, during the Daily Scrum, ask these three questions:

1. What did you do yesterday to help the team finish the Sprint?
2. What will you do today to help the team finish the Sprint?
3. What obstacles are getting in the team’s way?

That's all there is — each member answers the three questions. Then you have an overview of what's going on in the sprint. It shouldn't take more than 15 minutes. Will all tasks be done on time? Can we help each other with obstacles? You now know.

The Product Owner

Scrum allows the PO to perform the OODA loop. Information about how much value an increment created is used to inform the next sprint. We constantly get to make hypotheses and then test them. This is rapid innovation and adaptation.

Sutherland has boiled down the essential Product Owner characteristics down to these four

• needs to be knowledgeable about the domain
• has to be empowered to make decisions (about product vision)
• has to be available to the team, to explain what needs to be done and why
• needs to be held accountable for creating value

The PO determines what needs to be done and why. The team decides how and who.

The Product Backlog

The first thing you need to do when implementing scrum is to make a backlog. It can be contain many items, or few items, but you need a vision for the work.

The backlog should contain everything that could possibly be included in your product. You won't build all of it, but list everything that could be in the product vision. The items are written as stories, of course.

When you have a backlog filled with product vision stories, you need to prioritize. What should you do first? That which gives the biggest ROI. You need to start creating revenue immediately. You see to deliver value to customers immediately. So the highest priority items are those that would be most impactful for the business, customers, and are easy to do.

After creating the backlog, you should refine and estimate it. The team will be the ones estimating it; you know, the ones who'll actually execute and do.

Each item must create value, and should potentially be shippable. Don't estimate in hours, estimate in size. Then you can estimate by relative sizing. Use the Fibonacci sequence for estimating.

Continuously keep the backlog item priority order in flux. It should change as you learn — which you should after each sprint.

In scrum, you should do an 80/20 analysis on the product backlog. Which 20% of the features can we implement to capture 80% of the value?

Find that which gives the most value with the smallest investment (time, resources)

Product Vision

Take the Venn diagram of what you can implement, what you can sell, and what you can be passionate about. The intersection of those 3 is your product vision. That's something that just might become something great.

Scrum Teams

Teams should be able to go from 0 to delivery with just the members on the team. But it shouldn't be big teams - 7 is more than enough. More than that, and they actually go slower.

Lawrence Putnam did a study that found this. 3-7 members in a team is optimal. A team of that size requires 1/4 of the effort that a team of 9-20 members need for the same amount of work. In the appendix, Sutherland actually says that teams should be of size 3-9.

Planning Poker

Use the Fibonacci sequence to estimate work for tasks.

When playing planning poker:

• if everyone is within two cards of each other, just average the sum of your cards.
• If people are more than three cards apart, the high and low cards talk about why they think what they do.

This is to expedite the process. It's about estimates, not hard deadlines.

User stories

When defining a task (story), you want to define the

• who is it for
• what should be done
• why does the character want it? How will it serve them?

Bill Wake coined the INVEST criteria for identifying whether a story is ready. It must be

• independent - completable on its own
• negotiable - until it's being done
• valuable - to stakeholders / customers
• estimable
• small
• testable - must have a test to pass before it can be complete. Write the test before you write the story.

You should write your stories (tasks) in a concise and granular manner. They should really be broken down.

Format: As a X, I want to Y, such that Z.

That defines the who, what, and why.

Epics

We also have what's called Epics, which is a collection of stories that make up some whole. If the stories describe a bookstore, the epic is the idea about the bookstore. This seems similar to projects and tasks, the only difference being naming and format.

Velocity

Once you have completed a sprint, you can grab the estimations for each story and sum them. That's your velocity - how much you can do in a sprint.

I think it's a good idea to measure this over time. Get an average.

And once you have your velocity, you can estimate when you'll be done. Even more important: once you get your velocity, you can start figuring out how you can go even faster.

Definition of Done

Bake compliance requirements into individual tasks. Then you don't have to wait until the project is done and then finding out that something doesn't comply with FDA, QA, etc. Write it like "this is how we know this task is done." This standard is the Definition of Done. It lets everyone know when something is done or not - it's a clear standard.

The Toyota Production System / Lean

Taiichi Ohno made the great Toyota Production System. A key concept is flow: production should flow swiftly, and management should do everything they can to remove impediments to flow. Impediments are waste, and waste is a criminal offense.

Scrum actually comes from Japanese manufacturing (Lean, right?). And curiously, they got their ideas from an American named W. Edwards Deming.

He came to Japan after the American occupation of it after World War 2, as he worked for General Douglas MacArthur.

MacArthur's approach to fixing the Japanese economy was to fire most senior managers, and instead promote line management. He also brought in business operations experts like Deming from US.

Deming taught many Japanese engineers Statistical Process Control. The idea is to measure exactly what's being done, how well it's being done, and to always strive for continuous improvement. You should never settle for where you are. Always strive to improve. Constantly create experiments to see if you can improve.

Curiously, Lean manufacturing is the American term for the concepts of the Toyota Production System.

This is also a principle in Lean manufacturing; reducing work in progress. Any inventory has cost money. Having half-finished stuff laying around, waiting for its turn to become finished, actually means that you've spent a bunch of money without creating any value. In essence, don't build up a massive inventory; no matter if it's finished products or half-finished ones. Keep just enough so that you can keep a flow on delivering value. That's all that matters. Don't invest effort for nothing.

The Toyota andon cord is really about fixing issues as soon as possible. It's much more expensive and resource intensive to fix issues after development than during. Fix issues as soon as possible.

The PDCA Cycle and Scrum

Deming is famous for his PDCA cycle: Plan, Do, Check, Act.

First, plan what you'll do. Second, do it. Third, look for improvements. Fourth, act on implementing these improvements.

Scrum as Lean kind of reminds me of systems theory wherein you can improve rapidly by improving your cycle time, and therefore getting rapid feedback.

The PDCA cycle is a way to go through fast iterations and quickly improve your work. Actually, it formed the base for Lean manufacturing and Scrum.

General Principles

Plans are useful. Blindly following them is not. Plans could (and should) change when you discover new information / learn.

Fail fast is an often repeated mantra. Here's the reason for it. It embraces the Lean Startup methodology; fast testing of hypotheses and learning. But the important part comes in the latter part of the sentence; “fail fast so you can fix early.”

We face ego depletion. It's basically that any decision costs energy. When you exhaust that energy, you start making bad decisions. Your ability to be disciplined, thoughtful, and prescient goes way down.

Do things right the first time. Fix issues as they occur. It's much cheaper and faster.

OpenView Venture Partners figured out that capping work hours increased productivity. Productivity starts to do a steep dive around the 30-40 hour mark.

Research indicates that happy people simply do better. In fact, they do better in almost every aspect of life. People who are happy do better. You'd think they are happy because they do better, but actually they do better because they're happy. Happiness precedes performance. What actually makes people happy? Autonomy l mastery, and purpose. You should feel like you're doing something bigger than yourself. That you're getting better at it. And that you're in control of your own destiny.

Fundamental Attribution Error

When we're being blamed, there's an entire set of good reasons that explains our behavior. When we blame others, it's them personally that has a fault (I.e., that person is X, or that person alway Y).

The Stanley Milgram Experiment

One of the questions about the Holocaust is how so many people 'agreed' to do it. Was it because Germans are evil? No. Stanley Milgram found that anyone is capable of doing such things. Given the right situation, what makes you so sure you wouldn't do it, too?

On multitasking

Multi-tasking is the dumbest thing we think we can do. We can't. It's stupid. Don't try.

We lose a lot to context switching when we try to balance multiple projects. When you work on complex projects, you build up a ton of awareness and complex mental structures. These all collapse when you switch to another task; and it'll take a long time to get back into that state.

Balancing 2 projects at a time looses you 20% in context switching, leaving you with 40% time available per project. This is much, much worse when balancing 5 projects. You loose 75%, leaving a mere 5% time per project.

Trying to do everything at once induces so much context switching that you will waste much of your time. Instead, prioritize and focus on one thing at a time. You can still do everything — faster than had you tried to do multiple projects at once — but just one thing at a time.

The OODA Loop

The OODA loop, by John Boyd. Observe the situation clearly - get the whole picture. Orient yourself - what's your position? Possible outcomes? Alternatives?

Observation and Orientation leads to a decision, which leads to action. Then we repeat, beginning with the result of your action / the opponents action.

In business, it's the observation of the reaction of the marketplace.

How The Map Is Not The Terrritory relates to Planning

Interesting connection. The map is not the terrain (territory) and focusing on planning and preparation rather than actually doing. This is also the different between Scrum and Waterfall; waterfall spends too much time planning, and not enough on doing. Actually doing and implementing the plan is where the value is created, not before. Don't spend more time planning than you do implementing.

The New New Product Development Game — characteristics of the teams at the best companies in the world

In the paper "The New New Product Development Game", Professor Takeuchi and Nonaka described the characteristics of the teams they saw at the best companies in the world. This paper described became Scrum.

1 Transcendent - they have a sense of purpose beyond the ordinary.
2. Autonomous - they are self-organizing and self-managing. They can make their own decisions about how to work. They are empowered to make decisions that stick.
3. Cross-Functional - the teams have all the skills needed to complete the project; from planning to distribution.