Nuevas tendencias en el futuro de la agilidad

1. Introducción

El movimiento ágil nació como respuesta al uso de métodos de trabajo inspirados en ingenierías clásicas, cuyo inicio tuvo lugar con la famosa conferencia de la OTAN (la Organización del Tratado del Atlántico Norte) en el 68 en la que se empujó a la comunidad a imitar los métodos tradicionales de gestión (“software designers are in a similar position to architects and civil engineers”, citaban las actas [1]), cuya máxima expresión ha sido el ciclo de vida en cascada. En el año 2001, se introduce por primera vez el término ‘ágil’ en el contexto del desarrollo de software. Se definen un conjunto de valores, formando el conocido Manifiesto Ágil [2], como respuesta a prácticas y ciclos de vida pesados, como el ciclo de vida en cascada que emula los métodos de construcción de cosas físicas.

La agilidad actualmente está en auge, a pesar de que han pasado muchos años desde su comienzo, 15 desde el Manifiesto Ágil en el 2001, y más de 20 si se considera a DSDM (Dynamic systems development method) como el primer método ágil en el año 1994.

Lo cierto es que, cada vez son más las organizaciones que hacen uso de la agilidad. De hecho, en la décima encuesta de VersionOne [3] un 62% de los encuestados piensa que la agilidad acelera la entrega del producto, un 56% que mejora la capacidad de gestionar los cambios y priorizar. Además, en la encuesta se detallan los beneficios de utilizar la agilidad, donde un 87% piensa que el mayor beneficio es gestionar el cambio de prioridades.

Pero hoy, años después del comienzo del movimiento ágil, cada vez más personas hablan del futuro de la agilidad.

Como se puede observar en la figura 1 entre los primeros en adoptar (Early adopters) y la mayoría temprana (Early Majority) se encuentra el abismo, muchas ideas no superan el abismo y no avanzan, es decir, no se llevan a cabo. Matts explica que existe la creencia de que la agilidad está cruzando el abismo, o que lo ha cruzado ya [4]. De hecho, si se baja el nivel de abstracción, algunas prácticas ágiles lo han cruzado, como aquellas que se aplican a nivel de equipo, y otras como “escalar la agilidad” aún no han cruzado el abismo. Pero lo que sí parece ocurrir es que según se avanza hacia la derecha del abismo (Late Majority y Laggards), la tecnología (la agilidad en nuestro caso) se masifica y va perdiendo su esencia, la necesidad por la que surgió y muchos de los principios que caracterizaron dicho movimiento.

En este trabajo se presenta una reflexión y síntesis de la evolución de la agilidad, para ello se realiza un análisis de la agilidad y los retos que surgen a partir de la misma, lo que da comienzo a nuevas iniciativas que, actualmente, complementan la agilidad y en un futuro podrían sustituir ciertas partes de la misma.

El resto del trabajo se estructura de la siguiente manera: en la Sección II se presentan los nuevos problemas y las nuevas propuestas y en la Sección III se describe el futuro con las conclusiones.

2. Nuevos problemas y nuevas propuestas

A medida que el grado de madurez de la agilidad aumenta, aparecen nuevos problemas derivados del uso masivo de las ideas, modelos y conceptos ágiles. Entre los problemas que se generan, uno de los más significativos es el de la pérdida de los valores iniciales debido a la evolución (o comercialización) de la agilidad, esto, incluso, ha llegado a plantear la necesidad de definir un nuevo Manifiesto Ágil o de redefinir los valores actuales para adaptarlos a las nuevas necesidades. Otro de los problemas significativos es intentar llevar la agilidad a grandes empresas.

Cada vez más expertos plantean la necesidad de realizar un cambio en la agilidad, incluso hay quien piensa que la agilidad ha muerto, pero existen otras líneas que plantean que la agilidad tiene que evolucionar, o que ya ha evolucionado sin que se haya puesto de manifiesto.

A continuación, se muestran los principales problemas que se han encontrado desde que surgió la agilidad y las propuestas que han aparecido para solventar dichos problemas.

