Scrum fomenta la comunicación y colaboración

Parte del espíritu de Scrum es la colaboración entre los miembros que asumen cada rol de la implementación. Así que es lógico que esto se cumpla. Pero además de esa «teoría» que nos dice Scrum es colaborativo, está bien compartir experiencias que dan valor de verdad a estas definiciones.

Trabajo colaborativo
Trabajo colaborativo

Como comenté en una entrada anterior estoy trabajando en un nuevo equipo. El pasado lunes hubo una reunión general de todos los integrantes, donde pasamos a explicar varios temas y cambios en la forma de trabajar. Scrum implica un cambio tanto en la estructura y metodologías de trabajo, como en la forma de encarar el trabajo por parte de cada individuo.

En esta reunión, comentamos sobre algunas herramientas que usamos y vamos a integrar en nuestra metodología de trabajo: Subversion, Trac y Scrum. Subversion (además de ser mi sistema de control de versiones preferido) es el servidor que se viene usando para mantener los fuentes versionados. Trac es un sistema de gestión de tickets (bugs, arreglos, etc.) y un gestor de proyectos con integración con Subversion. Y Scrum, va a ser el framework que englobe todo el trabajo.

Comprobamos que el simple hecho de reunir a la gente, hacerla participar y contar apenas unos conceptos clave de la nueva forma de trabajo (roles, horizontalidad, participación, auto organización, etc) logró cambios en la interacción del equipo. En estos pocos días que han pasado desde el lunes, la comunicación entre todos los miembros del equipo ha sido mucho más fluída. Se escuchan conversaciones del proyecto entre varios miembros, todos participan. Y la colaboración ha sido un punto fuerte también. Hay más personas del equipo trabajando en equipo, pidiendo ayuda y ayudando.

Basado en esta experiencia, puedo afirmar con total seguridad:
Scrum fomenta la comunicación y colaboración de forma orgánica. Esto sin siquiera haber comenzado formalmente la implementación, sin task board, ni daily meetings. Solo un planning improvisado, y una introducción a algunos conceptos en una nueva forma de trabajo.

Sprint Planning – Planificación de Sprint

Acá les dejo un material que repartimos al equipo antes de la primer reunión de planificación de Sprint. El lunes comienza la reimplementación de Scrum. Es para tener una idea general del Sprint Planning, basado en apuntes e ideas obtenidas a lo largo de este tiempo:

Para cumplir con el criterio de Timeboxing, debe definirse una duración inicial para la reunión de planificación. Es importante que se cumpla con esta duración, y la reunión no profundice en temas que no son importantes al momento. El objetivo de esta reunión es obtener la planificación del Sprint.

Duración del Sprint

Mínimo 1 semana, máximo 1 mes.
Esto puede variar a medida que el equipo se adapte a Scrum, o de acuerdo a las entregas que quieran realizarse del producto.

Product Owner

Debe filtrar todos los intereses de jefes, directores, gerentes, de distintas áreas y con distintos intereses hacia el equipo. Para evitar el ruido, el Product Owner es el único que transmite las necesidades del producto al equipo, basado en el retorno de inversión.

Tiene que tener preparado para la reunión el backlog del producto: la lista de funcionalidades que hay que implementar. Durante la primera parte de la reunión, el P.O. explica el backlog.

El equipo

Una vez armado el backlog, el equipo debe seleccionar las funcionalidades con las que se va a comprometer a terminar en el Sprint. El objetivo es tener un producto potencialmente entregable al final del Sprint, y que la funcionalidad sea demostrable. Debe analizar y estimar qué se puede hacer, y despejar dudas sobre funcionalidad con el P.O..

Definiendo el Sprint

El Product Owner y el equipo deben definir juntos el trabajo a realizar en el Sprint. El P.O. es el responsable de elegir la prioridad, y el equipo de elegir cuánto trabajo va a poder terminar en esta etapa. De esta forma, se define el objetivo de cada Sprint. Su éxito será determinado al final del Sprint en una reunión de review. De esta manera, se arma un backlog para el Sprint.

Estimando el Sprint

Una vez definido el backlog del Sprint, cada tarea debe ser estimada, y dividida en partes que puedan ser medidas idealmente en 1 día o menos de trabajo. Cuanto más pequeño sea el alcance de cada tarea, más fácil de estimar.

Reimplementando Scrum

Duke Trabajando
Duke Trabajando

Hace ya 2 meses que cambié de trabajo.

Hasta ahora los posts relacionados a la implementación de Scrum en este blog habían sido siempre en la misma empresa. El cambio de trabajo debe ser uno de los momentos en que queda más evidente la utilidad de haber hecho este blog plasmando mis experiencias con Scrum.

