Skip to content

My takeaway

Entertaining introduction to Scrum. Supported by stories from how different companies have implemented the framework. Liked that the author explains the why behind the framework, not just the how, and that he’s doing it in an accessible and easy way. Gave me a more meaningful understanding of how Scrum can be integrated in projects.

My notes

These are my informal notes from Scrum. It contains a mix of key highlights as well as my own thoughts and lessons.

  • The Scrum framework harnesses how teams actually work and gives them the tools to self-organize and rapidly improve both speed and quality of work.
  • The end results of Scrum—the design goal, if you will—are teams that dramatically improve their productivity.
  • Often people simply say that everything is important. But what they need to ask is “what will bring the most value to the project?” Do those things first.
  • Agile declares the following values: 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.
  • One of management’s key tasks is to identify and remove impediments to the team’s flow.
  • For Scrum to really take off, someone in senior management needs to understand in his bones that impediments are nearly criminal.
  • Every little while, stop doing what you’re doing, review what you’ve done, and see if it’s still what you should be doing and if you can do it better.
  • Corporate culture often puts more weight on forms, procedures, and meetings than on visible value creation that can be inspected at short intervals by users. Work that does not produce real value is madness.
  • One of the key concepts in Scrum is that the team members decide themselves how they’re going to do the work.
  • In software development there’s a term called “Brooks’s Law” that Fred Brooks first coined back in 1975 in his seminal book The Mythical Man-Month. Put simply, Brooks’s Law says “adding manpower to a late software project makes it later.”
  • 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.
  • The sooner you give things to your customers, the quicker they can tell you if you’re making something they need.
  • Sprints are what are often called “time boxes.” They’re of a set duration. You don’t do a one-week Sprint and then a three-week Sprint. You have to be consistent. 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 the team commits to what they’re going to accomplish, the tasks are locked in. Nothing else can be added by anyone outside the team.
  • There’s no assigning of tasks from above—the team is autonomous; they do that.
  • What Scrum does is alter the very way you think about time. After engaging for a while in Sprints and Stand-ups, you stop seeing time as a linear arrow into the future but, rather, as something that is fundamentally cyclical.
  • A team that depends on regular heroic actions to make its deadlines is not working the way it’s supposed to work. Constantly moving from one crisis to the next causes burnout, and it doesn’t allow for reasoned, continuous improvement.
  • “Who is this task being done for? Whose lens on the world is the one we need to gaze through when we’re building this thing, making that decision, or delivering this piece?”
  • 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 the problem is, or T-shirt size (S, M, L, XL, XXL), or, more commonly, the Fibonacci sequence.
  • “What is the little improvement that can be done right away that will make things better?”
  • If the Product Owner isn’t available to the team, the whole process can fall apart.
  • When you’re thinking about building something, don’t assume you can’t deliver something of value until the very end.
  • Give people the freedom to do what they think best and the responsibility to be accountable for it.