2.1. Problema 1: Pérdida o evolución de los valores del Manifiesto Ágil

En los últimos años han aparecido cada vez más reflexiones sobre la situación en la que se encuentran los valores y principios originarios del Manifiesto Ágil. Como se explicaba anteriormente, se han encontrado ideas en la línea de que la agilidad ha muerto y de que era necesario refundar la agilidad [6], a continuación se presentan algunos ejemplos:

• Dave Thomas [7] firmante del Manifiesto Ágil, afirma que no estuvo presente en el décimo aniversario del Manifiesto Ágil, y tampoco participa en eventos ágiles simplemente porque esas cosas no forman ya parte de la esencia del Manifiesto Ágil. Thomas argumenta que la palabra “ágil” ha muerto, que se ha perdido el control por la comercialización actual de la misma, incluso propone que ha llegado el momento de retirar la palabra ágil y que el movimiento adquiera otro nombre.
• Thomas, Richard Bishop [8], programador conocido por sus aportaciones a DevOps, comentaba  que si por él fuera no tendría nada que ver con la palabra “ágil” pero es lo que vende en el mundo de los negocios. Afirma que los mejores defensores de la palabra “ágil” son los desarrolladores.
• William Edmondson, director de desarrollo general de Dave Ramsey, afirma que la agilidad está muerta [9] y que una de las causas de la muerte es el aumento de su popularidad en el ámbito corporativo y la pérdida de familiaridad con la cultura en el mundo del desarrollo.
• Andrew Hunt, firmante del Manifiesto Ágil, también dice que la agilidad ha muerto [10] argumentando que ser ágil no aporta valor a las organizaciones.
• Andrew Binstock, fundador de iText Software Corp y editor de Oracle Java Magazine, escribe que la agilidad está corrupta [11], porque se ha convertido en una doctrina y al perder su esencia ha disminuido su eficacia. Argumenta que el Manifiesto Ágil propone valores no prácticas, y que se ha convertido en un conjunto de prácticas personales.
• Matthew Kern, arquitecto empresarial e ingeniero de sistemas, relata que participó en algunos proyectos ágiles, pero que el resultado de los mismos no fueron satisfactorios, debido a que entre otras cosas, la palabra ágil se ha comercializado [12].

Haciendo un análisis de las opiniones presentadas previamente se pueden sintetizar los problemas en:

• Comercialización y corrupción de la palabra agilidad.
• Pérdida de los valores iniciales.
• Evolución de los valores a los tiempos actuales.

Ante estos nuevos problemas, autores como [13], [14], [15], [16], [17], [18], [19] plantean diferentes soluciones que intentan simplificar la manera en la cual se entiende y se aplica la agilidad en la actualidad. A continuación nos centramos en los dos movimientos que más fuerza están tomando: Heart of agile y Modern Agile.

2.1.1. Heart of agile

Debido al excesivo crecimiento y ampliación de la agilidad Alistair Cockburn, firmante del Manifiesto Ágil, propone en 2014 [20] destacar lo que él denomina como el “corazón de la agilidad” (Heart of Agile) [13]. Con un enfoque compuesto por cuatro palabras (figura 2): Colaborar, Entregar, Reflexionar y Mejorar. Según Cockburn estas palabras son simples y suficientes para apoyar el desarrollo ágil moderno [21]:

• Colaborar (Collaborate). La idea es facilitar la colaboración mejorando el área de la motivación y de la confianza.
• Entrega (Deliver). Por lo tanto se realizan entregas para poder aprender pero también para obtener dinero.
• Reflexionar (Reflect). Reflexionar sobre las ideas y sobre lo que sucede en el equipo para proponer mejoras.
• Mejorar (Improve). Se considera dependiente de reflexionar y viceversa, la mejora se consigue mediante experimentos y cambios.

2.1.2. Modern Agile

Modern Agile [14] es la propuesta de Joshua Kerievsky en 2015, muy similar a la anterior. En Modern Agile se proponen cuatro principios basados en libros como [22], [23], [24] entre otros.

