Posts Tagged ‘agil’

h1

Agile for Dummies

03/02/2017

Wizbook [Icon By Buuf]
 Libros.

El esfuerzo continuo – no la fuerza o la inteligencia – es la clave para liberar nuestro potencial.

Winston Churchill (1874 – 1965). Político y estadista británico.

Recientemente terminé de leer Agile for Dummies (2ª Edición), escrito por Amy Silberbauer y Bernie Coyne. Este libro es una edición limitada, resultado de la colaboración entre IBM y la editorial Wiley, que puede ser descargado de manera gratuita por todos aquellos que quieran empaparse un poco sobre el entorno ágil de hoy.

La principal relevancia de esta guía reside en que, si bien los contenidos son muy generales, el libro incluye una introducción a las principales propuestas de implementación, incluyendo Scrum, Extreme Programming y Kanban, así como las variaciones más “formales” de ágil, tales como Disciplined Agile Delivery (DAD) y Scaled Agile Framework (SAFe). Así, el libro se convierte en una referencia que proporciona no sólo teorías, sino también algunas sugerencias prácticas sobre cómo aplicar principios ágiles y cuándo aplicarlos, para evitar caer en las trampas más comunes al trabajar de esta manera. Usando el enfoque familiar de la serie “for Dummies” – con un lenguaje y ejemplos sencillos; tips y trucos aquí y allá – esta publicación es recomendable para cualquiera que esté involucrado en proyectos sin importar su tipo o dominio: será especialmente valioso para aquellos que estén interesados en aprender más sobre prácticas y metodologías ágiles, con la intención de aplicarlas para obtener mejores resultados.

Pic: Agile Manifesto ~ Fabian Schiller
El Manifiesto para el Desarrollo Ágil de Software resume, en cuatro valores y doce principios, las mejores prácticas para el desarrollo de software:

• Individuos e interacciones por encima de procesos y herramientas.
• Software funcionando en vez de documentación extensiva.
• Colaboración con el cliente por encima de negociación contractual.
• Respuesta ante el cambio por encima de seguir un plan.


Agile for Dummies se divide en 11 capítulos. Los primeros muestran una introducción al Manifiesto Ágil, los principales roles que lo componen durante su implementación, así como los artefactos y ceremonias más utilizados. Luego, se describen todas las variedades de ágil, desde las más sencillas de implementar, hasta las que proporcionan un mayor valor en ambientes que requieren una gran escalabilidad, tales como
DevOps
y el Agile Unified Process (AUP). Finalmente, los últimos capítulos se enfocan en mostrar al lector los principales mitos y problemas al llevar a cabo el enfoque ágil. El libro está escrito como un “manual de campo”, con términos concisos y claramente definidos. Cada capítulo inicia enumerando los puntos principales de lo que viene más adelante, y la lectura es bastante amena para aquellos que desconocen los términos mostrados en el libro.

Los últimos dos capítulos son aquellos que me parecen los más importantes dentro de toda la lectura: éstos explican las principales trampas y mitos sobre ágil. Aunque la explicación contenida en el libro es convincente, es demasiado corta, por lo que me hubiera gustado que los autores explicaran en mayor detalle los puntos descritos y cómo resolverlos, o con números, exponer por qué no son ciertos. Esto justamente, es lo que puede hacer la diferencia entre una implementación exitosa y un experimento fallido, y es lo que hace de este libro un buen volumen, pero no una excelente guía en ágil. Por ejemplo:

Falta de Apoyo Ejecutivo

Una adopción ágil eficaz requiere patrocinio ejecutivo al más alto nivel. Esta participación significa más que aparecer en una reunión de arranque para decir unas cuantas palabras. Sin el patrocinio ejecutivo que apoye a la iniciativa general, la adopción ágil estará a menudo condenada, porque las iniciativas ágiles requieren una inversión inicial de recursos y financiamiento – dos áreas que los ejecutivos suelen controlar.

Agile for Dummies. Amy Silberbauer & Bernie Coyne. (Wiley, 2015).

En tan sólo un pequeño párrafo, los autores se han despachado uno de los principales problemas a los que se enfrenta cualquier implementación ágil: si la organización en su conjunto no está convencida de que éste es el mejor camino, y no existe un sponsor que esté dispuesto a aportar recursos para llevar a cabo una prueba piloto, el ejercicio será completamente inútil. Sin embargo, si consideramos a este libro como un “panfleto” para crear conciencia, y no como una Biblia para ahondar en los detalles específicos de una adopción ágil, creo que es bastante aceptable.

Conclusiones

¿Cómo mejorar la productividad, calidad y satisfacción del cliente en nuestros proyectos? Agile for Dummies es un corto pero muy accesible libro que nos ofrece una introducción acerca de una de las técnicas de administración de proyectos más populares y exitosas de los últimos tiempos. Aprender acerca de esta filosofía nos dará la posibilidad de entenderlo, para posteriormente, aplicarlo a nuestro dominio específico – ¡no necesariamente el desarrollo de software! – y llegar a una solución que realmente funciona. Después de todo, si es implementado correctamente, ágil puede ser una gran manera de aprovechar las oportunidades de negocio, ya que permite abordar muchos de los retos de una organización con prioridades cambiantes, hace que el proceso de diseño sea más colaborativo entre diferentes áreas y enfoca a los miembros del equipo hacia la meta trazada por el negocio.

h1

¿Qué es la estrategia TI Bimodal (Bimodal IT) y cómo podemos implementarla?

01/08/2016

Wizdoc [Icon By Buuf]  Tips & Tricks.

No importa qué tan lento vayas, siempre y cuando no te detengas.

Confucio (551 – 479 AC). Profesor, editor, político y filósofo chino.

Hace un par de semanas tuvimos una reunión con cliente relacionada a su estrategia TI y cómo piensa crecer durante el próximo año fiscal. Durante la junta salieron a relucir algunas palabras clave como innovación o implementación ágil. Sin embargo, la frase que nos dio la respuesta a lo que realmente está buscando, se resume en dos palabras: estrategia bimodal. ¿De qué se trata? ¿Por qué algunos la están considerando como la nueva panacea que asegurará la competitividad de las organizaciones TI? ¿Y cuáles son los riesgos encontrados durante su adopción?

Durante el Simposio/ITxpo llevado a cabo por la firma de consultoría e investigación de mercado Gartner en Octubre de 2014, el vicepresidente senior y jefe global de investigación, Peter Sondergaard, señaló que mientras los CIOs no sean capaces de transformar sus departamentos TI de manera que sean más ágiles y competitivos, podrán convertir sus organizaciones mediante un modelo TI Bimodal; de hecho, según Gartner, para el 2017, el 75% de las organizaciones de TI tendrá una capacidad bimodal. Este modelo se describe como “La práctica de gestionar dos modos distintos y coherentes de ejecución de TI, uno centrado en la estabilidad y el otro en la agilidad. El Modo 1 es tradicional y secuencial, haciendo hincapié en la seguridad y precisión. El Modo 2 es exploratorio y no lineal, con énfasis en la agilidad y rapidez.” Así, la organización tendrá dos maneras de llevar a cabo sus iniciativas TI:

Modo 1

• Involucra a proyectos relacionados con el mantenimiento de los sistemas centrales (core systems) – usualmente las bases de datos y sistemas legados.
• Se centra en proporcionar estabilidad y eficiencia, respetando los ciclos de desarrollo más tradicionales, como cascada.

Modo 2

• Involucra a los proyectos que ofrecen innovación y agilidad para el negocio.
• El foco está en la respuesta rápida, mientras trabaja en liberaciones frecuentes (básicamente, desarrollo ágil de software).

No tan rápido

Sin embargo, el problema que intenta atacar Gartner no es nuevo (agilidad vs. estabilidad); por el contrario, si no se lleva a cabo de manera adecuada, el modelo bimodal puede degenerar en una lucha de poder entre las dos áreas, ya que es indispensable una colaboración transparente entre ambas con el afán de agregar valor de negocio. Las consecuencias, descritas en la revista CIO Insight, se enumeran a continuación:

