Work

La Definición de «Ready» es tan importante como la Definición de «Done»

/ Johnny Ordóñez / 2 comentarios

Ready

Usted no puede empujar a nadie a subir la escalera a menos que esté listo para subir por él mismo. – Andrew Carnegie

Uno de los conceptos más importantes y conocidos en el desarrollo de software ágil -utilizando varios sabores como Scrum y Kanban- es la Definición de «Hecho» (o Definition of Done, o DoD). La definición de Done es un acuerdo del equipo, y en muchas ocasiones de la organización. Mediante el criterio de Done se puede conocer cuando una Historia de Usuario se encuentra «Hecha» para ser presentada al Producto Owner o Stakeholders. Brinda una guía al equipo sobre las condiciones necesarias que debe cumplir una historia para ser decentemente terminada presentada durante o al final de la iteración. Es una herramienta que brinda transparencia y permite un entendimiento común de lo que significa “Hecho”.

Ya en la práctica, consiste en una especie de checklist que reúne los criterios acordados por el equipo al que se somete cada historia antes de ser colocada en la preciada columna de Done en el Taskboard. En muchos tableros he visto también la columna “Done Done!” o “Accepted” dando así dos niveles de aprobación de la historia de usuario, Done significa que cumple todos los criterios establecidos por el equipo que normalmente incluyen: el código en el repositorio, todas pruebas unitarias y de aceptación en verde, documentación si fuera necesario, integración en el ambiente de pruebas, revisión por el tester en el ambiente de pruebas, etc.; y «Done Done» o «Accepted» cuando ha sido revisada y “firmada” por el Product Owner.

Varios agilistas sugieren  lo mínimo que debe contener la definición de Done, y les dejo algunos artículos para su revisión un poco más abajo; sin embargo, quiero con este post hablar de otra definición quizás no tan conocida pero desde mi punto de vista bastante útil; la «Definición de Listo».

La Definición de «Ready» o DoR

Análoga a la Definición de «Hecho», la definición de «Listo» es un acuerdo entre del equipo, especialmente entre el Product Owner y el equipo de Desarrollo donde se colocan los criterios por las cuales una historia se encuentra lista para ser implementada dentro de un sprint. Básicamente, es un conjunto de condiciones -y un checklist también- a la cual se somete una historia para ser tomada en un Sprint Planning.

¿Por qué es importante?

Varias razones. Desde la práctica, una historia de usuario no está lista a la primera. El product Backlog es orgánico y necesita un tiempo de maduración. Significa que mientras el equipo de desarrollo está trabajando en las historias comprometidas en el Sprint Planning anterior,  el Product Owner está trabajando en refinar su backlog y poner a punto las historias para la siguiente y subsiguiente iteración (pienso que un buen PO prepara historias para un par de sprints adelante). Esto es, comprender el objetivo y el alcance funcional con los usuarios, expertos del dominio, UX designers, Product Managers; priorizar la historias usando técnicas apropiadas, descomponiendo historias en un tamaño apropiado para el equipo, estableciendo criterios de aceptación, identificando dependencias entre los items de su backlog y otros backlogs, colaborando con otros POs, entendiendo y revisando desafíos de arquitectura o técnicos con el arquitecto o Líder Técnico y trabajando junto con el equipo en el grooming del backlog, revisando y priorizando Bugs cuando aparecen. Así es, mucho trabajo para nuestro PO.