Estos principios han sido pensados para actualizar los cuatro principios originales del Manifiesto Ágil [25].

Uno de los motivos por los que aparece Modern Agile es que la agilidad va más allá del área del desarrollo software, incluye operaciones y negocios, y estas áreas deberían estar alineadas. Esta propuesta no habla de roles ni de prácticas, simplemente de cuatro principios (figura 3):

• Haz que las personas sean impresionantes (Make People Awesome).
• Haz de la seguridad (a nivel personal) un prerrequisito (Make Safety a Prerequisite).
• Entrega valor continuamente (Deliver Value Continuously).
• Aprender rápidamente con la experimentación sin miedo a equivocarse (Experiment & Learn Rapidly).

2.2. Problema 2: Olvidar la entrega de valor

Una de las premisas de un proceso ágil es entregar valor pronto y constantemente [26], de hecho el Manifiesto Ágil enuncia entre sus valores “Software funcionando sobre documentación extensiva”. El valor es lo que esperan los usuarios potenciales del producto que se está creando [27]. Por este motivo, a lo largo del proceso se debe tener en cuenta en todo momento las necesidades del usuario, priorizar estas necesidades por valor, realizar en primer lugar las necesidades de mayor valor y entregar prototipos constantemente que incorporen nuevas funcionales y por tanto valor al producto.

Sin embargo, en un proceso ágil enfocado en proyectos, y no en el desarrollo de un producto, se puede ver afectada la entrega de valor, porque al hablar de proyectos se centran en cerrar tiempo, presupuesto y requisitos en lugar de entregar valor. No solo hay que deshacerse de la palabra proyecto sino que también hay que cambiar la visión de estimación, la cual debe dejar paso al valor que es el que debe guiar todo el proceso.

En los últimos tiempos han aparecido nuevos pensamientos y movimientos para fomentar la entrega de valor al usuario: #Noproject, #Beyondprojects o unproject, #noEstimates, hypothesis Driven Development.

2.2.1. #Noproject, #Beyondproject o unproject

La idea del peligro de enfocar todo el desarrollo, evolución y creación de tecnología por proyectos se puede ver desde varios ángulos. No es lo mismo definir proyectos con diagramas de Gantt, fechas de inicio y fin, sus estimaciones y luego buscar personas para los mismos, que definir proyectos para potenciar equipos. Un proyecto tiene fechas, inicio y final, eso hace que encaje de manera poco natural en algo como el software que tiene inicio pero no tiene final. La idea principal de estos movimientos es que los equipos deben centrarse en la entrega de valor, pero si se está bajo el modelo de proyecto se centrará en objetivos de tiempo, presupuesto y requisitos. De otro modo, si se deja de lado la idea de proyecto clásico se reduce el riesgo, ya que se tiene contacto con el cliente y no solo ve el producto al final sino que va viendo su desarrollo.Es por ello que la idea del #noprojects o el #beyondproyect (según Allan Kelly [16]) actualmente está creciendo logrando que desaparezca el concepto “proyecto”, incluso en Spotify, hace años propusieron el eslogan de la cultura “unproject” [15].

2.2.2. #NoEstimates

La estimación clásica se basa en disponer de todos los requisitos, estimarlos y en ocasiones empezar a implementarlos por prioridad (que pudiera asemejarse al valor), para terminar todo en un plazo determinado y hacer una gran entrega final. Sin embargo, es muy diferente tener un montón de requisitos, priorizarlos por valor e ir haciéndolos para realizar una única entrega final, a tener un conjunto de requisitos, priorizarlos por valor e ir haciendo prototipos y entregas parciales que implementen sólo los ítems de mayor valor. Para posteriormente volver a valorar los siguientes requisitos a implementar. Esta última forma es mucho más ágil.

Actualmente el movimiento en contra de las estimaciones software se conoce como #noEstimates [17]. Propuesto por Zuill y Neil Killick, el movimiento defiende que las estimaciones en el mundo del software no tienen sentido e incluso son perjudiciales.

