En el año 2005, acababa de terminar de trabajar en mi último equipo XP y estaba casi listo para empezar a trabajar para un gran contratista del departamento de defensa en San Diego (gran error!!). Tenía algo de tiempo libre entre puestos de trabajo y me di cuenta de que Ken Schwaber iba a estar a San Diego para enseñar uno de los primeros cursos certificados ScrumMaster, así que me inscribí. Una cosa es leer sobre Scrum en Internet (que es donde la mayoría de la información sobre Scrum se encontraba entonces) y otra cosa es escuchar Ken describir cómo funciona en persona.

Lo que más recuerdo de esa experiencia fue la urgencia de Ken en la necesidad de cambio en la industria del software. Una y otra vez, Ken hizo hincapié en que nuestro comportamiento como profesionales de software ha estado contribuyendo a la mayor parte de los retos que experimentamos en nuestra industria – entrega tardía, de mala calidad, compromisos rotos, baja moral, malas relaciones, rotación de personal, bajos márgenes de ganancia, falta de la innovación, etc., etc. Ken identificó dos factores como fuente de estos desafíos. Uno, la disposición de los profesionales de software para cortar la calidad ya que managment exige lo imposible, conocido como entregar una hamburguesa ardilla. Dos, preferimos decir mentiras y dar excusas, explicaciones y justificaciones de nuestros defectos que enfrentar la verdad – que algo muy malo en la construcción de software de alta calidad.

En la historia clásica de “MLB Tix”, Ken preguntó a la gente que jugaran un papel de rol en un escenario en el que un equipo de software sobre-promete al jefe de la Major League Baseball (MLB) un sitio de reventa de entradas en pleno funcionamiento antes del día de apertura de la próxima temporada de béisbol (recordemos que esto fue en 2005, por lo que la reventa de entradas no existía entonces). Por desgracia, el sitio no está listo en la jornada inaugural y se desata un infierno. Ahora, un representante del equipo de software (desafortunados participantes CSM) tiene que explicar al comisionado de béisbol (Ken) lo que estaba pasando.

Grupo tras grupo les dieron a Ken excusas, justificaciones o promesas de una solución rápida y cada uno fue enviado de vuelta a sus mesas por un enojado Ken Schwaber. Después de seis fallidos esfuerzos, una persona de la audiencia finalmente acaba preguntando: “OK, entonces ¿qué haría usted en esta situación?” La respuesta de Ken, “Yo le diría al comisionado de béisbol la verdad. La hemos fastidiado y lo sentimos. Queremos hacer esto bien, por lo que vamos a trabajar con usted hasta que encontremos una solución “Esta respuesta ha quedado conmigo desde hace diez años, debido a su simplicidad. – Simplemente sea honesto y comprométase a trabajar con el cliente para arreglar las cosas. Eso es lo que cualquier cliente quiere oír.

Aquí están los grandes cambios reales que he visto con Scrum, ya a partir de 2005.

1. El trabajo está “hecho” o “no hecho”: en la literatura de Scrum del pasado se hacía un énfasis en las horas que quedan restante en una característica específica (punto Product Backlog) o una tarea de ingeniería (punto Sprint Backlog). Conocer el tiempo restante no es intrínsecamente malo, pero con la mentalidad equivocada esto a menudo conduce a la microgestión y a la conformidad con las estimaciones. Lo que ayuda a la gente a hacer esta transición es limitar el tamaño de los elementos del Sprint Backlog a no más de uno o dos días. Si un artículo Sprint Backlog es más grande que eso, tiene que ser roto en pedazos más pequeños.
2. La adición de la Junta de tareas: todos los equipos de Scrum tienen algún tipo de control visual para ayudarles a gestionar su trabajo. Por extraño que parezca, la tabla de tareas no es una práctica identificada en el marco de Scrum. Tobias Mayer llama a la tabla de tareas el “Corazón de Scrum” y escribió un breve ensayo sobre este tema en su libro, The People’s Scrum: Agile Ideas for Revolutionary Transformation. Los equipos de Scrum muy, muy exitosos, han acabado con todas esas tonterías que rodean a las tablas de tareas electrónicas para utilizar simples notas post-it en una pared.
3. El final de cerdos y pollos: si alguien no está familiarizado con esta fábula, está muy bien ilustrada por Mike Vizdos. Jeff Sutherland ofrece un buen comentario sobre cómo y por qué se creó la metáfora original de cerdos y pollos. A partir de 2011, la metáfora ya no es oficialmente parte del canon de Scrum. Gracias a Dios esta historia se está desvaneciendo en el pasado!
4. Scrum de Scrums: cuando Scrum comenzó a cobrar impulso, equipos y organizaciones comenzaron a utilizar Scrum para esfuerzos más y más grandes, con más y más equipos de Scrum. Como era de esperar, la coordinación entre los equipos de Scrum se convirtió en un problema, por lo que el concepto de Scrum de Scrums fue introducido. Scrum de Scrum tuvo SIEMPRE la intención de ser una reunión de personas técnicas que responden como un equipo virtual para resolver los problemas, pero de alguna manera en el camino, Scrum de Scrums se transformó en una reunión de estatus entre ScrumMasters. Mediante unos escrito recientes, Jeff Sutherland ha sugerido que el Scrum de Scrums es un equipo multifuncional que tiene la responsabilidad de hacer que el incremento del producto sea potencialmente entregado en cada Sprint.

Artículos 10 años de Scrum

Los mejores 10 artículos de scrum que no leyó: Lo mejor de lo mejor.

Solo sea honesto: Mis primeros 10 años de Scrum

¿Eso pasó en 2005? Retrospectiva de los grandes momentos del 2005.