Introducción a DevOps - ¿El siguiente paso a Scrum?

El desarrollo de software con Scrum, que comenzó con algunos equipos pioneros hace unos pocos años, se ha convertido en una tendencia creciente sinó ya del "mainstream". Es actualmente el modelo de desarrollo más extendido, aunque dista aún bastante de ser mayoritario y que se realice de manera madura allá donde se introduce.

"Cada empresa es un mundo", pero de la misma manera que Scrum se ha hecho enormemente popular, en general aún no ha alcanzado una integración suficientemente buena con las operaciones (explotación, producción...) fuera de las start-ups y los equipos muy pequeños.

Por otra parte, durante la década del 2000 se expandieron movimientos y frameworks como Enterprise Systems Management (ESM) e ITIL v2. Estos movimientos, que han aportado notables mejoras a la estabilidad de producción, han estado centrados principalmente en organizaciones grandes y proveedores IT como IBM, HP o CA.

Una visión alternativa, originada en la "pesadez" y la pobre adaptación a las empresas más pequeñas de estas aproximaciones, tomo forma en el concepto de DevOps, acuñado por Patrick Debois en 2009. Desde entonces se han ido sucediendo eventos (como los DevOpsDays) y webs dedicadas a la materia.

En resumen, actualmente la visión generalizada de los departamentos de IT según los grupos de desarrollo de software y de explotación/sistemas puede ser:

• Desarrollo: quiero construir y publicar lo que me pide el negocio con agilidad.
• Explotación: me miden por el coste y disponibilidad. No quiero riesgos.

El resultado muchas veces consiste en despliegues grandes y espaciados en el tiempo, con una pobre comunicación conjunta, que suele producir errores, retrabajo y más coste que haberlo hecho de manera conjunta desde el principio.

DevOps.org

El enfoque de DevOps comparte la agilidad de Scrum para mejorar la comunicación entre cliente (el negocio) y el proveedor (desarrolladores), fomentando la confianza, la compartición del plan y del avance en el trabajo, y tomando un feedback frecuente. Al igual que el Scrum Master y el Product Owner actúan como los responsables de la coordinación entre negocio y desarrollo, el DevOps engineer se encarga de planificar y seguir la coordinación entre desarrollo y operaciones, aunque sin tener necesariamente mando sobre éstos.

LMC Software

El rol principal en DevOps es Ingeniero de operaciones, similar al Chief Engineer el Toyota Production System. Consiste en coordinar a los equipos de desarrollo y a los administradores, aunque no tiene autoridad final sobre los equipos.

Attunity.com

Aunque DevOps tiene una fuerte relación con las herramientas que automatizan las operaciones (p.e. Jenkins, BuildForge, Puppet Labs, etc.) el aspecto fundamental son los procesos integrados entre desarollo y producción. No se trata de "hacerlo igual de mal, pero más rápido".

En España todavía no han habido eventos importantes sobre DevOps, si bien en Madrid hay un grupo de interés con bastante actividad. 

En próximos posts seguiré escribiendo sobre DevOps, y ¡estaré encantado de contactar con otras personas que estén interesadas sobre esta materia!

Chrome va lento con Flash

Un post off-topic sobre Google Chrome.

Desde las últimas semanas (agosto 2012) vi que Chrome va muy lento en aplicaciones con Flash (p.e. Gmail), convirtiéndose en una tortura.

El problema es uno de los plugins de Flash (PepperFlash) que falla. Para desactivarlo, 

1. Pegad en la URL:  chrome://plugins/
2. Localizar el plugin de flash (suele ser el 1º)
3. Click en "+ Details"
4. Desactivar PepperFlash y reiniar.
5. Voilà!

http://www.monkeycoder.co.nz/Community/posts.php?topic=3384

Plan de empresa Barcelona con Kit-emprendedores.com

Kit-emprendedores.com es una iniciativa de Cynertia Consulting que tiene como objetivo reunir su experiencia en la creación de Planes de negocio y el apoyo integral a los emprendedores.

En esta web se encuentran descritos los servicios y recursos que se ofrecen de soporte a la creación de empresas:

• Plan de empresa
• Web de empresa, posicionamiento en Google y guías
• Tienda virtual
• Soporte tecnológico
• Selección de local y proveedores