El resultado final de esta forma de trabajar difiere de la manera clásica, ya que se implementarán cosas que aportan valor porque se entregan y chequean con los usuarios potenciales, como defiende uno de los valores del manifiesto ágil “Colaboración con el cliente sobre negociación contractual”.

2.2.3. Hypothesis Driven Development

Frente a planes rigurosos, inamovibles, a largo plazo, incluso más allá del concepto de historia de usuario, aparece la idea de lanzar experimentos de manera frecuente para aprender rápido. Estas ideas se conocen como desarrollo basado en hipótesis (Hypothesis Driven Development).

El desarrollo basado en hipótesis propone desarrollar nuevas ideas, productos, servicios, etc, a través de experimentos, iterando hasta conseguir el resultado esperado o comprobar que la idea no era viable. Es decir comenzar trabajando en ideas pequeñas que funcionen rápido, para aprender de su éxito o fracaso.

2.3. Problema 3: Saber cómo potenciar el papel humano

Las personas son cada vez más importantes en las organizaciones. En [28], un estudio sobre la relación entre la felicidad y la productividad, se confirma que las personas más felices son aproximadamente un 12% más productivas. Casos de referencia, como Zappos [29], iniciativas como Happy Melly [30] o incluso que Google tenga una persona cuyo cargo es “Jolly Good Fellow” (“un muchacho excelente”), encargado de “gestionar la felicidad” [31], han puesto de moda la felicidad entre las personas de una organización.

Esto se conoce como Peopleware. Si bien, el término “Peopleware” es antiguo, se popularizó en el año 1987 en el libro “Peopleware: Productive Projects and Teams” de DeMarco y Lister [32]; en los últimos años se le está dando mayor importancia.

Para dar solución al problema de potenciar el papel humano aparecen nuevas formas de gestionar, que se describen a continuación: Management 3.0 y Tribus.

2.3.1. Management 3.0

Existen diferentes formas de gestionar una organización en lo que refiere a las personas, Jurgen Appelo [34] cuenta la visión clásica de gestionar (Management 1.0) y la visión del futuro-presente (Management 3.0).

En el Management 1.0 las organizaciones gestionan a sus trabajadores como máquinas, fomentando la competitividad entre los miembros del equipo. Hay organizaciones que han aprendido que hay otra manera de hacerlo mejor, las que se consideran que están en el Management 2.0. En este tipo de organizaciones hay conciencia sobre que las personas son el activo más valioso y que los directivos deberían ser quienes gestionen y proporcionen medios para que la gente pueda desarrollar su mayor potencial. Sin embargo, el problema de este tipo de organizaciones son las estructuras, porque empezaron gestionándose en Management 1.0.

El Management 3.0 se da normalmente en organizaciones nuevas, donde la estructura está pensada hacía las personas y no tienen malas prácticas acumuladas. Es por ello que muchas organizaciones en Management 1.0 consiguen pasar a Management 3.0 organizándose con nuevos grupos en modelo ”startup”.

Según Appelo la buena gestión en parte consiste en tener personas motivadas y felices para generar valor, definiendo prácticas específicas que permitan llegar a tener una organización gestionada con Management 3.0.

2.3.2. Tribus

Una tribu es un grupo de personas que puede tener entre 20 y 150 personas y se diferencian por su cultura y su líder.

Según los autores del libro Tribal leadership [18] los responsables de las empresas tienen que conocer las tribus que hay dentro de la misma, los medios de comunicación entre ellas y su cultura, de este modo entenderán cómo trabaja la empresa y cuales son sus límites. Además, proponen una caracterización de las tribus en 5 etapas, siendo la número uno la menos deseable y la cinco la más potente.

• En la primera etapa las personas que forman la tribu se unen para luchar contra injusticias que se les presentan en el día a día.
• La segunda etapa se caracteriza porque las personas se encuentran resignadas, son apáticas y están desmotivadas. El 25% de las tribus en las organizaciones están en esta etapa [18].
• En la tercera etapa el conocimiento es poder, y las personas son competitivas de manera individual. Las organizaciones en este nivel miden el éxito de forma individual. El 49% de las tribus se encuentran en etapa [18].
• En la cuarta etapa el sentimiento es de grupo, tienen un objetivo común y valores compartidos. En esta etapa aparecen grupos adversarios como competidores, como por ejemplo los equipos deportivos.
• En la quinta etapa se da un paso más, y el sentimiento de la tribu es que su trabajo cambiará el mundo y por tanto tendrá impacto global.

