Jeff Sutherland Quotes

No Heroics. If you need a hero to get things done, you have a problem. Heroic effort should be viewed as a failure of planning.

Multitasking Makes You Stupid. Doing more than one thing at a time makes you slower and worse at both tasks. Don’t do it. If you think this doesn’t apply to you, you’re wrong—it does.

Greatness can’t be imposed; it has to come from within. But it does live within all of us.

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.

That absolute alignment of purpose and trust is something that creates greatness.

Doing half of something is, essentially, doing nothing.

People aren't happy because they're successful. They're successful because they're happy.

the people who multitask the most just can’t focus.

Each cycle J.J. would talk to the team and ask three very simple questions: What did you do since the last time we talked? What are you going to do before we talk again? And what is getting in your way?

Making people prioritize by value forces them to produce that 20 percent first. Often by the time they’re done, they realize they don’t really need the other 80 percent, or that what seemed important at the outset actually isn’t.

It was the Scrum Master’s job to guide the team toward continuous improvement—to ask with regularity, “How can we do what we do better?” Ideally, at the end of each iteration, each Sprint, the team would look closely at itself—at its interactions, practices, and processes—and ask two questions: “What can we change about how we work?” and “What is our biggest sticking point?” If those questions are answered forthrightly, a team can go faster than anyone ever imagined.

observar, orientarse, decidir y actuar. Asimilaba

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.”8 This has been borne out in study after study.

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.

The thing that cripples communication saturation is specialization—the number of roles and titles in a group. If people have a special title, they tend to do only things that seem a match for that title. And to protect the power of that role, they tend to hold on to specific knowledge.

Agile Manifesto.” It declared 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. Scrum is the framework I built to put those values into practice. There is no methodology.

Never do betas. Never do work that you don’t think is good. You either give your customer something good, or you don’t. There is no ‘try’.

Embrace the unknown! That’s where learning lies! If you’re too afraid to learn, you will never get any better. This is the key to being successful at Scrum: embrace change.

Number of Simultaneous Projects Percent of Time Available per Project Loss to Context Switching 1 100% 0% 2 40% 20% 3 20% 40% 4 10% 60% 5 5% 75%

Blame Is Stupid. Don’t look for bad people; look for bad systems—ones that incentivize bad behavior and reward poor performance.

aunque planear el combate es importante, los planes se evaporan en cuanto suena el primer disparo.

The human mind has limits. We can only remember so many things; we can really only concentrate on one thing at a time. This tendency—for the process of fixing things to get harder as more time elapses—represents a similar limitation. When you’re working on a project, there’s a whole mind space that you create around it. You know all the different reasons why something is being done. You’re holding a pretty complicated construct in your head. Re-creating that construct a week later is hard. You have to remember all the factors that you were considering when you made that choice. You have to re-create the thought process that led you to that decision. You have to become your past self again, put yourself back inside a mind that no longer exists. Doing that takes time. A long time. Twenty-four times as long as it would take if you had fixed the problem when you first discovered it.

Often when people talk about great teams, they only talk about that transcendent sense of purpose. But while that’s a critical element, it’s only one leg of the three-legged stool. Just as critical, but perhaps less celebrated, is the freedom to do your job in the way that you think best—to have autonomy. On all great teams, it’s left to the members to decide how to carry out the goals set by those leading the organization.

The problem that I frequently see crop up is that people have a tendency to treat the Daily Stand-up as simply individual reporting. “I did this … I’ll do that”—then on to the next person. The more optimum approach is closer to a football huddle. A wide receiver might say, “I’m having a problem with that defensive lineman,” to which an offensive blocker might respond, “I’ll take care of that. I’ll open that line.” Or the quarterback might say, “Our running game is hitting a wall; let’s surprise them with a pass to the left.” The idea is for the team to quickly confer on how to move toward victory—i.e., complete the Sprint. Passivity is not only lazy, it actively hurts the rest of the team’s performance. Once spotted, it needs to be eliminated immediately.

Often when people talk about great teams, they only talk about that transcendent sense of purpose.

What Scrum does is bring teams together to create great things, and that requires everyone not only to see the end goal, but to deliver incrementally toward that goal.

people who work for those contractors aren’t stupid; they knew better. The problem was, everyone said, “Not my job.” They delivered their piece and left it at that. They never looked at the site from the user’s point of view, merely from their own. The reason they could do that was that they weren’t aligned—weren’t united in a common purpose.

A mi primer equipo con Scrum solía presentarle un video del equipo de rugby All Blacks preparándose para un partido. Los All Blacks, escuadra legendaria de la diminuta Nueva Zelanda, son un equipo trascendente. Antes de cada encuentro celebran la ceremonia de la haka, propia de los guerreros maoríes. La haka es una danza guerrera que llena de energía a quienes están por entrar en batalla. Al presenciarla, casi puedes ver la energía salir de cada jugador y fusionarse en un gran conjunto.

SCRUM Development Process” (Proceso de desarrollo con SCRUM),

