miércoles, abril 22, 2015

¿Y por qué dudamos de la auto-organización de los equipos?

Hola a todos

Hay algo que he notado que es recurrente cuando he dictado entrenamientos o charlas sobre Scrum y es en específico el rol del TEAM /DEVELOPER TEAM / EQUIPO DE DESARROLLO / EL EQUIPO, la primera pregunta que surge por alguno de los presentes es:

¿y cómo logran que se vuelvan auto-organizados?

Es como si dudáramos de nuestra capacidad de

  • jugar en equipo
  • jugar fútbol, baloncesto, rugby, voleibol
  • armar un paseo
  • realizar un asado
  • preparar entre varios una cena
  • jugar un juego de mesa
  • entre otros.


Pero para ser franco, yo siento esa pregunta hecha desde el temor, desde la desconfianza, desde un lugar de la memoria o experiencia  donde a alguien (incluso el mism@ que lanzó la pregunta) que le encomendaron algo no lo entregó a tiempo y para acabar de ajustar todos se dieron cuenta que despilfarro el tiempo en otras cosas sin importancia que no le aportaban al objetivo.

Yo comprendo esos temores - he estado allí - , y es por eso que tal vez:

  • nos aferramos al comando-control, 
  • asignamos tareas
  • asignamos filas de Gantt (hechas en ms project) a diestra y siniestra
  • ponemos "recursos" (que en realidad son personas, y trabajadores del conocimiento), 
  • les imponemos un tiempo calculado por un experto (que no fueron ellos)
  • hacemos micro-seguimiento, o micro-gestión cada ciertas hroas
  • y si se demoran más les decimos que deben pagar o/y mirar como reponer el tiempo.
La verdad tiene sentido, nos han fallado, hemos fallado y nos dominan los temores, y esos temores nos llevan al lado oscuro [1] - como diría Yoda - (al de comando-control - ver más)


Pero Scrum tiene herramientas que enganchan, empoderan y comprometen al equipo:

  • un objetivo de construir cosas listas (Done) a corto plazo.
  • Un planning que establece compromisos
  • El review que verifica si se logró el compromiso o se quedó en deuda  -(ver más en :  La cara del santo hace el milagro. Efectividad del Planning y Review - )
  • la retrospectiva que con su inspección y adaptación nos lleva hacia nuevos retos, y nos saca de zonas cómodas.
  • y el Scrum Master, que es el agente de cambio que esta cuestionando, ayudando a que el Equipo Scrum ( Product Owner, Team Members, y Scrum Master) salga de su zona de confort

Yo veo Scrum, como un buen juego de equipo, como el fútbol que establece:

  • Cancha, roles, y arbitro //unas cuantas reglas claras ( 3 roles, 4 reuniones, 3 artefactos,  ver más),
  • personas que se divierten jugando // un equipo que se trabaja motivado
  • una táctica para ganar // un tablero kanban y un burndown que muestran lo que tenemos que hacer en un ciclo corto de tiempo y si podemos o no lograr la meta.
  • el deseo de meter gol //un objetivo común y claro "generar el mayor valor en el cliente con la menor cantidad de software posible, en el periodo más corto de tiempo"

Observo en los equipos de desarrollo y en especial de scrum la capacidad innata a auto-organizarse. y dudar de eso, es dudar del niño interior que llevamos dentro, de nuestra capacidad de inventar de poco a poco, de ir mirando como dentro de las reglas establecidas todos nos vamos adaptando, de como podemos jugar mejor sin romper las reglas y meter la mayor cantidad de goles/puntos/aciertos/historias de usuario posibles en un periodo de tiempo.

Es dudar de nuestra voluntad de querer hacer un muy buen el trabajo, de querer dar resultado en equipo, es dudar de la capacidad humana y tribal de relacionarse, trabajar juntos y de querer avanzar en conjunto.

Y si alguien no quiere jugar bien

Creo que todos en diferentes circunstancias cuando alguien no juega correctamente en equipo

  • en el partido de futbol/baloncesto/voleibol el equipo llama la atención del que no está conectado
  • en el asado si alguien solo esta allí para ser servido y no colabora "ni siqueira" a recoger, le llaman la atención o no lo siguen invitando
  • la tía regañona que daña el paseo o la cena juntos deja de ser invitada.