Las etapas cuarta y quinta son muy potentes pero no todas las organizaciones pueden alcanzarlas.

2.4. Problema 4: Escalar agilidad

En agilidad se sigue la premisa de que los equipos grandes son menos productivos que los pequeños, por ello cuando el número de personas es grande (más de 7), se divide en varios equipos, esto se denomina agilidad en grandes empresas.

Hay diversas opiniones sobre escalar la agilidad; según Sutherland [35], los frameworks para escalar agilidad se utilizan a menudo para proporcionar a organizaciones pesadas y tradicionales, ayuda en su evolución. Sin embargo, la burocracia o cambios en la gestión a menudo paralizan y/o destruyen la implantación ágil. Appelo [36] apoya esta idea explicando que una adopción sin sentido del Manifiesto Ágil conduce inevitablemente a la conclusión de que la agilidad no escala.  De hecho, Ambler crea DAD (Discipline Agile Delivery) [37] como una manera de adaptar ideas extraídas del Manifiesto Ágil al nivel empresarial modificadas según su experiencia.Estos autores coinciden en que antes de llevar la agilidad a grandes empresas hay que ver la estructura de la organización y analizar las modificaciones que se deberían hacer para que sea más ligera.

2.4.1. Reinventing Organization

Frederic Laloux [38] estudia la “historia” del desarrollo de las organizaciones y los “modelos de conciencia” históricos que dieron lugar a diferentes estructuras o modelos de gestión.

En el modelo de Laloux cada color representa una etapa, una evolución que dio lugar a una cultura organizacional. Cada etapa tiene correlaciones con un momento particular de la historia de la humanidad y tiene una orientación “cognitiva, psicológica y moral”.

El rojo representa el modelo de gestión similar al modelo de gestión de las mafias. El ámbar representa el modelo de la iglesia católica, o el que siguen las administraciones públicas, el naranja se refiere al modelo de los bancos, multinacionales, es decir, organizaciones jerárquicas.  El verde se da en un grupo más selecto, representa a las organizaciones de estilo familiar, con holocracia en lugar de jerarquías como por ejemplo Zappos, de Starbucks, etc.

Las organizaciones sanas se representan con el color verde azulado, que representa “la próxima etapa en la evolución de la conciencia humana”. Hay tres cosas principales que caracterizan a una organización en esta etapa: La auto-organización, la Integridad, y el Propósito evolutivo.

3. Conclusiones

Como se ha ido exponiendo a lo largo del artículo, según pasa el tiempo la tecnología se va enfrentado a nuevos problemas. Al mismo tiempo surgen nuevas corrientes e ideas que proponen iniciativas y movimientos para dar solución a dichos problemas. De igual manera surge la agilidad como respuesta a los problemas del desarrollo software, desde su visión más tradicional al pretender imitar a otras profesiones, como la industria o la arquitectura.

Parafraseando el popular libro de Umberto Eco [39], hoy en día podemos encontrar, en lo que refiere al futuro de la agilidad, desde pensamientos más “apocalípticos” hasta pensamientos más bien “integrados”, desde ideas que abogan más por la muerte y sustitución de las ya antiguas ideas ágiles hasta ideas de carácter más evolutivo, que defienden más la vuelta a los principios y valores, en ocasiones simplificándolos o adaptándolos a los tiempos actuales.

Todo ello sin olvidar que independientemente de las tendencias y del futuro, aún hoy hay muchas organizaciones ajenas a la agilidad, o haciendo uso de las primeras ideas ágiles anteriores e incluso ni siquiera ágiles.