Cuando enseño a la gente a aplicar Scrum, me sirvo justo de eso: de aviones de papel. Divido al grupo en equipos y les digo que la meta es hacer el mayor número posible de aviones. Habrá tres roles en cada equipo: una persona confirmará que los aviones vuelen; otra participará en el proceso de montaje, pero buscará formas en que el equipo puede hacer mejores aviones y aumentar su producción, y todos los demás miembros se ocuparán de hacer el mayor número posible de aviones en el tiempo de montaje asignado. Posteriormente indico que se realizarán tres ciclos de

elaboración de aviones, de seis minutos cada uno. A planear cómo hacerlos se dedicará un minuto, tres a elaborarlos y probarlos y dos a revisar. En esta última fase, el equipo ve el modo de mejorar su procedimiento de elaboración de aviones. ¿Qué salió bien? ¿Qué salió mal? ¿El diseño debería cambiar? ¿En qué puede mejorar el procedimiento de elaboración? Finalmente, el equipo actúa. En el mundo de Deming, “actuar” significa cambiar la manera de trabajar con base en los resultados reales y las aportaciones reales del entorno. Esta estrategia es igual a la que siguió el robot de Brooks.

Recorre tres veces este ciclo y así hagas aviones de papel o naves espaciales, mejorarás, y mucho (trabajarás de dos a tres veces más rápido y con al menos el doble de calidad). El ciclo PDCA, una idea radical cuando Deming la transmitió a los japoneses, fue el medio que permitió a Toyota convertirse en la compañía automotriz número uno del mundo. Y

RESUMEN Dudar es mortal. Observa, oriéntate, decide y actúa. Determina dónde estás, evalúa tus opciones, toma una decisión ¡y actúa! Busca respuestas a tu alrededor. Los sistemas adaptativos complejos siguen unas cuantas reglas, que adquieren de su entorno. Los grandes equipos. Son interfuncionales, autónomos, con autoridad y con un propósito trascendente. No supongas; planea, haz, revisa, actúa. Planea qué harás. Hazlo. Revisa si lograste lo que querías. Actúa en consecuencia y cambia tu manera de hacer las cosas. Repite esto en ciclos regulares y alcanzarás la mejora continua. Shu Ha Ri. Primero aprende las reglas y formalidades y, una vez que las domines, haz innovaciones. Por último, en un alto estado de maestría, desecha las formalidades y sólo sé, con el aprendizaje que ya has interiorizado y tomando decisiones de modo casi inconsciente.

haga una venta. Interfuncional. El equipo debe tener todas las habilidades necesarias para terminar un proyecto, así su misión sea entregar software de Salesforce o capturar terroristas en Iraq. Prefiere lo chico. Los equipos reducidos trabajan más rápido que los grandes. La regla son siete miembros, dos de más o de menos. Peca de cicatero. Es absurdo culpar. No busques malas personas, sino malos sistemas: aquellos que incentivan la mala conducta y premian el bajo rendimiento.

puedas echar a andar un equipo en un par de días. Consigue tu lista de Pendientes, planea tu primer sprint y lánzate. No es necesario que dediques mucho tiempo a la planeación, reflexión, meditación, declaraciones de misión o proyecciones a cinco años. Deja esto a la competencia y que muerda el polvo. Y sobre la marcha, ¿por qué no haces un mundo mejor? Te diré cómo en el capítulo siguiente.

responsable del producto. Este individuo debe conocer el terreno y tener autoridad para tomar decisiones definitivas. Debe estar disponible para responder a preguntas y estará a cargo del suministro de valor. Observa, Oriéntate, Decide, Actúa (OODA). Percibe el panorama estratégico total, pero actúa tácticamente con rapidez. Miedo, incertidumbre y duda. Es mejor dar que recibir. Entra en el ciclo OODA de la competencia y envuélvela en su confusión. Obtén dinero por nada y haz las modificaciones gratis. Crea cosas nuevas sólo en tanto produzcan valor. Accede a intercambiarlas por cosas que requieren un esfuerzo igual. Lo que al principio creíste necesitar no es nunca lo que en verdad precisas.

Scott Maxwell dice que el verdadero poder de Scrum radica en sus Pendientes listos, priorizados y evaluados. Por eso implementó ese enfoque en su grupo de capital de riesgo y por eso lo considera una ventaja competitiva fundamental.

It’s the system that surrounds us, rather than any intrinsic quality, that accounts for the vast majority of our behavior.

We find in real projects that if stories are really Ready, the team will double the speed of implementation. And if the stories are really Done at the end of a Sprint, teams can double speed again.

They don’t change how big the project is, or what’s involved in creating it, but just by doing one thing exclusively before moving on, the work takes a little more than half as much time.