Los equipos al verse empoderados, cuestionan a los miembros que no ayudan en el objetivo común, y poco a poco los equipos van encontrando su forma, número, miembros,  modo, identidad y estilo; y es trabajo del scrum master lanzar las preguntas para que el equipo se conecte, reflexione, inspeccione, adapte y avance.

Cerrando

A mi modo de ver dudar de la auto-organización es dudar de nuestra naturaleza humana.

Cierro con esta frase :"La auto-organización no es una opción en Scrum; es un principio básico. Sin ella  nunca tendremos equipos de alta performance [2]




¿Ustedes que piensan? Queda abierta la discusión

Saludos Ágiles

Jorge Abad


----------
Otra lectura recomendada de este blog: Cualquiera puede ser ágil / Cualquier equipo puede ser ágil


--

[1] "El miedo es el camino al Lado Oscuro.
El miedo lleva a la ira.
La ira lleva al odio.
El odio lleva al sufrimiento.
El sufrimiento al Lado Oscuro.
Cuidado con el miedo, joven padawan." - Maestro Yoda

[2] Hundermark, Peter (traducido por Cyment, Alan) . Un mejor Scrum  -  http://www.scrumsense.com/wp-content/uploads/2012/03/Un-mejor-Scrum-2.pdf

martes, abril 14, 2015

Radioactividad de los requisitos - La necesidad de un enfoque ágil en la industria del desarrollo de software

Hola a todos

Hace poco recordé una lectura que había hecho sobre los requisitos, y hablaban que la vida media de ellos se había reducido con el tiempo (olvide la referencia en foro ágiles me dieron la ayuda - clic aquí - ) y notaba que estos se había convertido en radioactivos, o sea, estaban perdiendo valor en el tiempo.

La cita corresponde al artículo "Software Development: How the Traditional Contract Model Increases the Risk of Failure" de Susan Atkinson y Gabrielle Benefield - se los recomiendo -, el texto es el siguiente:

 "Recent studies, led by Al Goerner at the University of Missouri, Kansas City, demonstrate that the inherent value in Output-Based Requirements erodes exponentially over time. This rate of decay has been likened to the half-life of an unstable radioactive atom. The 'half-life' is the measure of the period of time it takes for the substance undergoing decay to decrease by half.

According to the studies carried out by the University of Missouri, the half-life of the value of the Output-Based Requirements has been rapidly decreasing. In 1980 this was around 10-12 years, by 2000 it had fallen to 2-3 years, and it is currently running at about 6 months.7

In other words, half of the Output-Based Requirements will become obsolete by the end of month 6, half of the remaining half (i.e. 1/4) will become obsolete by the end of month 12, half of the remaining quarter (i.e. 1/8) will become obsolete by the end of month 18, and so on. Hence, by the end of month 18, according to the University of Missouri studies, only 1/8 (i.e. 12.5%) of the Output-Based Requirements will still possess any inherent value."

---Inicio traducción --

"Estudios recientes  -2013 cuando se escribió el artículo - liderados or Al Goerner de la Universidad de Missouri, Kansas City, han demostrado que el valor inherente de los (sistemas) basados en requisitos se degradan exponencialmente con el tiempo. Esta tasa de degradación se ha comparado a la vida media de un átomo radioactivo inestable. La "vida media" es la medida del periodo de tiempo que toma una una sustancia en descomponerse la mitad.

De acuerdo con los estudios realizados por la Universidad de Missouri, la vida media del valor de los requisitos ha ido disminuyendo rápidamente. En 1980 esta fue de alrededor de 10 a 12 años, en el 2000 había caído a 2 a 3 años, y actualmente está funcionando a alrededor del 6 meses.

En otras palabras, la mitad de los requisitos quedará obsoleto antes de fin del mes 6, la mitad de la mitad restante (es decir 1/4) se convertirá en obsoleto antes de fin de mes 12, la mitad de la cuarta parte restante (es decir, 1 / 8) se convertirá en obsoleto antes de fin de mes 18, y así sucesivamente. Por lo tanto, antes del fin de mes 18, de acuerdo con la Universidad de Missouri, sólo 1/8 (es decir, el 12,5%) de los requisitos aún poseerán un valor intrínseco."

--- Fin traducción ---


Acaso no hemos escuchado de nuestros clientes frases como:

  • es lo que especifique y firmé pero: 
    • lo pensé y eso no era lo que quería decir.
    • ya no lo necesito de esa forma
    • el negocio ha cambiado