La filosofía de Kit-emprendedores es reutilizar la experiencia acumulada en proyectos reales para economizar el soporte, manteniendo en todo momento una atención totalmente personalizada y de alta calidad.

Scrum, PMBOK, modas y comparaciones

Hace unas semanas pude asistir a una interesante sesión organizada por la gente de Agile Barcelona, titulada "Agile, State Of The Art".

Aunque el objetivo de esta sesión no era introducir las metodologías y técnicas ágiles más conocidas y difundidas como Scrum o Kanban, sinó explicar que se está haciendo de nuevo en este ámbito, en algunos momentos se estableció el (clásico) debate sobre cuando es mejor aplicar Scrum y cuando otras metodologías tradicionales de gestión de proyectos (simbolizadas por PMBOK).

Este debate me inspiró a escribir este post, debido a que creo que existe cierta confusión sobre los factores que hacen que aplique más un tipo de metodologías que otras.

El entorno importa, más que la metodología.

Uno de los tópicos que se introdujo fue: en las metodologías tradicionales se negocia mal el alcance al comenzar y luego eres prisionero del "triángulo de acero". Esto pasa habitualmente por situaciones del contexto como:

• Comerciales (y clientes) poco capacitados.
• Empresas que entran conscientemente en proyecto sabiendo que sus propuestas son con pérdidas para "entrar en un cliente".
• No se consulta al equipo técnico, la oferta "es algo del comercial". 
• Competencia caníbal (yo me bajo los pantalones más que el otro), etc.

En mi opinión, se confunde una mala praxis habitual con las supuestas debilidades de metodologías tradicionales. Estos factores claramente son identificados como riesgos a evitar en PMBOK y por tanto, no se pueden atribuir como limitaciones de las metodologías "tradicionales". Además, si estamos en un entorno como estos, caracterizados por la poca capacidad, competencia desmedida, desconfianza entre cliente y proveedor, etc. Scrum tampoco funcionaría.

Todos solemos usar más la herramienta que más conocemos.

En la sesión creo que hablaron (hago una simplificación) fans de metodologías tradicionales, metodologías ágiles y otros "equidistantes" entre ambos tipos de metodologías.

La foto de la cabecera representa una cosa que me dijeron hace años cuando trabajaba en IBM "si sabes usar bien un destornillador, tenderás a clavar clavos con él". Es una tendencia natural entre todos la de confiar más en la metodología que más conocemos y desconfiar de aquella que conocemos, aunque no sea la que más se adapta al problema a resolver.

Igual que no tiene sentido aplicar PMBOK o Prince2 en proyectos claramente indefinidos y donde hay un alto grado de confianza entre cliente y proveedor (p.e. desarrollo interno de producto), tampoco tiene sentido aplicar Scrum donde hay poca confianza entre ambas partes, o donde existen altos costes asociados que deben ser evaluados cuidadosamente antes de comenzar el proyecto.

Haciendo una exageración, ¿alguien se imagina construir una central nuclear o una presa por iteraciones? ¿Podemos pasar al backlog del siguiente sprint una mejora en la reducción de escapes de radioactividad?

Mundo académico, mundo blogger y mundo profesional.

Los diferentes ámbitos tienen diferentes dinámicas, y en mi experiencia se decantan mayoritariamente hacia diferentes modelos de ver la gestión de proyectos. Digo mayoritariamente, porque lógicamente es imposible encontrar audiencias uniformes en estos ámbitos tan grande.

El mundo académico es pionero en el desarrollo y aplicación de técnicas, y explica desde hace décadas los modelos tradicionales de gestión de proyectos e ingeniería del software, pero en general es menos sensible a la evolución profesional y por ambas cosas, suele orientarse más a la aplicación estricta de la gestión de proyectos tradicional.

El "mundo blogger", entendido como los expertos que escriben en blogs, comunidades y redes sociales, es mucho más dinámico que el académico y difunde más rápidamente las tendencias y novedades. Por ello encontramos que la mayoría de autores en Internet hablan sobre Agile, más fácil de comenzar a usar (no siempre suficientemente bien) que sobre metodologías tradicionales.

Por otro lado, creo que existe una tendencia por parte de muchos bloggers que son freelances u ofrecen servicios de consultoría a ensalzar lo bueno que es aplicar la metodología que dominan y a demonizar (o situar como "pasado de moda") lo que no dominan. Esto, tristemente, pasa frecuentemente con Scrum.

