Release year: 2018

Author: Don McGreal & Ralph Jocham

Link to my handwritten notes

Buy this book

Review

I have started reading this book out of interest for the Product Owner role, which is a key role in the Scrum framework for delivering value.

Scrum is a pretty ubiquitous term in the world of software development. It is meant to help development teams (i.e. “programmers”) continuously deliver value, and pivot quickly in case they notice the direction they took in their development is not aligned with what customers want.

In theory it all sounds fantastic. It is a practical and adaptable application of the Agile manifesto , which lays out the order of priorities when developing software to ensure optimal results. The problem with Scrum (if there is one) is that everyone wants to put their own twist on the framework. That twist is too often to remove crucial parts of the framework, without which it loses its ability to function. In my experience, people will choose to cut the bits that “take up too much time”, e.g. the Sprint Retrospective. I suspect that this is because their teams have low psychological safety and don’t feel comfortable telling the truth. It could also be that the learnings made in those meetings are never brought into the sprint backlog to be worked on…

Anyway, this review is not to knock on Scrum. Actually, I believe Scrum is the way to go for software development, hence why I started to read this book. Product Ownership seems like a potentially interesting career path worth considering. I think it’s a nice way to have a significant impact on the culture of an engineering department. When done right, it could make the lives of tens of people significantly better.

What is a Product Owner? That is the person who makes the final call about what work assignments to give to the development team(s), with the right amount of detail, and ordered based on business priorities, risk, etc. The Product Owner will also report after every sprint what value increment was generated, and determine if and when to pivot. Think of this role as the transmission belt between the top management and the workers.

The book itself seemed very complete to me. If you’re thinking of becoming a Product Owner, this is a great reference. Not only will it lay out the responsibilities and expectations that come with the role, but it will be a great refresher on why Scrum, at least in theory, works. Get ready for a fairly dry read, though!

To be frank, there was so much material covered here (as can be noticed from reading my Star Quotes) that I will probably have to revisit these notions if/when I make the jump into this role. I could have probably made a better job of really getting to the essential bits and trimming my quotes down, but I think it will do for now. I am not a Product Owner yet, after all!

Félix rating:
👍

⭐ Star Quotes

  1. (p. xiv) As the person who wants something, when you use Scrum to improve communications and the outcomes, your role is called the Product Owner.

Part I: Strategy

Chapter 1: Agile Product Management

  1. (p. 6) Meaningful business targets examples:
    • user adoption
    • sales
    • stakeholder satisfaction
  2. (p. 6) “What can we ship first that will have the biggest impact on our thoughts?”
  3. (p. 10) The Three V’s: Vision –> Value –> Validation –> Vision –> …
  4. (p. 12) ⭐ Self-organization does not just happen. The two main ingredients are shared vision and clear boundaries.
  5. (p. 13) Defining value gives you something to inspect.
  6. (p. 13) A scrum team’s job is to identify and then attach pearls (value) to the thread (vision).
  7. (p. 13) ⭐ If everything is important, then nothing is.
  8. (p. 14) If you are not able to quantify success or to prove the realization of value, then the chances of being on the wrong track are rather high.
  9. (p. 14) Each valuable idea has to be validated as soon as possible. In Scrum this is done in the Sprint Review.
  10. (p. 15) You do not have true validation until the product or feature is in production and used.
  11. (p. 20) An entrepreneurial mindset is something Product Owners should assume. They should expect to see an ROW as though their own money was at stake.
  12. (p. 23) ⭐ Think about the product from a customer’s perspective:
    • Which customer needs are you addressing?
    • What do customers expect?
    • What product improvements will make customers’ lives easier?
  13. (p. 30) The real Product Owner ultimately decides which features are best, regardless of how many voices there are.

