Leído y Recomendado: No termines tus retrospectivas con un plan de acción

Hola a todos

Hace poco leí un excelente post de Hiroshi Hiromoto, un gran coach ágil de Perú.

En el invita a terminar las retrospectivas con propuestas de experimentos, que luego se validarán si fueron efectivos o no, (obvio orientados al a mejora continua)

Este es el post: No termines tus retrospectivas con un plan de acción

Se los recomiendo, es de colección.

Saludos ágiles

Jorge Abad

Una actividad/juego de sensibilización sobre los resultados de la ejecución tradicional (cascada o RUP) en proyectos de software

El JUEGO DE LA MUESTRA ESTADÍSTICA

Hola a todos

Muchas veces antes de dictar un entrenamiento o una charla sobre metodologías ágiles realizo la siguiente actividad  (la aprendí de mi colega Leonardo Agudelo - https://twitter.com/sweepnoise )

1. Trazo una linea divisoria imaginaria, o con cita de enmascarar 
2. Pongo a todo el grupo a un lado de la línea
3. Comienzo a realizar las siguientes preguntas e invito a los que las van cumpliendo pasen al otro lado de la línea
4. y así voy avanzando hasta que veo que es suficiente

La fuerza de la actividad radica en las preguntas y en que todos perciban lo mal o bien que les esta yendo haciendo la ejecución actual de proyectos (adicionalmente que no son los únicos que padecen los problemas de su día a día)

Estas son algunas de las que uso:

Nota: Resaltaré las preguntas que más me han sorprendido.

----

• Categoría: Roles
• Objetivo: Saber con quienes comparto la charla o entrenamiento
• Preguntas
• ¿quiénes son gerentes de proyecto?
• ¿quiénes son comerciales?
• ¿quiénes son desarrolladores?
• ¿quiénes son testers?
• etc

--

• Categoría: Tiempo
• Objetivo: Sensibilizar que la ejecución tradicional (cascada, Rup, o cualquier variación) no es precisa en cuanto al tiempo 
• Preguntas
• ¿quiénes han estado en un proyecto que se ha demorado el cuadruple de lo planeado?
• ¿quienes el triple?
• ¿quienes el doble? 
• ¿quienes han trabajado en un proyecto seguido sábados y domingos incansablemente por más de un año? -(lamentablemente los hay)
• ¿8 meses?
• ¿6 meses?
• ¿4 meses?
• ¿2 meses?
• ¿1 mes?

--

• Categoría: Costo
• Objetivo: Sensibilizar que la ejecución tradicional los costos no son predecibles
• Preguntas
• ¿quiénes han estado en un proyecto que ha costado el cuadruple de lo planeado?
• ¿quienes el triple?
• ¿quienes el doble? 

--

• Categoría: Alcance / Requisitos 
• Objetivo: mostrar que las especificaciones firmadas no son garantía éxito.
• Preguntas
• ¿quienes han estado en un proyecto donde a pesar de haber construido lo que hay en las especificaciones, el cliente afirma "ok, es lo de las especificaciones pero eso no es lo que yo quería"?
• ¿Quienes han estado en un proyecto donde los controles de cambio cuestan mas que el proyecto original?
• ¿a quienes el cliente les ha dicho?
• ¿yo se que yo firmé eso, pero eso no es lo que yo necesito?
• ¿es que esa funcionalidad aun no esta clara y no se como va funcionar?

--

• Categoría: Éxito de los proyectos tradicionales
• Objetivo: Sennsibilizar sobre lo dificil que es ser éxitoso en tiempo, costo, alcance y calidad en un proyecto tradicional
• Preguntas
• ¿quiénes han estado en un proyecto exitoso en tiempo, costo, alcance y calidad? (se sorprenderán.. muy pocos) 

--

• Categoría: Estimaciones
• Objetivo: Mostrar que tan acertadas son las estimaciones en proyectos de software son imprecisas, debido a la incertidumbre.
• Preguntas
• ¿quienes se han equivocado en una estimación el 8 veces, ejemplo dijeron 1 día y se demoraron 8?  -(lamentablemente los hay)
• ¿6 veces?
• ¿4 veces?
• ¿2 veces?

(será que no sabemos en que estamos trabajando)

--

• Categoría: Desgaste del equipo y de la vida personal
• Objetivo: Mostrar la forma en que hemos desgastado nuestras vidas y la de los equipos de trabajo forzando el éxito a toda costa
• Preguntas
• ¿a quienes su familia, novio, novia, esposo, esposa, hijos, hermanos madre, les ha dado un ultimatum...¡o renuncias o no vuelves a saber de nosotros! (aca el resultado ha sido doloroso, algunos comparten que les ha costado el divorcio, o situaciones similares)
• ¿quienes han trabajando seguido mas de ?
• 36 horas
• 24 horas
• 16 horas

--

• Categoría: los riesgos
• Objetivo: Evidenciar los riesgosos que son los proyectos de desarrollo de software
• Preguntas
• ¿ a quienes se les ha dañado una entrega teniéndola completamente lista?

--

• Categoría: Desperdicio /se construye lo que no se usa
• Objetivo: Mostrar cuanto software es desperdicio (la estadística muestra que del 100%, solo el 50% es usado, de ese 50%, el 20% con frecuencia y el 30 rara vez - Chaos Manifesto 2013)
• ¿quienes consideran que el 100% del software que hacen es usado por el cliente?
• ¿el 90?
• ¿el 80?
• ¿el 70?
• ¿el 60?
• ¿el 50?
• ¿quienes consideran que construyen documentación que nunca será usada?
• ¿quienes han estado en un proyecto que no salió a producción?
• ¿quienes han estado en un proyecto que saló a producción pero nadie usa?
• ¿quienes han estado en un proyecto donde dicen, la documentación que se hizo no sirve, volvamosla a construir?

y así.. sucesivamente

Si tienen más preguntas para la actividad, que bueno sería las compartieran...

Como se pueden dar cuenta no son los únicos que viven estos males.

Hagan la actividad y compartan la experiencia en este post, se llevarán sorpresas muy interesantes.

Saludos ágiles

Jorge Abad

Cualquiera puede ser ágil / Cualquier equipo puede ser ágil

Unas preguntas comunes cuando dicto un entrenamiento, es

• ¿y un equipo de seniors puede ser ágil? -  dado sus resabios
• ¿y un equipo de juniors puede ser ágil? -  dado su inexperiencia

Y lo que generalmente contesto es:

"si funcionamos en un esquema de gestión tradicional que es tan desgastante y orientado al fracaso, con seguridad lo haremos en ágil, se requiere de acompañamiento, pero se logra" 

Y es que pienso que  "Cualquiera puede ser ágil", o mejor "Cualquier equipo puede ser ágil", similar a la frase del Chef Gusteau en Ratatouille: "Cualquiera puede cocinar"

No lo niego, soy humanista:

• creo en la gente, 
• creo en que todos podemos y queremos lograr grandes cosas, 
• creo que podemos aprender a trabajar en equipo y lograr excelentes resultados

Es cierto soy Scrum Master y mi enfoque en las personas no puedo ocultarlo, es inherente a quienes vibramos con este rol de Scrum, y quienes queremos que las cosas mejoren.

Pues como lo expresa uno de los los principios ágiles -

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

Es por tanto, necesario el entorno, apoyo y confianza para que emerja la agilidad.

Bien lo dice Lucho Salazar en su post " “No puedes guiar el viento, pero puedes cambiar la dirección de tus velas”:  "Lo bueno de Ágil es que no tenemos que ser súperdotados para practicarlo ni para ser exitosos. Es más una cuestión de disciplina, de ganas, un deseo inacabable de ser feliz (o de volver a serlo) en el trabajo y de juntarse con las personas adecuadas"

(Siguiendo con la reflexión) Similar a como lo expresa Anton Ego en su discurso final en Ratatouille (1) pienso que un equipo ágil puede venir de cualquier parte, un gran equipo ágil pienso que es más difícil, pero con que sean un buen equipo, con seguridad estarán darán grandes resultados (mucho mejores que los ofrecidos por el mando-control de la gestión tradicional).

Acaso

• ¿que persona no quiere sentirse exitosa en su trabajo?
• ¿que equipo no quiere dar resultados?

Y eso es lo que nos da un entorno ágil, un lugar para aprender, fallar, corregir camino, y lograr grandes resultados, mientras trabajamos motivados y felices.

Saludos ágiles
Jorge Abad.

Referencias

(1) Frase de Anton Ego : <<Antes de este suceso, nunca escondí mi desdén por el lema del Chef Gusteau: “cualquiera puede cocinar”. Pero, me doy cuenta, recién ahora comprendo sus palabras. No cualquiera puede convertirse en un gran artista, pero un gran artista sí puede provenir de cualquier lugar.>>

Consideraciones y Aclaraciones Importantes

 Jurgen Apelo en Management 3.0

"The Agile Blind Spot 

I believe a “weakness”of the Agile Manifesto is that it doesn’t (explicitly) recognize that all software projects need people being smart, disciplined, and attentive. The “people over process”paradigm is great, until you find out that your team consists of two trolls, a parrot, and a hairdresser, and a relatively bright project manager, who happens to be deaf, blind, and mute. No amount of coaching can help a team like that to magically self-organize and to deliver a successful product. I call this the Agile “blind spot.”Agile (as promoted by the manifesto) is great only when the team is great (or at least good enough). To be fair, the need for great teams is probably even twice as important in non-agile environments,but the Agile Manifesto too leaves competence issue unresolved."  

Ken Schwaber

“En Scrum, un grupo en el que se lleven mal entre ellos, no comprendan el negocio del cliente y trabajen con malas herramientas... también producirán incrementos periódicos... de basura. ”

Ejemplo de historia de usuario : Ingreso al sistema

Hola a todos

A continuación presento un ejemplo de historia de usuario, bastante general (aplica para el 99.99% de los casos y sistemas) que puede ayudar a comprender mejor la escritura de las mismas:

-----------------------------------------------------------------------------------------------

HU: 20 -  Ingreso al sistema

Yo como Usuario 

Deseo ingresar al sistema

Para poder hacer uso de las funcionalidades del sistema

--- Criterios de aceptación -----

Criterios de Aceptación 1: Ingreso exitoso

• Cuando el ingreso del usuario y contraseña son correctos

• Entonces el sistema permitirá el ingreso al sistema

Criterios de Aceptación 2: Ingreso fallido

• Cuando el ingreso del usuario y contraseña son incorrectos

• Entonces el sistema NO permitirá el ingreso 

• Y el sistema presentará una alerta con el siguiente mensaje:  “Usuario y/o contraseña no válido, por favor recuerde que tiene 4 intentos para ingresar al sistema, luego de esto su usuario será bloqueado.”

Criterios de Aceptación 3: Último ingreso fallido

• Cuando el ingreso del usuario y contraseña son incorrectos

• Entonces el sistema NO permitirá el ingreso 

• Y el sistema presentará una alerta  con el siguiente mensaje: “Su usuario se encuentra bloqueado, favor contacte al administrador del sistema, o al teléfono xxxxxxxx  para que sean reestablecidos los accesos al sistema.”

Criterios de Aceptación 4: Ingreso a una url o página no autorizada

• Cuando el usuario intente ingresar a una URL o pantalla en la que no tenga permiso 

• Entonces el sistema no permitirá el ingreso a la dirección o pantalla solicitada

• Y no permitirá ninguna operación 

• Y el sistema direccionará a la pantalla de ingreso 

Criterios de Aceptación 5: Sesión expirada

• Cuando la sesión haya expirado  

• Entonces el sistema no permitirá ninguna operación

• Y el sistema direccionará a la pantalla de login

Nota: 

Se deberá configurar en el sistema el tiempo máximo de sesión para el usuario. XXXXX

Criterios de Aceptación 6: Falta uno o más campos obligatorios

• Dado que no se ingrese en el formulario alguno de los datos obligatorios. (marcados con * )

• Cuando el usuario oprima el botón “Ingresar” 

• Entonces el sistema no permitirá el ingreso al sistema

• Y aparecerá el mensaje :“Por favor ingrese los campos obligatorios (*) faltantes :

[Presentar el listado de campos faltantes]“

----------

Este puede ser el mockup /scketch/boceto resultado de esta historia

Ejemplo: Una historia de usuario - Listado de Morosos

Hola a todos

Les comparto una historia de usuario, generalmente es una de las que uso durante los cursos de scrum

Por lo general queda puntuada en 5 puntos, tomando como pivote 1 día feliz o productivo, es decir, se toma por lo general 5 días en lograr la Definition Of Done en la tecnología que cada quien maneja.

----

La transcribo para quienes la necesiten

Historia de usuario - Listado de morosos

YO COMO gerente de sucursal

DESEO el listado de morosos

PARA saber a quien comenzar a cobrar

---Criterios de aceptación

- El listado contendrá los campos

      -  Nombres

      -  Apellidos

      -  Cédula

      -  dias de mora

      -  monto

      -  tipo de préstamo

 - El listado debe estar ordenado x días de mora descendente

 - Quienes tengan mora

      -  mayor a180 dias en color rojo

      -  60-179 color amarillo

      -  color negro

 - Exportable a Excel 2010

 - Paginado por cada 20 registros

 - Accede solo el Gerente de sucursal

 - En la parte superior de reporte debe aparecer la fecha de corte (fecha en que se genera)

Leído y Recomendado : Agile no es para vos

Un excelente post: http://agilecoaching.com.ar/agile-no-es-para-vos/

Agile no es para todo el mundo, tomo por aca algunas razones:

1. Los requerimientos del negocio son estáticos
2. No estás dispuesto a cambiar tu mentalidad y preferís seguir trabajando de la misma forma que antes
3. Como manager pensás que las personas son recursos
4. Como desarrollador pensás que tu trabajo es codificar las especificaciones de requerimientos
5. Como tester pensás que es tu trabajo solamente es escribir y ejecutar pruebas
6. No tenés feedback ni contacto por parte del cliente (o Product Owner) periódicamente
7. Pensás que es mejor trabajar individualmente que en equipo
8. Creés que no es necesario seguir buenas prácticas de ingeniería
9. Tu Scrum Master no tiene habilidades blandas desarrolladas
10. No te gusta trabajar directamente con gente
11. Las decisiones que tomás son para apagar incendios en vez de una solución a largo plazo
12. Opinás que es mejor cumplir el contrato que escuchar al cliente
13. Suponés que la automatización es una pérdida de tiempo
14. Pensás que no es necesario mantener un balance entre personas, procesos y herramientas
15. Considerás que podés ser ágil sin tener un código saludable y de calidad
16. No aceptás la crítica constructiva del feedback
17. Querés adoptar agile sin mejorar la moral del equipo
18. Como manager no sabés qué es (o no te importa) la deuda técnica
19. Dependés de los demás para que te digan qué hacer
20. Sos indispensable en tu equipo

¿Por qué adoptar metodologías ágiles?

(Nota al inicio: Para escribir este artículo trate de seguir el estilo de varias referencias (1) (2) y fracasé, por lo tanto lo haré con mi estilo, espero les guste)

Antes de adentrarnos en porqué pasarnos a metodologías agiles, comencemos haciendo varias aclaraciones.

Haciendo las correspondientes excepciones:

·         Existen proyectos tradicionales (implementados con Cascada, RUP, o WaterRUP -  como le dice mi amigo Lucho Salazar - ) ejecutados de forma magistral y exitosa

·         Y Existe productos y proyectos desarrollados empleando metodologías ágiles que son que son un fracaso

Pero bajo este escenario también es importante  definir éxito,  a la luz de la experiencia  como:

·         Se  cumplieron las expectativas de tiempo, alcance, costo y calidad

·         Se produjo el producto correcto y de valor para la compañía

·         El equipo no se sobreesforzó para lograr este objetivo (no se puede llamar ÉXITO a sobreesfozar – reventar- al equipo de trabajo)

Con estas bases comparto varias reflexiones por las cuales pasarse a utilizar metodologías ágiles:

·         En términos generales

o   Se ha fallado suficiente con las metodologías tradicionales  y no tiene sentido insistir en algo que está desgastando a la industria, teniendo a Clientes, Proveedores, Gerentes de Proyecto, Desarrolladores, Tester y demás en una carrera de las ratas en los que todos salen perdiendo.

o   Se ha trasnochado lo suficiente generando insatisfacciones en toda la cadena

o   Se ha generado demasiada documentación que luego nadie vuelve sobre ella o más aún cuando se lee todos dicen  “esto no sirve” hay que volverlo hacer

o   No hay transparencia entre cliente- proveedor y entre ambos se dicen mentiras respecto a avances y progresos

·         Respecto al alcance

o   Se han ha construido demasiado software que hay que volverlo a hacer debido a que

§  Ya no sirve (se demoraron demasiado tiempo en construirlo)

§  No fue bien construido

§  Fue bien construido pero eso no era lo que se quería

o   Se ha perdido suficiente dinero y tiempo en cosas funcionalidades que no agregan valor (reportes que nadie usará, funcionalidades que se construyen porque están especificadas pero nadie les ve sentido, entre otros)

·         Respecto al tiempo

o   Los tiempos no se cumplen (ver la explicación en la parte de riesgos)

o   Hay una creencia férrea en los cronogramas pero nos damos cuenta que estos no sirven y que las cosas van mal cuando nos incumplen

o   Los cronogramas son mentirosos, pues muchas veces nos demoramos el finalizando el 10% restante otro 90% de tiempo (o sea que el proyecto demoro 90% hasta el 90% del cronograma y otro 90% tratando de cerrarlo, en total 180% aproximadamente)

o   Las ideas pierden su valor porqué nos demoramos demasiado en implementarlas, miremos:

§  2 en aprobación del proyecto de líder funcional que se le ocurrió

§  6 meses levantando las especificaciones

§  1 mes negociando con el proveedor

§  12 meses construyendo el software (habíamos jurado que duraba 6 pero realmente fue el doble con retrasos y controles de cambio)

§  Mínimo 21 meses desde el momento inicial y la salida a producción generando pérdida de valor de la idea y con seguridad oportunidades de negocio.

·         Respecto al costos

o   Muchos proyectos no son financieramente un  gana-gana para cliente proveedor

o   Muchas veces creer que contratos a valor cerrado controlan los riesgos a veces

§  Terminamos contratando a otro proveedor para que arregle lo que “otro hizo mal”

§  Terminamos pagando más en controles de cambio que en el costo original

o   La mayoría de veces el costo del proyecto lo asume el proveedor.

·         Respecto a los riesgos

o   Los riesgos saltan y saltan por doquier

§  Entregas tardías de información que recitábamos

§  Componentes que supuesta funcionaban ya no funcionan

§  Alguien se enferma

§  Alguien se vá

§  El servidor no lo entregaron a tiempo

§  Etc, etc.

Todo nos atrasa, pero el cronograma sigue avanzando por más que hayamos querido plasmar holguras para afrontar esos riesgos, el cronograma se termina desfasando en proporciones no esperadas.

·         Respecto a la calidad

o   Postergamos la calidad para fases finales y terminamos haciendo trasnochar al equipo de pruebas

o   Entregamos productos sin calidad y permitimos que se vayan así a producción

o   Permitimos que el tiempo de desarrollo se absorba el tiempo de pruebas

o   La fuerza bruta en calidad (aumentar los testers) no mejora la calidad del proyecto

Como lo he expresado antes estamos resolviendo el problema de forma incorrecta.(Causas del "MANEJO" o dícese de "LA FALTA DE TRANSPARENCIA") 

Las metodologías ágiles o marcos de trabajo ágil como Scrum (aclaro “bien ejecutados”) logran:

1.       Liberación más rápida de producto (más rápido time to market)  (1)

Debido a:

·         Enfoque en liberaciones rápidas y de calidad en periodos de 2 semanas a un mes (para SCRUM)

2.       Retorno de inversión (ROI) más rápido (1) (3)

Debido a:

·         Enfoque en liberar lo antes posible funcionalidades y mostrar valor con software funcionando se logra mas rápido retorno de inversión lo que supera con creces a los 21 meses explicados en los párrafos superiores.

3.       Más rápida retroalimentación del cliente.  (1)

Debido a:

·         La entrega de un producto más rápido lo que permite evolucionar el software con más certeza.

4.       Construcción del producto correcto, debido al feedback de cliente.  (1)

Debido a:

·         Similar al punto anterior, el feedbak se vuelve esencial para construir el producto correcto

·         Enfocarse en las funcionalidades de valor al negocio evita que se construya el producto incorrecto.

5.       Temprana reducción del riesgo (1) (3) – aclaro, no es que no existan riesgos -

Debido a:

·         Los ciclos cortos, la constante comunicación y feedback, el enfoque en la calidad, y la constante implantación de mejoras en el proceso (fruto de las retrospectivas) permite que los riesgos sean gestionados de una forma más eficiente y proactiva.

6.       Mayor calidad (2)

Debido a:

·         El enfoque a la excelencia técnica

·         Las prácticas ágiles de desarrollo

·         Y la Definición de Terminado (Defitinion of Done)

Logran que el equipo se enfoque en incluir cada sprint o ciclo la calidad y no postergarlo para fases finales.

7.       Mejor cultura y moral del equipo (1) (2)

Debido a:

·         Continuo feedback del cliente

·         Ciclos de mejora dados por las retrospectivas

·         Victorias tempranas y cíclicas

Logran que la moral del equipo se mantenga alta y motivada para producir productos grandiosos.

8.       Satisfacción del cliente (1)

 Debido a:

·         La entrega continua de producto con valor

·         El constante feedback a la equipo sobre el producto

·         El avance visto como software funcionando

Mejoran la satisfacción del cliente.

9.       Mayor calidad (2)

Debido a:

·         No postergar la calidad sino embeberla en cada ciclo de desarrollo.

10.   Mejor gestión del cambio (2)

Debido a:

·         El cambio es bienvenido y es considerado una oportunidad para darle mayor beneficio al negocio del cliente

·         Si se requiere algo nuevo, se desplaza o quita algo y se hace la nueva funcionalidad

11.   Mayor velocidad y eficiencia (2)

La velocidad no se da porqué se omitan pasos en el desarrollo de software, ocurre debido a:

·         los equipos de desarrollo están enfocados en funcionalidades de valor para el negocio

·         Las funcionalidades se construyen en ciclos cortos con la calidad inmersa

Debido a lo anterior se logra el feedback del cliente y en consecuencia mayor velocidad para el negocio.

12.   Eliminación de Funcionalidades redundantes en el Software (3)

Debido a:

·         Enfoque en las funcionalidades que más valor le entrega al negocio

13.   Documentación más ligera y útil (3)

Debido a:

·         Se produce documentación útil y orientada a que aporte al producto. De forma que no hay desperdicio en documentación y en el tiempo de elaboración.

14.   No es una moda, es un enfoque que se decide o no adoptar

Debido a:

·         El Departamento de Defensa de los Estados Unidos está trabajando bajo metodologías ágiles (4)

·         SAP, Microsoft tiene miles de programadores mejorando sus productos con Scrum (5)

·         Gartner y Forrester lo dicen (6)

·         Entre muchos casos a nivel local (Colombia) como Sura, EPM, Protección entre otros.

15.   Alta visibilidad y control sobre el progreso del proyecto y producto (6)

Debido a:

·         Al enfoque en la transparencia

·         Ciclos cortos que evidencien falencias a corregir

·         Los ciclos cortos permiten mejorar el seguimiento del proyecto

16.   Un dueño de producto empoderado que proporciona feedback y es clave en el exito (6)

Esto proporciona al equipo una rápida solución de dudas, inquietudes y la posibilidad de caminar ciclo por ciclo sobre requisitos claros y bien definidos. Adicional a esto esta comunicación continua y efectiva mitiga riesgos asociados a la confianza ciega en la documentación

17.   Agile ayuda a cumplir los objetivos de IT dentro del Negocio. (6)

Debido a que solo se trabaja en las prioridades de negocio.

18.   Un enfoque en la mejora continua

Debido a que el equipo ciclo tras ciclo  (al menos cada mes) identifica como mejorar para lograr mayor éxito la siguiente iteración (tanto en lo técnico, como en el proceso y equipo), implica una adopción temprana de lecciones aprendidas que permite la mejora en eficiencia y desempeño de todos los involucrados en la construcción del producto.

Pero una última recomendación, si se decide dar el paso hacia el agilismo no solo se necesitan:

·         Certificaciones

·         Y capacitaciones

SE REQUIERE DE  ACOMPAÑAMIENTO, tanto a los roles directivos como a quienes construirán los productos, en primer lugar para que estén alineados y tengan claros los resultados esperados en la medida que van avanzando y en segundo lugar para que lo hagan bien, pues se requiere remover muchas “malas prácticas” y vicios – como querer tener todo controlado o Mando Control - , para dejar emerger y funcionar los valores ágiles:

·         Transparencia

·         Confianza

·         Enfoque

·         Coraje

·         Apertura

·         Compromiso

·         Respeto

Y lograr así los anhelados frutos del agilismo “entrega de SOFTWARE CON VALOR de forma frecuente con EQUIPOS ALTAMENTE MOTIVADOS”

Bienvenidos los proyectos pilotos con acompañamiento…

De todos modos yo ya hice mi elección  y ¿usted?

Fuentes:

1. Leading Agile. The 12 Key Reasons Companies Adopt Agile. [En línea] 30 de Enero de 2011. [Citado el: 28 de Enero de 2015.] http://www.leadingagile.com/2011/01/the-12-key-reasons-companies-adopt-agile/.

2. PMOinformatica.com. 10 razones para aplicar metodologías ágiles: Primera parte. [En línea] 28 de Enero de 2013. [Citado el: 28 de Febrero de 2015.] http://www.pmoinformatica.com/2013/01/10-razones-para-aplicar-metodologias.html.

3. PMOinformatica.com. 10 razones para aplicar metodologías ágiles: Segunda Parte. [En línea] 6 de Febrero de 2013. [Citado el: 28 de Febrero de 2015.] http://www.pmoinformatica.com/2013/02/10-razones-para-aplicar-metodologias.html.

4. Pahuja, Savita. InfoQ.com. US Department of Defense (DoD) is Going Agile. [En línea] InfoQ, 31 de Mayo de 2014. [Citado el: 1 de Marzo de 2015.] http://www.infoq.com/news/2014/05/DoD_agile.

5. Suttherland, Jeff. Youtube. Jeff Sutherland | "Scrum: The Future of Work" | Monday Keynote | Global Scrum Gathering® Las Vegas. [En línea] http://www.scruminc.com/, 13 de Mayo de 2013. [Citado el: 1 de Marzo de 2015.] https://www.youtube.com/watch?v=RYIPSPWVc8o&list=PL0IaI6QFvmiTj8qc0vnpW7k0K48HI3Fda&index=6.

6. Proulx, Martin. Analytical Mind. Seven wrong reasons to adopt Agile. [En línea] 4 de Mayo de 2010. [Citado el: 1 de Marzo de 2015.] http://analytical-mind.com/2010/05/04/seven-wrong-reasons-to-adopt-agile/.

7. Elatta, Sally. Scrum Alliance. Destination: Agile - Top Eight Reasons Why Organizations Are Making the Switch. [En línea] 8 de Enero de 2008. [Citado el: 1 de Marzo de 2015.] https://www.scrumalliance.org/community/articles/2008/january/destination-agile.