• La primera y de mayor impacto sería la creación de silos artificiales para productos, procesos y personas. Esta es la dirección opuesta a toda tendencia organizacional saludable de TI desde que el término “síndrome del silo funcional” fue acuñado por Phil Ensor en 1988. TI Bimodal en silos significa lanzarse al ruedo precipitadamente, ignorando numerosos estudios publicados durante los últimos cuatro decenios.

• Estancamiento del Modo 1: El enfoque bimodal propone aplicar una curita sobre la herida que representan las plataformas tradicionales, pero no hace nada por detener la hemorragia. Este modelo institucionaliza el estancamiento, al desalentar la innovación en plataformas legadas bajo el pretexto de que “si no está roto, no lo arregles”.

• Rigidez del Modo 2: En palabras de Gartner, “el Modo 2 requiere un enfoque riguroso y disciplinado”, así que el modelo bimodal prescribe un flujo de proceso definido, previsible y lógico en torno a lo que en esencia, es un proceso impredecible para la experimentación y el descubrimiento. Algo así como “Pintura por números para la obra de Jackson Pollock.”

• Sobre-simplificación de procesos: Las nuevas aplicaciones se acuñarán en torno a uno de dos modos y serán siempre encerradas en un modus operandi que sin duda resultará ser inadecuado a largo plazo. TI Bimodal cierra las puertas a las aplicaciones legadas del Modo 1 para evolucionar a las ofertas ágiles del Modo 2; por el contrario se endurecerán las condiciones para que un prototipo ágil del Modo 2 pueda convertirse en una oferta de servicio más estable de acuerdo al Modo 1.

¿Cómo implementarla?

Aunque TI Bimodal suena bastante razonable sobre el papel, en la práctica los principales retos a sortear incluyen la priorización de los proyectos, la distribución de recursos entre ambos modos, integración o intercepción de proyectos (ya que por ejemplo, una aplicación móvil no es nada sin un back-end estable que la soporte) y cómo mantener a la organización, proveedores y socios de negocios apegados a esta visión. En pocas palabras, para alcanzar la meta planteada, es fundamental definir un gobierno TI o governance adecuado. Aunque la definición completa de un gobierno TI no es el objetivo de este post, baste decir que éste debe incluir los siguientes puntos:

• La alineación entre la estrategia de la organización y las TI.

• Obtención de valor que las TI generan para la organización.

• Mecanismos que permitan mediciones apropiadas para poder valorar las TI en su conjunto y poder tomar decisiones respecto a su gobierno.

• Gestión del riesgo que en un momento dado pueda afectar e impactar negativamente en las actividades y procesos de la organización.

• Gestión de los recursos TI y la utilización óptima de los mismos.

El gobierno TI debe facilitar un modelo transparente en el que todos los interesados tengan visibilidad sobre el día a día de las operaciones y el avance del programa estratégico. Asimismo, el modelo debe proveer una comunicación y priorización claras, que ayuden en la detección y resolución de problemas más rápidamente. Por ello, el proceso de gobierno debe abordar los siguientes tres niveles de revisión:

1. Estratégico: Cuando a un nivel de dirección ejecutiva, los diferentes grupos de interés puedan mantener y hacer crecer la relación (evitando caer en luchas de poder), resolviendo asuntos importantes, manteniendo la dirección establecida y aprobando los cambios estratégicos y el plan para el futuro.

2. Táctico: Donde a través de reuniones periódicas de los grupos de interés, éstos son capaces de asegurar que se está avanzando de acuerdo a los objetivos generales del programa.

3. Operacional: Cuando todos son capaces de trabajar sobre una base del día a día para ofrecer los servicios y entregables TI, respondiendo a peticiones, problemas y consultas, en línea con los objetivos del programa.

Pic: Bimodal IT Governance Example


Para que TI Bimodal – o cualquier otra estrategia de TI – tenga éxito, la visión tiene que ser compartida por todos los niveles de la organización: la alta dirección, proveedores, socios de negocio, gerentes de proyecto y equipos de trabajo por igual. Además, el éxito se mide no sólo por la entrega de valor a la organización de TI, sino por el valor del negocio; es decir, que la estrategia TI beneficia al negocio de una manera cuantificable. El éxito del programa, por lo tanto, debe ser comunicada a todos los niveles de la organización.

Parafraseando a George Orwell, aunque los tres niveles de revisión son igualmente importantes, algunos son más iguales que otros: el nivel estratégico tiene como principal responsabilidad mantener alienada la estrategia con los objetivos de negocio, monitoreando el desempeño de las demás áreas y detectando y resolviendo cualquier riesgo de alto nivel que se llegue a presentar; por otro lado, el nivel operativo lleva a cabo los proyectos individuales, reportando su progreso y asegurándose que las métricas impuestas por los otros dos niveles se cumplan. Sin embargo, el nivel que es crucial durante la implementación es el nivel táctico (la Oficina de Gestión de Proyectos o PMO, así como el Centro de Excelencia o CoE) ya que tiene por principal responsabilidad:

• Generar estándares y procesos, así como seleccionar las herramientas y tecnologías que usará el resto de la organización.

• Revisar el rendimiento y apego a normas de desempeño acordados para todos los grupos.

• Desarrollar el programa de implementación de la estrategia.

• Llevar a cabo el presupuesto, planeación y asignación de recursos.

• Asegurarse de que todas las políticas, planes, normas, etc. permean a los equipos de la organización.

• Resolver problemas tácticos escalados con el Comité de Gobierno estratégico (Steering Committee) y

• Escalar problemas al Comité de Gobierno cuando sea apropiado (por ejemplo, asuntos contractuales).

Algunos tips durante la adopción de este modelo

La gran ventaja de Bimodal es que la organización ya debería poseer un área de operaciones/desarrollo relativamente madura trabajando en Modo 1; esta madurez es precisamente la que asegura una implementación ordenada y estable, pero impide que iniciativas “para ayer” se concreten eficazmente. Por lo tanto, el proceso de adopción debe enfocarse a la creación del Modo 2 y cómo sus equipos deben interactuar y coordinarse eficientemente con los equipos del Modo 1. Por lo tanto, una adopción debe considerar entre otros, los siguientes puntos dentro del programa de implementación de estrategia:

• Una evaluación de la capacidad (readiness assessment) para convertir un segmento de la organización al Modo 2 de operación. Esto permitirá saber qué equipos y proyectos pueden generar el mayor valor de negocio en el menor tiempo posible. Por ejemplo, los proyectos más apropiados para llevarse a cabo en el Modo 2 son aquellos que poseen 1) fechas de entrega muy agresivas, 2) un alto grado de complejidad, y 3) un alto grado de innovación.

• Identificar uno o varios coaches versados en el Modo 2 de operación – Scrum, Lean, Kanban, V-Model, etcétera – que puedan resolver las dudas durante la implementación. Éstos por supuesto, deben ir de la mano con el Centro de Excelencia para definir los procesos, herramientas y entregables de gestión y desarrollo ágil que adoptará la organización.

• En caso de que los equipos del Modo 2 se hayan integrado con el personal original de la organización, es indispensable enfocarse en el cambio cultural. Si bien las prácticas y herramientas ágiles son importantes, establecer una mentalidad ágil es indispensable. Esto implica creer firmemente en el empowerment, liderazgo subordinado o equipos multidisciplinarios. El beneficio es que aseguramos una mentalidad de colaboración y urgencia para satisfacer las cambiantes demandas del negocio.

• Para el momento en que se inicie el delivery de equipos en el Modo 2, ya se debe haber seleccionado una herramienta de planeación (por ejemplo, JIRA o VersionOne), se debe haber proporcionado el entrenamiento adecuado a los equipos y se deben haber definido las métricas mínimas para que de manera periódica, pueda existir una rendición de cuentas al Comité de Gobierno.