Como dijo Bohr, “predecir es muy difícil, y sobre todo el futuro”, así que es más fácil exponer las actuales tendencias: vuelta a los valores, vuelta a la simplicidad de los mismos, escalado y potenciar una de las claves de cualquier trabajo intelectual en grupo, como es el desarrollo software, el papel humano.

Desde nuestro punto de vista, la agilidad no está muerta, sino que está en constante evolución, prueba de esto son las diferentes propuestas que han surgido, y siguen surgiendo, en los últimos años.  En este artículo, con el objetivo de apoyar esta idea, hemos presentado un análisis de los principales movimientos que han surgido en los últimos tiempos para dar solución a los problemas que se han ido generando a partir de la masificación de la agilidad.

4. Agradecimientos

Este trabajo ha sido financiado en forma conjunta por el Deporte y el Fondo Social Europeo 710 (Ley 1880/2015) dentro del Programa Operativo de Empleo Juvenil y la Iniciativa de Empleo Juvenil, por CONICET (Argentina) y la Universidad Tecnológica Nacional (Argentina).

5. Referencias

[1] “The NATO Software Engineering Conferences”.  [online] Homepages.cs.ncl.ac.uk. http://homepages.cs.ncl.ac.uk/brian.randell/NATO/index.html  [Accedido Oct. 2016].

[2] “Manifesto for Agile Software Development”. [online] Agilemanifesto.org. http://agilemanifesto.org/ [Accedido Sep. 2016].

 [3] “VersionOne 10th Annual State of Agile Report” [pdf]  Versione.com “https://versionone.com/pdf/VersionOne-10th-Annual-State-of-Agile-Report.pdf” [Accedido Sep. 2016].

[4] “Communities of Need & Community of Solutions”. [online] The IT Risk Manager https://theitriskmanager.wordpress.com/2015/04/19/communities-of-need-community-of-solutions/ [Accedido Sep. 2016].

[5] G. A. Moore. “Crossing the chasm: Marketing and selling technology products to mainstream customers”. New York: HarperBusiness, 1991.

[6] M. F. Kern. “Agile is Dead”, [online] linkedIn. Com https://www.linkedin.com/pulse/agile-dead-matthew-kern [Accedido Sep. 2016].

[7] D. Thomas. “Agile is Dead (Log Live Agility)”.  [online] PragDave https://pragdave.me/blog/2014/03/04/time-to-kill-agile/, [Accedido Sep. 2016].

[8] R. Bishop  “Agile Is Dead: The Angry Developer Version” . [online] Rubiquity.com http://rubiquity.com/2014/03/12/agile-is-dead-angry-developer.html, [Accedido Sep. 2016].

[9] W. Edmondson. “Agile is Dead”. [online] William Edmondson http://www.williamedmondson.com/agile-dead/ [Accedido Sep. 2016].

[10] “Is the Agile Manifesto dead?”. [online] TechBeacon http://techbeacon.com/agile-manifesto-dead [Accedido Sep. 2016].

[11] “The Corruption of Agile Andrew Binstock”. [online] Dr. Dobb’s ttp://www.drdobbs.com/architecture-and-design/the-corruption-of-agile/240166698  [Accedido Sep. 2016].

[12] M. F. Kern. “The Agile Hype Cycle”. [online] LinkedIn https://www.linkedin.com/pulse/agile-hype-cycle-matthew-kern-msea-cea-pmp-itil-cissp-issap?trk=mp-reader-card [Accedido Sep. 2016].

[13] A. Cockburn. “The Heart of Agile”. [online] Alistair.cockburn.us http://alistair.cockburn.us/get/3613 [Accedido Sep. 2016].

[14] “Modern Agile”  [online] Modern Agile http://modernagile.org/ [Accedido Sep. 2016].

[15] H. Kniberg. “Spotify – the unproject culture”  [pdf] http://blog.crisp.se/wp-content/uploads/2014/03/unproject.pdf [Accedido Sep. 2016].

[16] A. Kelly. “Beyond Projects/#NoProjects”. [online] Allankelly.net http://www.allankelly.net/presentations/noprojects.html  [Accedido Sep. 2016].

