He tenido el placer de leerme esta última semana el libro “The Scrum Field Guide: Practical Advice for Your First Year” de Mitch Lacey. Mitch fue mi profesor del curso de certificación para ScrumMaster de la scrumalliance.org. Si el curso fue una pasada, el libro lo es aún más.
Debería ser de lectura obligatoria para todos aquellos que estáis en un proceso abierto de Scrum en vuestra empresa (si lo estáis pensando también os ayudará pero no le sacaréis tanto rendimiento). Da igual si lleváis 6 meses o 2 años, tendréis ejemplos claros y descripciones detalladas (a modo de relato) de las típicas situaciones y no tan típicas cuando os enfrentéis a su implementación, mantenimiento, mejora, relación con buenas prácticas de desarrollo, etc.
Aprovecho para dejar aquellas cosas que he subrayado porque me han parecido interesantes a destacar. Espero que os guste.
In The Fifth Discipline, Peter Senge defined learning organizations as “organizations where people continually expand their capacity to create the results they truly desire, where new and expansive patterns of thinking are nurtured, where collective aspiration is set free, and where people are continually learning to learn together”. Creating a team structure where people can grow their skills while accomplishing business goals is a challenge.
A team consultant is someone in your organization who is available for some amount of work and directly fills a skill gap between the team and the project. Team consultants are not core team members. They have no team, per se.
Añadir gente a un equipo existente
Brooks’ Law: “Adding manpower to a late software project makes it later”
In a 1999 article, Steve McConnell suggests that “controlled projects are less susceptible to Brooks’ Law than chaotic projects,” because people can be safely added due to better tracking, documentation and design.
Scrum en general
You don’t want frustrated management and disappointed customers. If you give them a set velocity, they are likely to make plans around that one number.
Facilitation is not solving other people’s problems or doing it for them; it’s making things run more smoothly
Titles do not map to the roles in Scrum. Skills do.
Good ScrumMasters need to have the soft skills to intervene when necessary and the emotional intelligence to know when it’s better to stay out of it altogether.
“If you want to make enemies, try to change something.” That quote, commonly attributed to former United States President Woodrow Wilson
Scrum y su relación con las buenas prácticas de ingeniería
Scrum does not talk about engineering practices.
TDD is not a testing process. It’s a software design technique where code is developed in short cycles. You can think of the TDD process as Red, Green, Refactor.
By following TDD, you will be less reluctant to implement some change that is required by a key stakeholder or customer, even late in the project.
At the University of Utah, Laurie Williams programming was 15 percent slower than two independent developers but produced 15 percent fewer bugs.
An agile release plan only has to include the best— and worst-case final release dates, but many plans also include smaller releases along the way, including end-of-sprint releases and quarterly releases.
No release plan or Gantt chart gives the true status like working software.
Writing stories and tasks that are right-sized can mean the difference between succeeding with Scrum and failing miserably. It’s that important.
Coste e impacto de los bugs
Industry standard numbers to fix a defect range from the familiar 1:10:100 rule, where things identified on the team member’s desktop have a cost of one and as they move through the software life cycle, they get more expensive.
The cost to fix a defect post release is 300 percent higher and takes triple the amount of time to get out the door.
The bus factor is the “number of people on your team who have to be hit with a bus before the project is in serious trouble”
La 4a pregunta de Scrum
What is your confidence, on a scale of one to ten, that the team will accomplish the goal of this sprint?
“If a person is otherwise comfortable with his environment but doesn’t understand one thing, then he will usually try stuff until he figures that one part out. This state of trying to reconcile one’s past experiences with an environment that doesn’t quite fit is Beginner’s Mind” [BELSHEE, p. 2].
Promiscuous pairing is an advanced skill, best suited for seasoned, well-practiced teams. New teams working in an unfamiliar framework will likely find this high-level practice too much to handle, at least at first.
Micro-pairing, coined by Peter Provost in 2006, has its roots in a game invented by Peter and Brad Wilson, The Pair Programming TDD Game.
Pair programming should be a tiring activity. If you arrive home spent but upbeat, you’ve probably had a good day of pairing.
Pairing is great for communicating design and for mentoring, but if you have a bunch of fairly straightforward bug fixes or are simply implementing a minor feature in an already fleshed out design, pairing might not be worthwhile.
Producto potencialmente entregable
While some would say that the sprint backlog is more of a forecast than a commitment, I firmly believe that when the team says it can deliver a certain amount of functionality in a sprint, it is a commitment made to the product owner and stakeholder group, who might well need to release that functionality at the end of the sprint.
“You’re efficient when you do something with minimum waste. And you’re effective when you’re doing the right something” [DEMARCO, p. 122].
To get a team in the mindset of delivering working software every sprint, I have them focus on one of two factors: core story, which we saw in the story, or number of users.
The core story is the absolute base requirement, the smallest slice of end-to-end functionality that is the most commonly used.
The key is to document as much as you need and nothing more.