Citizenship in a Republic” (Ciudadano de una república) que el expresidente Theodore Roosevelt pronunciara en la Sorbona en 1910: No es el crítico el que importa; el que señala cómo tropieza el fuerte o qué habría podido hacer mejor el resuelto. El mérito es de quien está en el ruedo, cubierta la cara de polvo, sudor y sangre; de quien lucha con valentía; de quien falla y se equivoca una y otra vez, porque no hay esfuerzo sin tacha ni error; de quien asume la responsabilidad de actuar; de quien conoce grandes entusiasmos y devociones; de quien se entrega a una buena causa; de quien al final conoce el triunfo de su empeño y que si, en el peor de los casos, fracasa, lo hace al menos habi

Uno de sus nuevos productos es un sistema automatizado para el hogar. Esa compañía fabricó un sistema capaz de controlar todos los aspectos de una casa, desde la apertura del portón hasta el control de costos de calefacción y el encendido de luces, todo desde un dispositivo portátil. Así, sus ejecutivos se reunieron para hacer una lista de lo que necesitaban para hacer posible ese sistema: interruptores, controladores, interfaces, sensores, protocolos de comunicación... No las reglas y piezas específicas, sino todas las “historias” que necesitarían. Escribieron cosas como “En mi calidad de propietario de una casa, me gustaría poder ver quién llama a mi puerta para abrirla únicamente a quien quiero que entre”. Escribieron historias sobre la apertura de la puerta de la cochera, el encendido del HVAC y el control de las luces. Y no dejaron de escribir hasta tener una lista de todo lo que creían que el sistema debía hacer para resultar una adquisición atractiva.

¿Y si pudieras empezar ofreciendo cosas cinco veces más rápido que la competencia, con cinco veces más valor? Sería un éxito inicial total. La compañía automatizadora tomó una enorme lista de funciones ante la que sus miembros se preguntaron: “¿Qué haremos mañana? ¿Qué es lo más importante para el cliente? ¿Cómo podemos ofrecerle valor más rápido que nadie más?”. Como dice Scott Maxwell, la parte difícil no es saber qué quieres, sino qué puedes lograr. Esto es cierto así construyas una casa o fabriques un auto, escribas un libro o un videojuego o

¿cómo sabrás que ya está terminada? Usemos como ejemplo la historia de Stoll: Como médico de fuerzas especiales, debo enseñar fisiología básica a mis alumnos, para que conozcan el cuerpo humano. Yo uso siempre un recurso nemotécnico para saber si una historia está lista. Fue creado por Bill Wake, especialista en diseño de software. Wake dice que para que una historia esté lista debe cumplir los criterios INVEST (“Invierte”): Independiente. Debe ser practicable y completable por sí sola. No debe depender inherentemente de ninguna otra. Negociable. Hasta que no esté terminada, debe ser posible reescribirla, llevar integrada la tolerancia a cambios. Valiosa. Tiene que aportar valor a un cliente, usuario o interesado. Estimable. Debe ser posible evaluarla.

colaborar con los clientes antes que negociar con ellos y responder al cambio antes que seguir un plan. Scrum es el marco que yo creé para poner en práctica esos valores. No es ninguna metodología.

El experimento de Milgram consistía en lo siguiente: el sujeto, un individuo del común, era instruido por alguien con bata blanca (lo que le daba una apariencia de autoridad científica) para que administrara choques eléctricos cada vez más intensos a un tercero, un actor, situado en otro cuarto. El sujeto podía oír pero no ver al actor. Mientras los choques aumentaban, este último empezaba a gritar y suplicar. Finalmente el actor (quien, en algunas versiones del experimento, decía al sujeto que padecía una enfermedad del corazón) comenzaba a golpear la pared, pidiendo a gritos parar el experimento hasta que, por último, guardaba silencio. Algunas personas se detenían en los 135 volts, cuando el actor gritaba, y preguntaban sobre el propósito del experimento. Casi todas continuaban una vez que se les aseguraba que no se les haría responsables. Algunas reían nerviosamente al oír los gritos angustiosos salidos del cuarto contiguo. Cuando el sujeto quería hacer alto, el “científico” le decía: “Siga, por favor”. Y si el sujeto no lo hacía, aquél agregaba: “El experimento requiere que usted continúe”. En ausencia aún de una reacción, el científico añadía: “Es esencial que continúe”. La mayoría de los sujetos parecían estar bajo

RESUMEN La multitarea te embrutece. Hacer más de una cosa al mismo tiempo te vuelve más lento y peor en ambas. No lo hagas. Si crees que esto no se aplica a ti, te equivocas. Hacer a medias es no hacer. Un auto a medio hacer utiliza recursos que podrían usarse en crear valor o ahorrar dinero. Cualquier cosa “en proceso” cuesta dinero y energía sin rendir nada. Hazlo bien a la primera. Cuando cometas un error, corrígelo al instante. Deja lo demás y ocúpate de él. Corregirlo después puede consumir veinte veces más tiempo, o más, que si lo corriges ahora. Trabajar demasiado sólo complica las cosas. Trabajar mucho tiempo no permite hacer más, sino menos. Resulta en fatiga, lo que induce errores y esto te obligará a corregir lo que acabas de hacer. Más que trabajar hasta tarde o los fines de semana, hazlo entre semana a un ritmo sostenible. Y tómate unas vacaciones. No seas irracional. Las metas desafiantes motivan, las imposibles deprimen.