Bob Galen habla mucho del «Readiness Criteria» en varios artículos y en su libro Agile Reflections y sugiere una lista de Ready como la siguiente (a estos puntos les daré mi modificación desde mi criterio en paréntesis, pero la lista original la colocaré en las referencias):

  • Historias bien definidas y con al menos 5 criterios de aceptación (este valor es heurístico, igual se puede establecer un número máximo de criterios de aceptación);
  • Historias de un Tamaño apropiado, que entre dentro de un sprint (un tamaño adecuado con que el equipo se sienta cómodo y mejore su throughput, un buen tamaño que permita un mejor entendimiento, mejores criterios de aceptación, más fácil de probar, más fácil revisar, mejora la moral del equipo);
  • Que el equipo haya revisado las historias en una sesión de Grooming, donde se haya comprendido la naturaleza, el valor y desafíos técnicos;
  • De ser necesario, que la historia haya tenido un spike para explorar las implicaciones de diseño, arquitectónicas o tecnológicas (cuando el equipo no tiene mucha incertidumbre sobre lo que implica técnicamente la historia, es apropiado un spike; luego de eso la historia se puede revisar nuevamente, estimar y pasar a la columna de Ready);
  • Que la historia sea transversal, es decir que describa un comportamiento end-to-end (que sea “visible” para le negocio);
  • Que el equipo comprenda el enfoque para las pruebas tomando en cuenta aspectos funcionales y no funcionales;
  • Que se haya identificado dependencias con otras historias dentro del mismo backlog u otros backlogs a los que una historia pueda estar conectada;
  • Que la historia se alinee (y esté “enganchada”) a un objetivo u objetivos del sprint, que sean claramente visibles y demostrables.

Esta definición es bastante útil cuando tenemos a un PO que está desarrollando sus skills y su «olfato» para gestionar el trabajo para un equipo ágil. Ahora estoy trabajando con unos 29 equipos y un equipo de 14 POs; y acabamos de introducir esta práctica para lograr que las historias lleguen lo mejor trabajadas a los equipos; y estoy viendo varios beneficios de su aplicación (que espero que se sigan expandiendo):

  • Sprint plannings más rápidos;
  • Involucramiento y conocimiento temprano del equipo sobre los desafíos del siguiente sprint;
  • Gestión colaborativa del backlog;
  • Feedback temprano;
  • Levantamiento temprano de riesgos y necesidades (si se necesita del apoyo de un arquitecto, el SM ya lo puede buscar y planificar para el siguiente sprint);
  • Mayor conciencia del equipo sobre los objetivos de negocio y el alcance;
  • Ayuda al PO a comprender la visión sobre aspectos técnicos que le indica el equipo, y a sensar con qué tamaño de historias se sienten cómodos;
  • Historias mejor trabajadas en las cuales el equipo se siente parte y por ende mejora el compromiso.

Pensamientos finales

Pienso que el uso definiciones DoD y DoR claras y difundidas son herramientas muy útiles para la colaboración , claridad y “fluidez” de los equipos. Haga que el mismo equipo sea quienes revisen y definan estas definiciones, pero si están trabajando con varios equipos colaborando para construir juntos un “big working software” estas definiciones deben ser coherentes a través de todos lo grupos. Se puede crear comités y reuniones de trabajo para afinarlas. Igualmente, están sujetas a revisión y modificación tras cada iteración.

Coloque una columna “In Analysis” o “En Revisión” (o cualquier nombre, sea creativo) donde colocará aquellas historias sobre las que debe trabajar y refinar. Cuando estén listas y se cumpla con la DoR, agréguelas a la columna “Ready” o “Backlog” que son aquellas que se explicarán en el siguiente sprint planning.

Trabajar bajo estas definiciones brindará claridad y fluidez al trabajo de los equipos y aportarán a su crecimiento y madurez. Una vez lo que hagan, por favor compártanme sus experiencias.

Gracias, y que la agilidad esté con Ustedes.

Johnny

Referencias

http://guide.agilealliance.org/guide/definition-of-done.html

http://www.solutionsiq.com/what-is-the-definition-of-done-dod-in-agile/

https://www.scrum.org/Resources/Scrum-Glossary/Definition-of-Done

https://www.scrumalliance.org/community/articles/2008/september/definition-of-done-a-reference

http://www.allaboutagile.com/definition-of-done-10-point-checklist/

https://agilefaq.wordpress.com/2012/12/02/what-is-definition-of-ready/

http://www.batimes.com/robert-galen/user-stories-ready-set-go.html

James Cameron sabe de Agile

/ Johnny Ordóñez / Deja un comentario

IMG_5590

Son las 9:15 am y siento el batuquear del avión que me lleva a Medellín para asistir a una nueva edición del evento más grande de Agilismo en Latinoamérica, Ágiles 2014. Mientras el avión se estabiliza, normalmente comienzo a ojear las revistas de las aerolíneas hasta que pueda sacar mi libro o la laptop (me mareo con facilidad). Con un bostezo, comienzo a revisar las páginas de publicidad que no se terminaban, hasta que llegué a la sección de lecturas interesantes; entre aquellas, un titular que me llamó la atención: “James Cameron: Visionario en Ciencia y Entretenimiento”.