• Finalmente, una vez que se han dado los primeros pilotos de adopción del Modo 2 y se ha establecido la manera en que ambos tipos de equipo estarán colaborando, es indispensable generar un proceso de mejora continua para perfeccionar la integración de todos los interesados. Para este momento, iniciar la estandarización – por ejemplo, certificar los proyectos corriendo en Modo 1 en CMMi-5 y los proyectos ejecutados en Modo 2 en CMMi-3 – ya es posible.

Conclusiones

La estrategia Bimodal NO es la bala de plata. Es tan sólo un paso intermedio hacia la introducción de prácticas como DevOps. A final de cuentas, lo que cualquier organización debe buscar, es la convergencia para actualizar sus procesos e infraestructura a la realidad del mercado. Hace algún tiempo, el analista independiente Jason Bloomberg dio su propio punto de vista al respecto de lo que él llamó una “receta para el desastre” de Gartner, añadiendo su propia recomendación: … para que la transformación digital tenga éxito, debe ser de extremo a extremo – con los clientes en un extremo y los sistemas legados del otro. TI tradicional, por supuesto, sigue siendo responsable de los sistemas legados.

Así, el enfoque debe ser el de empresas exitosas como Apple, Amazon o Google:

• ¿Cómo podemos deleitar a los clientes con nuevos productos y un mejor servicio?

• ¿Cómo se puede mejorar continuamente nuestro negocio con pequeños incrementos?

• ¿Cómo podemos optimizar la cadena de valor?

• ¿Cómo nos aseguramos de que el negocio impulsa el cambio y no el departamento de TI o marketing?

La clave reside en contestar estas preguntas honestamente y trabajar en ello… o formar parte del registro fósil de empresas fallidas, junto a anti-ejemplos tales como Eastman Kodak, PanAm y Compaq.

h1

¿Cuál es el rol de un Scrum Master en un proyecto ágil?

07/04/2014

Wizdoc [Icon By Buuf]  Tips & Tricks.

Caminar sobre el agua y desarrollar software a partir de una especificación son fáciles… si ambos están congelados.

— Edward V. Berard, ingeniero de software y autor estadounidense.

Desde hace tiempo, he venido predicando y evangelizando acerca de las metodologías ágiles; especialmente Scrum y Extreme Programming. Ahora bien, muchos de los neófitos suelen ser muy cautelosos y hasta escépticos en cuanto a los beneficios que éstas pueden aportar. Una de las preguntas más comunes que he escuchado, consiste en qué rol debe tomar un Scrum Master (SCM) como parte del proyecto ágil; la gran mayoría cree que el SCM es un “administrador de proyectos” o “líder técnico”, quien debe asumir la responsabilidad sobre el proyecto y los integrantes del equipo, dirigiendo las tareas o asignando responsabilidades durante de la ejecución del mismo. Nada más alejado de la verdad, ya que el SCM es el guardián del proceso… y no mucho más. De hecho, si el equipo de trabajo ya cuenta con el conocimiento necesario para llevar a cabo las ceremonias y generar los artefactos de manera adecuada, en cada ciclo o iteración de desarrollo es posible que el rol de Scrum Master sea tomado por algún miembro del equipo diferente en cada ocasión; no necesariamente el responsable técnico o el más senior del grupo. Debido a esto, presento a continuación las tareas desempeñadas por un SCM como parte de un proyecto, basándome en mi propia experiencia durante estos últimos años:

Se coordina con el Product Owner (PO). Un Scrum Master debe trabajar en conjunto con el PO para facilitar las actividades requeridas y cumplir con el release. Estas actividades incluyen aportar activamente durante la priorización del backlog, rastrear actualizaciones relacionadas al sprint actual, alzar la mano cuando se detecte algún riesgo, o trabajar con el PO para seleccionar los elementos a implementar durante el siguiente sprint.

Se convierte en el enlace entre el equipo de trabajo y el Product Owner. En muchas ocasiones, el PO es una persona con un background de negocios, por lo que hablarle en bits y bytes puede convertirse en todo un reto; esto es especialmente crítico, ya que para que Scrum sea exitoso, es necesaria una interacción constante entre el Product Owner y los desarrolladores. Por ello es importante que el Scrum Master mantenga a todos en sintonía, ya sea mediante sesiones grupales para aclaración de dudas o reuniones “uno a uno” donde el Scrum Master participa como moderador. De acuerdo a mi experiencia, el equipo usualmente pregunta poco durante la sesión de planeación del sprint, dejando casi todas las dudas para sesiones de preguntas y respuestas posteriores. Entonces, es recomendable calendarizar este tipo de reuniones una vez que inicie el análisis de historias de usuario, incluso a manera de reverse knowledge transfer, en el que el desarrollador le explica al PO, en sus propias palabras, qué es lo que entendió de la historia de usuario a implementar. Así mismo, para evitar que una sesión de este tipo se convierta en una reunión maratónica, es una buena idea acordar un tiempo fijo o timebox. El SCM debe entonces evitar que la reunión se desvíe del tema principal y todos los involucrados vayan directo al grano.

Facilita la demostración del sprint y la retrospectiva. El SCM es usualmente el indicado para calendarizar y facilitar la revisión al final del sprint, en la que los miembros del equipo muestran a los stakeholders el trabajo terminado. Ya que seguramente los participantes harán preguntas y proporcionarán retroalimentación al equipo, el Scrum Master puede actuar como escriba o moderador. Para las retrospectivas, un SCM experimentado puede ayudar a que los participantes “se aflojen”, para que las preguntas ¿Qué salió bien? ¿Qué salió mal? ¿Cómo podemos mejorar para la próxima en base a nuestras lecciones aprendidas? Puedan contestarse de forma honesta y ordenada, ayudando a que el equipo se concentre en cómo mejorar, en vez de designar culpables. Para proyectos pequeños o medianos en los que existan de uno a tres equipos de desarrollo, la revisión al final del sprint así como la retrospectiva pueden realizarse de manera combinada mediante videoconferencia; cuando el staffing del proyecto sobrepase más de 30 participantes, es mucho más cómodo que el equipo líder (Scrum de Scrum Masters, Arquitecto Líder, Product Owner de Product Owners) sea la única voz de cara a los stakeholders; dejando a cada equipo hacer sus propias retrospectivas.

Protege al equipo del Product Owner. El Scrum Master debe impedir a como dé lugar que el objetivo del sprint cambie una vez que ha iniciado. Si el SCM se da cuenta que el PO está cambiando los objetivos a mitad del sprint, su labor deberá ser la de negociar con el Product Owner cómo intercambiar historias de usuario equivalentes en esfuerzo de acuerdo a la prioridad de entrega, dejando las historias removidas de vuelta en el product backlog para su posterior implementación. Esto no es ideal, pero es bastante más sano que cancelar el sprint completo. Por otro lado, si esta re-priorización se vuelve la norma, es aconsejable adoptar un modelo de Scrumban, en el que se acuerda con el PO limitar el monto de trabajo por fase (por hacer, en ejecución, terminado), permitiendo intercambiar las tareas o entregables en cualquier momento. También es recomendable aclarar con el Product Owner que este intercambio de tareas tiene un costo: el “cambio de contexto” o tiempo mínimo necesario para cambiar de la tarea A a la tarea B, puede incrementar hasta en 24% el tiempo del proyecto si se le usa de manera constante.

Representa al equipo en el Scrum de Scrums (SoS). Sólo stakeholders de alto nivel participan en esta reunión. Si el equipo tiene múltiples reuniones internas, típicamente cada SCM representará a su equipo en un SoS. El Scrum Master puede ir acompañado durante esta reunión, ya que cualquier miembro del equipo puede proporcionar estas actualizaciones. Sin embargo, el SCM es quien debería saber lo que está pasando con su equipo en todo momento, y debería estar al tanto de cualquier plan de acción que pretenda llevarse a cabo. Durante el SoS es bastante común que se discutan cuestiones de diseño técnico así como reglas de negocio e impedimentos que afecten al proyecto en su conjunto, tales como problemas de infraestructura y regulatorios. Los participantes idealmente deberán ser Scrum Masters, Product Owners, arquitectos, gerentes de proyecto, etcétera.