[17] N. Killick. “#NoEstimates Part 1 – Doing Scrum Without Estimates”. [online] Neil Killick’s blog — Shifting conventional thinking to the right https://neilkillick.wordpress.com/2013/01/31/noestimates-part-1-doing-scrum-without-estimates/ [Accedido Sep. 2016].

[18] D. Logan, J. P. King, H.Fischer-Wright. “Tribal leadership: Leveraging natural groups to build a thriving organization.” New York: Collins, 2008.

[19] M. Poppendieck, T. Poppendieck. “Lean Software Development: An Agile Toolkit” Addison-Wesley Longman Publishing Co., Inc., Boston, USA, 2003.

[20] A. Cockburn. “The heart of agile”. [online] Heartofagile.com http://heartofagile.com/ [Accedido Oct. 2016].

[21] A. Cockburn. “Expanding the diagram” [online] Heart of Agile http://heartofagile.com/expanding-the-diagram/ [Accedido Sep. 2016]

[22] K. Sierra. “Badass: Making Users Awesome” Sebastopol: O’Reilly & Associates.20157

[23] T. Hsieh. “Delivering happiness: a path to profits, passion, and purpose” New York : Business Plus, 2010

[24] S.Stratten, ‎A. Kramer. “The Book of Business Awesome” Hoboken, N.J.: John Wiley & Sons, Inc, 2012

 [25] “Modern Agile” [online] Agilealliance.org https://www.agilealliance.org/resources/sessions/modern-agile/ [Accedido Sep. 2016].

[26] R. Jeffries. “Value, not Scarcity, not Estimates”  [online] RonJeffries.com http://ronjeffries.com/articles/015-jul/value-not-estimates/ [Accedido Sep. 2016].

[27] Jeffries, R. “The nature of software development: Keep it simple, make it valuable, build it piece by piece”, 2015

[28] J. Leber. “Happy Workers Are More Productive: Science Proves It”. [online] Co.exist https://www.fastcoexist.com/3028160/happy-workers-are-more-productive-science-proves-it  [Accedido Sep. 2016].

 [29] “The Zappos Family – How They Work” [online] Youtube https://www.youtube.com/watch?v=axlWBn7YQA4  [Accedido Sep. 2016].

 [30] “Happy Melly Business Network” [online] Happy Melly http://www.happymelly.com/join-us/ [Accedido Sep. 2016].

[31] J. Bort. “This Google engineer’s title is ‘Jolly Good Fellow’ and he’s solving unhappiness and war” [online] Business Insider http://www.businessinsider.com/google-jolly-good-fellow-chade-meng-tan-2015-9 [Accedido Sep. 2016].

[32] T. DeMarco,  T. Lister. “Peopleware”. New York, NY: Dorset House Pub. Co, 1987.

[33] R. Whippman. “America is obsessed with happiness — and it’s making us miserable”. [online] Vox http://www.vox.com/first-person/2016/10/4/13093380/happiness-america-ruth-whippman [Accedido Sep. 2016].

[34] J. Appelo.“#Workout: Games, Tools & Practices to Engage People, Improve Work, and Delight Clients” (Management 3.0), Rotterdam: Happy Melly Express, 2014.

[35] Sutherland. “The Shu Ha Ri of Scrum @ Scale”. [online] Scruminc.com http://www.scruminc.com/wp-content/uploads/2016/08/Credit-Suisse-Jul-2016.pdf [Accedido Sep. 2016].

[36] J. Appelo. “No. Agile Does Not Scale”. [online] Meidum https://medium.com/@jurgenappelo/no-agile-does-not-scale-98df99da3ff3#.843l5ly1d [Accedido Sep. 2016].

[37] S. W. Ambler, M. Lines. “Disciplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery” in the Enterprise (1st ed.). IBM Press, 2012

[38] F. Laloux, K. Wilber. “Reinventing Organizations”, 2014

[39] U. Eco, A. Boglar. “Apocalípticos e integrados”. 1st ed. Barcelona: Tusquets Editores, 2001