Chapter 2: Vision

  1. (p. 34) ⭐ A vision is a picture of the success of a project at a particular time in the future. A vision is not a mission statement.
  2. (p. 34) An effective vision needs to be:
    • Inspiring
    • Strategically sound (you have a shot at doing it)
    • Documented (written down)
    • Communicated (tell people about it!)
  3. (p. 46) Elevator Pitch template:
    • For [target audience]
    • Who [need, want]
    • [Product name] is a [market category]
    • that [one key benefit]
    • unlike [competition or current situation]
    • our product [competitive advantage]
      • Once you’ve filled in the blanks, take some time to distill it into one or two sentences and find a way to make it a little more practical and a little more emotional.
  4. (p. 46) A good vision becomes much more memorable when your audience can imagine themselves doing something (practical) and when it tugs on their heart strings (emotional).
  5. (p. 49) As a product owner, it is your responsibility to communicate the vision and ensure it is well understood and adhered to.
  6. (p. 50) The sprint retrospective is your opportunity to inquire about the effectiveness of your vision communications.
  7. (p. 50) ⭐ Consider asking the following questions in the retrospective:
    • Is everybody on the team comfortable with the vision?
    • Is our vision still relevant?
    • Which actions from the last Sprint reflect the vision? Which do not?
      • Do our stakeholders understand the vision? Which ones do not?
      • What are some ways to improve our vision communication?
  8. (p. 50) Find ways to make the vision statement visible in the team’s work area.
  9. (p. 52) A Product Owner needs to focus on the “what” (strategy), not the “how.”

Chapter 3: Value

  1. (p. 56) As people, anything we consider to be of value ultimately comes down to happiness. As companies, anything they consider to be of value ultimately comes down to money.
  2. (p. 56) For non profits, money is circumstantial. In fact, increasing revenue while not positively impacting society would be considered negative value.
  3. (p. 57) Each release is an opportunity to create value. Everything leading up to a release is an investment.
  4. (p. 59) ⭐ Until you release, you are adding no value, only costs.
  5. (p. 60) Each release should be looked at as a return on investment.
  6. (p. 63) ⭐ Wrong assumptions lead to bad decisions.
  7. (p. 66) Value metrics based on Evidence-Based Management:
    • Current value:
      • Revenue per employee
      • Product cost ratio
      • Employee satisfaction
      • Customer satisfaction
    • Time to market
      • Release frequency
      • Release stabilization
      • Cycle time
      • On-product index
    • Ability to innovate
      • Installed version index
      • Usage index
      • Innovation rate
      • Defects
  8. (p. 68) Revenue per employee is an interesting metric to observe when your product or organization is going through a growth phase.
  9. (p. 69)
    • Leading metric example: Investment in product development
    • Lagging metric example: Cost of running the product in production
      • Lagging metrics are much more meaningful to the business because they represent the reason for having a product.
  10. (p. 70) ⭐ Engaged employees that know how to maintain, sustain, and enhance the software systems and products are one of the most significant assets of an organization.
  11. (p. 71) The Sprint Retrospective is a great time to measure the employee satisfaction of the Dev team. A simple consistent question will allow you to spot trends over time:
    • “On a scale from “5 - I am super happy!” to “1 - I never want to experience that again,” how did you feel about that last sprint?
  12. (p. 71) ⭐ The purpose of business is to create and keep a customer (Peter Drucker)
  13. (p. 72) Let your customers give you feedback directly through your product:
    • “Tell us what you like”
    • “Tell us what can be better”
  14. (p. 73) Without actively managing Time-to-market (ability to deliver), the ability to sustainably deliver value in the future is unknown.
  15. (p. 74) Tracking a rolling window of release frequency over three-month periods demonstrates time-to-market agility in a much clearer way than velocity or scope ever could.
  16. (p. 75) ⭐ Whenever you are “Done” with the development of a feature, you should make a release. Any delay beyond that is considered waste.
  17. (p. 76) For each additional project someone undertakes, 20% of their time is lost to the act of context switching.
  18. (p. 78) ⭐ How many of your customers are using your latest product version? This percentage is a direct reflection of the value you are delivering each release.
  19. (p. 82) ⭐ When the maintenance work is unpredictable, measure the time spent on unplanned maintenance items each sprint.
  20. (p. 86) ⭐ According to several studies, people are between three to seven times more likely to relate negative experiences than positive ones.
  21. (p. 87) ⭐ If the fix is quick and dirty, the result is technical debt. The dirty stays, while the quick is long gone.
  22. (p. 89) ⭐ You cannot manage what you cannot measure. But also, what you measure drives the behavior of the people involved.
  23. (p. 90) ⭐ If you punish bad news, you will only get good news – or, more accurately, camouflaged bad news made to look good.
  24. (p. 90) ⭐ Goodhart’s Law: When a measure becomes a target, it ceases to be a good measure.