Facilita los daily standups. El scrum diario es una reunión en la que los miembros del equipo proporcionan actualizaciones sobre su trabajo, comentando qué hicieron ayer, que piensan hacer hoy y qué obstáculos se encuentran en su camino. El SCM debe asegurarse que los standups tengan una duración definida y que la conversación fluya correctamente – es decir, evitar concentrarse en los detalles o permanecer demasiado tiempo hablando acerca de un tema particular. Si es necesario, el Scrum Master puede tomar nota y calendarizar sesiones adicionales para tratar temas puntuales.

Ayuda a remover impedimentos que bloqueen el trabajo del equipo. Esta es de hecho, la tarea más importante que debe desempeñar el Scrum Master. Si el equipo se enfrenta a un reto que impida entregar el trabajo acordado, el SCM debe entender de qué se trata y cómo resolverlo, coordinándose con otros stakeholders para “despejar el camino”. Si el problema está “fuera de su jurisdicción”, es indispensable que el Scrum Master escale el problema lo más pronto posible.

Se convierte en un coach ágil. En caso de que algún miembro del equipo no conozca del todo el proceso ágil, es responsabilidad del Scrum Master que todos aprendan y sigan las prácticas de la metodología correctamente.

Tiene que hacer cumplir la definición de Terminado. El SCM debe asegurarse que el equipo se adhiere a la “Definición de Terminado”; es decir, una lista previamente negociada y aceptada entre los integrantes del equipo, en la que se define bajo qué criterios el trabajo es considerado como finalizado. Por ejemplo, (1) debe cumplir con los criterios de aceptación definidos en la historia de usuario, (2) las pruebas unitarias, de integración y de aceptación deben haber sido terminadas, (3) deben existir cero defectos de severidad alta y (4) la revisión de código por algún colega debe haberse completado.

Facilita la sesión de planeación. La sesión de planeación es aquella en la que el equipo decide el objetivo del sprint y cuáles elementos del Product Backlog serán seleccionados para implementarse durante la presente iteración. Usualmente durante los primeros sprints, el Scrum Master es quien definirá o reforzará las reglas del Planning Poker usado para dimensionar las historias de usuario en términos de puntos de historia (por ejemplo: la serie de Fibonacci o “puntos perro“).

Conclusiones

Aunque la mayoría de las actividades que desempeña un SCM han sido cubiertas en este post, pueden presentarse muchas más actividades que dependen de la naturaleza del proyecto. Por ejemplo, en un equipo de desarrollo, el SCM era un excelente arquitecto en Java, por lo que además de sus funciones como Scrum Master, colaboró con el líder técnico del equipo para definir una arquitectura que fuese fácil de implementar y mantener. Por otro lado, en un caso que me tocó personalmente, en el que desempeñando la labor de Scrum de Scrum Masters, también tenía que fungir como Program Manager, llevando el tracking de varios equipos y proyectos operando simultáneamente, comunicando el avance y problemas a la alta dirección mediante presentaciones especialmente hechas para este fin – así es, de esas con portafolios, semáforos y “tiburones” listos para desayunarse al presentador si ellos ven algo que no les gusta.

h1

Una adopción ágil: retos y soluciones

02/14/2014

Wizdoc [Icon By Buuf]  Tips & Tricks.

Primero, tienes que aprender las reglas del juego. Luego, tienes que jugar mejor que nadie.

Albert Einstein (1879 – 1955). Físico judeo-alemán, nacionalizado suizo y posteriormente, estadounidense.

Desde hace poco menos de un año hemos venido trabajando con varias células de desarrollo ágil para un cliente que en aquél entonces era relativamente inexperto en esta metodología. Algunas de estas células han sido todo un éxito, compuestas por gente altamente calificada que trabaja como uña y mugre con el Product Owner (PO) perteneciente al cliente, mientras lanzan funcionalidad a producción como si fueran una fábrica de juguetes china. Otras células menos afortunadas han tenido que afrontar duros retos, incluyendo gente sin la suficiente experiencia para implementar el stack tecnológico y grado de colaboración necesarios para lidiar con proyectos y clientes complicados.

Pues bien, a partir de enero de este año, el cliente nos solicitó integrar Extreme Programming (XP) como parte de la implementación ágil, sin dejar de lado Scrum como framework de gestión de proyectos. Esto requirió un poco de flexibilidad entre ambas partes para incluir una serie de nuevos controles, tales como:

• Programación por pares, donde el trabajo es desempeñado por dos desarrolladores en vez de hacerlo de forma individual.

• El refactoring y la integración continua han tomado un rol mucho más importante durante el ciclo de desarrollo.

• Ahora existe una “propiedad colectiva del código”, en la que cualquiera puede modificar el código de otro, siempre que éste cambio sea respaldado por las mandatorias pruebas unitarias así como una correcta integración continua, evitando los así denominados cowboy coders: programadores muy buenos, pero que siempre dejan detrás de ellos un revoltijo inmantenible de código.

• La planeación ahora debe tomar en cuenta spikes de XP, los que en realidad son experimentos, análisis técnicos o pruebas de concepto que incluyen una revisión formal por parte del cliente.

• Anteriormente, la definición de “terminado” significaba tener algo listo para la demo. Ahora, ésta ha cambiado a “cuando el cliente lo haya probado satisfactoriamente”. Esto significa que durante el Sprint, el cliente realiza pruebas sobre los entregables, previo a la sesión de demostración.

• El análisis y diseño arquitectónico deben hacer uso de “metáforas”, o historias muy sencillas que explican cómo funciona el sistema. Esto se debe a que para el análisis, debemos interactuar con “embajadores” que oficialmente fungen como enlace entre las áreas de negocio y TI. Por ello la necesidad de explicarles cómo funcionan las cosas en términos “que hasta un niño pueda entender”.

Estos puntos han derivado en que el equipo tenga que reforzar la disciplina, pues si no tenemos cuidado, podemos terminar con una dinámica de grupo totalmente anárquica, en la que cada quien hace lo que quiere. Esto es más aparente si tomamos en cuenta que ahora todos trabajan en pares y pueden “tocar” cualquier parte del código. Por otro lado, el beneficio principal y la razón por la que el cliente ha considerado hacer este cambio, es que ya somos lo suficientemente maduros como para evolucionar el proceso hasta la fase de innovación:

pic: Enterprise agility adoption roadmap

Roadmap de adopción ágil. Generalmente, todo inicia con una fase de experimentación a través de un proyecto piloto con sólo un equipo de trabajo (Pasos 1 y 2). Posteriormente, corremos una fase de lanzamiento, donde varios equipos ágiles trabajan en paralelo sobre un mismo programa (Pasos 3 y 4). Después, ejecutamos un rollout general, donde establecemos ágil a nivel portafolio (Paso 4). Finalmente, viene la fase de innovación (Paso 5), en la que se implementan prácticas como colaboración remota y configuración de un ALM comercial. (Fuente de la imagen: appslog.com)

Lo que debe quedar muy claro, es que antes de llegar a esta fase, debimos haber alcanzado el punto en el que el cliente confía en nosotros lo suficiente como para sólo indicarnos cuál es el valor de negocio de la funcionalidad a entregar, dejando a nuestro criterio todo lo demás. Es decir, el momento en el que se le ha cedido el control y mando al equipo.

Los principales retos durante la adopción

