Equipos de Alto Desempeño

Del manual: "Introducción a la Gerencia de Procesos" de Carlos Pittaluga, me llamó la atención el resumen de lo que entiende por equipos de alto desempeño:

Las competencias críticas de un equipo de alto desempeño que se destacan como prominentes son las siguientes:

• Sentido de propósito: visión compartida de futuro, rumbo y camino común. Dirección estratégica comprendida, compartida y apoyada por todos los integrantes del equipo.
• Comunicación abierta: posibilidad de expresar de modo franco los sentimientos y opiniones propias. Derecho a opinar, a disentir y a cambiar de opinión.
• Confianza y respeto mutuo: cada quien es tomado como una persona que piensa y siente, con sus propias peculiaridades. Cada quien es estimado por su valor como persona. Existe membresía e identificación por el orgullo de compartir con los compañeros de equipo.
• Liderazgo compartido: hay apoyo mutuo. Las decisiones son tomadas por consenso. El liderazgo rota según el principio la mejor persona para cada situación.
• Procedimientos eficaces de trabajo: los procesos de trabajo son sencillos, las tareas que cada uno ejecuta son complejas. El equipo tiene la oportunidad de mejorar continuamente. 
• Construir sobre las diferencias: la diversidad (de posiciones e ideas) se usa como herramienta para crear. Todos los miembros del equipo están dispuestos a tomar en cuenta las ideas del otro y aprender de ellas, si es el caso.
• Flexibilidad y capacidad de adaptación: los procesos se retan continuamente. Se considera que siempre hay una mejor manera de hacer las cosas. Hay disposición al cambio y muy alta capacidad de respuesta. 
• Aprendizaje continuo: se consagra el derecho de errar (errores inevitables) y aprender de ello. Hay tiempo para pensar, y eso se valora. Existe disposición y habilidad para indagar sistemática y continuamente. La experiencia nueva se comparte. Existe memoria tecnológica.

Consideraciones antes de hacer la Definición de Listo

A la hora de definir cuando algo está listo o "hecho" (DoD =definition of done) siempre debemos tomar en cuenta que cada lista de cosas por hacer es diferente de proyecto en proyecto, el equipo humano tampoco es el mismo en todo los proyectos y las circunstancias que rodean al proyecto igualmente son variables. Por lo tanto no existe una Definición de Listo exactamente igual para todos los proyectos.

Hay que dejar claro también que pueden existir varias DoD en un proyecto: la DoD de una funcionalidad, la DoD de un Sprint, etc. En este caso nos enfocaremos solamente en la DoD de una funcionalidad, como parte del cumplimiento de un set de requerimientos de un usuario.

Algunas cosas que debemos tomar en cuenta antes de establecer la Definición de Listo son las siguientes:

1. El nivel de detalle de los requerimientos levantados:

¿Están las historias de usuarios (H.U) bien definidas?. En otros post hablaremos de como establecer el criterio de "bien definidas". Lo importante a resaltar aquí es que la precisión de los criterios de aceptación, las asunciones y las conclusiones finales nos pueden indicar un criterio bien razonable para en conjunto llegar a una Definición de Listo adecuada al proyecto.

Es bueno recordar que los criterios de aceptación por si solos no indican la Definición de Listo de una funcionalidad o H.U.

2. El equipo de proyecto del proveedor.

El equipo humano es vital para establecer una clara Definición de Listo, lo que nos lleva a hacernos la siguiente pregunta ¿En que momento del proyecto tenemos una Definición de Listo correcta? Básicamente va a depender, en parte, de cuan bien se conozcan los actores involucrados en términos de desempeño. Alguna de las razones que llevan a esta conclusión son las siguientes:

2.1 Nivel de compromiso del product owner y su equipo

El nivel de compromiso "verdadero", no el profesado, se conoce cuando se está en pleno en el proceso de desarrollo e implementación de las funcionalidades de software. Esto hace que cualquier Definición de Listo que dependa de los niveles de respuesta del product owner y su equipo debe suponer el mas alto nivel de compromiso con el proyecto, para luego poder evaluar bien las brechas entre lo exigido y lo recibido por parte de dicho equipo.

Ahora bien, ¿que sucede si la brecha entre lo Recibido vs lo Esperado es negativa y no se puede cerrar? Evidentemente habrá razones de peso para justificar esto, pero no deja de ser un escenario viable sobre todo en un proyecto de ERP (enterprise resource planning system) en el cual la operación de la empresa se lleva en paralelo con el desarrollo e implementación de las funcionalidades, y muchas veces toca estar en la empresa cuando hay situaciones tales como: cierre fiscal anual, corte trimestral de inventario, rotación de personal, cierre de línea de negocio, entre otras.