RESUMEN El mapa no es el terreno. No te enamores de tu plan. Casi seguro es erróneo. Planea sólo lo que necesitas. No intentes proyectar todo con años de anticipación. Planea apenas lo suficiente para mantener ocupados a tus equipos. ¿Qué tipo de perro es esto? No evalúes en términos absolutos, como horas; está demostrado que los seres humanos somos pésimos para eso. Evalúa las cosas relativamente: a qué raza de perro o tamaño de camiseta (CH, M, G, EG, EEG) corresponde el problema, o emplea la secuencia de Fibonacci, de uso más común. Consulta el oráculo. Usa una técnica ciega como el método de Delfos para evitar sesgos de condicionamiento como el efecto halo o tren, o el mero pensamiento grupal. Planea con póker. Usa el póker de planeación para evaluar rápidamente el trabajo por hacer. El trabajo es una historia. Piensa primero en quién recibirá valor de algo; luego, en qué es esto, y después en por qué lo necesita. Los humanos pensamos

Pero las cosas no siempre quedan perfectas al primer intento. Somos humanos; cometemos errores. La forma en que manejas esos errores puede tener gran efecto en lo rápido que haces las cosas y en su nivel de calidad. En Toyota, como ya dije, cualquier trabajador puede detener la línea de producción. La idea es mejorar continuamente el proceso y que el momento indicado para resolver un problema es justo cuando se le detecta, no después.

El responsable del producto no sólo necesita una gama de habilidades más amplia que el Scrum Master, sino que también debe apegarse a una serie de normas diferente. El Scrum Master y el equipo están a cargo de lo rápido que avanzan y de la mayor rapidez que pueden alcanzar. El responsable del producto lo está de traducir la productividad del equipo en valor. Al paso de los años, he reducido a cuatro las características esenciales de un responsable del producto: Uno: debe conocer el terreno. Por esto entiendo dos cosas: comprender el proceso que el equipo recorre para saber qué puede hacerse e, igualmente, qué no. Pero también conocer el qué para saber cómo traducir lo que puede hacerse en valor verdadero y significativo. Esto podría ser un sistema de cómputo que ayude al FBI a atrapar terroristas o un método de enseñanza para mejorar el aprovechamiento de los alumnos de escuelas públicas. El responsable del producto debe conocer bien el mercado para saber qué marcará una diferencia. Dos: debe tener autoridad para tomar decisiones. Así como la dirección no ha de interferir con el equipo, el

el responsable del producto debe disponer de margen para tomar decisiones sobre cuál será la visión del producto y qué debe hacerse para realizarla. Esto es importante porque el responsable del producto se halla bajo presión de muchos interesados, tanto internos como externos, y debe ser capaz de mantenerse firme. Debe estar a cargo de los resultados, pero se le ha de permitir tomar decisiones. Tres: debe estar a disposición del equipo para explicar qué se debe hacer y por qué. Aunque está a cargo en definitiva de los Pendientes, ha de mantener un diálogo constante con el equipo. A menudo la experiencia de este último determinará las decisiones que el responsable del producto ha de tomar. Este individuo debe ser confiable y congruente y estar a disposición del equipo. Sin acceso a él, el equipo no sabrá qué hacer o en qué orden llevarlo a cabo. Depende del responsable del producto respecto a “la visión” y, asimismo, la inteligencia del mercado sobre qué es importante. Si el responsable del producto no está a disposición del equipo, todo el proceso puede venirse abajo. Por ello rara vez recomiendo como ejecutores de esta función a directores generales u otros altos ejecutivos, quienes no cuentan con el tiempo

tiempo que el equipo necesita. Cuatro: el responsable del producto debe hacerse cargo del valor. En un contexto de negocios lo que importa son los ingresos. Yo mido a un responsable del producto por los ingresos que produce por “punto” de esfuerzo. Si el equipo produce cuarenta puntos de trabajo a la semana, debo medir cuántos ingresos crea cada punto. Pero la medición de valor podría ser cuántos éxitos tiene un equipo. Sé de un equipo de representantes de la ley que medía el valor por el número de arrestos de criminales buscados que hacía cada semana, y de iglesias que usan Scrum y miden su éxito por lo bien que sirven a su comunidad y si crecen o no. La clave es decidir cuál es la medida de valor y hacer que el responsable del producto asuma el deber de ofrecer cada vez más de él. En Scrum, este tipo de medida es fácil de observar a causa de la increíble transparencia del método. Todo esto es mucho pedir a una sola persona y por eso en proyectos grandes suele haber un equipo de responsables del producto que se ocupan de todas las necesidades. Abundaré en esto más adelante. Primero, para visualizar lo que el responsable del producto debe hacer, me gustaría que te imaginaras en la cabina de un F-86