Tanto la adopción ágil en general, como la implementación de XP en particular, han implicado muchísimos retos que sobre todo, tienen que ver con el lado humano. Ciertamente, desde hacía tiempo ya habíamos cubierto el tema del ciclo de desarrollo o SDLC y la calidad de los entregables; por lo que ahora debíamos lidiar con temas como “… ¿por qué debo sentarme con este tío a programar?” El cambio de algunos paradigmas, incluso entre gente “ágil”, no es cosa sencilla. A continuación, enumero los mayores retos que llegamos a enfrentar y cómo los hemos mitigado:

• El primero, y más importante de todos: ágil no significa que terminaremos un proyecto en menos tiempo. Este es un concepto erróneo que muchos usan como argumento de venta. La realidad es que el mayor beneficio de ágil, desde el punto de vista de negocio, son las liberaciones tempranas: ¿Para qué esperar seis meses a tener todo terminado, si desde el primer mes ya existe un entregable “listo para liberar a producción” que puede indicarnos si el proyecto está destinado al éxito o al fracaso? Obviamente, tendremos que esperar otros cinco meses para tener todo al 100%, pero desde el primer mes tendremos algo tangible y generando un ingreso, o podemos darnos cuenta que el caso de negocio era erróneo, teniendo la posibilidad de “tirar del enchufe” cuando apenas se ha gastado una pequeña fracción del presupuesto.

• Interdependencias entre equipos y proyectos. Aunque Scrum hace énfasis en que no existan interdependencias entre equipos, la realidad es que esto es el pan nuestro de cada día. Por ejemplo, un equipo en Java desarrolla web services que serán consumidos por una aplicación en .net desarrollada por otro equipo. En este caso, podemos echar mano de un perfil que no viene descrito en el framework original, conocido como Technical Owner (TO), que está al mismo nivel del Scrum of Scrum Masters. El TO es el responsable de la arquitectura de un programa o portafolio, definiendo interfaces y dependencias. Así mismo, debe apoyar en la definición del plan de liberación o release plan, evitando al máximo que nos pisemos los callos unos con otros, trazando una ruta crítica que tomará precedencia sobre cualquier otro ítem de los product backlogs para cada equipo involucrado:

pic: Scrum in an interdependent environment

El equipo 1 (rojo) hace Sprints de dos semanas y liberaciones cada mes; el equipo 2 (azul) ejecuta Sprints de cuatro semanas y libera cada dos meses. Sabiendo que el equipo 2 debe implementar ciertos componentes para que el equipo 1 pueda integrarlos, el Technical Owner debe apoyar a los Product Owners de ambos equipos para definir la ruta crítica y acordar quién hará qué y cuándo debe tenerlo listo. (Fuente de la imagen: cardinalsolutions.com)

Así, el TO apoyará en la generación de las especificaciones necesarias para que los equipos utilicen “mock ups” mientras tienen lista su parte. Finalmente, los POs deben considerar un Sprint o parte de éste dedicado a la integración, pruebas y refactoring entre ambos equipos.

• Dificultades para asegurar la calidad y generar los entregables de acuerdo a CMMi-L3. Desde un principio contamos con un miembro del equipo que podía fungir como “especialista técnico” (su puesto oficial es Tech Lead o TL, pero NO es el líder del equipo; tampoco tiene el rol de Scrum Master). Dicha persona colabora de forma muy estrecha con el TO para implementar adecuadamente la arquitectura definida por aquél, así como reforzar una correcta ejecución de desarrollo guiado por pruebas (TDD) e integración continua. En resumen: un TL no puede confiar en un software que no tenga un set de pruebas cuantificables que puedan ejecutarse con sólo pulsar un botón. Por otro lado, contamos con un par de Business Analysts (BA) encargados de verificar una correcta transferencia de conocimiento entre el cliente y el resto del equipo. Ya que esta transferencia está muy relacionada a la documentación requerida por CMMi, ellos son también los encargados de apoyar en esta tarea, liberando a los desarrolladores de cargas innecesarias.

• Scrum distribuido. Esta modalidad del proceso es una historia aparte, pero baste decir que en un par de células, algunos miembros del equipo pertenecen a offshore. Es decir, por un lado tenemos al Scrum Master, el tech lead, un desarrollador y un analista de negocio trabajando hombro con hombro con el cliente, mientras el resto del equipo – el tester, tres desarrolladores y otro business analyst – colabora desde literalmente, el otro lado del mundo. Desde un punto de vista táctico, el principal reto es la comunicación, confianza y respeto mutuo, así como diferencias culturales. En cuanto a estrategia de negocios, este modelo rebaja muchísimo los costos, pero también refleja una pequeña pero perceptible disminución en la productividad – en nuestra experiencia, a menos que todo el equipo este co-locado o ya se hayan resuelto diferencias culturales, los tiempos de ejecución se incrementarán hasta en un 25% debido precisamente, al overhead de comunicación.

Conclusiones

Cualquier adopción ágil y su correspondiente implementación tendrán retos a enfrentar, principalmente en las áreas de interdependencia entre equipos, manejo de recursos remotos y alineación del cliente. Sin embargo, si obtenemos el patrocinio sincero de high management – o como en nuestro caso, es una directiva que viene del cuartel general y debe adoptarse por todas sus subsidiarias alrededor del mundo – nuestros problemas serán mucho menores, limitándose a temas de madurez y alineación de procesos.

¿Dónde nos encontramos parados después de todo este ejercicio? Bastante bien, ya que después de diez meses, hemos trabajado de forma casi ininterrumpida, e incluso tenemos la oportunidad de expandir nuestras operaciones a otras unidades de negocio. Si todo sale bien, en un par de meses estaremos haciendo un copy + paste del proceso de adopción e implementación, aunque en esta ocasión, tendremos que enfrentar un área en la que personalmente no me siento tan fuerte: e-commerce.

h1

Implementando Scrum: un caso de la vida real (Parte 2)

07/14/2013

Wizdoc [Icon By Buuf]  Tips & Tricks.

La suerte no es un factor. La esperanza no es una estrategia. El miedo no es una opción.

James Cameron (n. 1954), director, guionista, productor de cine y explorador marino canadiense.

En el post pasado mostré un ejemplo de la vida real, con algunos de los tropiezos con los que podemos toparnos durante una implementación de Scrum. En resumidas cuentas, el usuario es nuevo en el paradigma ágil y por la premura de cerrar el contrato, a nosotros nos falló conseguir al personal adecuado, así como capacitarlos correctamente en las mejores prácticas de desarrollo ágil. Sin embargo, esto sólo es la punta del iceberg, ya que durante las siguientes iteraciones y para los demás equipos, tendremos que incluir una serie de medidas de control para asegurar la efectividad y eficiencia del proceso, así como de la calidad de los entregables.

Uno de los requerimientos más importantes para el cliente es una elevada productividad por cada Sprint, así que nos decidimos por un esquema de “trabajo especializado en paralelo”:

Tiempo (día) Planeación Análisis Diseño y Codificación Pruebas Despliegue
Planeación del Sprint
1 Recolectar reqs. del backlog        
2 Transf. de conocimiento de analistas hacia resto del equipo

Atomización de reqs. en tareas

Reunión de Sprint planning

     
3        
Ejecución del Sprint
4 – 13   Análisis para crear/insertar nuevos reqs. en backlog (siguiente Sprint) Diseño Ágil

Codificación

Pruebas Unitarias

Pruebas Funcionales

 
Cierre del Sprint
14         Reunión de Sprint review
15 Retro.        

Ciclo de “especialización en paralelo” con Scrum. Nótese cómo mientras una parte del equipo se enfoca a desarrollar los entregables del Sprint actual, otra parte (dos analistas) se dedica a realizar el análisis de requerimientos del siguiente Sprint.