O peor, 

¿a quienes no les ha pasado que levantan los requisitos de alguien y por alguna razón interrumpen el proceso y vuelven en dos meses a iniciar y estos son completamente diferentes?


Un enfoque tradicional bajo este escenario esta destinado al fracaso, si por ejemplo, levantamos especificaciones durante 6 meses al  mes 7 cuando ya comencemos a desarrollar, lo que se levantó inicialmente algunos de los requisitos comenzarán a ser obsoletos.

Es necesario :
  • un enfoque ágil,
  • de entregas frecuentes (ojalá cada dos semanas)
  • centradas en el valor de negocio
  • que habiliten el feedback del cliente
  • que apoyen los negocios cambiantes y su estrategia
Es necesario en software adoptar metodologías ágiles, muchos en la industria lo están haciendo

¿cuando te decidirás a dar el paso?

---

Una última pregunta ¿cual es la vida media de los requisitos en tu entorno de software?


Saludos ágiles

Jorge Abad

domingo, marzo 29, 2015

Trabajo sobre gestión ágil - Alumnos Pregrado Sistemas - Eafit 2015- sem 01

Hola a todos

Mis alumnos de pregrado  hhhbbbbnngrado grado do de Gestión de proyectos informáticos tienen la mitad del semestre una entrega sobre gestión ágil y otra sobre gestión tradicional.

Les comparto los dos trabajos sobre gestión ágil que resaltaron este semestre:

Los trabajos tienen:


  • Visión
  • Product Vision Board
  • Product Backlog Board
  • User Story Map
  • Plan de Releases
  • Costo del producto por releases
  • Historias de usuario
  • Simulación de Scrum empleando Mockups / Bocetos / Scketches
    • Gráficas de Velocidad, y burndown
Estos son los links



Espero los disfruten y les ayude en sus proyectos.

Saludos Ágiles

Jorge Abad

lunes, marzo 23, 2015

Cómo se ve un User Story Map (mapa de historias de usuario)

Tomado de: http://winnipegagilist.blogspot.no/2012/03/how-to-create-user-story-map.html?goback=.gde_117832_member_162001454


¿Cuáles son los vicios que los más poderosos aborrecen?

Les comparto el resultado de una investigación sobre cuales son los hábitos que no gustan entre los poderosos   en el ambiente laboral y al crecimiento profesional


Esta es:


  • Deshonestidad
    •  las personas que viven una vida honesta pueden relacionarse con los demás armónicamente y en paz
  • Desinterés
    • las personas triunfadoras viven la mayor parte del tiempo explorando, innovando y creando. La vida es muy corta para desperdiciarla en la monotonía y la simplicidad.
  • Mediocridad
    •  la característica de los emprendedores es ser capaces de superar las propias debilidades. Un líder debe desarrollar todo su potencial en momentos de adversidades.
  • Desorganización
    •  el desorden causa estrés y afecta la salud emocional de las personas. La mejor forma de optimizar recursos y tiempo es tener todas las cosas en el momento y en los lugares precisos.
  • Malos hábitos alimenticios
    • las personas que no mantienen una alimentación saludable, que tiene muchos conflictos interpersonales y que no cuidan su salud son incapaces de orientar a otras personas.
  • Irrespeto
    •  las relaciones sociales cordiales son necesarias para alcanzar el éxito. Las personas que respetan a sus semejantes reciben lo mismo y se convierten en modelos a seguir.
  • Ingratitud
    • el desagradecimiento dificulta la construcción de sólidas relaciones de amistad y compañerismo.
  • Desconfianza
    • as personas que no confían en los demás ocultan su inseguridad. La construcción de los intercambios sociales depende del desarrollo de la integridad y autovaloración de cada ser.
  • Ira (agresividad)
    • en momentos de furia y agresividad, los seres humanos bloquean su racionalidad y terminan tomando pésimas decisiones.
  • Pesimismo
    • aquellos que viven desilusionados y llenos de desesperanza ven problemas en momentos que se necesitan soluciones rápidas y efectivas.

20 grandes frases de trabajo en equipo

Tomado de: http://www.soyentrepreneur.com/27200-20-grandes-frases-de-trabajo-en-equipo.html




