Complexity is not beyond our comprehension
Things that made sense in the past no longer make sense today, not as we understand them at least. We need a new way to address this complexity, no longer in the bureaucratic way but in a way that puts focus upon simplicity, human collaboration, and systemic resolutions at their center. Complexity isn't beyond our understanding, it can be understood and can be grasped to our advantage. Scrum was designed to address the intricacies, and complexities of our day-to-day working environment, and to steer us towards a collective focus designed to simplify and contextualise our working environment.
How do we actually acquire this simplicity in our working environment? What are the necessary conditions that must be met? What steps are needed, and who do we need to make this possible?
These are questions that have plagued many organisations today, as they steer themselves away from monolith organisational systems towards lightweight conditions that encourage flexibility, responsiveness, and of course adaptability to changing market environments.
This is no longer a question anymore, it's become a fact: change or die. We need to become adaptive enough to remain relevant to our customers, our environment, and to support an internal collaborative corporate culture. In this article I provide a summary of the key content written by the great Jeff Sutherland in his monumental piece titled Scrum: The Art of Doing Twice the Work in Half the Time. Each section is intended to guide you through the main essence that you need to know, and understand, in order to not only implement Scrum but also be able to explain to others.
If you can't explain it to yourself, there's no way you can implement it in teams. The following text is taken from Jeff Sutherland's book, bear with me as I take you through it.
Let us begin.
Shu Ha Ri
- Scrum has its origins in Japanese thought and practise.
- Scrum is something that you can only really learn by doing.
Shu
- You know all the rules and forms
- You repeat them like steps to a dance
- You don't deviate at all
Ha
- Once you've mastered the forms you can make innovations
Ri
- You're able to discard the forms
- You're able to be creative in an unhindered way
- Your every step expresses its essence
Key Takeaways
Hesitation is Death
- Observe, orient, decide, act --> know where you are, assess your options, make a decision and act!
Look outward for answers
- Complex adaptive systems follow a few simple rules, which they learn from their environment.
Great Teams Are
- Cross-functional, autonomous and empowered with a transcendent purpose.
Don't Guess
- Plan, Do, Check, Act.
- Plan what you're going to do.
- Check whether it did what you wanted.
- Act on that and change how you're doing things.
- Repeat in regular cycles, and by doing so, achieve continuous improvement.
Shu Ha Ri
- First, learn the rules and the forms.
- Once you've mastered the rules and forms, make innovations.
- Discard the forms and just be -- with all the learnings internalised and decisions made almost unconsciously
Teams
- Teams are what get things done in the world of work.
- In business we tend to focus on the individuals, even if production is a team effort.
- Managers tend to focus on the individual because it makes intuitive sense -- but this is wrong.
- There is a much larger difference in team performance than there is in individual performance.
Characteristics of Quality Teams
- Transcendent: They have a sense of purpose beyond the ordinary. This self-realised goal allows them to move beyond the ordinary and into the extraordinary
- Autonomous: The teams are self-organising and self-managing, they have the power make their own decisions about how they do their jobs, and are empowered to make those decisions stick.
- Cross-functional: Teams have all the skills needed to complete the project. Those skills feed and reinforce each other. Motivation has to come within.
- On all great teams, it's left to the members to decide how to carry out the goals set by those leading the organisation.
- One of the key concepts in scrum is that the team members decide themselves how they're going to do the work.
- It's management's responsibility to set the strategic goals, but it's the team's job to decide how to reach those goals.
- Great teams have all the necessary skills to get things done.
- Classically organised structures have what is called "phase gates" --> team of planners , team of testers, production team, team of shippers
- Phase gates: Each team along the way has to finish its piece of the action before the project can move to the next step. No one team by itself can actually get a product out the door.
- When you look at the best teams there isn't a separation of roles. Each team has all the people on it to do everything.
- Team dynamic only works well in small teams.
- More resources make the team slower.
- 4 aspects worthy of emulation are: 1) intense focus on the goal; 2) radical collaboration; 3) hunger to crush it; 4) universal excitement.
Framework of Sprints
- Daily standups, sprint reviews, retrospectives
- There needs to be someone to make sure that the process itself is effective
- That person is a servant leader --> the Scrum Master
- The scrum master would facilitate all the meetings, make sure there was transparency and help the team discover what was getting in their way.
- The key part was to realise that often impediments may be in the process itself.
- It was the scrum master's job to guide the team toward continuous improvement. How do we do this better?
At the end of each sprint the team would look closely at itself.
- At the iterations
- At the practises
- At the process
The team would ask two questions
- What can we change about how we work?
- What is our biggest sticking point?
The system
- Low team morale, cohesion and productivity are based on a fundamental misunderstanding of how humans work.
- It is the system that surrounds us, rather than any intrinsic quality that accounts for the vast majority of our behavior.
- Scrum us designed to manage complex systems.
- Scrum doesn't look for blame or fault, it rewards positive behavior by focusing people on working together and getting things done.
- We're all creatures of the system we find ourselves embedded in. What scrum does is accept this reality, and instead of seeking someone to blame, it tries to examine the system that produces the failure and fix it.
- If we can blame someone else, we insulate ourselves from the possibility that we'd do the same thing (Fundamental Attribution Error).
- History doesn't matter, it's only the future -- only solutions -- that matter.
Greatness
- Greatness can't be imposed; it has to come from within: it does live within all of us.
- Scrum is about setting up the right framework with the right incentives and giving people the freedom, respect and authority to do things themselves.
- Change team performance, not individual performance.
- Great teams have a purpose that is greater than the individual.
- Give teams the freedom to make decisions on how to take action -- to be respected as masters of their craft. Let them improvise.
- The team must have every skill needed to complete a project.
- Small teams get work done faster than big teams.
- Don't look for bad people, look for bad systems -- ones that incentivise bad behavior and reward poor performance.
Time & Sprints
- Time is the ultimate limiter of human endeavour, affecting everything from how much we work, to how long things take, to how successful we are.
- The relentless one-way flow of time fundamentally shapes how we view the world and ourselves.
- A sense of mortality hovers over our every effort.
- What scrum does is alter the very way you think about time.
- After engaging for a while in sprints, you see time as fundamentally cyclical
- Each sprint is an opportunity to do something totally new; each day, a chance to improve.
- Scrum encourages a holistic worldview.
Sprints
- We called them sprints because the name evoked a quality of intensity. We were doing work all out for a short period of time and then stop to see where we were.
- Nothing gets moved to done unless it can be used by the customer.
- Sprints are what are often called "time boxes" They have a set duration.
- You want to establish a work rhythm where people know how much they can get done in a set period of time.
- One crucial element of an individual sprint is that once a team commits to what they're going to accomplish, the tasks are locked in.
- Nothing else can be added to a sprint by anyone outside the team.
The Daily Standup
- The Scrum Master asks each member 3 things: 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?
- If it takes more than 15 minutes, you're doing it wrong.
- There is no assigning of tasks from above -- the team is autonomous (they do the assigning)
- There is no detailed reporting to management
- The greater the communication saturation -- the more everyone knows everything -- the faster the team.
- The thing that cripples communication saturation is specialisation -- the number of roles and titles in a group.
- Where the work was done, there were only team members.
- Getting everyone together in a room was key, because it gave the team the opportunity to self-organise around challenges.
- If someone was stuck with a problem -- everyone saw the impediment could block the whole sprint, and they swarmed on it, making sure it got fixed.
- Rule 1: The team meeting was held at the same tim everyday, and everyone had to be there. If the entire team wasn't present, communication simply didn't happen. The point was to give the team a regular heartbeat.
- Rule 2: The meeting couldn't last more than 15 minutes. We wanted it to be crisp and to the point. If something required further discussion, we noted it and met further after the daily. The idea was to get the most actionable and valuable information in the least amount of time.
- Rule 3: Everyone had to actively participate. Everyone had to standup. It would keep meetings short.
- The optimum approach to the daily scrum is akin to a football huddle.
- The idea is for the team to quickly confer on how to move toward victory -- completing the sprint.
- Passivity actively hurts the team's performance, once spotted it needs to be immediately eliminated.
- I want aggressive teams -- ones that come out of the daily meeting knowing the most important thing they need to accomplish that day.
- The team needs to want to be great.
- A team has to demand greatness from itself.
- "Do you really want to suck forever? Is that what your motivation is in life? Because it's a choice, you know -- you don't have to be that way"
Key Takeaways
Time is finite. Treat it that way
- Breakdown your work into what can be accomplished in a regular, set, short period -- optimally one to four weeks -- call it a sprint.
Demo or Die
- At the end of each sprint, have something that's done -- something that can be used.
Throw away your business cards
- Titles are specialised status markers. Be known for what you do, not how you're referred to.
Everyone knows everything
- Communication saturation accelerates work.
One meeting a day
- When it comes to team check-ins, once a day is enough. Get together for 15 minutes at the daily standup, see what can be done to increase speed and do it.
Waste is a crime
- The heart of scrum is rhythm
- Scrum creates a different kind of pattern.
- Scrum accepts that we're habit-driven creatures, seekers of rhythm, somewhat predictable.
- "Work in process" or "inventory". The idea is that it's wasteful to have a bunch of stuff lying around that isn't being used to build something.
- In Lean Manufacturing, the idea is to minimise the amount of half-built stuff lying around.
- "Done" implies complete, deliverable product that can be used by a customer.
- We have a very limited capability to make decisions, and the more energy depleted we are, and the less downtime we get, the worse we are at it.
- Overworked employees get more distracted and begin distracting others.
- People who work too many hours start making mistakes.
- When we don't have energy reserves left, we're prone to start making unsound decisions known as "ego depletion".
- Making any choice involves an energy cost.
- Whatever resource is burned up by making decisions is also used up in self-regulations.
- There's a limited number of sound decisions you can make in any one day, and as you make more and more, you erode your ability to regulate your own behavior.
- By not working so much, you'll get more and better work done.
- Scrum asks those who engage in it to break from the mindset of measuring merely hours. Hours themselves represent a cost. Instead measure output.
Three types of waste expressed by Taiichi Ohno
- Muri (unreasonableness) --> absurdity: you want to give your team challenging goals, to push them to reach for more. But you don't want them striving for absurd, impossible goals.
- Unreasonable Expectations --> A team depends on heroic actions to make its deadlines is not working the way it's supposed to work.
- Overburden -->Behaviour that includes onerous company policies that get in the way like unnecessary reporting, or meaningless meetings.
- Emotional waste --> When a company has an asshole in its midst, someone who likes spinning people and putting them in a tizzy.
The focus
- Scrum focuses us on trying to eliminate pointless waste that seems part of work.
- What you really want in your work is effortless "flow"
Key Takeaways
Multitasking makes you stupid
- Doing more than one thing at a time makes you slower and worse in both tasks.
Half-done isn't Done
- Anything that's in-process costs money and energy without delivering anything.
Do it right the first time
- When you make a mistake, fix it right away. Stop everything else and address it.
Working too hard only makes more work
- Working long hours doesn't get more done, it gets less done.
- Working too much results in fatigue, which leads to errors, which leads to having to fix the thing you just finished.
Don't be unreasonable
- Goals that are challenging are motivators -- goals that are impossible are just depressing.
No Heroics
- If you need a hero to get things done, you have a problem.
- Heroic effort should be viewed as a failure in planning.
Enough with the stupid policies
- Any policy that seems ridiculous likely is.
- Stupid forms, stupid meetings, stupid approvals, stupid standards are just that -- stupid. If your office seems like a Dilbert cartoon, fix it.
No assholes
- Don' be one, and don't allow that behavior.
- Anyone who causes emotional chaos, inspires fear or dread, or demeans or diminishes people needs to be stopped cold.
Strive for flow
- Choose the smoothest, most trouble-free way to get things done.
- Scrum is about enabling the most flow possible.
Plan Reality, not Fantasy
- The very act of planning is so seductive, so alluring, that planning itself becomes more important than the actual plan.
- The map is not the terrain.
- Refine the plan throughout the project rather than do it all upfront.
- Plan in just enough detail to deliver the next increment of value, and estimate the remainder of the project in larger chunks.
- In scrum, at the end of each iteration, you have something of value that you can see, touch and show to customers.
- Figure out the really important things and work on them first.
- Organise by value, whatever value that may be.
- The numbers in the Fibonacci sequence are far enough apart that we can easily tell the difference. It's easy for people to come down on one side or another.
- Our minds don't work in smooth increments. We're better at perceiving jumps from one state to another -- jagged ones, not smooth jumps.
Planning Poker
The idea of planning poker is simple; for example:
- Each person is given a deck of cards with the Fibonacci sequence: 1, 3, 5, 8, 13, etc...
- Each item that needs to be estimated is brought onto the table.
- Everyone pulls the card they think represents the right amount of effort and puts it face down on the table.
- At the same time, everyone flips their cards over.
- If everyone is within two cards of each other (e.g. 5, 8, 8, 13), the team just adds them all up and takes the average (in that case 6.6) and moves on to the next item
Note: we are taking estimates, not schedules. If people are more than 3 cards apart, then the high and low cards talk about why they think what they do.
We need to know 3 things:
- Who is this task being done for?
- What do we want done?
- Why does this person want this thing?
Before you prioritise what needs to be done for your business, you need to:
- Define the character, the user, the customer -- the person who is going to use what you're going to make/do.
- Know their likes, dislikes, passions, enthusiasms, frustrations and joys.
- Understand their motivations
- When you write user stories, you want to make them small enough that you can actually estimate them.
User stories
Bad user story
- As a customer, I want the world's biggest online bookstore so that I can buy any book I want at any time.
Good user story
- As a customer, I want to be able to browse books by genre, so that I can find the types of books I like.
- As a customer, I want to put a book into a shopping cart, so that I can buy it.
- As a product manager, I want to be able to track a customer's purchases, so that I can market specific books to her based on past purchases.
Important:
- User stories need to be specific enough to be actionable but don't prescribe how they're going to be done.
- The team decides how the work will be accomplished, but what will be accomplished is decided by business value.
- The whole collection of stories that might make up that idea is often referred to as an "epic" -- a story too big to do by itself but that includes a number of smaller stories that add up to a single idea.
- When you're writing stories or making a list of work to be done, it's important to ask two questions: 1) Is the story ready? 2) How will you know when it's done?
For any story to be ready, it must meet the INVEST criteria
- INDEPENDENT: The story must be actionable and "completable" on its own. It shouldn't be inherently dependent on another story
- NEGOTIABLE: Until it's actually done, it needs to be rewritten. Allowance for change is built in.
- VALUABLE: It actually delivers value to a customer/user/stakeholder
- ESTIMABLE: You have to be able to size it.
- SMALL: The story needs to be small enough to be able to estimate and plan easily. If it's too big, rewrite it or break it down into smaller stories.
- TESTABLE: The story must have a test that it is supposed to pass to be considered complete. Write the test before you do the story.
For each story pursued, there should be a "definition of ready" (does it meet the INVEST criteria?) and a "definition of done" (what conditions need to be met to call it complete?)
Sprint Planning
Everyone gets together and looks at the list of stories that have to be done.
- What can we accomplish this sprint?
- Can they be done by the end of this iteration?
- Can we demo them to the customer?
- Can we show real value?
Velocity
- We can finally start answering the question as to when things will be done, because we now know to measure what the team is actually doing.
- At the end of the week we count up all the stories we've completed, total the points they were estimated at, and that number tells us how fast the team is going -- their velocity.
- Once you have a velocity, you can look at how many stories you have left and how many points they represent and then you'll know when they'll be done.
When you have your velocity you can figure out the most important thing in scrum:
- What is keeping you from going faster?
- What is preventing your acceleration?
Important
- Getting rid of waste is key to accelerating teams
- Nothing is written in stone, question everything.
- Changing culture is what allows true excellence to emerge.
3 Questions to ask Management:
- Is there anything we can do differently to speed things up?
- Can we offload some backlog items? Is there stuff we can get other teams to do?
- Can we not do something? Can we reduce the scope of the project by any amount?
Key Takeaways
The map is not the terrain
- Don't fall in love with your plan. It's almost certainly wrong.
Only plan what you need.
- Don't try to project everything out years in advance. Just plan enough to keep your teams busy.
What kind of dog is it?
- Don't estimate in absolute terms like hours -- it's been proven that humans are terrible at that. Size things relatively, by what breed of dog that problem is, or T-shirt size (S, M, L, XL, XXL), or, more commonly, the Fibonacci sequence.
Ask the Oracle
- Use a blind technique, like the Delphi Method, to avoid anchoring biases such as the halo effect or the bandwagon effect, or just plain stupid groupthink.
Plan with Poker
- Use planning poker to quickly estimate work that needs to be done.
Work is a story
- Think first about who'll be getting value from something, then about what it is, and then why they need it. Humans think in narratives so give them one. As an X, I want Y, so that Z.
Know your velocity
- Every team should know how much work they can get done in each sprint.
- They should know how much they can improve that velocity by working smarter and removing barriers that are slowing them down.
Velocity x Time = Delivery
- Once you know how fast you're going, you'll know how soon you'll get there.
Happiness
- Just as work needs to be broken down into managemable chunks, time needs to be broken down into manageable pieces. Improvement needs to be sliced to one step at a time.
- What is the little improvement that can be done right away that will make things better?
- People aren't happy because they're successful; they're successful because they're happy. Happiness is a predictive measure. Even just a little bit of happiness leads to markedly better outcomes.
- Even small gestures can have a great impact.
- Scrum is focused on taking small things and systematically building them up into a scaffolding for success.
Sprint Retrospective
At the end of each sprint has team shown what they've accomplished during the last sprint and they sit down and think about:
- What went right?
- What could have been better?
- What can be made better in the next sprint?
What is the improvement in the process that they can implement right away?
You're looking to improve the process
- Why did it happen that way?
- Why did we miss that?
- What could make us faster?
Critical Aspects
- It is crucial that people as a team take responsibility for their process and outcomes and seek solutions as a team.
- People have to have the fortitude to bring up the issues that are really bothering them in a way that is solution-oriented rather than accusatory.
- The team has to have the maturity to hear feedback, take it in, and look for a solution rather than get defensive.
- It is not good enough to show how you feel, you need to be able to act.
- There should be no secret cabal, no hidden agendas, nothing behind the curtain.
- People want to grow; they want to get better at what they're doing and find what else they can get better at. The idea is that mastering work motivates people.
- Scrum, through its retrospectives and transparency, illuminates the behavior of knowledge hoarders almost immediately. It becomes obvious where the roadblocks are, where the waste is.
- Scrum provides a structure for the whole organisation to head towards a common goal.
- For the retrospective to be effective, the meeting requires a certain amount of emotional maturity and an atmosphere of trust.
- Key thing to remember is that you're not seeking someone to blame, you're looking at the process.
- The retrospective is the "check" part of Deming's Plan-Do-Check-Act cycle. The key is getting to that "act" step, that kaizen, which will actually change the process and make it better the next time.
- It's not good enough merely to share how you feel, you need to be able to act.
Worth understanding and noting:
- The pillars of scrum are: transparency, teamwork and collaboration.
- Happiness is not complacency.
- Managers can encourage autonomy by letting people make their own decisions about their job.
- Managers should give quick and direct feedback.
Measuring Happiness
Getting out of the happiness bubble: It is important for the team to know the "happiness bubble"
- The first step is being aware of the problem, which is why teams need to measure their velocity.
- It is important to know what the rate of change is.
- The scrum master needs to be able to see the problem and bring it up to the team.
- It's crucial that someone asks the hard questions.
The happiness metric is a simple but effective way of getting at what the kaizen should be:
- On a scale from 1 to 5, how do you feel about your role in the company
- On the same scale, how do you feel about the company as a whole?
- Why do you feel that way?
- What one thing would make you happier in the next sprint?
- Happiness metrics are predictive.
Keep in mind that...
- Financials look at what happened in the past, but when you ask people how happy they are, they actually project into the future.
- If you pay close attention to what your team is telling you, you can take action and fix the issue before it becomes a problem.
- If you were only looking at productivity, you wouldn't know that there was a problem until it dropped off a cliff. Bit if you see a team-wide drop in happiness, even as productivity is increasing, you have an issue that you need to address, and so on.
- What are the things that actually make people happy? Autonomy, mastery and purpose. The same things that makes teams great!
- One element needed to acquire these three things is transparency.
- Atomising people into informational silos simply slows everyone down. It breeds suspicion and distrust.
- Because the team knows what has been done and what needs to be done, they can regulate themselves.
- The team can self-organise to defeat problems that become obvious once everything is transparent.
- The more connected people are to other people at work, the happier they are -- the more productive and innovative as well.
- People want to grow, they want to get better at what they're doing and find what else they can get better at.
- Mastering work motivates people.
- Happiness is the farthest thing from passivity.
- Managers can encourage autonomy by letting people make their own decisions about their job.
- Managers should also have zero tolerance for incivility and never allow an employee to poison corporate culture through abuse or disrespect.
How it works:
- Every person on the team takes a turn.
- The method exposes what is most important for each member, and what they think is important for the company.
- The team takes that one top improvement and makes it the most important thing to do in the next sprint -- with acceptance tests (how can you prove you've made that improvement)
- You need to define what success is in a concrete actionable way, so that in the next sprint retrospective it is really easy to see if you've achieved kaizen.
How scrum helps:
- What scrum does is promote a single, galvanising mindset.
- By having everyone work together, the team helps the hedonist look ahead, convinces the nihilist there is a future without whining, and tells those managers stuck in an unending rat race that there is actually a better way.
- Scrum focuses on helping people achieve personal growth and fulfilment.
Key Takeaways
It's the journey, not the destination
- True happiness is found in the process, not the result.
- Often we reward results, but what we really want to reward is people striving toward greatness.
Happiness is the new black
- Happiness helps you make smarter decisions.
- When you're happy, you're more creative, less likely to leave your job, and more likely to accomplish far more than you ever anticipated.
Quantify happiness
- It's not enough just to feel good, you need to measure that feeling and compare it to actual performance.
- Other metrics look backward. Happiness is a future-looking metric.
Get better everyday -- and measure it
- At the end of each sprint, the team should pick one small improvement, or kaizen, that will make them happier.
- That item should become the most important thing they'll accomplish in the next sprint.
Secrecy is poison
- Nothing should be secret.
- Everyone should know everything, and that includes salaries and financials.
- Obfuscation only serves people who serve themselves.
Make work visible
- Have a board that shows all the work that needs to be done, what is being worked on, and what is actually done.
- Everyone should see that board.
Happiness is autonomy, mastery, and purpose
- Everyone wants to control their own destiny, get better at what they do, and serve a purpose greater than themselves.
Pop the happy bubble
- Don't get so happy that you start believing in your own bullshit.
- Make sure happiness is measured against performance, and if there is a disconnect, be prepared to act.
- Complacency is the enemy of success.
Priorities
Scrum isn't just about making teams go faster, it's about boosting impact
- If you concentrate only on what you can build, you can end up making something that nobody actually wants.
- If you concentrate only on what you can sell, you can promise things you can't build.
- If you build what you can sell but aren't passionate about, you end up working hard to build mediocrity.
- A vision needs to be rooted in reality -- a vision with a real possibility of becoming something great.
Product Backlog
- The first thing you need to do when implementing scrum is to create a backlog.
- You need a clear idea of what you want at the end of the work.
- Once you have a vision, you need to consider what it will take to make that happen.
- The idea behind the backlog is that it should havae everything that could possibly be included in the product. You're enever actually going to build it all, but you want a list of everything that could be included in that product vision.
- The key is what you decide to do first. Ask yourself: 1) what are the items that have the biggest business impact? ; 2) what are the most important to the customer, that can make the most money? ; 3) What are the easiest to do?
- You want to get to the things that deliver the most value with the lowest risk.
- You want to begin with the things that will immediately create revenue, effectively "de-risking" the project, and you want to do it on the feature level.
- You want to deliver value to your customers as soon as you can.
- Please note: 80% of the value is in 20% of the features.
- In order to prioritise the work, you need to figure out what the vision is and where the value lies. In scrum we call that person the product owner.
The Product Owner
- There are only 3 roles in a scrum team: 1) part of the team and you're doing the work; 2) Scrum Master helping team figure out how to do the work better; 3) Product Owner
- Leadership has nothing to do with authority. Leadership has to do with knowledge and being a servant leader
- The scrum master is the how.
- The Product Owner is the what.
- The Product Owner needs to be able to deliver feedback to the team from the customer each and every sprint.
- A Product Owner needs to spend half their time talking to the people buying the product (getting their thoughts on the latest incremental release and how it delivered) and half their time with the team creating the backlog (showing the team what the customers valued and what they didn't).
- The product owner is accountable for translating the team's productivity into value.
- The scrum master and team are responsible for how fast they're going and how much faster they can get.
Note: The customer is anyone who will get value from what you're doing.
The Product Owner knows the product from the customer's point of view:
- What did people who were actually using the product actually need?
- When choosing a product owner, get someone who can put themselves in the mind of whoever is getting value from what you're doing.
- The product owner needs to be held to a different set of standard.
Essential Characteristics of a Product Owner
The Product Owner needs to be knowledgeable about the domain
- Should understand the process the team is executing well enough to know what can and can't be done.
- Needs to understand the what well enough to express what can be done into true, meaningful value.
- Needs to know the market well enough to know what will make a difference.
The Product Owner must be empowered to make decisions
- Must be given leeway to steer the product's vision.
- Needs to hold firm from the pressures coming from outside.
- Needs to be responsible for outcomes.
- Must let the team make their own decisions.
The Product Owner needs to be available for the team and explain what needs to be done and why:
- There needs to be constant dialogue with the team.
- Must be reliable, consistent and available.
- Without access to the product owner, the team won't know what to do or in what order.
- The team relies on the product owner's vision and market intelligence on what is important.
- The product owner needs to be present or the process falls apart.
The Product Owner needs to be acountable for the value
- Measure a product owner by how much revenue they deliver per "point" of effort.
- The measurement of value could be how many successes a team has.
- The key is to decide what the measure of value is and hold the Product Owner accountable for delivering more of it.
- For big projects there is usually a team to address all the needs.
Fundamentals of the Product Owner
- The product owner needs to make decisions quickly, based on real-time feedback
- Through constant feedback, you're in a position to constantly adjust your strategy and more quickly succeed.
Why the OODA Loop?
- Minimize reaction time in high-stake situations.
- Being unpredictable makes it difficult for your opponents to understand and orient themselves to what will happen next.
- The ability to make decisions faster than an opponent is important
The product owner needs to know the OODA loop
Observe:
- See the situation as it unfolds
- Move outside yourself to see the whole picture.
Orient:
- What outcomes you're capable of seeing.
- What alternatives you create for yourself.
- Factors affecting what you're able to see are: genetic heritage, cultural traditions, previous experiences, and the unfolding circumstances.
- How you see the world.
- Your place in the world.
Decision:
- Suggestions towards an action or response plan, taking into consideration all the potential outcomes.
Act:
- Carrying out the decision and related changes that need to be made in response to that decision.
Factors affecting the OODA Loop are:
- The number of potential scenarios that can be pursued.
- Denial that a specific event has occurred, and refusing to acknowledge it right away.
- The complexity of the stimulus.
- The need for approval prior to carrying out a response.
- The emotional stress of the team or environment at the onset of the stimulus.
- The level of trust that exists within a team to rely on each other's decisions.
- The amount of intuitive skill that is possessed relating to the stimulus.
- Clearly, or unclearly, defined business goals.
- Stimulus that is constantly evolving or changing.
Importance of Feedback
- What scrum does is give the product owner the ability to see how much value that an increment creates and how people react to it.
- Based on this feedback loop, the product owner can change what the team will do in the next sprint.
- This feedback loop accellerates innovation and adaptation, and enables the product owner to measure how much value is delivered.
- The product owner has the ability to adjust on the fly to a constantly changing world.
- The key is to look for what slices actually hold value -- enough value that you can get real feedback on them and creact in real time.
- The key is not to have a fully established design at the beginning but to make a functional prototype and then see what you can improve.
- The sooner you have some real feedback the faster you can make things better.
Delivering Value
- When you're thinking about building something, don't assume you can't deliver something of value until the very end.
- Think about the minimum viable product. What is the absolute least I can build and still deliver some value to a customer?
- Create yourself an opportunity to inspect and adapt.
- The key to the backlog is to figure out how to deliver the most value most quickly.
- 20% of the features hold 80% of the value.
- After the first sprint you may change the order of the backlog, realising that another arrangement is actually better.
- The backlog is about the order that delivers value the fastest.
- The order of the backlog is always in flux.
- The key is to acknowledge uncertainty.
- Because of constantly shifting market needs and because managers don't know exactly where the most value lies, is prioritising everything -- everything is top priority.
- When you're making something, you want to put it into the hands of those who are actually going to use it as fast as possible. You want to do this before you make 20% of the features.
- You want to do this with something that delivers at least a tiny bit of value -- the "minimum viable product" --> this should be the first thing you show to the public the first time.
- You need to get that product out as early as possible, this will get you the feedback you need to power your decision loop and prioritisation.
- Every hour spent polishing the apple is lost opportunity for value.
- What is great about scrum is that this process is iterative.
- Once people have your product or service, they will tell you what the next most valuable things are.
- Traditional project management is set up to stop you, it's set up to stop delivering value faster.
Managing Risk
- Managing risk is at the heart of any successful venture.
- The three most common types of risk are: market risk, technical risk, and financial risk.
- Do people want what you're building (market)
- Can we actually build it? (technical)
- Can we really sell what we've built (financial)
- Scrum helps you minimize risk by emphasizing market delivery.
- Scrum allows you to put a product in front of customers faster.
- Scrum allows you to obtain feedback early and often.
- Financial risk is what makes most companies fail.
Getting Started with Scrum
- Put together a backlog
- Put together a team
- Think about the vision you have for your product or service.
- Start breaking down things you need to execute that vision.
- Start with just a week's worth of backlog items.
- Keep an eye on that backlog.
- As a product owner, put together a roadmap of where you think things are going --> just estimate.
- Create transparency by using a roadmap.
- Ensure that everything is done in the open.
Know as a product owner that you'll be evaluated on revenue and cost.
Key Takeaways
Make a list, check it twice
Create a list of everything that could possibly be done on a project, then prioritise it. Put the items with the highest value and lowest risk at the top of the backlog, then the next, and then the next.
The Product Owner
The product owner translates vision into the backlog. The Product Owner needs to understand the business case, the market, and the customer.
A leader isn't a boss
A product owner sets out what needs to be done and why. How the team accomplishes it and who accomplishes it is up to the team.
The Product Owner's Knowledge
The product owner has the knowledge of the domain and the power to make final decisions. He or She is available to answer questions and is accountable for delivering value.
Observe, Orient, Decide, Act (OODA Loop)
See the whole strategic picture, but act tactically and quickly.
Fear, Uncertainty and Doubt
It's better to give than to receive. Get inside your competitions OODA loop and wrap them up in their own confusion.
Get your money for nothing and your chnange for free
Create new things only as longa s those new things deliver value. Be willing to swap them out for things that require equal effort. What in the beginning you thought you needed is never what is actually needed.