Finalmente, el "mundo profesional" es seguramente el más variado. Existen empresas certificadas y muy orientadas al "compliance" de metodologías, otras que han adoptado completa o parcialmente Agile, y muchas otras que usan lo que traen como experiencia sus trabajadores. Cada empresa es un mundo.

¡Queremos vuestros comentarios!

Esta es mi visión del asunto, reconociendo que generalizar en "4 líneas" es un ejercicio siempre incompleto, pero aportando mi opinión sobre lo que la confusión y comparaciones equivocadas que se establecen entre las diferentes metodologías.

Me gustaría recibir vuestros comentarios, seguro que son enriquecedores vuestros puntos de vista.

Nueva versión de WorkBook, el ERP lider para empresas de servicios

Workbook A/S, el fabricante del ERP lider para empresas de servicios del sector de publicidad y servicios profesionales ha publicado la versión 8.2 de WorkBook.

Este producto cubre las principales necesidades de las empresas orientadas a proyectos, mediante las siguientes módulos:

• CRM para gestionar oportunidades y crear ofertas de proyectos
• PM para definir calendarios de trabajo, asignar tareas, controlar el avance del proyecto e imputar las dedicaciones
• FI para gestionar la facturación y la contabilidad

Esta herramienta es web y se puede operar tanto en la nube (pagado por uso de usuarios y módulos), tanto como en la infraestructura de la empresa.

Esta nueva versión incorpora novedades que aumentan la facilidad de uso y flexibilidad del producto.

Gestión ágil de equipos vs Parálisis burocratica

Uno de las principales dificultades que supone la gestión de personas, y particularmente la de equipos, es la burocracia que se establece cuando los equipos crecen e incorporan personas con poca experiencia trabajando conjuntamente.

Todos podemos reconocer este fenómeno que suele reducir considerablemente la eficiencia y eficacia de los equipos, así como la moral de aquellos miembros más activos de estos grupos que trabajan activamente a favor de la mejora de la comunicación.

El Dr. Michael Sutcliffe de la Universidad de Cambridge, identifica en un artículo [1] los 8 síntomas características del fallo en la comunicación (8 Symptoms of Communication Breakdown), que son los siguientes:

1. La decisión invisible: no se sabe claramente quien toma realmente las decisiones.
2. Trabajo inacabado: se inician muchas tareas y se acaban pocas.
3. Parálisis en la coordinación: no se puede hacer nada sin validarlo con todas las partes.
4. Nada nuevo: no hay ideas o pensamientos laterales radicamente nuevos.
5. Pseudo-problemas: pequeños impedimentos se convierten en problemas insalvables.
6. Guerras centralizadoras: el "centro" lucha para mantener "la consistencia y el control" sobre las unidades independientes.
7. Dominación de las entradas: las personas reaccionan cuando se les asigna una tarea pero no asumen ninguna responsabilidad proactivamente.

Estos síntomas, con los que podría estar de acuerdo cualquier fan de la clásica serie británica Yes Minister, me llamaron la atención y pensé en analizar como los afrontan las metodologías de gestión ágil como Scrum. Revisitando la lista tenemos lo siguiente:

1. La decisión invisible: Scrum tiene claramente definidos los roles (Product Owner, Scrum Master, Development Team), así como cuando y como se toman y documentan las decisiones.
2. Trabajo inacabado: este fenómeno no se puede producir en Scrum, pues se eligen cuidadosamente las funcionalidades a incluir en cada Sprint (Sprint Backlog) y en caso que alguna de ellas no se pueda acabar se devuelve al contenedor del proyecto (Product Backlog).
3. Parálisis en la coordinación: de nuevo esto no se da en Scrum pues la coordinación se reduce a momentos puntuales (Daily Scrum) y las tareas son asignadas a una persona únicamente.
4. Nada nuevo: Scrum respeta de manera explícita la comunicación abierta y el respeto por los demás. Igualmente existen momentos definidos para encontrar mejoras al proceso (Scrum Retrospective) y al producto (Scrum Review).
5. Pseudo-problemas: en Scrum, las dificultades que tienen los miembros del equipo se comentan sistemáticamente con carácter diario (Daily Scrum) y tienen el soporte del equipo para impedir que se conviertan en problemas serios.
6. Guerras centralizadoras: este puede ser uno de los problemas en la implantación de Scrum para organizaciones complejas. En el libro [2] se detallan técnicas para establecer un buen marco de colaboración entre la oficina de proyectos, product managers y product owners.
7. Dominación de las entradas: los miembros del equipo toman de manera autónoma la responsabilidad sobre las funcionalidades y tareas a implementar, sin esperar a que nadie se las tenga que asignar.