El trabajo en equipo es clave para que una organización tenga éxito y sobreviva con el tiempo. Por eso te compartimos 20 citas inspiradoras que te servirán para impulsar esta forma de trabajar en tu empresa:
1. “El talento gana partidos, pero el trabajo en equipo y la inteligencia ganan campeonatos” Michael Jordan.
2. “Yo hago lo que tú no puedes, y tú haces lo que yo no puedo. Juntos podemos hacer grandes cosas” Madre Teresa de Calcuta.
3. “Trabajar en equipo divide el trabajo y multiplica los resultados” Anónimo.
4. “No preguntes qué puede hacer por ti el equipo. Pregunta qué puedes hacer tú por él” "Magic" Johnson.
5. “Son tres las cosas que le diría a un equipo para ayudarlo a mantenerse unido: Cuando algo resulta mal: yo lo hice. Cuando algo resulta más o menos bien: nosotros lo hicimos. Cuando algo resulta realmente bien: ustedes lo hicieron” Paul “Bear” Bryant.
6. “Los individuos marcan goles, pero los equipos ganan partidos” Zig Ziglar.
7. “La unidad es la variedad, y la variedad en la unidad es la ley suprema del universo” Isaac Newton.
8. “Las fortalezas están en nuestras diferencias, no en nuestras similitudes” Stephen Covey.
9. “No hay problema que no podamos resolver juntos, y muy pocos que podamos resolver por nosotros mismos” Lyndon Johnson.
10. “Los logros de una organización son los resultados del esfuerzo combinado de cada individuo” Vince Lombardi.
11. “Llegar juntos es el principio. Mantenerse juntos, es el progreso. Trabajar juntos es el éxito” Henry Ford.
12. “Puedes diseñar y crear, y construir el lugar más maravilloso del mundo, pero se necesita gente para hacer el sueño realidad” Walt Disney.
13. “Ninguno de nosotros es tan bueno como todos nosotros juntos” Ray Kroc.
14. “Si quieres ir rápido, ve solo. Si quieres llegar lejos, ve acompañado” Proverbio africano.
15. “Si estamos juntos no hay nada imposible. Si estamos divididos todo fallará” Winston Churchill.
16. “Los cinco dedos separados son cinco unidades independientes. Ciérralos y el puño multiplica la fuerza. Ésta es la organización” James Cash Penney.
17. “Lo más hermoso del trabajo en equipo es que siempre tienes a otros de tu lado” Margaret Carty.
18. “No des a tus empleados por sentado. Si no valoras a tu equipo, ellos no valorarán a tus clientes” Richard Branson.
19. "Solos podemos hacer muy poco; unidos podemos hacer mucho" Hellen Keller.
20. “El espíritu de equipo es lo que da a muchas empresas una ventaja sobre sus competidores” George Clements.

Unas gráficas interesantes de Google Trends sobre Agile

Hola a todos


Realizando una presentación sobre Metodologías Ágiles, decidí realizar unos comparativos entre varios términos en Google Trends, los resultados son interesantes.

Quedan en sus manos las conclusiones.

Saludos ágiles
Jorge Abad


---------------------------
Términos:
  • Agile Software Development
  • CMMi


URL de búsqueda : Clic aquí

---------------------------
Términos:
  • Scrum
  • CMMi + Capability Maturity Model Integration


URL de búsqueda : Clic aquí


---------------------------
Términos:
  • Scrum
  • CMMi + Capability Maturity Model Integration
  • RUP + Rational Unified Process

URL de búsqueda : Clic aquí

---------------------------
Términos:
  • Scrum
  • CMMi + Capability Maturity Model Integration
  • waterfall model + waterfall development
  • Agile software development
  • RUP + Rational Unified Process



URL de búsqueda : Clic aquí

---------------------------
Términos:
  • Agile software development
  • PMP + Project Manager Professional + Project Management Institute
  • CMMi + Capability Maturity Model Integration
  • Scrum






URL de búsqueda : Clic aquí

---------------------------
Términos:
  • User story + user stories
  • Use cases + use cases


URL de búsqueda : Clic aquí

---------------------------
Términos:
  • casos de uso + caso de uso
  • historias de usuario + historia de usuario


URL de búsqueda : Clic aquí

Única Nota: 
Se podría concluir que los hispano-hablantes aún no nos hemos interesado mucho por las historias de usuario