Este modelo de tres semanas con análisis en T+1 es posible ya que cada célula incluye dos analistas de sistemas. Ciertamente esto contradice el paradigma ágil, ya que en teoría, todos los integrantes del equipo deben ser milusos o como dicen nuestros vecinos del norte, jack of all trades. Sin embargo, la misma figura literaria también dice: jack of all trades, master of none o lo que es lo mismo: quien mucho abarca, poco aprieta. Es decir, en algunas ocasiones es recomendable tener gente especializada en la célula que nos ayude a maximizar la eficiencia del equipo, pues por citar un ejemplo, un desarrollador promedio puede conocer PL/SQL y obtener buenos resultados, pero un DBA experimentado, “creará magia”.

Cabe recalcar que este esquema resultó exitoso en cuatro células pero falló catastróficamente en una de ellas. La manera más objetiva de demostrarlo es a través de números fríos: mientras la célula más productiva ha generado 819 story points durante las últimas 13 semanas, la peor ha generado tan sólo 130 que aun así, están siendo impugnados por el cliente. Esta falta de productividad fue achacada inicialmente a una falta de seguimiento en el proceso Scrum, sin embargo en términos generales, dicho proceso fue seguido al pie de la letra; el problema derivó en no implementar correctamente la construcción de los entregables. Este proceso, separado de Scrum, es conocido como el ciclo de vida de desarrollo de software (Software Development Life Cycle o SDLC).

El desarrollo de software se compone de dos procesos

Cualquier proyecto de desarrollo de software está compuesto por dos familias de procesos fuertemente ligados que atacan aspectos muy diferentes del proyecto:

• El proceso de gestión de proyectos, que de acuerdo al Project Management Body of Knowledge (PMBOK), se compone por diez áreas de conocimiento: integración, alcance, tiempo, costos, calidad, recursos humanos, comunicación, riesgo, adquisición y stakeholders.

• El proceso de desarrollo de software o SDLC, enfocado a la entrega del producto y conformado por las disciplinas ya conocidas por todos: análisis de requerimientos, diseño, construcción, pruebas, despliegue, mantenimiento y gestión de la configuración.

El problema es que los neófitos en el paradigma ágil creen que cualquier metodología define ambos procesos, algo que es tan FALSO como que el PMBOK nos indique cómo implementar un plan de pruebas. Scrum está enfocado al proceso de gestión de proyectos, dejando que el equipo decida cómo implementar a nivel operativo sus desarrollos; por el contrario, metodologías como Extreme Programming (XP) se enfocan de lleno a la ingeniería de software y por ende, a la entrega y calidad del producto. Es así como una de las metodologías híbridas más utilizadas en la industria es la mancuerna Scrum/XP, ya que ésta permite una combinación ganadora:

↑ Prácticas de gestión de proyectos Gestión de Costos Gestión de adquisiciones Gestión del tiempo

Sprint

*40 Hrs./Semana

Gestión de RRHH

Scrum master

*Propiedad colectiva del código

*Cliente on-site

*Coach, no PM

  Alcance y reqs.

Product Owner

Product Backlog

*Juego de planeación

*Cliente on-site

*Historias

Gestión de la comunicación

Scrum diario

Reunión de Sprint planning

Reunión de Sprint review

*Cliente on-site

*Historias

Gestión de la integración

Sprint

Reunión de Sprint planning

Sprint backlog

*Juego de planeación

*Liberaciones cortas

Gestión del riesgo

Reunión de Sprint planning

Reunión de Sprint review

Scrum diario

*Juego de planeación

*Liberaciones cortas

*Programación orientada a pruebas

*Cliente on-site

↓ Prácticas de desarrollo de software Diseño de software

*Metáforas

*Diseño simple

Construcción de software

*Programación por pares

*Refactoring

*Propiedad colectiva del código

*Estándares de codificación

Gestión de la configuración

Build diario

*Integración continua

Gestión de la calidad

Reunión de Sprint review

*Programación orientada a pruebas

*Refactoring

*Cliente on-site

*Estándares de codificación


Combinación de metodologías de gestión de proyectos y desarrollo de software. En este caso, Scrum y Extreme Programming. Nota: las prácticas con (*) pertenecen a XP. (Fuente: just-another-blog-for-kicks @ blogspot.com)

Esta combinación incluye controles entre las disciplinas de gestión de proyectos y desarrollo de software, dejando fuera sólo la gestión de adquisición y costos, que podrían ser llevadas a cabo de forma adecuada por una Oficina de Proyectos o PMO. Como opinión personal, este ejercicio debería ayudarnos a entender que Scrum por sí solo no resolverá nuestros problemas, ya que no hay soluciones técnicas para problemas de gestión, pero puede haber soluciones administradas para problemas técnicos. Por ello la necesidad de complementarlo con mejores prácticas de otras metodologías o frameworks enfocados al nivel operativo.

Asegurando que todos hacen lo que dicen que hacen

Es así como hemos decidido verificar el seguimiento de estas prácticas a través de un checklist aplicado por un experto en la materia (Subject Matter Expert o SME) en colaboración con el resto del equipo, incluyendo el líder técnico (TL), los analistas (BA), los desarrolladores (DEV), el tester (TE) y el Scrum master (SCM):

Fase Punto de revisión Responsable Evidencia Resultado
Análisis Documentación elaborada por analistas está completada al 100% y están de acuerdo al objetivo de las historias de usuario seleccionadas para el presente Sprint. BA/TL Documento
Análisis La documentación aprobada está publicada, distribuida y disponible para todos los miembros del equipo. BA/ TL/ SCM TFS/ Sharepoint
Diseño Modelo de persistencia y modelo conceptual cumplen con alguno de los tres enfoques ORM: esquema primero, modelo primero, código primero. TL TFS/RSA
Diseño La arquitectura ya ha sido definida y comprendida por todo el equipo: cliente-servidor, N-capas, SOA. TL TFS/RSA
Construcción Los estándares de código han sido aplicados a todo artefacto de software construido de acuerdo a la filosofía de codificación adoptada. TL TFS/RSA
Construcción El ambiente de desarrollo está correctamente instalado y configurado en las instalaciones del cliente y si aplica, en las laptops de los desarrolladores. TL Ambiente verificado
Pruebas Unit tests para cada artefacto de software. TE/DEV Artefactos de software
Pruebas Matriz de pruebas actualizada con todos los casos y escenarios de prueba. TE Documento
Despliegue Obtener la documentación con los procedimientos de instalación y configuración de los entregables de software en los ambientes de QA, PERF y PROD TL Documento
Despliegue Verificar que existan procedimientos de gestión de cambios para los ambientes de QA, PERF y PROD. TL Documento

Lista de verificación para mejores prácticas del SDLC ágil.

Este es sólo un ejemplo, ya que dependiendo de la madurez del equipo o empresa que está implementando el proyecto, la lista puede tener más de 150 controles. De momento, nosotros no requerimos tantos (sólo 50-60 dependiendo de la tecnología usada), pero nuestra área de SQA ya nos adelantó la noticia que dentro de 6-8 meses certificaremos la cuenta en CMMI-5. Por ello, muy probablemente, acabaremos con una lista muy extensa, comprobada no sólo por nuestros SMEs, sino también por SQAs calificados o los appraisers que otorgan la certificación CMMI.

Conclusiones

El SDLC es el proceso que empleamos para desarrollar nuestros entregables. Y sin importar la metodología que ocupemos, si nuestro SDLC es inmaduro o deficiente, estamos en serios problemas. Sin embargo, NO existe un proceso único que pueda ser implementado por todos; incluso, debería ser lo suficientemente flexible como para cambiarlo de acuerdo a las necesidades de negocio o conforme va creciendo el alcance de nuestro proyecto. La situación es que siempre es necesario tener un proceso formal y comprendido por todos los involucrados, que pueda seguirse de forma sustentable. La alternativa es trabajar de forma desorganizada, o confiar ciegamente en que el equipo sabe lo que hace. Así que, nuestra mejor opción al adoptar ágil, consiste en adherirse al proceso de gestión, definir un SDLC formal, y hasta que estemos seguros que ambos procesos sean llevados a cabo de forma natural y repetible, es necesario introducir medidas de control para asegurarnos que todo funciona correctamente.