Siento un gran apego por James Cameron, no sólo porque me gustan sus películas, pienso que es un gran Director (sentí que le robaron el Oscar hace un par de años), también porque considero que ha aportado a la industria cinematográfica con su trabajo y además porque uso el ejemplo de la película Titanic en mis presentaciones para ilustrar la diferencia entre el éxito de un producto frente al éxito de un proyecto (comparándolo con el Maglev Chino, un fantástico ejemplo que me enseñó mi amigo Heitor Roriz); siempre es útil.

Comencé a leer sobre la entrevista que le hicieron a James acerca del nuevo documental que está dirigiendo y produciendo: James Cameron’s DeepSea Challenge 3D; sobre los desafíos de construir una máquina que pueda sumergirse más, de la tecnología y de su equipo; y de a poco me fui topando con frases que enseguida despertaron mi “sentido ágil” (algo así como el “sentido arácnido”); la primera:

“La única manera de construir este vehículo, dentro de un tiempo y presupuesto razonable, era hacerlo con un equipo pequeño de personas dedicadas y multifuncionales.”

Dije entre mí: “Suena como un equipo Scrum. Chévere!”. Continuaba la lectura y apareció una joya que enseguida me dibujó una sonrisa:

“El método que utilicé se llamó: Total Transparencia Radical. Todos los que estaban trabajando en el vehículo tenían que sentarse alrededor de una mesa, cada mañana a las 8h15 –no 8h14 ni 8h16– y ahí aireábamos nuestros problemas. Las conversaciones sobre lo que iba mal en el proyecto debían ser públicas. Tú llevabas tus problemas al grupo y nosotros, como grupo, los resolvíamos.”

IMG_5597

Pensé: “Hey!, estos son valores y prácticas de agilismo.”. Y no podía parar de leer:

“La gente pensaba que estaba loco, pero después de unas dos semanas, empezamos a trabajar realmente como equipo. Ellos empezaron a entender que uno no oculta sus problemas, uno los comparte con el grupo.”

“Dos semanas…un Sprint!?; mucha coincidencia!”. Luego el periodista pregunta:

“¿Qué nueva tecnología estás utilizando en las tres secuelas que estás haciendo de Avatar las cuales se presentarán a partir del 2016?”

Y James responde:

“Unos dos meses después de haber terminado Avatar, volvimos a reunirnos para hacer un gran análisis postpartido. Le pedí a cada departamento que elaborara un libro sobre lo que hicimos bien, lo que hicimos mal y lo que podríamos hacer mejor la próxima vez. Y de ahí surgieron las directrices para el desarrollo de un nuevo software y las mejoras del sistema.”

“Una retrospectiva post-mórtem!.”  dije.

 

Agile no es «sólo» desarrollo de Software

Okay, analicemos esto. Tenemos valores, principios y prácticas aquí:

  • Disciplina
  • Transparencia Radical
  • Reuniones Diarias
  • Equipos pequeños multidisciplinarios
  • Retrospectivas
  • Visión
  • Liderazgo

Son elementos esenciales para realizar cualquier trabajo de forma colaborativa. Una de las percepciones más comunes que se dan cuando se habla o se lee sobre Agile es pensar que es exclusivamente para el desarrollo de software. Nunca me cansaré de decir o escribir esto: comprendamos qué es Agile y qué significa:

Agile es un mindset basado en valores, guidado por principios y expresado en prácticas.

En mi experiencia, he visto e incorporado principios y prácticas de agilismo más allá del software: Marketing, Ventas, Tesis de Maestrías, en la casa. Agile es algo que trasciende; son simplemente elementos necesarios para realizar un trabajo de forma colaborativa y bien hecha.

Sin duda, la fuerza Agile es fuerte en James; podría sin duda ser un gran Agile Coach; y esto hace que tenga ganas de ver el documental.

IMG_5594

Reportando desde el aeropuerto El Dorado de Bogotá, haciendo escala hasta Medellín.

