Llevo ya algunos meses colaborando en la comunidad de Taiga, escribiendo artículos sobre Agile, y no lo había comentado aquí. Están todos en inglés, aunque están revisados por el equipo de comunicación de Kaleidos y así mejoran mucho. 🙂
Vamos a explorar la tensión que provoca en una organización el aumento del número de equipos trabajando en un único producto.
Hace ya mucho tiempo comencé lo que pretendía ser una serie de artículos sobre escalado Agile que, por diversas razones, había dejado “colgada” pero que no quería dejar inconclusa. Creo que merece la pena poner en orden todas las ideas que se pueden articular alrededor de esta serie.
Con este artículo pretendo explicar cómo puede crecer una organización desde un único equipo ágil que construye un único producto hasta una configuración donde tenemos a muchos equipos construyendo varios productos y colaborando entre ellos.
Dediqué el artículo anterior a la primera parte del libro “This is Lean”, que habla principalmente de la paradoja de la eficiencia. Esta entrada la dedicaré al resto del libro, que justamente se centra en explicar qué es Lean.
La semana pasada, tras acabar la lectura de “This is Lean”, hice una encuesta en Twitter y el resultado no fue del todo concluyente. Así que he decidido utilizar el libro como excusa y hablar de algunos temas relacionados con la eficiencia.
Por fin en esta entrada concluyo la serie “El desarrollo de software son conversaciones”. Se trata de cerrar el círculo y ver qué sucede cuando nuestro software (completo, o apenas un incremento) llega hasta los usuarios: lo que llamamos feedback.
Ya va siendo hora de retomar esta serie sobre las conversaciones en el desarrollo de software. Tal y como avancé en el capítulo IV, quiero acabar con la fase del “downstream” en este (espero) penúltimo capítulo. Así, hoy voy a hablar sobre las pruebas y el despliegue: esas actividades que solemos realizar desde que consideramos que una nueva funcionalidad está acabada, hasta que realmente está a disposición de los usuarios.
