Agile, Scrum, Waterfall, Kanban, the list of software development methodologies is endless. Well, maybe not endless, but really long.

Like most things in life, it’s hard to implement a process or system exactly as it was designed. Most times we take the framework and adapt it to suit our needs.

While reading Scrum: The Art of Doing Twice the Work in Half the Time I took notes on the very best of Scrum (as I see it).

  • Scrum incorporates the concepts of continuous improvement and minimum viable products to get immediate feedback from consumers, rather than waiting until a project is finished. Read more at location 73
  • Question whether there are any ways to improve how you’re doing what you’re doing, any ways of doing it better and faster, and what might be keeping you from doing that, and what will bring the most value to the project? Do those things first.
  • People over processes; products that actually work over documenting what that product is supposed to do; collaborating with customers over negotiating with them; and responding to change over following a plan.
  • And the most powerful part of Scrum from his point of view? “Demos. Driving toward a demonstrable product on a frequent basis.” Every two weeks the Sentinel team would demonstrate what they’d accomplished. And this show-and-tell wasn’t just to themselves. Read more at location 313
  • If he or she responds by mentioning the product they’re working on (say automation or integration) rather than their specialty (such as network engineering), she nods approvingly. When a specialist identifies with their specialty more than with the product they’re actually making, you know you’ve got it right
  • Just as on a Special Forces team, everyone on a Scrum team has to know what everyone else is doing. All the work being done, the challenges faced, the progress made, has to be transparent to everyone else. And if the team gets too big, the ability of everyone to communicate clearly with everyone else, all the time, gets muddled. There are too many crosscurrents. Often, the team socially and functionally breaks into sub-teams that begin working at cross-purposes. The cross-functionality is lost. Meetings that took minutes now take hours. Don’t do it. Keep your teams small. Read more at location 979
  • The Scrum Master, the person in charge of running the process, asks each team member 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 it. That’s the whole meeting. If it takes more than fifteen minutes, you’re doing it wrong. Read more at location 1219
  • This phenomenon has been labeled “ego depletion.” The idea is that making any choice involves an energy cost. It’s an odd sort of exhaustion—you don’t feel physically tired, but your capacity to make good decisions diminishes. What really changes is your self-control—your ability to be disciplined, thoughtful, and prescient. Read more at location 1637
  • Let’s say it’s a week long. 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. And once you have a velocity, you can look at how many stories you have left and how many points they represent, and then you know when you’ll be done. Read more at location 2109
  • Only Plan What You Need To. Don’t try to project everything out years in advance. Just plan enough to keep your teams busy. Read more at location 2182
  • 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. Read more at location 2192
  • Know Your Velocity. Every team should know exactly how much work they can get done in each Sprint. And they should know how much they can improve that velocity by working smarter and removing barriers that are slowing them down. Read more at location 2195
  • Set Audacious Goals. With Scrum it is not that hard to double production or cut delivery time in half. If you do it in the right way, your revenue and stock price should double as well. Read more at location 2198
  • Here’s how it works. At the end of each Sprint each person on the team answers just a few questions: 1. On a scale from 1 to 5, how do you feel about your role in the company? 2. On the same scale, how do you feel about the company as a whole? 3. Why do you feel that way? 4. What one thing would make you happier in the next Sprint? Read more at location
  • People high up on that pyramid are not only happier and more fulfilled, they’re more effective and innovative. And they’re able to deliver greatness. Read more at location 2540
  • It’s the Journey, Not the Destination. True happiness is found in the process, not the result. Often we only reward results, but what we really want to reward is people striving toward greatness. Read more at location 2551
  • 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. Read more at location 2556
  • Get Better Every Day—and Measure It. At the end of each Sprint, the team should pick one small improvement, or kaizen, that will make them happier. And that should become the most important thing they’ll accomplish in the next Sprint. Read more at location 2558
  • 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 it, and everyone should update it every day. Read more at location 2563
  • Every company needs to think about this diagram. If you concentrate only on what you can build, you can end up making something that nobody actually wants, even if you’re passionate about it. If you concentrate only on what you can sell, you can promise things you can’t build. If you only build what you can sell but aren’t passionate about, you end up working hard to build mediocrity. But in the center, that sweet spot, is a vision rooted in reality—a vision with a real possibility of becoming something great. Read more at location 2587
  • Immediately create revenue, effectively “de-risking” the project. And you want to do that on the features level. You want to start delivering value to your customers as soon as you possibly can. You want something that is completely Done—that you can show. It could be just a small part of the larger project, but it should be demonstrably Done. If you’re painting a house, maybe what’s Done first is all the trim in the living room. In product development there’s a hard-and-fast rule that has been proven over and over again. I talked about this earlier: 80 percent of the value is in 20 percent of the features. Read more at location 2616
  • The Chief Engineer can’t simply say something has to be done a particular way. He has to persuade, cajole, and demonstrate that his way is the right way, the best way. It usually takes someone with thirty years of experience to fill the role. I wanted that in Scrum, but I’m also well aware that very… Read more at location 2664
  • There may be many millions of ways to arrange that Backlog, but the one you want delivers those 20 percent of features that hold 80 percent of the value as quickly as possible. Your first guess for the first Sprint almost certainly won’t be the right one, but it will be your best guess at the time. Read more at location 2822
  • One bad habit a company can fall into, because of constantly shifting market needs and because managers don’t know exactly where the most value lies, is prioritizing everything. Everything is top priority. The adage to keep in mind comes from Frederick II of Prussia, later to be called “the Great”: “He who will defend everything defends nothing.”… Read more at location 2833
  • Then every Sprint, the customer, who in this scenario is contractually obligated to work closely with the Product Owner, can change priorities completely. Any item or feature in the Backlog can be moved anywhere else. And new features? No problem: just drop equivalently sized features from the deliverables. Oh, you want a laser-guided system now? Well, that’s 50 points of work—to compensate… Read more at location 2910
  • Make a List. Check It Twice. Create a list of everything that could possibly be done on a project. Then prioritize it. Put the items with the highest value and lowest risk at the top of that Backlog, then the next, and then the next. Read more at location 3008
  • At any point, the Product Backlog is the single, definitive view of “everything that could be done by the team ever, in order of priority.” Only a single Product Backlog exists; this means the Product Owner is required to make prioritization decisions across the entire spectrum. The Product Owner should consult with all stakeholders and the team to make sure they are representing both what people want and what can be built. (See Chapter Eight: Priorities for more.)Read more at location 3475
  • Refine and Estimate the Product Backlog. It is crucial that the people who are actually going to complete the items in the Product Backlog estimate how much effort they will take. The team should look at each Backlog item, and see if it is actually doable. Is there enough information to complete the item? Is it small enough to estimate? Is there a Definition of Done, that is, everyone agrees on what standards must be met to call something “done”? Does it create visible value? Each item must be able to be shown, to be demonstrated, hopefully to be potentially shippable. Do not estimate the Backlog in hours, because people are absolutely terrible at that. Estimate by relative size: Small, Medium, or Large. Or even better use the Fibonacci sequence and estimate the point value for each item: 1, 2, 3, 5, 8, 13, 21, etc. (See Chapter Six: Plan Reality, Not Fantasy for more.) 6. Sprint Planning. This is Read more at location 3479