h1

Implementando Scrum: un caso de la vida real (Parte 1)

07/05/2013

Wizdoc [Icon By Buuf]  Tips & Tricks.

El éxito no es definitivo; el fracaso no es fatal: lo que cuenta es el coraje para continuar.

Winston Churchill (1874-1965), político y estadista británico.

Ahora que ya tenemos un par de meses implementando Scrum con un cliente relativamente inexperto en esta metodología, nos hemos llevado un par de chascos que seguramente pueden ocurrir en cualquier implementación donde no exista una definición concreta de expectativas, cuáles son sus procesos y artefactos, o aquellos que ejecutan el desarrollo no cuentan con los skills necesarios.

Pero empecemos por el principio: de entre cinco células ágiles, un equipo de desarrollo en Java “falló espectacularmente” de acuerdo al cliente. Esto provocó alerta entre nuestro “high management”, ya que el incidente puso en duda nuestra capacidad para trabajar con Scrum así como para generar los entregables de alta calidad que nos fueron solicitados. Aunque al principio esto se achacó a falta de conocimiento en los procesos ágiles, elaboramos un RCA en el que encontramos la verdadera causa del problema:

• Primero, el cliente se acercó a nuestra empresa solicitando células de desarrollo ágil. Inicialmente, pidió dos de “altísima urgencia”, advirtiéndonos que si no se conformaban e iniciaban los trabajos inmediatamente, encomendaría el proyecto a alguien más. Esto claramente fue para presionarnos, pues hasta la fecha, NO existe otro proveedor que esté ofreciendo este tipo de servicio a nuestro cliente.

• Luego, lo que el cliente solicitó fueron “células en Java y .Net”. Ni más ni menos. El requerimiento no incluyó un conjunto de tecnologías o perfiles específicos, ni en qué tipo de proyecto se estaría trabajando. Esto, aunado a la presión por iniciar de inmediato, significó que nuestra área de reclutamiento se limitó a buscar candidatos genéricos: “Hola, soy de la empresa X. ¿Sabes Java o .Net? ¿Sí? Te espero mañana para firma de contrato.” En el equipo .Net tuvimos muchísima suerte de contar con un desarrollador que ya conocía el tipo de arquitectura a implementar (Model-View-View-Model). En el equipo Java no tuvimos tanta suerte, pues el proyecto no sólo consistía en conocer el core del lenguaje, sino también en dominar una variada multitud de frameworks, herramientas y tecnologías como Spring, Hibernate, Websphere, JPA, JAX-WS o JSF.

Toy Stories: Noel (Texas, USA) ~ Gabriele Galimberti


Stack Tecnológico del equipo original. Como puede apreciarse en la tabla, las habilidades prácticas de las personas tendían a medio o bajo – sólo 16% de la experiencia podía ser considerada como “alta”. Sin un liderazgo técnico adecuado, el equipo estaba condenado desde un principio. (Dar click en imagen o aquí para ver a mayor escala)

• Dos semanas después de iniciado el delivery nos dimos cuenta que los skills requeridos eran muy especializados, ya que el proyecto se trata de implementar un SOA con todo y web services, flujos de trabajo, validaciones de negocio y colaboración constante con otros proveedores. Es decir, aparte de no contar con las habilidades necesarias para realizar su tarea, la gente tampoco tenía el “colmillo” para defenderse ante los demás proveedores o el mismo cliente, pues a la primera oportunidad, culparon de cualquier retraso a nuestro equipo.

• Después de otro par de semanas, tuvimos que cambiar de líder técnico y Scrum Master. ¿La razón? No supieron hacer “click” con el responsable del lado del cliente o Product Owner (PO), quien además de ser una persona bastante difícil de tratar, también tiene altos skills técnicos y funcionales – el típico “YO lo haría en dos horas. ¿Por qué TÚ vas a tardar un día en hacerlo?” Esto acentuó los problemas con el equipo, quienes presenciaban constantes discusiones a nivel técnico y administrativo con este personaje, además que se desmoralizaron al ver cómo sus líderes dejaban el proyecto con las piernas por delante.

• En la iteración tres ocurrió el desastre. Teniendo que entregar cuatro web services, el líder técnico cometió el error de “entrar al ruedo”, programando uno de éstos, pero desatendiendo el avance de los desarrolladores. Por otro lado, el Scrum Master no tomó suficiente ownership del equipo, pues cuando preguntaba “¿Cómo vas?” todos respondían “Bien”, sin que éste indagara más al respecto. Lo triste del asunto es que en realidad no iban nada bien – de hecho, algunos jamás probaron su código. Este exceso de confianza hacia los desarrolladores significó el principio del fin, ya que como cereza del pastel, nuestro tester jamás hizo las pruebas correspondientes sobre el código “terminado”.

• Durante la demostración al final del Sprint, todo reventó en nuestras manos: algunos desarrolladores sólo probaron en sus laptops; otros jamás probaron en absoluto. Sin embargo, nadie probó en el ambiente del cliente, así que durante la revisión de la demo, nada funcionó. El cliente, enfurecido, nos dijo que a partir de ese momento, su propia gente desarrollaría estos web services. Por lo pronto, esta célula estaba cancelada.

Y es así como hemos estado la última semana y media tratando de “salvar el honor”, pues aunque sabemos que el cliente ya está desarrollando los componentes por su cuenta, nosotros tenemos que entregar algo funcional para solicitar el pago por estas semanas de trabajo. A raíz de este incidente, hemos podido generar un plan de acción con el afán de que esto no se vuelva a repetir en el resto de las células, incluyendo controles para asegurar la efectividad de todos nosotros:

• Desde un inicio, contar con los recursos adecuados. Ahora, en las células nuevas, primero se presenta un líder técnico que “mide las aguas” para obtener el stack tecnológico y los perfiles requeridos. Posteriormente, dicho líder debe estar presente durante el proceso de reclutamiento, ya que la mejor manera de asegurar un buen recurso es contestando afirmativamente la pregunta: “si esta persona va a estar bajo mi responsabilidad, ¿me conviene traerlo a bordo?”

• Por otro lado, es necesario mejorar el liderazgo, pues no se ha dado una comunicación efectiva entre en líder técnico y el Scrum Master, además de que ha faltado ownership por parte de ambos. Básicamente, evitar la práctica de estarse pasando el mono.

• El cliente tiene un conocimiento muy bajo en metodologías ágiles. Es decir, ellos sólo recibieron el curso de dos días para convertirse en Scrum Master. Por ello, es necesario crear un par de workshops: el primero dirigido hacia los POs para que conozcan cuál es la verdadera función de un Product Owner y cuáles son las expectativas y entregables que deben estar manejando con el resto del equipo; el segundo debe estar dirigido hacia los ejecutivos del cliente (gerentes y directores) para que se den cuenta que ágil no es la “bala de plata”, al mismo tiempo que mostramos cuáles son las métricas con las que nos deberían estar midiendo, pues algunos entregables que nos están solicitando como “reportes de horas” y “cartas de aceptación” son algunos esquemas de control que se contraponen a la ideología de ágil.

• Finalmente, darnos cuenta que este problema no se debió a falta de conocimiento en ágil, sino a temas más pedestres como poco ownership, un líder técnico que quiso ser héroe, exceso de confianza entre el Scrum Master, el líder y el equipo así como poca experiencia por parte del equipo, puntualmente en el proceso de desarrollo de software (SDLC), y sus disciplinas más importantes, como integración continua, refactoring y pruebas de concepto. De hecho, el cliente mismo mencionó que el problema no era Scrum, sino los skills, actitud y experiencia de la gente. Después de todo, código entregado sin haber sido probado es un tema preocupante que no tiene que ver con conocimiento en (o la falta de) Scrum. Por ello estamos reforzando el proceso SDLC a través de dos expertos, uno en Java y uno en .Net, quienes asegurarán el correcto seguimiento de las prácticas de desarrollo ágil a través de las herramientas y procesos más adecuados.