Pendientes: qué hacer y cuándo Lo primero que debes hacer al poner en ejecución Scrum es elaborar una lista de Pendientes. Puede constar de cientos de elementos, o contener las pocas cosas que debes resolver primero. Por supuesto, necesitas una idea clara de qué quieres tener al final del trabajo. Podría ser un producto, una boda, un servicio, una nueva vacuna o una casa pintada. Podría ser cualquier cosa, pero una vez que tienes una visión, debes considerar qué implicará hacerla realidad.

La gente quiere ser feliz. No feliz de manera complaciente, pusilánime, sino activa. Thomas Jefferson, entre muchos otros, exaltó la felicidad que se deriva de la búsqueda. Buscar algo parece ser lo que nos hace felices. Bien practicado, Scrum hará felices a los trabajadores, los clientes, los gerentes y los accionistas (por lo general en ese orden).

habiéndose atrevido a lo grande, así que no habrá de contarse nunca entre los espíritus tímidos e indiferentes que no conocen la victoria ni la derrota.

RESUMEN Jala la palanca correcta. Cambia el desempeño de tu equipo. Este desempeño tiene mucho más influencia –en varios órdenes de magnitud– que el individual. Trascendencia. Los grandes equipos tienen un propósito mayor que el individual; por ejemplo, sepultar al general MacArthur, ganar el campeonato de la NBA. Autonomía. Concede a los equipos libertad para tomar decisiones sobre cómo actuar, para que se les respete como maestros en su oficio. La posibilidad de improvisar marcará toda la diferencia, sea que la unidad cubra una revolución en Medio Oriente o

Bueno, ¿qué harás mañana para implementar Scrum donde trabajas? El primer paso es reunir una lista de Pendientes y un equipo. Piensa en la visión que tienes de tu producto, servicio o lo que sea, y empieza a desglosar lo que debes hacer para realizarla. No necesitas mucho. Basta con Pendientes para una semana. Mientras los miembros del equipo celebran sus reuniones de parada diaria y ejecutan su primer sprint, podrás acumular Pendientes suficientes para mantenerlos ocupados en los dos sprints siguientes. Sin embargo, nunca pierdas de vista tus Pendientes, porque a medida que tu equipo se acelere, empezará a producir más de lo que creíste posible. Luego, como responsable del producto, elabora una guía de caminos que te permita ver adónde te diriges. ¿Cuánto crees poder terminar este trimestre? ¿Dónde quieres estar este año? Cabe recordar que esto es sólo una instantánea en el tiempo, así que no planees de más, sólo calcula. No estás haciendo un contrato de compromisos obligatorios; simplemente deja asentadas tus ideas acerca de dónde estarás en un tiempo. Créeme: el panorama cambiará. Tal vez radicalmente. La razón de planear así es crear transparencia en la organizaci

organización. Si tienes un equipo de ventas, debe saber en qué funciones estás trabajando para poder empezar a promoverlas. El liderazgo debe tener una idea sobre la fuente de ingresos, así como sobre cuándo y cuánto. El mensaje clave es que todo debe hacerse a descubierto. Cualquiera debe poder ver dónde está tu producto en cualquier momento. Debe poder ver avanzar a Terminado las historias en el pizarrón de Scrum. Debe poder ver puntos gráficos de historias contra el tiempo y una línea estable en dirección a cero, o nada, para saber cuántos puntos de historias hizo tu equipo en el más reciente sprint y cuántos calculas que hará en el siguiente. Has de saber que, como responsable del producto, se te evaluará con base en los ingresos y los costos. Descubrirás pronto, sobre todo si trabajas en un sitio con múltiples equipos, que tendrás que empezar a formar un equipo de responsables del producto para poder generar Pendientes suficientes para los equipos. Podrías tener un responsable del producto a cargo de la estrategia y la interacción con el cliente, y otro táctico, que decida qué harán los equipos en cada sprint. Lo importante, sin embargo, es empezar, así que comienza de una vez. Scrum está diseñado para que puedas

Un ejemplo excelente dado por estos autores es la presentación de un artículo para su publicación en una revista. Supongamos que un primer editor lo rechaza, tras de lo cual el autor lo propone a otra revista. Enterado del primer rechazo, es muy probable que el editor de esta última lo rechace también. Y si hay una tercera, su editor, al tanto de los dos rechazos anteriores, tiene aún más probabilidades de hacer lo propio. La gente parte del supuesto de que los demás emiten juicios razonables, aun si contradicen los suyos propios

propios. Esto no está bien. Cuando te formas una idea de cuándo entregarás un proyecto multimillonario –o si terminarás todo a tiempo para el día de tu boda–, es crucial que uses tu propio criterio y que emplees otras estimaciones para mejorar la tuya, no para remplazarla.

El responsable del producto En Scrum hay únicamente tres papeles. Eres parte del equipo y haces el trabajo, o eres el Scrum Master, ayudando al equipo a saber cómo hacer mejor el trabajo, o el responsable del producto. Este último decide qué hacer. Está a cargo de los Pendientes, su contenido y, sobre todo, el orden de éste.