Como resúmen, Scrum (y otras metodologías ágiles) atacan con efectividad la problemática de la burocracia en el ámbito de la gestión de proyectos. Un ámbito muy interesante que queda por  es la extensión de estos principios ágiles a la gestión de procesos y funciones de empresas no orientadas a proyecto, espero publicar algún post una vez haya leído el siguiente libro [3] que tengo en cartera.

Referencias:

• [1] The Personal MBA - P218. Communication Overhead. Nota: no he podido localizar el artículo original del Dr.Sutcliffe que aparece citado en esta sección.
• [2] Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Dean Leffingwell. 2011 Addison-Wesley Professional. 
• [3] The Leader's Guide to Radical Management: Reinventing the Workplace for the 21st Century. Stephen Denning. 2010  Jossey-Bass.

Spanair y el Cloud Computing:

El 28/1/2012 Spanair dejó de operar de manera súbita. Aunque muchos estaban al corriente de sus dificultades financieras, la gran mayoría del público la veía como una compañía asentada y fiable. La sorpresa fue mayúscula.

Este caso puede ser relevante en la discusión actual sobre el futuro de la computación. En los últimos años, y de manera más intensamente desde 2011, los términos "cloud computing", "ahorro energético", "pago por uso", "public cloud vs private cloud", etc. cada vez se oyen de manera más frecuente y parece que la cuestión no es si el modelo actual de  computación basado en poseer el software (libre o con licencia, de código abierto o cerrado) y operarlo va a continuar, sinó cuanto tiempo falta para la migración más o menos masiva al cloud.

Además de los actores consolidados de infraestructuras (Amazon EC2, Google, IBM, Microsoft, etc.) y de aplicaciones (Salesforce, Google Apps, Microsoft, WebEx, etc.) han aparecido multitud de "miniaplicaciones" verticales muy usadas para hacer casi de todo, p.e.:

1. Compartir pantalla (p.e. join.me)
2. Compartir documentos y presentaciones (p.e. Cacoo.com y Sinc.in)
3. Mantener diagramas Gantt de proyecto (p.e. Gantto.com)
4. Y un larguísimo etcétera.

Muchos de estos proveedores, especialmente aquellos que ofrecen aplicaciones con una mínima complejidad y necesidad de integración, ponen a disposición de los usuarios APIs que permiten su integración e incluso el "backup" de datos.

Así pues, usando de "aquí y allá" las funcionalidades que más nos interesan, podemos integrarnos un mapa de aplicaciones independientemente de si estas están "operadas" por nosotros o por terceros. El esquema "best of breed", sin duda parece muy interesante.

Ahora bien, más allá de todos los matices de este modelo, la dudas básicas que se plantea es: 

1. ¿qué pasa si un proveedor deja de operar así, sin más, como hizo Spanair? 
2. Por mucho que tengamos garantías en forma de contratos, SLA, capacidad de hacer backup de datos, etc. ¿qué pasaría el día siguiente con esta aplicación?
3. ¿Y con los datos? 
4. ¿Y las integraciones con terceras aplicaciones?

Como es sabido, este modelo presenta sus incógnitas, por mucho que nos imaginemos que ciertos proveedores son "grandes y estables", como lo parecía Spanair para el público general.

Además de poder hacer "backup" de los datos, es conveniente para mitigar este riesgo poder cambiar de "operador de infraestructura" si el que usamos actualmente falla. Y eso, de momento sólo pasa por tener a mano el código.

¿Podemos usar aplicaciones (p.e. de código abierto) y operarlas en un cloud privado (p.e.Capside)? Puede ser una solución mientras los proveedores (o markets) no tienen en cuenta esta problemática.

Checklist para Scrum

En el blog de Javier Garzás he visto que Jeff Shuterland publica en su web un checklist que ayuda a comprobar la adherencia a las prácticas de Scrum.

Que un miembro de equipo de Scrum, p.e. Scrum Master, quiera conocer el grado de adherencia que tiene su equipo a Scrum parece totalmente razonable.