Chapter 4: Validation

  1. (p. 94) ⭐ All ideas are nothing but hypotheses until customers validate them by paying for and using the resulting products or services. This is called validated learning.
  2. (p. 95) ⭐ The company that can fail and learn the fastest on an ongoing basis will be the most successful and sustainable.
  3. (p. 97) MVPs are about the validation of your hypotheses. You need to validate two kinds of hypotheses: technical and market.
  4. (p. 98) The higher the impact of a user story, the higher the priority order should be and the earlier you get to inspect at a Sprint Review and Retrospective.
  5. (p. 100) What makes an MVP:
    • The basic features (what customers assume are included with the product)
    • Enough performance features (customers ask for them because they are not always assumed to be included, e.g. AC in a car, navigation system)
    • A few exciter features (customers have likely not thought about them, but are thrilled once they discover them)
  6. (p. 106) When the data validates assumptions or is inconclusive, then continue to persevere, gathering more data along the way. When the data reveals that you are not gaining the value originally hoped for, then cur bait, pivot, and avoid the trap of complacency.
  7. (p. 106) ⭐ (Roman Pichler) Customer feedback is the basis for ideas. Customer data is the basis for decisions.

Part II: Scrum

Chapter 5: Empiricism

  1. (p. 115) Three steps of feedback loops:
    • Transparency
    • Inspection
    • Adaptation
  2. (p. 117) ⭐ One of the most important ingredients for high-performing teams is trust – without it, no effective team behavior will emerge.
  3. (p. 128) In general, it’s good to have high-risk Product Backlog items higher up in the backlog to enable quick learning and allow enough time to find an alternative solution or even to cancel the product without having lost too much money.
  4. (p. 128) Risk is uncertainty of outcome
  5. (p. 131) The key to getting support from management is building trust. ⭐ Scrum becomes a trust generation framework by delivering results each Sprint and by providing transparency.
  6. (p. 131) ⭐ (Mary Poppendieck) A late change in requirements is a competitive advantage.
  7. (p. 132) ⭐ $\text{Overall risk} = \text{Probability} * \text{Impact}$
    • Once you can set probability or impact to zero, the risk is managed.

Chapter 6: Scrum

  1. (p. 137) Forcing a process on a team will lead them to assign blame to the process when something goes wrong. It becomes all about finger pointing.
  2. (p. 137) If organizations are not careful, Scrum can be viewed as a rented process. We want a team to take ownership and to point to themselves when things don’t work out, so they self-organize with accountability.
  3. (p. 140) Those performing the work and those inspecting the resulting increment must share a common definition of “Done.”
  4. (p. 141) (Thomas Edison) Vision without execution is hallucination.
  5. (p. 142) The Product Owner is the sole person responsible for managing the Product Backlog.
  6. (p. 142) For the Product Owner to succeed, the entire organization must respect their decisions. The PO’s decisions are visible in the content and ordering of the Product Backlog. No one can force the Dev Team to work from a different set of requirements.
  7. (p. 143) A single person who truly owns the product and has the last say is crucial for product success.
  8. (p. 145) A good PO is a domain expert who knows the business from many angles.
  9. (p. 172) The harder it is to come up with a good concise Sprint Goal, the more you probably need one.
  10. (p. 180) The Sprint Retrospective is the most important event in Scrum.
  11. (p. 186) (Steve McConnell) “The problem with quick and dirty is that dirty remains long after the quick has been forgotten.”
  12. (p. 186) The Agile Manifesto values:
    • Individuals and interactions over processes and tools
    • Working software over comprehensive documentation
    • Customer collaboration over contract negotiation
    • Responding to change over following a plan

Part III: Tactics