Si la distancia entre dos números es de más de tres cartas, quienes tiraron los naipes respectivos explican sus razones, tras de lo cual se juega otra ronda de póker de planeación. De lo contrario, se promedian las estimaciones, lo que dará números aproximados a los que dieron los estadísticos en la Rand Corporation.

Escribe historias cortas Cuando escribas tus historias, sin embargo, no olvides que deben ser cortas y precisas para poder evaluarlas. Imagina

pensamos en forma de relatos, así que ofrece uno: “Como X, yo quiero Y, para que Z”. Conoce tu velocidad. Cada equipo debe saber con precisión cuánto trabajo puede hacer en cada sprint. Y tiene que saber cuánto puede aumentar esa velocidad trabajando con más inteligencia y eliminando barreras que lo retrasan. Velocidad x tiempo = entrega. Una vez que sabes lo rápido que avanzas, sabrás cuán pronto llegarás a la meta. Fija objetivos audaces. Con Scrum no es tan difícil duplicar la producción o reducir a la mitad el tiempo de entrega. Si lo consigues, tus ingresos y el precio de tus acciones también se duplicarán.

Por razones que presentaré en capítulos posteriores, llamé Scrum a ese marco para trabajar en equipo. Este término procede del rugby y se refiere al modo en que un equipo se desempeña en común para mover el balón por la cancha. Acoplamiento, unidad de propósito y claridad de metas van de la mano. Ésa es la metáfora perfecta para mi manera de entender el trabajo en común.

Scrum abraza la incertidumbre y la creatividad. Dota de estructura al proceso de aprendizaje, lo que permite a los equipos evaluar qué crearon e, igualmente importante, cómo lo hicieron. Scrum se vale del trabajo real en equipo y brinda a este último las herramientas necesarias para organizarse y aumentar en poco tiempo tanto la rapidez como la calidad de su trabajo. Scrum se basa en una idea simple: cada vez que se ejecuta un proyecto, ¿por qué no revisar con regularidad para ver si lo que se está haciendo sigue la dirección correcta y es lo que la gente quiere? ¿Por qué no revisar si se puede hacer mejor y más rápido y qué lo impide? Esto se llama ciclo de “inspección y ajuste”. Cada tanto, haz una pausa, revisa lo que hiciste y ve si debes seguir haciéndolo y cómo podrías hacerlo mejor. La

Uno de los conceptos clave de Scrum es que los equipos deben decidir cómo trabajar. Es

La dinámica de grupos sólo opera correctamente en equipos pequeños. La cifra clásica son siete integrantes, dos de más o de menos, aunque he visto funcionar de maravilla a grupos de apenas tres individuos. Lo asombroso es que los datos demuestran que

La planta alemana invertía más esfuerzo en resolver problemas recién creados que el que la japonesa dedicaba a producir un auto casi perfecto a la primera.8 Sí, leíste bien: los alemanes destinaban más tiempo a reparar un auto recién terminado que el que los japoneses

No a los actos heroicos. Si necesitas que un héroe haga las cosas, tienes un problema. El esfuerzo heroico debe entenderse como un error de planeación. Basta de políticas absurdas. Toda política que parece ridícula probablemente lo es. Los formularios, reuniones, aprobaciones y normas absurdos son sólo eso: absurdos. Si tu oficina parece una caricatura de Dilbert, ponle remedio. Fuera idiotas. No lo seas, ni permitas esa conducta. Quienquiera que cause caos emocional, inspire miedo o temor o degrade o subestime debe ser parado en seco. Busca el flujo. Opta por la manera más tersa y sin contratiempos de hacer las cosas. Scrum consiste en permitir el mayor flujo posible.

La clave, sin embargo, es lo que decides hacer primero. Las preguntas que debes hacer son: ¿cuáles son los elementos con mayor efecto de negocios, los más importantes para el cliente, los que pueden producir más dinero y los más fáciles de hacer? Debes percatarte de que hay muchos elementos en esa lista que nunca conseguirás, pero has de conseguir primero los que rinden más valor con menos riesgo. Dado el desarrollo y cumplimiento incremental de Scrum, comienza por las cosas que generarán ingresos inmediatos, librando de riesgos el proyecto. Y haz eso en el nivel de funciones. Empieza a ofrecer valor a tus clientes en cuanto sea posible. Necesitas algo que esté completamente Terminado, algo que puedas enseñar. Podría ser una pequeña parte del gran proyecto, pero debe estar demostrablemente Terminada. Si vas a pintar una casa, quizá lo Terminado en primera instancia sean todas las molduras de la sala. En el desarrollo de productos existe una regla empírica eficaz, confirmada una y otra vez. Ya me he referido a ella: ochenta por ciento del valor radica en veinte por ciento de las funciones. Piensa en esto un

Me inspiré a este respecto en el jefe de ingeniería de Toyota. En esta organización, un jefe de ingeniería es responsable de una línea de productos completa, como la de Corolla o Camry. Para ejercer esta función, quienes la asumen deben echar mano del talento de grupos especializados en ingeniería de carrocería, o chasís, o sistema eléctrico y demás. El