Por otro lado, la filosofía agile parece opuesta al "compliance". El Agile Manifesto habla de "Individuals and interactions over processes and tools". Por ello, ¿tendría sentido poder "puntuar" la adherencia de un equipo a Scrum, o bien, el provecho que está obteniendo de este proceso?

Otro punto es saber si una aproximación de certificación (como CMMI o ISO15504) puede usarse para conocer, mediante un esquema externo de puntuación. Este enfoque permite reforzar el seguimiento uniforme de Scrum en los proyectos, combinando CMMI y Agile, aunque supone hibridar Scrum con otros métodos.

Encuesta sobre el uso de SCRUM (3 de 4)

Encuesta sobre el uso de SCRUM (3 de 4)

Uso real de SCRUM

En el artículo anterior se analizaban las respuestas sobre las ventajas percibidas por Scrum, provinientes de la encuesta que pasé a algunos de mis alumnos del Máster en IT Project Management de la UPC School.

Como cada empresa adapta y evoluciona el uso de Scrum, quería saber cómo lo hacen en los aspectos básicos y aquí está el resultado.

P4.1. ¿Cuál es la duración de tus iteraciones?

Scrum recomienda que las iteraciones duren hasta un mes, aunque existen diferentes opiniones de cual es la duración óptima. Probablemente no haya una duración única recomendable para diferentes equipos y proyectos, por lo que la tendencia más aceptada corresponde a que cada equipo escoja la duración de sus iteraciones como parte del aprendizaje y evolución usando este proceso.

Una duración demasiado corta puede introducir una sobrecarga innecesaria de gestión, pruebas o reuniones, mientras que una duración excesiva puede hacer “perder el ritmo” tanto dentro del equipo como entre el equipo y el cliente.

Mi experiencia es que la mayoría de los grupos que han madurado Scrum suelen ir a una duración de 2 semanas, combinándolas con iteraciones de 3 semanas en caso que la iteración produzca una release. He visto otras duraciones y sí tengo constancia que casi todas las que iban más allá de 4 semanas provocaban problemas de desviaciones y bajadas en la confianza del equipo.

Los resultados de los que respondieron la encuesta parecen alinearse con esta tendencia, incluso manteniéndose muy estrictos en no superar las 2 semanas (2 de cada 3).

P4.1. ¿Cual es la duración de tus iteraciones?	Total
1. 1-2 semanas	8
2. 2-3 semanas	3
3. 1 mes	1
Respuestas	12

 

P4.2. ¿Cual es el tamaño de un equipo?

El tamaño de los equipos normalmente queda fuera del alcance de decisión de los equipos y es un factor ligado usualmente al tamaño de la empresa. Las empresas más pequeñas suelen realizar proyectos de menor tamaño y su dimensión no les permite formar equipos grandes.

En el caso de los participantes, es unánime el tamaño pequeño de los equipos, aunque este dato no puede correlacionarse con otros como el tamaño de la empresa o de los proyectos al carecer de estos últimos datos.

P4.2. ¿Cual es el tamaño de un equipo?	Total
1. 3-5 miembros	12
2. 6-10 miembros	0
3. 10-15 miembros	0
4. Más de 16 miembros	0
Respuestas	12

 

P4.3. ¿Desarrolláis un producto o proyectos para terceros?

Otra de las tendencias sobre Scrum, combinado también con su posicionamiento, es que esta metodología se usa mayoritariamente en proyectos internos o de desarrollo de producto.

Esto se suele deber a que los proyectos externos suelen tener alcances definidos y cerrados por contrato, mientras que el desarrollo de producto encaja muy bien con las condiciones que obtienen el mejor resultado de Scrum, como la confianza entre los roles y la flexibilidad que se requiere.

Los resultados de esta pregunta también pueden interpretarse según este posicionamiento, la casi totalidad de los encuestados desarrolla producto propio, aunque algunos lo compaginan con proyectos externos.

P4.3. ¿Desarrollais un producto o proyectos para terceros?	Total
1. Sólo producto propio	9
2. Producto propio y proyectos	2
3. Sólo proyectos	1
Respuestas	12

 

P4.4. ¿Cuántos proyectos habéis desarrollado con SCRUM?