De momento, sólo hemos visto un pequeño ejemplo de lo que puede pasar durante una implementación de ágil en un ambiente inmaduro. En el próximo post veremos que Scrum “de la vida real” no sólo consiste en leer los papeles de Ken Schwaber y esperar lo mejor: la realidad es que es necesario contar con el apoyo de una buena gestión de proyectos, un governance bien estructurado y hasta que no estemos seguros que el proceso está siendo seguido por todos los involucrados, deben existir algunos puntos de control para asegurar que todo marcha sobre ruedas.

h1

Sobre Agil y “Radical Management”

11/01/2012

Wizdoc [Icon By Buuf]  Tips & Tricks.

Sólo hay una definición válida para un objetivo de negocios: crear un nuevo cliente.

Peter Drucker (1909 – 2005), consultor de gestión, educador y autor Austriaco-Estadounidense.

Desde hace tiempo muchas organizaciones han buscado adoptar del paradigma ágil (Scrum, XP, Lean, Kanban) con el afán de mejorar la tasa de éxito en sus proyectos de desarrollo de software y a final de cuentas, mejorar las ganancias de la compañía. Sin embargo, en un contexto más general, ¿qué pasaría si los mismos principios que rigen estas metodologías se adoptaran no sólo al desarrollo de software, sino que formaran parte de la actitud predominante dentro de la compañía? Es interesante ver los resultados de este modelo organizacional en la práctica:

Stock Quotes: Salesforce, Cisco, Amazon, Apple and General Electric


Mientras ciertas empresas han “sobrevivido” con márgenes mínimos durante los últimos 4 años, otras han crecido enormemente. En la gráfica, el crecimiento accionario de Salesforce (púrpura: CRM), Amazon (amarillo, AMZN), Apple (rojo, AAPL), Cisco Systems (azul rey: CSCO) y General Electric (azul obscuro, GE). (Fuente: Google Finance)

¿Qué permite que empresas como Salesforce, Amazon o Apple logren un crecimiento de hasta 600% en 4 años mientras organizaciones como Cisco Systems y General Electric apenas se mantienen a flote? La respuesta es que están aplicando ágil a toda la empresa: no sólo al desarrollo de software, un producto, bien o servicio. Estas empresas basan su operación diaria en una nueva cultura organizacional denominada Gestión Radical; sus principios se enumeran a continuación:

• Deleitar a los clientes. En vez de decirle al cliente esto es lo que tenemos: tómalo o déjalo, la compañía se enfoca en ser vista como un solucionador de problemas o socio de negocios: entendemos tus problemas y te sorprenderemos resolviéndolos.

• Equipos auto-organizados. Dejar de lado el modelo de comando y control, donde el gerente o líder funge como capataz, asignando tareas y haciendo “marcación personal” a los miembros del equipo. Ahora, éste se vuelve un facilitador, eliminando obstáculos que impiden a sus subalternos hacer su trabajo.

• Coordinación dinámica. En vez de seguir procesos llenos de reglas, reportes y burocracia, el trabajo es iterativo; los objetivos de cada ciclo se basan en lo que más deleita al cliente; las decisiones sobre cómo debería hacerse el trabajo se delegan al equipo que directamente realizará la labor y el progreso es medido en base a la retroalimentación directa del cliente.

• De valor a valores. Es decir, cambiar de un enfoque meramente económico y de maximización de eficiencia hacia uno donde se inculquen valores como innovación y crecimiento sostenible.

• Conversación. Un cambio en la comunicación, tradicionalmente top-down, compuesta por órdenes jerárquicas en un solo sentido, hacia conversaciones maduras que solucionan problemas y generan nuevas ideas.

En realidad este concepto no es nuevo y tampoco es radical: sólo que muchas organizaciones han adoptado estos principios de forma aislada o local, e incluso algunas veces han echado estos principios por la borda, obteniendo pobres resultados: Google, que es reconocida como una de las empresas más innovadoras del mundo, ha metido la pata de vez en cuando; al obsesionarse con el éxito de Facebook, incursionó en las redes sociales con su Google+. Sobra decir, todo terminó en un enorme fiasco. Oponiéndose al principio de deleitar a los clientes, Google incluyó ideas propias que no gustaron a los usuarios (esto es lo que tenemos, tómalo o déjalo). A final de cuentas, a todos nos encanta el motor de búsqueda, pero pocos realmente queremos migrar a Google+.

Una crisis global… y quienes salen mejor parados

De acuerdo al estudio The Shift Index publicado por la consultora Deloitte, la mayoría de las empresas Estadounidenses – y por ende, del resto del mundo desarrollado – están viendo una disminución gradual en su desempeño desde 1965. La principal causa de este problema es el uso continuo de modelos de gestión empresarial completamente obsoletos, así como el hecho de que las tecnologías emergentes (internet, redes sociales, aplicaciones en “la nube”) le han dado suficiente empowerment al cliente como para “botar” un mal proveedor y encontrar rápidamente otro, incluso si éste se encuentra del otro lado del mundo.

Según el mismo estudio, las empresas que deseen mejorar sus prospectos a futuro tendrán que reinventarse a sí mismas, cambiando el enfoque basado en el jefe dentro de la compañía como centro del universo, hacia un modelo donde la organización y sus trabajadores se encuentren gravitando alrededor de las necesidades del cliente. De hecho, Michael Hugos, director del Centro para Innovación en Sistemas (c4si), comenta:

La profesión de TI está en un punto de inflexión: un grupo de profesionales de TI ha aprendido que ágil es el camino a seguir, pero los practicantes más tradicionales todavía lo consideran radical. Sin embargo, los tradicionalistas siguen aplicando las mismas viejas formas de hacer las cosas que dan lugar a los mismos proyectos terriblemente caros, multianuales, que producen sistemas apenas mejores de lo que había antes, si es que llegan a funcionar del todo. Cada vez más ejecutivos están llegando a la conclusión de que el apoyo efectivo a la agilidad del negocio es la razón principal de que su empresa cuente con un grupo interno de TI.

Five Reasons Why CIOs Should Consider Agile Development. Ryan Martens. (Rally’s AgileBlog, 2010).

Así que en realidad ágil ha pasado de ser algo “exclusivamente de los desarrolladores” a un modelo que debería ser adoptado por el resto de la organización.

Y un poco más cerca de casa

Y todo este análisis viene de un simple hecho: la compañía en la que estoy trabajando está poco a poco cortando el cordón umbilical con Estados Unidos – de hecho por eso no he posteado artículos estas últimas semanas. Ya que los mercados Norteamericano y Mexicano tienen necesidades diferentes (allá todo se trata de eficiencia, aquí es la seguridad), estamos buscando pasar de ser meramente reactivos y “tropicalizar y vender lo que hicieron los gringos” a innovar y crear cosas de forma local. Y desde el punto de vista económico no es difícil, pues sí hay plata, pero nos falta reorganizarnos para escuchar las necesidades del cliente y salir a resolver sus necesidades, en vez de ofrecer productos que se venden bien, pero cada vez tienen menos ingresos.

Aunque todavía nos falta mucho por hacer, ya estamos trabajando para incrementar la colaboración entre las diferentes áreas de la compañía y mejorar el proceso de “liberación de producto”, desde que se genera una necesidad, pasa por el área de desarrollo (tanto de hardware como software), hasta que la solución se etiqueta y libera comercialmente. ¿Todo va sobre ruedas? No del todo: viejas formas de pensar, procesos legados y ciertamente, la posibilidad de que no se dé un apoyo completo e incondicional por parte de “top management” pueden descarrilar la iniciativa. Así que… veremos si pasamos a ser un poco más ágiles e independientes como empresa o nos aplican un doloroso bitchslap.