En conclusión, en el caso que los niveles de compromiso esperados resultasen mucho mayor a los que realmente demuestra el cliente, cualquier Definición de Listo que se haya realizado debe revisarse en pro de la salud económica del proyecto.

3. Infraestructura de hardware

El acuerdo que defina cual va a ser la plataforma de Testing y Producción, y como va a funcionar la misma, es otro aspecto importante en cuanto a la Definición de Listo de funcionalidades de software.

Muchas veces se comienzan proyectos (y se terminan) sin que el despliegue de los servidores de producción tenga fecha fija de ejecución, por lo que todas las funcionalidades desarrolladas quedan implementadas en un entorno de Testing o pre-producción, que en teoría debería ser una de las etapas intermedias del despliegue de la funcionalidad, pero en este caso termina siendo la final.

Por lo tanto el iniciar un proyecto de desarrollo /implementación de software a la par de un proceso de procura, instalación o puesta a punto de servidores de producción debe tomar muy en cuenta la Definición de Listo de una forma muy precisa en cuanto a lo que se tenga HOY en día como infraestructura, y no con lo que se va a tener a futuro cercano, mediano o lejano. Recordando que del cumplimiento de "Listo" depende el cierre técnico/administrativo de la funcionalidad, no puede éste estar atado a retrasos de despliegue de infraestructura no estipulados en el proyecto.

4. La DoD no es un Checklist inexpugnable

Aún cuando logre definirse una lista de actividades para una DoD tomando en cuenta la variabilidad comentada en las secciones anteriores, hay que tener presente que una misma DoD muchas veces no aplica igual para todas las funcionalidades. La definición natural de "Listo" tiene ciertas limitaciones si lo vemos como un cheklist obligatorio para todas las funcionalidades que se desarrollen. El equipo de desarrollo debe estar consciente de ello y entender que algunas actividades deben ser aplicadas para cumplir el checklist y otras no, dependiendo de lo que se este implementando.

Día de la Innovación 2014 - Evento

Bibliografía Ágil (Parte I)

De la Comunidad de Práctica Ágil del PMI extraigo un interesante resumen de títulos de bibliográficos divididos por áreas de interés. Todos están en inglés, dado las características lingüisticas de la comunidad. Sin embargo queda pendiente el post de la bibliografía en español.

 1. Project Planning:

• Software by numbers: Low Risk, High Return Development
• Agile Estimating and Planning
• User Stories Applied: For Agile Software Development
• Beyond Software Architecture: Creating and Sustaining Winning Solutions 
• Innovation Games: Creating Breakthrough Products Through Collaborative Play
• The Mythical Man Month: Essays on Software Engineering
• The IT Payoff: Measuring of Business Value of Information Technology Investments
• Outside in Software Development: A Practical Approach to Building Successful Stakeholders-based

2. Agile Project Management:

•  Manage It!: Your Guide to Modern Pragmatic Project Management
• The Software Project MAnagement Bridge To Agility
• Making Things Happen: Mastering PRoject Management

3.  Organizational Change:

• Agile Adoption Patterns: A Roadmap to Organizational Success 
• Make Success Measurable!: A Mindbook - Workbook for Setting Goals and Taking Actions
• Organizational Patterns of Agile Software Developments

4. Productivity:

• Getting Thins Done: The Art of the Stress Free Productivity
• The 7 Habits of High Effective People (Disponible en Español también)
• Slack: Getting Past Bornout, Busywork and the Myth of Total Efficiency 

En una próxima entrega seguiré mostrando títulos por otras áreas de interés, tales como: Team Building, Quality Assurance and Control, Development, entre otros.

---

Slds

Metodología Ágil: ¿Una moda?

El auge que ha tenido el termino “ágil” dentro de la industria del desarrollo del software y la intención de heredar mucho de sus modelos en la concepción y gestión de los proyectos “no tecnológicos” ha introducido un debate entre los líderes y gerentes de proyectos en sí las metodologías ágiles son o no una nueva manera de hacer las cosas y si en realidad hecha por la borda toda la teoría tradicional de gerencia de proyectos que se ha madurado en estos últimos años.

Quisiera enfocarme en el primer punto relacionado a ¿que tan nuevo es esta manía de ser ágiles?, y rescatar algunos eventos y datos importantes que ya han venido sucediendo desde hace tiempo.