Para poder realizar la encuesta con garantías, hice un sondeo previo que indicaba que la mayoría de los alumnos conocían Scrum y muchos lo habían usado en proyectos.

Como se menciona en otras preguntas, la madurez en el uso de Scrum suele influir en algunos parámetros de uso, como el tamaño de las iteraciones o mejora en la confianza que éste genera en la organización.

En este caso, la mayoría de los participantes en la encuesta han usado poco Scrum, aunque el planteamiento de las preguntas no deja claro si alguno de estos no ha usado este proceso en proyectos reales.

P4.4. ¿Cuántos proyectos habeis desarrollado con SCRUM?	Total
1. Menos de 5	8
2. De 5 a 10	0
3. Más de 10	0
Sin respuesta	4
Respuestas	12

 

P4.5. ¿Qué herramientas usais para SCRUM?

Finalmente, se preguntó por el medio usado para realizar la planificación y seguimiento del Sprint.

Las tendencias más puristas optan por el uso de elementos físicos como los PostIt para mostrar la evolución del trabajo en un lugar permanente y compartido por el equipo. Otras herramientas de software pueden ser centralizadas, como hojas de cálculo, o trackers funcionando sobre una base de datos.

Los resultados de la encuesta muestran que el uso está polarizado entre PostIt, probablemente combinando Scrum con Kanban, mientras que los demás usan trackers. Aquí, además de realizar la observación, no puedo realizar correlaciones con otras respuestas. A nivel personal, soy un claro partidario de usar un tracker (probablemente soportado por una pantalla o televisión grande) pues la eventual pérdida de espontaneidad queda sobradamente compensada por el mejor control del avance, del trabajo, de la trazabilidad con el repositorio, etc.

Una opción que sería interesante añadir a la pregunta sería el uso combinado de PostIt más tracker, ya que probablemente sea usado por algunos encuestados.

P4.5. ¿Qué herramientas usais para SCRUM?	Total
1. PostIT	7
2. Pizarra	0
3. Hojas de cálculo	0
4. Trackers tipo Jira-Redmine	5
Respuestas	12

 

Conclusiones

Las conclusiones generales de estas respuestas no permiten hacer grandes inferencias ni presentan descubrimientos demasiado sorprendentes.

Se observa que los participantes tienen, en media, poca experiencia con Scrum y han participado en proyectos pequeños, generalmente de desarrollo de producto.

Para saber más

Post de Javier Garzás sobre la Encuesta anual Versionone sobre el uso de Agile 

Encuesta sobre el uso de SCRUM (2 de 4)

Encuesta sobre el uso de SCRUM (2 de 4)

En el artículo anterior se analizaban las respuestas sobre las ventajas percibidas por Scrum, provinientes de la encuesta que pasé a algunos de mis alumnos del Máster en IT Project Management de la UPC School.

En esta continuación del análisis, me centraré en el bloque de preguntas que trata sobre otra parte que no suele “airearse” demasiado: las dificultades reales de adopción y aprovechamiento de Scrum.

Desafíos de SCRUM

P3.1. Adecuación a mi proyecto o empresa.

La primera pregunta se plantea como encaja Scrum con la empresa del encuestado, donde pueden influir factores como la cultura de la empresa, de las personas concretas que forman el equipo del encuestado, si la empresa realiza proyectos externos o internos, o si existe poca o mucha volatilidad de los miembros de los equipos, entre otras.

La opinión mayoritaria es bastante clara, 2 de cada 3 encuestados opina que no se adapta bien (poco o nada). Buscando una explicación a esta respuesta, en las preguntas del bloque Ventajas de Scrum se identifica la tendencia que los equipos aprecian los beneficios internos de Scrum más que en la interacción con otras figuras de la empresa, posiblemente porque éstas no conozcan bien o crean en la efectividad de Scrum.

En este caso, podríamos encontrarnos con una explicación similar, los miembros de los equipos pueden pensar que “quien manda” no está por la labor de adaptarse a la filosofía de Scrum, más que la posibilidad que la empresa no fuese capaz de sacar un rendimiento a su uso, como principal impedimento para la adopción de Scrum.

P3.1. Adecuación a mi proyecto o empresa.	Total
1. Nada	2
2. Poco	6
3. Bastante	4
Respuestas	12

 

P3.2. Credibilidad de los métodos ágiles respecto a los tradicionales.