Así es. La gente no es feliz por ser exitosa, sino exitosa porque es feliz. La felicidad es una medida predictiva. Y el desempeño aumenta aun si la gente es sólo un poco más feliz. No es necesario cambiar radicalmente la vida de alguien para hacerla feliz, al menos por un tiempo. Aun un poco de felicidad produce resultados mucho mejores. La

Personas comunes que se limitan a cumplir su trabajo y carecen de toda hostilidad particular pueden volverse agentes de un terrible proceso destructivo. Además, aun si los efectos destructivos de su labor resultan patentemente claros y se les pide ejecutar acciones incompatibles con normas morales fundamentales, un número relativamente reducido de ellas tiene los recursos indispensables para resistirse a la autoridad.11

segundo ejemplo que me viene a la mente es algo distinto. Me recuerda lo sistemático que es para muchas personas buscar culpables de un problema antes que la solución. Tiene que ver con la forma en que operan los capitalistas de riesgo con los que trabajo cuando deciden invertir en una empresa. La primera vez que me asocié con OpenView Venture Partners me sorprendió que, a diferencia de muchas otras sociedades de inversión de riesgo, a ésta no le importara cómo la empresa elegida había gastado el dinero antes de invertir en ella. El pasado no importa. OpenView decide si invertir o no con base en la situación presente de una compañía; todo lo demás es irrelevante. Quiere saber cómo va a gastar ésta el dinero que ella le dará. No importa cómo haya gastado el dinero de otros. Lo único relevante es el futuro, las soluciones.

Supongamos que al tratar de integrar código de Matt en el sistema, los empleados de control de calidad detectaban un error. Renuente, como la mayoría de los desarrolladores, a corregir ese código de inmediato, Matt se comprometía a ocuparse de eso después. Primero escribía nuevo código. En casi todas las compañías pruebas como ésa no ocurren siquiera el mismo día. Pueden pasar semanas o meses antes de probar todo el código y sólo entonces se descubrirían los problemas. Pero Palm hacía pruebas automáticas diarias de todo su código, así que sabía de inmediato cuándo había un problema. Puesto que examinaba a todos sus “Matts” –cientos de desarrolladores–, la compañía decidió analizar cuánto implicaba remediar un error si se le corregía de inmediato o semanas después. Recuerda que el software puede ser demasiado complicado, así que ¿cuál crees que era la diferencia entre ambas prácticas? De veinticuatro veces. Si un error era atacado el mismo día en que se le cometió, corregirlo llevaba una hora; tres semanas después, veinticuatro. Así el error fuera grande o pequeño, simple o complejo, corregirlo suponía siempre veinticuatro veces más tiempo tres semanas después. Como

Se trataba de que hicieran algo que a veces nadie quiere hacer: enumerar el trabajo en orden de prioridad. La gente suele decir que todo es importante. Pero lo que Barton preguntó fue: “¿Qué es más valioso para el proyecto? Hagamos eso primero”.

RESUMEN Haz una lista. Revísala dos veces. Elabora una lista de todo lo que quizá deba hacerse en un proyecto y luego disponla en orden de prioridad. Coloca los puntos con mayor valor y menor riesgo al inicio de los Pendientes y luego los siguientes y los siguientes. Responsable del producto. Esta persona traduce la visión en Pendientes. Debe conocer la propuesta de negocios, el mercado y el cliente. Un líder no es un jefe. Un responsable del producto establece lo que se debe hacer y por qué. Cómo se realizará y quién está a cargo de ello lo decide el equipo.

que diecisiete líderes de desarrollo de software escribimos lo que hoy se conoce como el Agile Manifesto. En ese documento proclamamos estos valores: personas antes que procesos, productos que funcionen antes que documentar lo que se supone que deben hacer, colaborar

Pero como eres un hábil responsable del producto, priorizas lo que la gente desea: una alarma fácil de programar, volumen suficiente, un radio y una pantalla lo bastante vívida para poder verla ya sea que la habitación esté iluminada o a oscuras. Y cuando tu equipo termina eso, te percatas de que creó el reloj con alarma más elegante que haya habido nunca. Es el iPod de Apple de los relojes con alarma. Es bonito y hace una cosa muy, muy bien. Así que en vez de poner a tu equipo a incorporar funciones adicionales, lanzas ese reloj y te pones a trabajar en el proyecto siguiente. El equipo puede proporcionar más valor haciendo otra cosa.

Deduce qué puede ofrecer más valor con menos esfuerzo y haz eso de inmediato. Luego identifica el siguiente incremento de valor y después el siguiente. Antes de lo que crees, habrás creado u ofrecido algo con resultados reales y demostrables. La clave es disponer el trabajo por orden de prioridad. ¿Cómo hacerlo? Primero necesitas a alguien que sepa cuál es la visión y dónde radica el valor. En Scrum esa persona se llama “responsable del producto”.

