Consideremos Kanban… otra alternativa ágil

El sistema Kanban para el software, derivado del Sistema de Producción de Toyota (TPS), son un enfoque sin iteraciones para organizar el trabajo. En vez de usar iteraciones de tiempo fijo y reuniones de planificación, el equipo toma historias del backlog sólo cuando completó su trabajo anterior.

En la comunidad ágil no existe un único modelo ágil de trabajo que se aplica a todas las situaciones. Es importante expandir el repertorio de opcionas más allá de Scrum / XP y familiarizarse con otras herramientas, como ser Kanban.

Hay varios enfoques para implementar Kanban en los equipos que desarrollan software. James Shore, autor de El Arte de Desarrollo Ágil, escribe: “El equipo toma una historia del backlog, la desarrolla, y la entrega ni bien esté completa. Luego toman la historia siguiente del backlog, la desarrollan, y la entregan. El trabajo se entrega ni bien está listo, y el equipo sólo trabaja de a una historia a la vez”.

Los elementos claves para hacer funcionar a un sistema Kanban son:

  • Características Vendibles Mínimas (Minimally Marketable Features – MMF): un MMF es es la característica más pequeña que tiene valor para el mercado. Los MMF se mantienen en una cola (muy parecida al Backlog del Producto de Scrum), pero que tiene un estricto tamaño fijo que la limita (en general, entre dos y siente elementos en la cola).
  • Trabajo en Progreso: el equipo trabaja en el elemento más importante hasta que lo termina. Trabajan un único elemento por vez, descomponiéndolo en muchas tareas pequeñas.
  • Estimación: en vez de usar la planificación y estimaciones habituales, se asume que todos los MMF tienen aproximadamente el mismo tamaño. Así se puede seguir el tiempo promedio en completar una caractarística, y se puede calcular el tiempo de espera en la cola para cada elemento.
  • Elementos urgentes: ocasionalmente puede surgir trabajos de emergencia. Se reserva un único casillero para el trabajo de emergencia. Este lugar tiene más prioridad que el resto del backlog y el equipo trabaja para terminar ese elemento lo antes posible. Si aparece más trabajo urgente mientras el casillero está ocupado, va a parar el backlog común.
  • Bugs: los errores en la programación se arreglan inmediatamente si la característica está en construcción. Sino, se los ubica en el backlog.

Para muchos, la receta para el éxito puede resumirse en Enfocarse en la calidad, reducir el trabajo en progreso, balancear la capacidad vs. la demanda, Priorizar.

¿Por qué Kanban?

Para lograr entregar las características de un producto tienen que trabajar personas con diferentes capacidades. No hay que construir características que nadie necesita ahora. No hay que escribir más especificaciones de las que se pueden codificar. No hay que escribir más código del que se puede probar. No hay que probar más código del que se puede desplegar… Kanban ayuda a resolver estos problemas de manera más eficiente que otras alternativas.

En definitiva, ágil no es Scrum (aunque Scrum es ágil). Ágil no es XP (aunque XP es ágil). Ágil consiste en entregar valor, calidad, y lograr un proceso que pueda aprender de si mismo. Kanban en el software es una alternativa ágil más para lograr estos objetivos.

Opiniones?

Estrategias de equipo para generar confianza

Cuando un grupo de personas se une para trabajar en equipo, pasan por una serie de dinámicas grupales conocidas como “Formación, Enfrentamiento, Normalización, Desempeño y separación (en algunos casos)”. Al equipo le lleva tiempo  pasar por cada una de estas etapas. Progresan, tienen retrocesos, discuten y se llevan bien. Con el tiempo, a menudo varios meses, y con el apoyo adecuado, el equipo logra conocerse y trabajar bien juntos. El equipo sobresale. La productividad aumenta. Hacen un trabajo increíble. ¿Qué se necesita para lograr este nivel de productividad?

El equipo tiene que asumir una responsabilidad conjunta por su trabajo. Los miembros del equipo necesitan pensar en el resto del equipo como “nosotros”, no como “ellos”. Si un miembro nota que necesita hacerse algo, asume la responsabilidad aunque no sea su especialidad: hace el trabajo, busca a alguien para que lo ayude, o recluta a alguien más para que se ocupe.

Entonces, los miembros del equipo necesitan confiar entre ellos para ayudarse. Cuando un miembro del equipo encuentra una pregunta que no puede responder, no duda en preguntarle a quien conoce la respuesta. A veces estas preguntas rápidas se convierten en sesiones más largas trabajando en pareja.

La confianza es esencial para que el equipo logre un buen desempeño. Se necesita confianza para que tomarse tiempo en ayudar a otra persona no nos haga ver improductivos. Se necesita confianza en que seremos tratados con respeto cuando pedimos ayuda o no estamos de acuerdo con alguien.

La organización también necesita confiar en su equipo. Al principio Extreme Programming (XP) es diferente y extraño. No tiene los indicadores normales de progreso que los gerentes están acostumbrados a ver. Se necesita confianza para que crean en el equipo y en su capacidad de entregar un resultado exitoso.

La confianza no aparece por arte de magia – hay que trabajarla. A continuación veremos algunas estrategias para generar confianza en un equipo XP.

Estrategia #1: empatía Cliente – Programador

