Daily Meeting Scrum sin metodología ágil de desarrollo

Vengo interesado por las metodologías ágiles de desarrollo de software hace algún tiempo, sin embargo poco las aplico, ya que en mi empresa no se trabaja así y como además trabajo en soporte y mantenimiento es difícil tomar tiempo para hacer algo diferente.

Pese a lo anterior nos plantearon las siguientes necesidades

·         Mayor comunicación

·         Mejorar la productividad

·         Mejorar el cumplimiento

·         Solucionar impedimentos rápidamente

·         Trabajo en equipo

Algunos compañeros sugirieron que nos reuniéramos y auto-controlarnos diariamente. De inmediato vi entonces la oportunidad de introducir la práctica de Daily Meeting usada en SCRUM y entonces les dije lo siguiente para vender la idea:

Objetivos:

·         Mejorar la comunicación

·         Aumentar la visibilidad y contexto de lo que hacemos

·         Mejorar la colaboración  y sincronización del equipo

·         …

Beneficios:

·         Productividad

·         Aprendizaje

·         Trabajo en equipo (autogestionados)

·         Mejora continua

·         Mitigación riesgos

·         …

Dinámica:

Cada uno responde 3 preguntas:

·         Que hice ayer

·         Que voy a hacer hoy

·         Que impedimentos tengo.

Algunas Reglas

·         Timeboxing (tiempo fijo: 15 min máximo)

·         Mismo lugar y misma hora todos los días.

·         Solo se habla de las tres preguntas

·         No se asignan a otro tareas. Se auto asignan

·         No se debe extender en explicaciones ni discusión de problemas

·         Mantener el foco de la reunión

·         Todos deben estar y participar

·         Debe haber un facilitador y rotarlo cada x tiempo

·         Quien tenga información y pueda ayudar a solucionar un impedimento se ofrece pero se reúne luego para hablarlo

·        

Algunos Valores

·         Compromiso

·         Transparencia

·         Colaboración

·         Confianza

·         Excelencia

·         Respeto

Ya realizamos la primera reunión y aunque empezamos 5 minutos tarde, duró 25 mintuos en vez de 15, y no utilizamos tablero visual, pienso que está práctica si podrá aportarnos en la solución de algunas necesidades.

Saliendo de la reunión, pensé, como registramos los resultados de la reunión y se me ocurrieron estas posibilidades, pero para iniciar nos aventuramos con Trello

• ·         No registrar. El registro es la comunicación verbal
• ·         Excel
• ·         Tablero digital “Trello”
• ·         Tablero físico móvil . aunque más elaborado de lo que necesitamos, este es un ejemplo http://www.proyectosagiles.org/ejemplo-tablero-pizarra-tareas-scrum-taskboard
• 
  

EEspero que esto ayude a otros si tienen una situación similar. En el futuro les contaré los resultados que se vayan dando de esta experiencia.

Lean software development

Después de un par de charlitas de introducción a Lean Software Develoment resumo lo siguiente:

Lean es un paradigma y no una metodología. Similar al paradigma ágil, pero las "metodologías" serían por ejemplo SCRUM, KANBAN, XP.

Los principios son:

1. Eliminar Desperdicios (Elimine la grasa)
2. Ampliar el aprendizaje (Mente abierta)
3. Decidir lo mas tarde posible (No se acelere)
4. Entregar y/o reaccionar lo mas rápido posible (Cambiar con el cambio)
5. Potenciar el equipo (Todos ponen y todos pueden)
6. Crear la integridad (Cara a cara) (diferentes aspectos de la solución, no solo el producto)
7. Ver el todo (Con cucharita) (Visión general, pero aborde cada cosa)

Un poco mas de estos principios:

Eliminar Desperdicios 

Se trata de simplificar y eliminar si es posible aquellas actividades, funcionalidades, esperas, documentos u otros elementos innecesarios que no aporten valor 

Ampliar el aprendizaje 