Si se hace una investigación no muy extensa, se puede encontrar que mas allá del año 2001 el término Ágil, como pensamiento o metodología de hacer las cosas, no era muy utilizado. Es casualmente en este año que alrededor de 70 auto denominados “anarquistas organizacionales” realizan el lanzamiento de El Manifiesto Ágil, nacido de un movimiento que comenzó a gestarse desde el año 2000 en Utah y que proponía en ese momento en vez del termino Ágil (o Agile en Inglés) el termino “Light”, en relación a las metodologías o procesos “ligeros” de desarrollo que este grupo de gente venía manejando con anterioridad: Extreme Programming, Adaptative Software Development, Crystal y SCRUM.

Pero investigando un poco mas a fondo podemos llegar a encontrar raíces de estas metodologías “ligeras” o “ágiles” por allá por mediados de los 80 en Japón. Por ejemplo en 1986 un señor llamado Ikujiro Nonaka et al. publica en la Harvard Business Review algo llamado “The New New Product Development Game” ó el nuevo juego de desarrollo de nuevos productos; un nuevo enfoque para gestionar el desarrollo de nuevos productos en la industria manufacturera, especialmente en la automotríz. El señor Nonaka es considerado el abuelo de SCRUM ya que su invención dio la inspiración para que Jeff Sutherland idease SCRUM posteriormente en 1993 para desarrollos de software!!. Para aquellos que quieran leer mas, vean el propio blog de Jeff y las reseñas obvias y reconocimiento que él mismo hace al señor Nonaka.


Igualmente Ikuhiro Nonaka y Hirotaka Takeuchi a mediados de los '90 crean el modelo SECI como propuesta de proceso de creación del conocimiento, para entender la naturaleza dinámica de la creación del conocimiento, lo cual para muchos representa el inicio de la concepción del modelo de aprendizaje cíclico del pensamiento ágil tal cual se aplica hoy en día.

Por tanto vemos que ya a partir de 1990 comienza a madurarze el concepto de desarrollos ágiles dentro de la industria del software y ya para la firma de El Manifiesto en 2001 existen publicaciones importantes relacionadas con el tema:

Planning Extreme Programming, Kent Beck and Martin Fowler, Addison-Wesley Professional, 2000.

Extreme Programming Installed, Ron Jeffries, Ann Anderson, and Chet Hendrickson, Addison-Wesley Professional, 2000.

Agile Software Development with Scrum, Ken Schwaber and Mike Beedle, Prentice Hall, 2001.

Luego desde 2001 comienza el gran movimiento de conocimiento, impulsado entre otros por publicaciones importantes tales como:

User Stories Applied, Mike Cohn, Addison-Wesley Professional, 2004.
Agile Software Development Principles, Patterns, and Practices, Robert C. Martin, Prentice Hall, 2002.

Test Driven Development: A Practical Guide, David Astels, Prentice Hall Ptr, 2003.

Agile & Iterative Software Development A Manager's Guide, Craig Larman, Addison-Wesley, 2004.

Concluyendo; desde hace mas de 20 años se vienen gestando una serie de conocimientos que apuntan a la mejora de los procesos de desarrollo de nuevos productos y software, y desde hace 10 años se ha dado un vuelco importante a la manera de desarrollar y manejar proyectos de desarrollo de software basado en dichos enfoques. Para el día de hoy existen muchas empresas con años de experiencia y casos de éxitos demostrado en implementaciones ágiles, existen cientos de consultores con importantes horas de proyectos ágiles sobre sus hombros y existe toda una plataforma comunicacional (libros, foros, eventos, blogs, canales, certificaciones) que avalan que esto que se ha llamado “ágil” no es sólo una etiqueta de moda si no por el contrario una corriente de conocimientos que hoy en día quiere extenderse a otras áreas de proyectos, impulsando el gran debate.

Bienvenida

El concepto de este blog es crear un espacio de discusión en Español de temas relacionados con la gestión de proyectos empleando las practicas ágiles. La razón: una ausencia significativa de esta información en nuestro idioma en la internet.

Me parece ideal inaugurar este blog con la razón de ser de las practicas ágiles; El Manifiesto Ágil, escrito hace 10 años exactamente por un grupo de desarrolladores, líderes de proyecto, especialistas, entre otros y que ha dado pie a un sin fin de análisis, prácticas, teorías, mejoras y que hoy en día sigue siendo un tema que evoluciona de acuerdo al conocimiento generado día a día por quienes lo ejercitan.

Les dejo pues El Manifiesto Ágil, para aquellos que no lo conocen aún y para aquellos que siempre les gusta leerlo:

Seguimos estos principios:

Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.

Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al
cliente.

Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.

Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.

Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.

El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.

El software funcionando es la medida principal de progreso.

Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.

La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.

La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.

A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.