Esta serie sobre aplicación de agile en ambientes que no son de desarrollo inicia con un artículo donde hablamos de uno de los valores motores de cualquier proceso de adopción agile: la transparencia.

¿Qué es la transparencia? Transparencia es la actitud de poner en conocimiento de los demás lo que estamos haciendo, pero no sólo: también es dar modo a los demás de conocer el motivo por los cuales estamos actuando de esa manera, y los juicios que nos llevan a tomar la decisión de ser transparentes.

Pero como si eso fuera poco, para que un equipo sea ágil, se requiere que esa actitud de transparencia sea compartida por todos, y que además sea mantenida en el tiempo. No basta con ser transparentes solo en situaciones de calma sino también en situaciones de crisis, y no solamente en los momentos en que estamos siendo reconocidos por nuestras tareas sino también cuando tenemos oposición a nuestro accionar por parte de otras personas o equipos.

Obviamente la resistencia a exponerse de ese modo puede surgir naturalmente. Es totalmente comprensible, más aún si estamos inmersos en una cultura empresaria de buscar culpables para evadir las consecuencias de los errores propios.

¿Cómo lograr entonces la adopción de la transparencia en el equipo?

Publicado en Scrum

¿Es posible incorporar metodologías agile (en particular scrum) en ambientes que no sean de desarrollo de software?

Esta pregunta la escucho prácticamente en todos los cursos de scrum y metodologías ágiles. Y generalmente devuelvo la pregunta a los mismos estudiantes para que la contesten según su percepción.

Generalmente la respuesta suele ser un "SI" convencido, pero lo cierto es que tras la pregunta de algún ejemplo concreto, los silencios abundan. Esto porque hay prácticas que pueden aplicarse en distintos ambientes, pero que por si solas no aseguran la agilidad.

¿Te ha pasado estar en empresas donde aseguran hacer scrum, pero en realidad lo que hacen es waterfall mezclado con reuniones de daily, planning y demo? Les contesto la pregunta: si a las reuniones asisten agotados, sin ganas y sienten que son una pérdida de tiempo, probablemente esté sucediendo eso.

¿Cómo hacer entonces para que esto no suceda en otros ambientes donde aún no está arraigado agile?

Publicado en Scrum

De la mano del mítico Mike Cohn, uno de los firmantes del manifiesto ágil, nos viene propuesto un framework para escalar Agile.

Pero antes de seguir adelante, una advertencia: se trata de una broma, solo que a diferencia de otras bromas de este estilo (como puede ser el framework "Safe"), esta vez la broma es admitida y fomentada por una empresa que trabaja seriamente para implementar Agile.

Por otro lado, lo valioso en mi opinión es que varias de las características definidas son muy cercanas a las orientaciones que las empresas que se declaran ágiles con una finalidad de marketing (o que lo hacen sin saber realmente de qué se trata) imponen en su propia estructura. Desde ese punto de vista, es un framework muy ilustrativo para evitar esos peligros.

Vamos a darle un vistazo... y que conste, cualquier parecido con la realidad que puedas estar viviendo (o haber viivido) es "puramente casual"...

Publicado en Scrum

El viernes 26/9 y sábado 27/9 realizaremos el primer evento "Agiles Argentina 2014" en la Universidad de Belgrano.

Publicado en Noticias

Desde hace ya varios años, se habla y se discute sobre la deuda técnica como de algo sabido por todos. Sin embargo, en mi experiencia, este no es un tema suficientemente analizado o comprendido por la generalidad de los desarrolladores y los ejecutivos que conozco.

¿A qué nos referimos con el concepto de "deuda técnica"?... básicamente, con este término nos referimos a todas esas decisiones tanto hardware como software, que puedan comprometer la calidad o el funcionamiento del producto. Un ejemplo: desarrollar un sistema software sin pruebas unitarias para minimizar los tiempos de desarrollo por una necesidad urgente de oportunidad o de mercado.

La idea es que "puede ser algo que ahora funciona o tiene sentido", pero que en realidad pagaremos en el futuro cuando suframos las consecuencias de nuestras decisiones (por ejemplo dificultad para mantener el sistema, calidad insuficiente, etc)

Dicho de este modo, pareciera que el concepto de deuda técnica queda claro, y de hecho es un concepto simple, pero hay muchos grises en esta definición ya que queda librada al juicio de un equipo o de una persona, por lo que las interpretaciones pueden diferir entre equipos o personas.

Veamos algunos conceptos que creo son importantes al momento de identificar estas situaciones:

Publicado en Scrum

En Scrum, uno de los roles es el de "dueño del producto" o "product owner", y es uno de los pilares que hace funcionar la ecuación del trabajo en equipo bajo esta metodología, pero hasta ahora he visto muy pocos "dueños del producto" que correspondan con quien realmente va a terminar siéndolo... por lo que me ha tocado trabajar hasta ahora, el dueño del producto no suele ser quien finalmente lo usará o lo poseerá, sino personas que la empresa (o la empresa contratista) identifica como quienes deberán dar las pautas al equipo de desarrollo... una especie de "super analista funcional pero solo en el nivel conceptual".

A mi parecer, este no es el rol previsto en esta metodolo(filoso)fía, y puede ser causa de riesgo de fracaso del proyecto. Veamos un poco por qué:

Publicado en Scrum

Es buena práctica indicar los criterios de aceptación de las historias con el formato "dado-cuando-entonces" ya que en una simple frase se pueden indicar los criterios de aceptación que en última instancia es el contrato entre el dueño del producto y el equipo de desarrollo, ¿pero qué pasa cuando el product owner no comprende o no le resulta intuitiva esta sintaxis?

Publicado en Scrum

Ya está dsponible el examen para validar los propios conocimientos antes de rendir el examen de Scrum Alliance para la certificación de Scrum Master (CSD).

Los exámenes de prueba constan de 10 preguntas tomadas en forma aleatoria de un pool de decenas de preguntas disponibles (y en constante aumento). El examen está disponible al siguiente link: Test gratuito para la certificación CSM

Espero que esta iniciativa les resulte útil.

 

Publicado en Scrum

En el Agile Open Space que se hizo en la Universidad de Belgrano (en Buenos Aires), se charló entre otras cosas sobre personal kanban y si bien no se dijo nada de particular que me haya agregado algo a lo que sabía, sí se mencionó un programa en la web que permite hacer simples tableros kanban: trello (http://www.trello.com). Es un servicio gratuito al día de hoy, pero no encontré indicación de si alguna vez iniciará a ser pago o si seguirá siendo gratuito por siempre.

A partir de ahí me puse a investigar y me pareció bastante interesante como producto; y estas son las características que a mí me resultan más interesantes:

Publicado en Auto Gestión

El pasado 19 de julio dí una charla sobre el manifiesto ágil en el club de programadores de Buenos Aires.

Estos eran los objetivos:

"Presentar y discutir juntos sobre la filosofía que está detrás del manifiesto ágil, y hablar sobre lo que significa aplicar estos principios en el trabajo de todos los días en especial en informática. Vamos también a intentar aclarar algunos términos como Agile, XP, Lean, Scrum, Kanban y otros, que son usados muchas veces como sinónimos aunque no lo sean.
Si estás empezando o querés empezar a trabajar con filosofía agile y tenés dudas sobre algunos de estos temas, esta charla es para vos."

 

Publicado en Scrum
Volver arriba