Se trata de entender que el desarrollo de software requiere de un aprendizaje continuo y que tiene un grado de incertidumbre mayor entre mas temprana sea la fase.  Es por esto que se deben usar diferentes técnicas para ampliar el aprendizaje del producto como por ejemplo los prototipos

Decidir lo mas tarde posible 

Como se mencionó en el principio anterior, siempre va a haber un grado de incertidumbre, por lo cual no debemos tomar decisiones apresuradas y se debe retrasar las decisiones al ultimo momento responsable para tomarlas. Es decir, ni antes, ni despues de cuando deben ser. 

Entregar y/o reaccionar lo mas rápido posible 

El desarrollo ágil debe ser iteractivo e incremental y esto permite que se realicen entregas más rápidas que vayan generando valor a los clientes y usuarios. También se busca obtener retroalimentación lo más pronto posible para disminuir los riesgos y costos de no estar realizando el producto correcto o correctamente

Potenciar el equipo 

El equipo del proyecto debe tener autonomía y auto-gestión, dándoles la confianza para ello y los administradores o directores le deben indicar a los trabajadores que hacer y no como

Crear la integridad 

La idea es lograr un balance entre los distintos aspectos del proyecto y producto para tener en cuenta todo lo que gira al rededor del este como por ejemplo la divulgación , el costo, los requisitos no funcionales, etc. 

Ver el todo 

Se trata de tener una visión completa del proyecto y producto y cada una de sus partes y abordarlas una a una en el momento adecuado

"Piensa en grande, actúa en pequeño, equivócate rápido; aprende con rapidez"

Como Dividir una Historia de Usuario

Tomado de http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/

"El Scrum escondido detras de Scrum" Por Martín Alaimo

Hola

Unas Ideas sobre implementación de SCRUM que aprendí en una charla con Martin Alaimo de Kleer

Aparte del conocimiento del framework de Scrum y del proceso, es muy importante como lo dice el manifiesto ágil, LAS PERSONAS.

Es muy importante entonces:

1. Las relaciones entre las personas deben estar basadas en el respeto
2. Diferenciar entre los hechos y las opiniones o interpretaciones
3. Entender que las personas podemos tener diferentes puntos de vista
4. Usar un lenguaje adecuado para comunicarnos
5. No quedarse describiendo lo que pasó, sino lo que se va a hacer al respecto. (Pasar de un espacio descriptivo a uno generativo)... Especialmente en las retrospectivas
6. PO (Pedidos y Ofertas): Ser hábiles pidiendo y reconocer rápido que necesitamos ayuda. Al no pedir nos llenamos de cosas y finalmente tampoco le podemos ofrecer ayuda a los otros.
7. Al aceptar una oferta se genera un compromiso y se debe cumplir
8. Feed-bak . Se debe dar mucho feed-back pero no mucho feed-forward (consejos) limitando o condicionando el actuar del equipo. Es decir. Se pueden dar consejos pero es el equipo quien tiene la autonomia sobre ellos
9. Confianza. Se basa en tres pilares: Sinceridad, Habilidad y cumplimiento de los compromiso
10. Conocimiento vs aprendizaje: El conocimiento es una foto o copia de las cosas. El aprendizaje es un proceso . Debemos entonces perderle el miedo a un producto evolutivo. Aprender haciendo
11. Satisfacción de las personas en el equipo de trabajo.

          Un trabajador de conocimiento, una vez que tenga el dinero para satisfacer sus necesidades básicas, este deja de ser su principal motivador como si lo son:

• Autonomía (toma de decisiones)
• Maestría (aprendizaje)
• Propósito (para qué)

Video completo en http://www.youtube.com/watch?v=fw5Xjkpt5kU

Inicio de carrera ágil

Curso Métodos y Prácticas Ágiles: Material para profesores http://agilismoatwork.blogspot.com.es/2013/05/curso-metodos-y-practicas-agiles.html