RESUMEN Es el viaje, no el destino. La felicidad verdadera está en el proceso, no en el resultado. Solemos premiar sólo resultados, pero lo que realmente debemos honrar es a la gente que se esfuerza por ser grande. La felicidad es lo de hoy. Te ayuda a tomar decisiones más inteligentes. Además, cuando eres feliz también eres más creativo, menos propenso a dejar tu trabajo y más a cumplir más de lo que nunca previste. Cuantifica la felicidad. No basta sentirse bien; debes medir

medir esa sensación y compararla con tu desempeño. Otros indicadores ven atrás; la felicidad es una medida que mira al futuro. Mejora cada día y mídelo. Al final de cada sprint, el equipo debe tomar una pequeña mejora, o kaizen, que lo haga más feliz. Y esto debería ser lo más importante por cumplir en el sprint siguiente. El sigilo es veneno. Nada se debe mantener en secreto. Todos deben saberlo todo, y esto incluye sueldos e información financiera. La confusión sólo sirve a la gente que vela por su interés propio. Haz visible el trabajo. Ten un pizarrón que muestre todo el trabajo pendiente, lo que está en proceso y lo que ya se terminó. Todos deben verlo y actualizarlo cada día. La felicidad es autonomía, maestría y propósito. Todos queremos controlar nuestro destino, mejorar en lo que hacemos y perseguir un propósito que nos trascienda. Rompe la burbuja de la felicidad. No seas tan feliz como para dormirte en tus laureles. Asegúrate de medir la felicidad de acuerdo con el desempeño; si hay divergencias, preparate para actuar. La complacencia es enemiga del éxito.

If you can’t actually take time off without having to make sure everything is going right at the office, the thinking goes, you aren’t managing your teams well.

Suficientemente corta. Debe ser corta para poder calcularse y planearse fácilmente. Si es demasiado grande, reescríbela o divídela en historias más pequeñas. Totalmente comprobable. Debe poder pasar una prueba que confirme que ha sido completada. Escribe la prueba antes de ejecutar la historia.

La representación visual más elocuente de esta idea, la cual hallarás en toda sala de trabajo en equipo con Scrum en el planeta, es el pizarrón de Scrum.

La dinámica de grupos sólo opera correctamente en equipos pequeños. La cifra clásica son siete integrantes, dos de más o de menos, aunque he visto funcionar de maravilla a grupos de apenas tres individuos. Lo asombroso es que los datos demuestran que un equipo de más de nueve se vuelve torpe. En efecto: más recursos hacen más lento a un equipo.

Pero en lugar de abandonarlo, o de abandonar la forma en que se le concibió, los directivos contratan gente para que haga parecer que funciona. En esencia, pagan para que se les mienta.

That’s short for Observe, Orient, Decide, and Act. And while it may sound funny on the tongue, it’s deadly in war and in business. Getting inside someone’s loop reduces them to confusion and doubt. They overreact and underreact.

Para ser eficaz, esta reunión requiere cierto grado de madurez emocional y una atmósfera de confianza. La clave es que no se busca a quién culpar; se examina el proceso. ¿Por qué las cosas resultaron así? ¿Por qué no pudimos hacerlas de otra manera? ¿Qué pudimos hacer más rápido? Es crucial que, como equipo, la gente asuma la responsabilidad de su proceso y resultados y busque soluciones como equipo. También debe tener fortaleza para sacar a colación los asuntos que le molestan en una forma orientada a la solución, no acusatoria. Y el resto del equipo debe tener madurez para oír esos comentarios, aceptarlos y buscar una solución en vez de ponerse a la defensiva.

When you’re writing stories or making a list of work to be done, it’s important to ask two questions: Is the story ready? And how will you know when it’s done?

It was because they made a very basic mistake. They thought they could plan everything ahead of time. They spent months of effort making the sort of detailed plans that seem plausible—that are laid out on pretty charts and include carefully precise steps and almost always describe a fictional reality.

People don’t multitask because they’re good at it. They do it because they are more distracted. They have trouble inhibiting the impulse to do another activity

Suffice it to say here that the effect of eliminating waste is dramatic, but people often don’t do it, because it requires being honest with themselves and with others.

It’s better that a project manager not become the Scrum Master of his project. When a former project manager steps into that role, there’s a fair chance that everyone will fall back into their old patterns. The developers will expect him to solve all their problems, and he’ll feel obligated to do so.

The Scrum Master ensures that daily stand-ups are held at a fixed time every day for up to 15 minutes.

Scrum doesn’t have project managers. Instead, the team is empowered. They’re responsible for the outcome, and they can manage themselves. The classic project manager ‘boss’ of the team isn’t needed in Scrum. The team plans each Sprint based on the priorities of the Product Owner. They divide the work among themselves, make progress transparent and monitor themselves.

You aren’t going to fix problems in fifteen minutes—I don’t care how task-oriented you are.” “You’re right; that’s not what the stand-ups are for. They’re to point out problems—or what in Scrum we call ‘impediments’.

Man, what a day. Not the worst day of my life, but up there. Top five.

I was the leader of this team. They had faith in me. I had to let go of the worry. Let go of the fear. I could curl up and cry at home. Not here.