Scrum

Scrum (16)

Las metodologías ágiles están de moda... sobre esto no hay duda. De hecho, distintas empresas están buscando transformar su modo de trabajar usando estas metodologías, a veces por motivos que las mismas desconocen.

En estos casos, Scrum suele ser la solución elegida ya que combina la posibilidad de cambiar la visión del equipo desde el producto hacia la necesidad del negocio, al mismo tiempo que otorga al nivel ejecutivo esa sensación de previsión -generalmente falsa- a la que estaban acostumbrados con los procesos anteriores.

En mi experiencia, cuando se trabaja con la provisión de un servicio y no con el desarrollo de un producto, el ritual que presenta más desafíos es el de la demo; probablemente porque se tiene la percepción de que se está realizando un ritual vacío... y esta sensación puede sabotear la transformación a agile de equipos o incluso de organizaciones enteras.

Esto representa un desafío: ¿Cómo hacemos para que el equipo vea el sentido de realizar la demo en aquellos ambientes donde no están trabajando sobre un producto sino sobre un servicio?

En este artículo intentaré aportar elementos para una respuesta...

Martes, 09 Enero 2018 07:43

Construcción de tableros útiles con Excel

Escrito por

En dos artículos anteriores de ejemplo de tablero visual (parte 1 y parte 2) presentamos una propuesta de tablero para un departamento no desarrollo, concretamente un concesionario.

Allí mencionábamos que toda herramienta de seguimiento debe ser útil

Pero... ¿Qué significa útil? Significa que debe ser una herramienta moldeable, que permita ordenación, filtros, que pueda ser adaptada a la manera de trabajar de cada uno.

Veamos cómo realizar un tablero útil con Ms. Excel

Luego del artículo anterior sobre la transparencia, llega el momento de otro valor que forma parte de la misma cadena, y es el coraje.

Y si bien todos sabemos a que nos referimos cuando hablamos de coraje, este suele ser uno de los valores  que suelen generar mas dudas cuando no nos encontramos en ambientes de desarrollo.

¿Qué se entiende con coraje?  ¿Coraje en que sentido? ¿Coraje para hacer qué cosa? Suelen ser las preguntas que más veces he escuchado... Sobre todo por parte de quienes gestionan equipos, quizás temiendo que los actos del equipo puedan provocar actitudes indeseadas.

Veamos algunas reflexiones que quizás aporten a resolver estas dudas.

En nuestro episodio anterior sobre un tablero visual presentamos una propuesta de tablero para un departamento no desarrollo, concretamente un concesionario.

Toda herramienta a nuestra disposición, para ser útil, debe ser usada y alimentada periódicamente, y es éste el objeto del presente artículo: presentar un modo integrado de uso del tablero, que permita el control de las operaciones al mismo tiempo que honre los principios ágiles.

Veamos cómo lo estamos implementando:

En un artículo anterior hablamos de la transparencia y formas de llevarlo a cabo en un equipo, departamento u organización.

Veamos ahora una herramienta sencilla que puede ayudarte a fomentar este valor, que consiste en un Tablero Kanban, que es una herramienta orientada a conocer el flujo de trabajo y el estado actual de cada tarea; y que además te permite fomentar la transparencia si está expuesto en el lugar adecuado.

¿Son aplicables estos tableros dentro de una organización de ventas, construcción, servicios, otros? Sí, lo son. Te explico cómo y te invito a que lo lleves a la práctica.

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?

¿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?

Miércoles, 25 Octubre 2017 19:30

Experiencia de transición a Agile de un departamento

Escrito por

Este artículo es una colaboración de Antonio Delgado, quien comparte con nosotros su experiencia en la implementación de Agile en un departamento.

Está dirigido a profesionales ajenos al marco de trabajo Scrum, por lo que puede ser útil cuando no sabemos qué cambios esperar durante y luego de la transición.

Todos los que hemos facilitado estos procesos, tenemos una historia común de implementación, pero matizada en su forma de aplicarlo, dependiendo de distintos factores (como el entorno y el contexto). Estos factores son los que hacen que cada equipo varíe el modo de implementar estos cambios, aunque todos tiendan luego a un resultado común.

Disfrutemos juntos de la experiencia de Antonio en este caso:

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"...

Lunes, 09 Octubre 2017 10:55

Qué es la deuda técnica

Escrito por

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:

Volver arriba