Si bien no escribí tanto como me hubiera gustado desde mayo cuando empecé el blog, hay muchas cosas útiles que vi en su momento, que aprendí, que apliqué, que me pueden servir hoy en el nuevo trabajo. Links, recursos, artículos y demás. Si bien no ha sido tanto como esperaba, algo se ha ido guardando.

En este nuevo trabajo estamos por empezar una nueva implementación de Scrum. Por lo tanto, a partir de ahora, reimplemento Scrum.

Una de las ventajas es que trabajo con otro Scrum Master certificado. Ya han habido ideas de Scrum y agilidad en la empresa, pero aparentemente no se ha llegado a hacer una implementación completa.

Prometo en esta nueva instancia de implementación de Scrum, comentar más experiencias en el blog.

La esencia de Scrum – Tobias Mayer

Esta es una definición muy buena de lo que hace a la esencia de Scrum. Está escrita por Tobias Mayer y traducida al español por Angel «Java» Lopez:

Scrum comenzó su vida como uno de las nuevas formas Agiles para construir software. En estos días, se lo considera una forma que puede ser usada para mejorar el mundo del trabajo, en un sentido más general, y así, cambiar la forma en que los individuos piensan e interactúan con otros en situaciones de trabajo. El potencial completo de Scrum está por explorar.

En resumen, Scrum es una manera simple de manejar problemas complejos, proveyendo un marco de trabajo para soportar la innovación y permitir que equipos auto-organizados entreguen resultados de alta calidad en tiempos cortos. Scrum es un estado de la mente; en una manera de pensar que libera el espíritu creativo mientras se mantiene firmemente apoyado en principio sólidos y largamente respetados, incluyendo el empirismo, la emergencia y la auto-organización.

Empirismo se refiere al proceso continuo de inspeccionar/adaptar que permite que tanto trabajadores como gerentes tomen decisiones en tiempo real, basado en datos actuales, y como resultado, puedan responder rápidamente a  condiciones siempre cambiantes que se presentan en el ambiente, como por ejemplo, el mercado donde el software a construir es vendido o distribuido.

La Emergencia surge de una aproximación empírica. Implica que todas las soluciones a todos los problemas se volverán claros a medida que trabajamos. No se volverán claros si simplemente hablamos de ellos. El “Big Up Front Design” (gran diseño de antemano) sólo producirá un “Big Wrong Design” (gran diseño erróneo) o a lo sumo un “Big Working But Totally Inflexible Design” (gran diseño que funciona pero totalmente inflexible). Cuando permitimos que las soluciones emerjan es siempre la solución más simple y apropiada, para el contexto actual, la que sube a la superficie. La emergencia junto con el empirismos nos guiaran a la solución más apropiada y flexible (es decir, que podemos cambiar).

Auto-organización se refiere a la estructura de los equipos que crean el producto. Se les da poder a pequeños equipos multidisciplinarios para que puedan tomar decisiones importantes, necesarias para 1) crear un producto de alta calidad, y 2) manejar su propio proceso. Acá la idea es que aquellos que hacen el trabajo conocen mejor que nadie cómo hacer el trabajo. Estos equipos trabajan de una manera altamente interactiva y generativa, donde el producto emerge del diálogo continuo, de la exploración e iteración. La auto-organización funciona cuando hay objetivos y límites claros.

Además de estos principios, Scrum se apoya en dos mecanismos principales: priorización y “timeboxing” (poner límites de tiempo a una tarea).

Priorización simplemente significa que hay cosas que son más importantes que otras. Esto es tan obvio que se olvida muchas veces cuando pensamos “necesitamos esto AHORA”. Scrum nos ayuda a poner el foco de vuelta en seleccionar cuáles son las cosas más importantes a hacer primero, y entonces, a hacerlas! Tomándose el tiempo para priorizar, y siendo rigurosos sobre eso, es esencial para el éxito de Scrum.

Timeboxing es un mecanismo simple para manejar la complejidad. No podemos imaginar el slistema completo de una vez, todo junto, entonces, tomamos un pequeño problema y en un corto espacio de tiempo, digamos una semana o un mes, trabajamos en solucionar ese problema. Los resultados de esa acción nos guiaran entonces a una solución para el próximo problema, más grande, y nos dará más conocimiento sobre las necesidades del sistema en conjunto.

Cambio organizacional