Esta segunda pregunta se interesa por una de las posibles dificultades más habituales de cualquier cambio en una organización, la falta de credibilidad en el nuevo modelo.

Ya decía Maquiavelo en El Principe, su célebre tratado sobre política, que los cambios suelen ser difíciles porque quienes creen que van a perder con ellos oponen resistencia y quienes van a ganar, no suelen saberlo y por tanto, no presionan a favor de éstos.

Centrándonos más en el terreno práctico, creo es es una opinión consensuada que las metodologías ágiles son principalmente “de techies para techies”. Muchos jefes de proyecto con largo recorrido, y los directores de área, suelen ver su función más como un “control de horas” donde los “cambios” deben ser minimizados porque sólo traen desviaciones, que una participación activa en el proyecto para maximizar el valor entregado al cliente y mantener el equilibrio entre alcance y recursos de manera proactiva.

Otra opción realista, y en ocasiones compatible, es pensar que Scrum puede no adaptarse realmente a la empresa y al tipo de relación que se establece con los clientes. Algunos factores comunmente identificados (ver [1], [2] y [3]) son:

·         Proyectos con una gran inversión en materiales

·         Proyectos con un alcance y fecha comprometidos a priori

·         Mantenimientos correctivos urgentes (¡Kanban!)

·         Etc.

La metodología en general es poco conocida, apreciada y vista como una herramienta efectiva para solucionar los males endémicos de muchos grupos de desarrollo. Dentro de esta visión pesimista, las metodologías de gestión de proyectos tradicionales han conseguido abrirse paso más que las ágiles, probablemente porque muchos de aquellos que tienen capacidad de decisión hoy en día sobre si adoptarlas o no, se vieron expuestos a ellas en funciones de desarrollo antes de la llegada de las metodologías ágiles.

P3.2. Credibilidad de los métodos ágiles respecto a los tradicionales.	Total
1. Nada	2
2. Poco	7
3. Bastante	3
Respuestas	12

 

P3.3. Falta de soporte de la gerencia.

Este es otro de los factores clásicos, y fatales, para el cambio en las organizaciones. Sin el soporte de la gerencia, habitualmente con sus propias preocupaciones y percepción de las prioridades, es muy difícil que ningún cambio llegue a buen puerto y sea sostenible.

En este caso, no se observa un escenario tan desfavorable, 5 de los 12 opina que la gerencia le apoya bastante o mucho. Aún así, es una cifra baja que puede explicar porque muchos proyectos de implantación de Scrum fracasan y porqué la percepción de los miembros de los equipos es pesimista respecto a la capacidad de la organización de adoptar esta metodología (P3.1).

P3.3. Falta de soporte de la gerencia.	Total
1. Nada	4
2. Poco	3
3. Bastante	3
4. Mucho	2
Respuestas	12

 

P3.4. Falta de conocimientos internos para implentar SCRUM.

Esta pregunta trata de identificar la preparación de los encuestados, tanto teórica como práctica, para implementar esta metodología y trabajar regularmente con ella.

Dado que no todos los encuestados han usado Scrum en sus empresas, se puede considerar normal que sólo el 50% considere que esto no sería un problema.

P3.4. Falta de conocimientos internos para implentar SCRUM.	Total
1. Nada	3
2. Poco	3
3. Bastante	3
4. Mucho	3
Respuestas	12

 

Conclusiones

A nivel general, teniendo en cuenta los beneficios que observan los encuestados sobre Scrum y las dificultades que afirman, podría pensarse que Scrum es una metodología que se ve útil pero que no tiene un gran conocimiento y aceptación fuera de los equipos, y a menudo también dentro de los propios equipos.

Para vencer este desconocimiento y falta de credibilidad, los desarrolladores que quieren implementarlo deberían llevar la argumentación sobre los beneficios de Scrum al contexto y preocupaciones de los gerentes. Algunas de estos factores deberían ser:

·         Capacidad de vender y planificar los proyectos con un riesgo económico asumible

·         Capacidad de dar un seguimiento claro conjuntamente los clientes

·         Posibilidad de mantener el control por parte de la dirección

Para leer más

 [1] Linkedin Group [Agile and Lean Software Development] - Should Scrum be used for Specific project types?

[2] Scrum Aliance - What to do when Scrum does not work

[3] VANWYNSBERGHEA - Why Scrum doesnt work for us