Scrum par Jeff Sutherland

Ressources

• Scrum: The Art of Doing Twice the Work in Half the Time

Cette dernière section sur Scrum est un ensemble de note que j’ai trouvé intéressante lors de la lecture du livre Scrum: The Art of Doing Twice the Work in Half the Time

L’auteur

Jeff Sutherland est l’un des fondateurs du cadre de travail Scrum. Au fil du temps, ces méthodes ont évolué, s’écartant parfois de leurs principes initiaux. Jeff Sutherland revient sur le pourquoi et le comment du framework Scrum, en détaillant son approche et en présentant les résultats scientifiques qui en démontrent l’efficacité.

Notes de lectures

Inspection et adaptation

• At its root, Scrum is based on a simple idea: whenever you start a project, why not regularly check in, see if what you’re doing is heading in the right direction, and if it’s actually what people want? And 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. That’s what’s called an “Inspect and Adapt”
  • Introspection, honnêteté et discipline

Taiichi Ohno’s

• Scrum is based on: Toyota. And, more specifically, Taiichi Ohno’s Toyota Production System.
  • One of the key concepts that Ohno introduced is the idea of “flow.”
  • Production should flow swiftly and calmly throughout the process
  • Management’s key tasks is to identify and remove impediments to that flow.
  • Eliminate waste must be a business’s first objectives

Ohno’s ideas come in—they discuss not what they did, but how they did it. They ask, “How can we work together better in the next Sprint? What was getting in our way during the last one? What are the impediments that are slowing our velocity?”

⇒ En d’autres termes il faut identifier et résoudre se qui nous a ralenti

Valeur

• “Scrum is not about the developers. It’s about the customers and stakeholders.

Planification

• Planning Is Useful. Blindly Following Plans Is Stupid. It’s just so tempting to draw up endless charts. All the work needed to be done on a massive project laid out for everyone to see—but when detailed plans meet reality, they fall apart. B

Par conséquent, il faut intégrer dans notre méthode de travail l’hypothèse du changement, de la découverte et des idées nouvelles.

Hyperproductivité

• Scrum teams that work well are able to achieve what we call “hyperproductivity.” It’s hard to believe, but we regularly see somewhere between a 300- to 400-percent improvement in productivity among groups that implement Scrum well.

Teams

• Everyone knows this, but in business we all too often focus solely on individuals, even if production is a team effort. Think of performance bonuses or promotions or hiring. Everything is focused on the individual actor, rather than the team
• Managers tend to focus on the individual because it makes intuitive sense. You want the best people, and people are different, so focus on getting the best performers, and you’ll get better results, right? Well, it’s not quite that simple.

Avec Scrum on ne se concentre pas sur les performances individuelle, on cherche à créer la meilleure équipe. Ainsi on peut se demander qu’est-ce qui caractérise une bonne équipe et comment pouvons nous le reproduire ?

1. Transcendent: They have a sense of purpose beyond the ordinary. This self-realized goal allows them to move beyond the ordinary into the extraordinary. In a very real way the very decision to not be average, but to be great, changes the way they view themselves, and what they’re capable of
2. Autonomous: The teams are self-organizing and self-managing, they have the power to make their own decisions about how they do their jobs, and are empowered to make those decisions stick
3. Cross-Functional: The teams have all the skills needed to complete the project. Planning, design, production, sales, distribution. And those skills feed and reinforce each other. As one team member that designed a revolutionary new camera for Canon described it: “When all the team members are located in one large room, someone’s information becomes yours, without even trying. You then start thinking in terms of what’s best or second best for the group at large and not only where you stand.”

On peut également se poser la question de la taille de l’équipe, la Loi de Brooks que nous avons déjà évoqué nous dit adding manpower to a late software project makes it later

• Once the teams grew larger than eight, they took dramatically longer to get things done. Groups made up of three to seven people required about 25 percent of the effort of groups of nine to twenty to get the same amount of work done.

Pourquoi ajouter du monde à un projet le rend pas plus rapide ?

• The first is the time it takes to bring people up to speed.
• The second reason has to do not only with how we think but, quite literally, with what our brains are capable of thinking : the number of communication channels increases dramatically with the number of people, and our brains just can’t handle it.