Muchas organizaciones están luchando con una actitud “nosotros contra ellos” entre clientes y programadores. Los clientes a menudo sienten que a los programadores no les importa sus necesidades o fechas de entrega, algunas de las cuales podrían costarle su trabajo. Los programadores a menudo se sienten forzados a comprometerse a objetivos que no pueden cumplirse, afectando su salud y relaciones.

A veces este enfrentamiento es tan intenso que los grupos empiezan a actuar justo como el otro teme: los programadores reaccionan inflando las estimaciones y enfocándose en juguetes técnicos afectando las características necesarias; los clientes reaccionan ignorando las estimaciones de los programadores y ejerciendo presión sobre la planificación. Esto puede ocurrir aunque no se presencie una hostilidad cara-a-cara.

Todo esto es una situación difícil sin una respuesta fácil. Lleva mucho tiempo reconstruir relaciones tan dañadas. Como ningún grupo puede forzar al otro a construir el puente, lo mejor es enfocarnos en cambiar nuestra propia actitud.

En esta situación, el componente faltante más importante es la empatía por la posición del otro grupo. Programadores: recuerden que los clientes tienen jefes que les demandan resultados. Los bonos, las promociones, e incluso la seguridad laboral dependen en las entregas diarias, y estas demandas no siempre son razonables. Los clientes tienen que entregar resultados de todas formas.

Clientes: recuerden que ignorando las recomendaciones profesionales de los programadores sobre las fechas de entrega a menudo lleva a consecuencias serias para los programadores. “Los equipos en proyectos comprometidos son la norma, no la excepción… Estos equipos a menuda trabajan 13-14 horas por día, seis días a la semana… en los peores proyectos, no es raro ver que uno o dos miembros del equipo caigan exhaustos, sufran úlceras o colapsos nerviosos, o se divorcien” (según Yourdon). Lo común de estas experiencias hace que los programadores sientan apatía y cinismo sobre las planificaciones y los compromisos.

Sentarse juntos es la forma más efectiva de construir empatía. Cada grupo puede ver en qué los demás están trabajando tanto como ellos. Las retrospectivas también ayudan, si se logra que los equipos no se hechen la culpa. Los programadores pueden ayudar siendo respetuosos de los objetivos del cliente, y los clientes pueden ayudar siento respetuosos de las estimaciones y recomendaciones técnicas de los programadores.

Estrategia #2: empatía Programador – Tester

También existe una actitud “nosotros contra ellos” entre programadores y testers, aunque no sean tan común ni fuerte como el problema Cliente – Programador. Cuando ocurre, los programadores tienden a no respetar las habilidades de los testers, y los testers creen que su misión es romper el trabajo de los programadores.

Al igual que con Cliente – Programador, la empatía resulta clave para mejorar las relaciones. Programadores: recuerden que el testing necesita de habilidades y trabajo cuidadoso, igual que la programación. Aprovechen las habilidades de los testers para encontrar errores que nunca se pensaron, y denles las gracias por ayudarlos a prevenir que estos problemas le lleguen al cliente y a los usuarios. Testers: enfóquense en el objetivo compartido del equipo: producir un gran producto. Cuando encuentran errores, no es motivo de celebración ni éxito. También recuerden que todos cometen errores, y que los errores no son un signo de incompetencia o pereza.

Estrategia #3: comer juntos

Otra manera de mejorar la cohesión del equipo es comer juntos. Las comidas ayudan a bajar las barreras y fomenta la cohesión del equipo. Pueden probar con un almuerzo gratis por semana. Si traen el almuerzo a la oficina, pongan la comida en una mesa “estilo familia” para que las personas no se lleven la comida a sus escritorios. Si salen a comer afuera, pidan una única mesa grande en vez de mesas separadas.

Estrategia #4: continuidad del equipo

Usualmente, cuando un proyecto

Algunos equipos serán más productivos que otros. Aprovechemos esto usando a estos equipos más efectivos como área de entrenamiento para los otros equipos. Podemos rotar a miembros junior hacia estos equipos para que puedan aprender del mejor; podemos rotar a miembros experimentados para que lideren sus propios equipos. Si hacemos esto de forma gradual, mantendremos intacta la cultura de equipo y la confianza.

La continuidad de equipo es una práctica avanzada: no porque sea difícil de lograr, sino porque desafía las estructuras organizacionales normales. Aunque la continuidad del equipo es muy valiosa, no es necesaria para tener éxito.

Opiniones?

Salu2!

Cuando tienes muchas cosas en mente…

Por lo general, se pierde la paciencia cuando te sobrecargan de labores y responsabilidades en tu trabajo, y más aún, si no es equivalente entre personas y equipos. Es algo realmente complicado, sin contar el sin fin de problemas de otra indole que afecten tu ritmo de vida. Lamentablemente, no hay mucho que hacer pues necesitas el trabajo, y en fin; la vida jamás es como la sueñas.

Pero existen maneras de poder relajarte en esos momentos de alta tensión. Antes para mi un pequeño escape era fumar hasta que se me pasara un poco la ira, o tomar un café bien cargado, pero no me habia dado cuenta, que con eso, no resolveré nada de los problemas que me aquejan, asi que no encontré mejor táctica de “dibujar” mi problema.

De esa manera, aparte de distraerme bosquejando y lanzando rayas, en algo puedo cooperar en la organización general de los motivos que me aquejan, y por lo menos resulta una super buena terapia para mi; no pierdo mi tiempo, me relajo dibujando, y más encima organizo el problema.

Opiniones?

salu2!