Un abrazo!

El valor de la disciplina en entornos ágiles

/ Johnny Ordóñez / 1 comentario

HuHN5gg

“Es importante la constancia, el compromiso, la colaboración y la interacción entre individuos pues es lo que genera la máxima productividad.”

– Norberto Gaona 

Algo que siempre decimos y percibimos los agilistas es ”que los equipos ágiles son muy disciplinados”. Disciplina, acuerdos y compromiso son -desde mi punto de vista- pilares para la ejecución y adopción ágil (y de cualquier trabajo, sea ágil o no).  Son clave para que el proceso ágil fluya, mejore y se entregue el valor en un ritmo constante en periodos cortos. Las prácticas ágiles fueron diseñadas a propósito para elevar el sentido de disciplina; por esta razón los timeboxes son fijos (pase lo que pase), los sprint plannings se basan en compromisos, las reuniones son llamadas ceremonias, el código se sube todos los días, la definición de Done y los criterios de aceptación se cumplen, si hay que hacer documentación, se hace; y se respetan los acuerdos organizacionales y del equipo. Cuando un equipo ágil es disciplinado, incluso el trabajo remoto se lleva mejor.

1406804729923_Image_galleryImage_Jamaica_s_Usain_Bolt_prac

“Agilidad requiere una dosis extra de disciplina, porque cada miembro del equipo es indispensable. El valor, el peso y la responsabilidad de cada uno es por lo tanto mayor.”

– Giancarlo Girardi

En mi experiencia, la moral del equipo se incrementa al ver software funcionando creado en un sprint luego de haber trabajado en una jornada dura, pero donde se demostró disciplina, ahínco, profesionalismo y compañerismo. Los equipos ágiles tienden a convertirse en equipos de alto desempeño, los miembros de un equipo son como atletas; para llegar a ser un gran atleta y competir en alto nivel, existe mucha disciplina en los entrenamientos, en su plan de nutrición, en su disciplina mental y física. Skills, Disciplina, Entrenamiento. Es lo mismo para los equipos ágiles.

131dcd4f-dcf9-4968-8107-772a4929e0f7

 “Disciplina para hacer lo que sabes que es correcto e importante, aunque difícil, es el camino real para el orgullo, la autoestima y la satisfacción personal.”

– Margaret Thatcher

article-2187195-1480BB74000005DC-77_634x425

Todos somos llamados a fomentar la disciplina a través de nuestro trabajo del día a día. Disciplina no es miedo, disciplina no es micromanagement, disciplina no es autoritarismo. Disciplina es un valor que expresa diariamente; es el puente entre las metas y los logros. El Agilismo está lejos de la anarquía de las que temen muchos managers, sobretodo en organizaciones grandes. Disciplina es un valor requerido en el Agilismo. A practicarlo!

(Buscando imágenes para este post me encontré con estas fotos sobre la Belleza de la Disciplina en el entrenamiento de monjes Shaolín; me encantó).

eFSyPr0

 

Referencias

http://www.futuresourcesummit.com/noticias/no-caer-en-la-indisciplina-clave-para-el-desarrollo-agil/
http://development-geek.blogspot.com/2011/11/scrum-agile-malos-habitos-iii-agilidad.html
http://www.thefirstmanscrapbook.com/%E5%B0%91%E6%9E%97-the-beauty-of-discipline-shaolin-monk-training/

Acerca del compromiso y el trabajo

/ Johnny Ordóñez / Deja un comentario

Cuando una empresa pretende mejorar, debe centrar su atención en lo más importante, en su corazón…las personas que la forman. El primer paso: valorar a las personas con las que cuenta. Pero la valoración no es simplemente la evaluación de los talentos y habilidades que una persona pueda tener. Al ser persona, un trabajador de una compañía está rodeado de factores humanos que le son inherentes y muy importantes: la familia, su carrera, sus expectativas, sus valores. Comprender a la persona y sus necesidades más allá del aspecto laboral es deber de toda empresa que entiende que el crecimiento está ligado fuertemente al crecimiento y bienestar de aquellos que la conforman.