Chapter 7: Product Backlog Management

  1. (p. 196) By being purposefully ambiguous and intriguing, user stories are designed to increase conversations.
  2. (p. 198) Use INVEST to inspect the quality of your user story:
    • Independent
    • Negotiable (and negotiated by the customer and dev during development)
    • Valuable (to the customer)
    • Estimable (negotiation helps the estimate)
    • Small (smaller stories get more accurate estimates)
    • Testable (requiring customer tests before implementing a story helps productivity)
  3. (p. 202) If a Product Backlog item cannot be turned into “Done” by the end of the Sprint, it is too large.
  4. (p. 204) To split a story, start with the acceptance criteria (“What are we going to demonstrate to prove this story is complete?”). Each proof can be translated into its own separate story.
  5. (p. 209) A poor reason for having a spike is to research a feature so that the Dev Team can feel more confident with their estimates. This is more fear of failure than experimentation and does not really help the Scrum Team make decisions.
  6. (p. 211) $$\text{The Order rank in the backlog} = \frac{\text{Business value} + \text{Risk}}{\text{Size (aka cost)}}$$
  7. (p. 220) Think of the definition of “Done” as the rules of quality that everyone commits to.
  8. (p. 223) Definition of Done template
  9. (p. 225) Organize your kitchen before you start cooking. If you are not “Ready” at the beginning of the sprint, you won’t be “Done” at the end of the Sprint.
  10. (p. 230) ⭐ The first reasonable moment to make a decision is the last responsible one.
  11. (p. 230) Delay commitment and keep important and irreversible decisions open until the cost of not making a decision becomes greater than the cost of making a decision.
  12. (p. 245) Simple asking “Could you give me some real examples that you would try to prove this works?” could resolve much ambiguity.

Chapter 8: Release Management

  1. (p. 258) The further an organization moves from major releases toward functional releases, the more essential it is to:
    • Bring testing into the Dev Team
    • ⭐ Bring operations into the Dev Team (DevOps)
    • Automate tests
    • Automate deployment
    • Engage stakeholders and users more often
  2. (p. 264) ⭐ Velocity is a circumstantial representation of value and is prone to Goodhart’s law: “When a measure becomes a target, it ceases to be a good measure.”
  3. (p. 267) (Frederick Brooks) Adding manpower to a late software project makes it later.
  4. (p. 292) Ensure that your stakeholders are consistently informed on where the money is being spent and what they are getting in return.
  5. (p. 293) If you are asked for a fixed budget for a fixed scope, realize that you have been asked to take on all the risk. Therefore communicate that the cost will be higher to effectively manage this risk.
  6. (p. 297) Any paperwork describing progress is futile – no customers will pay for that.
  7. (p. 301) Kickoff with Purpose, Context, and Alignment:
    • Purpose:
      • Vision
      • Mission
      • Mission tests (how can you measure that you are on the right track toward your mission?)
    • Context:
      • Boundaries
      • Project Community Interaction
      • Committed Resources
      • Prospective Analysis
    • Alignment:
      • Values and Principles
      • Core team
      • Working agreements
  8. (p. 303) In general, plan for at least one day for the kickoff.
  9. (p. 306) Validation is doing the right thing. Verification is doing it right.

Chapter 9: The professional Product Owner

  1. (p. 317) Identify all your stakeholders and go and talk to them, even if it means leaving the building. You need to understand their needs, their fears, their frustrations, and their hopes, so that you develop true customer empathy.
  2. (p. 321) How clear is your product vision?
    • Do the people creating the product know it?
    • Do your stakeholders know it?
    • Does your product backlog reflect the vision?
    • Are your release plan and sprint goals in line with the vision?
  3. (p. 321) How are you measuring value?
    • How often are you measuring it?
    • Are you maximizing return on investment?
    • Are your customers happier?
    • Is your Dev Team happier?
    • How much of your budget is being spent on new innovative features that your customers are asking for rather than maintenance?
    • Are you validating the product with your stakeholders and the marketplace?
      • If so, how often?
      • Are you adjusting the direction accordingly?
    • Is the quality of the product consistent enough to release whenever needed?