Con base en los recursos de la semana unos comprenderán los aspectos teóricos

sobre la gestión de proyectos.

Ahora les pido realizar una investigación compartiendo dos casos reales sobre un
proyecto de gestión exitoso y otro que haya fracasado, identificando en cada uno
mínimo tres factores decisivos para que ello sucediera.

Casos con éxito de proyecto:

Spotify

Una empresa que ha sabido adaptarse perfectamente a las metodologías ágiles

es Spotify, haciendo especial hincapié en la figura del Scrum Master. Muchas
veces contratan un Agile Coach externo con una gran experiencia en el campo
para liderar los proyectos. Vemos aquí la importancia de contar con roles
especializados que conozcan las metodologías ágiles para llevar un proyecto de
este tipo al éxito. Ya no solo el Scrum Master, sino también otros roles como el
Product Owner, responsable de entender al cliente y al usuario para saber
trasladar en tiempo y forma la información adecuada al equipo de desarrollo.
Spotify es consciente de la metodología de trabajo de su competencia (Google o
Apple, por ejemplo), por lo que decidieron acercarse al Scrum de forma muy
sistemática. Compitiendo contra semejantes corporaciones, sabían que en
cualquier momento podrían ser derrotados a menos que fuesen más rápidos, más
baratos y mejores. Por ejemplo, fijémonos en el nuevo iTunes Radio, ofrece
exactamente lo mismo que Spotify. Es por eso que han tenido que mejorar sus
equipos de trabajo para asegurarse que van más rápido. En Spotify los equipos se
organizan por escuadrones (squads), pequeños equipos de Scrum con la habilidad
de implementar el software desarrollado al final de cada sprint, sin romper ningún
otro equipo. Una característica curiosa del funcionamiento de Spotify es que cada
uno de estos pequeños grupos tiene una parte del producto que es totalmente
suyo. Después crean tribus (tribes) agregando distintos escuadrones. Scrum
(proceso en el que se aplican de manera regular un conjunto de buenas prácticas
para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible
de un proyecto).

Primer proyecto de fotocopiadora

El original de la copia. - Chester Floyd Carlson (1906-1968) era un físico

estadounidense que en1938 pasaba sus horas en el departamento de patentes de
una firma electrónica, copiando a mano centenares de documentos con planos,
especificaciones, etc. Así fue como se obsesionó con la idea de diseñar un
aparato que copiase documentos rápidamente. Tras abandonar la empresa, y
utilizando su propio dinero para financiar los experimentos, logró construir el
primer prototipo de fotocopiadora, tomando como base un material fotoconductor
que se cargaba de electricidad estática sólo en las zonas iluminadas. En 1940
obtuvo la primera de varias patentes para su proceso, denominado xerografía.
Después inició un peregrinaje para encontrar empresas que se embarcasen en su
comercialización, recibiendo más de 20 negativas, entre ellas la de IBM, que
calificó el invento como inútil. En 1947 la empresa Haloid se asoció al desarrollo
de esta tecnología, aunque la primera fotocopiadora (Xerox914) no se introdujo en
el mercado hasta 1959.

Caso con proyecto de no éxito:

Hesalthcare.gov

Healthcare es un proyecto del gobierno americano diseñado para ofrecer toda la

información y transparencia sobre el mercado de los seguros sanitarios, para que
los consumidores puedan asegurarse de obtener el mejor valor. Jeff lo cita como
ejemplo de mala gestión de un proyecto Scrum. Las principales causas del fracaso
en el desarrollo de Healthcare fueron la falta de coordinación entre el Front End y
el Back End, la falta de liderazgo en un proyecto con más de 20 consultoras
implicadas y no haber lanzado el proyecto fase a fase sin testeo ni aprendizaje de
por medio, haciendo que fuese imposible detectar las fases que sí funcionaban y
las que no. Según Jeff Sutherlands, el fracaso de este proyecto no debería
sorprendernos tanto ya que se trata de un proyecto de desarrollo en cascada, y
afirma que el 86% de este tipo de proyectos suelen acabar en fracaso. Tras
trabajar en el desarrollo durante varios años, sólo se tuvieron seis días para
testear la aplicación debido a las presiones para el inminente lanzamiento. Es de
entender que con tan corto periodo de testing el proyecto no saliese bien lo que
provocó que, aunque el equipo del Back End realmente trabajó como un proyecto
ágil y en unos meses ya habían terminado su trabajo, el error estuvo en no
respetar el segundo principio del manifestó Agile de aceptación del cambio:
“Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo.
Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva
al cliente.” Así que por mucho que acabasen el desarrollo, no lograron que
funcionase.

Referencias bibliográficos:
Iebschool. (2014). Éxitos y fracasos en proyectos Scrum: Spotify vs. Cuidado de la
salud. Pensando para la Innovación . https://www.iebschool.com/blog/exitos-y-
fracasos-en-proyectos-scrum-spotify-vs-healthcare-agile-scrum/