Con Scrum, las jerarquías de gerencia de las organizaciones tienden a ser niveladas y los equipos de desarrollo tienen más contacto directo e inmediato con los clientes. El ambiente de trabajo se vuelve menos “comandar-y-controlar” hacia un estilo más colaborativo. Se promueve el diálogo regular y abierto sobre la documentación extensiva, y el acuerdo negociado es preferido a los contratos de trabajo formales e impersonales.

Las cualidades de apertura, honestidad y coraje son fomentadas en todos los niveles, y la ganancia individual se vuelve secundaria ante el avance colectivo. Un ambiente Scrum es uno que soporta a la gente, donde las personas de todos los niveles muestran respeto y confianza entre ellos. Las decisiones se toman por consenso, más que por imposición de alguien de más arriba, y todo el conocimiento es compartido, de una manera transparente y sin recelos.

Scrum va en contra de lo que hacen muchas compañías de la industria del software, donde una forma en fases acoplada con un alto grado de micro-gerenciamiento, y una insistencia en procesos definidos y documentación extensiva, se han hecho la norma por treinta años. Muchas compañías se basan en el miedo y el dinero como motivaciones claves para sus trabajadores. Esta forma de trabajo ha mostrado éxitos a corto plazo, pero más y más compañías están comenzando a entender que no es una buena estrategia para el largo palzo. Sin embargo, el concepto de cambiar a algo tan radical como Scrum aterroriza a muchos corazones de ejecutivos y gerentes de nivel medio.

Scrum está aún en la etapa de los “early-adopter” (los que abrazan tempranamente las nuevas ideas). Tomará muchos años para que la mayoría de las compañías reconozcan los beneficios de crear más lugares de trabajo, llenos de confianza. Sin ese cambio, muchas compañías de software se irán hundiendo bajo el peso de sus procesos pesados, y fuerzas de trabajo sobrecargadas. Otros, aquellos que abracen el método liviano, ágil, de Scrum, tendrán la gran oportunidad de sobrevivir y prosperar. Para aquellos que pasen a Scrum, y lo abracen completamente, la vuelta atrás a a los viejos días de trabajo será impensable. Un cambio de paradigma está ocurriendo en el lugar de trabajo, y Scrum es una parte importante de ese cambio.

Nota: el término Scrum proviene de un “paper” titulado The New New Product Development game de Hirotaka Takeuchi y Ikujiro Nonaka. En rugby, un scrum es una forma de recomenzar el juego, luego de una infracción accidental o después que la pelota salió de juego. La práctica de Scrum en el mundo del software incluye reuniones regulares diarias y cortas donde los miembros del equipo se juntan para comunicar su progreso. Debido a la similitud entre la pausa del juego (trabajo), y habiendo los jugadores (miembros del equipo) armado la reunión, ésta se conoce comúnmente como el Daily Scrum. Jeff Sutherland, John Scumniotales y Jeff McKenna son los responsables de haber introducido el término Scrum en el mundo del desarrollo del software en 1993, mientras trabajaban en la Easel Corporation, una compañía de herrmientas de software de Massachusetts. Ken Schwaber escribió el “paper” original sobre Scrum, SCRUM Development Process, que fue presentado en la conferencia OOPSLA en 1995.

Otras referencias:
Scrum: its place in the world
Scrum for Software Development

Tobias Mayer visita Buenos Aires

Ágiles

Tobias Mayer volverá a visitar Argentina para dar su curso de CSM.

Ya se publicó la noticia en Ágiles BS AS y foro-ágiles, y la información es la siguiente:

Tobias ya ha venido varias veces a Argentina, y dio 6 cursos de CSM. En enero nos visita en la semana del 25 al 26 y aprovechamos con varios actividades:

(*) En ambos casos, cada día cuesta 220 usd + IVA. Tomando ambos curos el costo es 330 usd + IVA – La facturación la realizará Agilar, que organiza estos eventos.

Consultas CSP

Luego de hacer un curso oficial de Scrum te convertis en CSM. Pero, más allá del valor de tomar el curso, todos sabemos que no es una «certificación» muy exigente. Por eso puede interesarte dar el próximo paso en las certificaciones de la Scrum Alliance: Certified Scrum Practicioner (http://www.scrumalliance.org/pages/certified_scrum_practitioner). Para facilitar este proceso, Tobias Mayer y Alan Cyment ayudarán y responderán dudas sobre como completar el formulario.

Y si tenemos algún tiempo, podremos hacerles otras preguntas.

Dónde: Microsoft Argentina, Bouchard 710 4to piso, Ciudad de Buenos Aires.

Cuándo: martes 26 de enero, de 19 a 21hs
Cuánto: gratis, pero tenes que registrarte.