Con esto en mente, una empresa no sólo contará con personas capaces para emprender cualquier desafío que le imponga el mercado; contará con personas que sienten que no son un empleado más, sino que la empresa es también de ellos y que cada acción que realizan está orientada a sacar adelante un ideal que es de uno y de todos al mismo tiempo. Desafíos y retos que se asumen auténticamente porque no sólo es un lugar de trabajo, es su empresa y la siente como suya, dispuesto a dar cada gota de esfuerzo.

Cuando una empresa logra hacer esto, no cuenta con empleados, cuenta con amigos, con miembros de la misma familia, con guerreros…con personas verdaderamente comprometidas. El compromiso no se exige de la empresa al trabajador como parte del contrato laboral. Es un despertar auténtico dentro una persona frente a un ideal correcto, establecido por la cultura empresarial.

Pensadores y Hacedores: Pensando en la Altitud

/ Johnny Ordóñez / Deja un comentario

Hace pocos días leí un gran artículo denominado Pensadores y Hacedores redactado por Francisco Sáez (@franciscojsaez), fundador y CEO de FacileThings. Francisco comenta acerca de la disposición de las personas en dos grupos: los «thinkers» y los «doers» y resalta las características de cada uno. Siendo ambos importantes para una organización, Francisco sugiere la búsqueda de un equilibrio en el cual se rescaten las cualidades de cada personalidad con el fin de lograr un objetivo.

Yo me sentí realmente identificado, ya que en ese preciso día había tenido feedback por parte los miembros de mi equipo con respecto a que sólo pasaba pensando y no haciendo. Esto no quiere decir que para hacer algo no haya que pensar, sino más bien, que me pasaba soñando mucho y pensando en estrategias en lugar de ayudar a cristalizarlas. Al sentirme así, mi comentario fue el siguiente:

Mi_comentario

Al día siguiente Gorky Estrella también comentó al respecto:

Comentario_de_gorky

Gorky es un gran compañero y amigo, y junto a Mercy formamos este pequeño equipo lleno de ilusiones y ganas por hacer cosas geniales. Entenderán entonces su comentario, estaba enojado conmigo.

Reflexionando sobre el tema pensaba que el problema de los thinkers es que pasan (o en este caso pasamos) mucho tiempo en las nubes. En cambio, el problema de los hacedores es que se concentran tanto en el cómo hacerlo que se sumergen mucho en los detalles. Esto puede ser expresado con una cuestión de Altitud. Qué significa??.

Al pensar en nubes y en inmersión recordé un slide de una presentación de Jeff Patton (@jeffpatton) con la que ilustra que una definición de tarea de usuario o construcción de UX es sensible a la altitud en la que nos encontramos al momento de diseñarla.

Niveles

Adentrándome un poco al desarrollo de SW, si el nivel de altitud es demasiado alto nos arriesgamos a un Big Design Up Front, en donde comencemos a pensar y a diseñar cientos de cosas, una arquitectura súper completa adaptable a todos los escenarios imaginables y que permita satisfacer todas las necesidades del usuario incluso las que todavía no tiene. Por otro lado, si el nivel es demasiado bajo, estaremos tan pendientes de los detalles de implementación: el objeto, la clase, el algoritmo, etc., que perderemos fácilmente la visión del para qué estamos construyendo esta funcionalidad o qué necesidad del usuario satisface. Tal como concluye Jeff Patton, es necesario que exista un balance, es decir; encontrar un punto medio que permita abstraer de forma más real e idónea una necesidad de negocio o el mismo UX.

Jeff_patton

Es evidente que en este punto medio se encontrarán las habilidades y fortalezas de Thinkers y Doers, trabajando juntos para alcanzar la meta: hacer brillar a nuestro cliente de felicidad. Esto no quiere decir que se deba permanecer siempre a nivel del mar. Seguramente nos adentraremos en los detalles y resolver el cómo realizarlo. De igual forma, es necesario subir y abstraer e imaginar nuevos escenarios y oportunidades. Ubicarnos entre el nivel de la cometa y el nivel del mar es el punto de partida que nos permitirá enfocarnos hacia una apreciación adecuada y hacia un trabajo dirigido hacia el usuario.

Thinkers y Doers: mismo equipo, misma meta!.

PD: Estimado Gorky, por favor tenme paciencia 🙂