Transformación Ágil A Gran Escala en Ericsson

TRANSFORMACIÓN ÁGIL A GRAN ESCALA EN ERICSSON: UN ESTUDIO DE CASO.
Autores: Paasivaara, M., Behm, B., Lassenius, C., y Hallikainen, M. (2018).

Ingeniería de software empírico.
Octubre 2018, Volumen 23, Número 5, pp 2550–2596
TABLA DE CONTENIDO
1. Antecedentes del problema de investigación .................................................................. 2

2. Problema de investigación ............................................................................................. 3
3. Propósito de la investigación ......................................................................................... 4
4. Naturaleza del estudio ................................................................................................... 4
5. Preguntas de investigación / hipótesis ............................................................................ 6
6. Marco teórico ................................................................................................................ 6
7. Definición de términos ................................................................................................... 9
8. Limitaciones ................................................................................................................ 10
9. Hallazgos principales ................................................................................................... 10
10. Estudios relacionados............................................................................................... 14
11. Conclusiones. ........................................................................................................... 16
12. Referencias ............................................................................................................... 18
Transformación Ágil a Gran Escala en Ericsson: Un Caso de Estudio
Autores: Paasivaara, M., Behm, B., Lassenius, C., y Hallikainen, M. (2018). Elaborado Por: Álvaro Acuña López.
1. Antecedentes del problema de investigación
El artículo titulado “Transformación Ágil a Gran Escala en Ericsson: Un estudio de Caso”, utiliza
la metodología de estudio de caso (Yin 2009 ), en una organización de desarrollo de software en
Ericsson que trabaja en una plataforma XaaS y un conjunto de servicios relacionados (productos).
El producto proporciona un conjunto de servicios a los clientes comerciales, que lo utilizan para
proporcionar servicios a sus clientes. Originalmente, la plataforma estaba diseñada para un solo
cliente. En el momento de la investigación, el producto estaba en su ciclo de vida inicial con
decenas de clientes, cuya cantidad se esperaba que creciera rápidamente, y se consideraba que el
producto tenía un gran potencial de mercado.
Arquitectónicamente, el producto consistía en módulos, posteriormente denominados
componentes. Algunos componentes fueron desarrollados por terceros y otros por Ericsson. El
desarrollo de los componentes requirió experiencia altamente especializada debido a su
complejidad.
Ericsson adquirió el producto en 2011. Antes de la adquisición, aproximadamente 30 a 35
personas, incluidos contratistas externos y consultores, desarrollaron toda la plataforma. Como
parte de la adquisición, Ericsson contrató a unos diez expertos en dominios de la organización de
desarrollo anterior y se hizo cargo del desarrollo del producto. Inmediatamente después de la
adquisición, la organización, en nueva construcción tuvo que centrarse en la transferencia de
conocimientos de los consultores externos a los empleados de Ericsson y a los consultores recién
contratados.
La organización de desarrollo en Ericsson creció rápidamente: de dos equipos a fines de 2011 a 10
equipos en la primavera de 2013 y 15 equipos en la primavera de 2014. Se agregaron nuevos
desarrolladores y equipos a la organización gradualmente. Los mayores aumentos se produjeron a
2
fines de 2012 y durante 2013. En el 2012, una consultoría externa proporcionó personal para el
proyecto, y se realizó la contratación interna y externa. Durante el año 2013, se agregaron cinco
equipos ágiles, parte de los cuales se reasignaron de otro proyecto en Ericsson.
Durante este tiempo, el tamaño de la organización aumentó de unas pocas docenas a alrededor de
200. En el año 2014, la organización de desarrollo consistió en equipos ágiles (que generalmente
consistían de 7-9 personas), propietarios de productos, arquitectos, entrenadores ágiles, gerentes
de línea, gerentes de producto y otros gerentes. Además, la organización incluía personal de ventas,
y soporte y operaciones al cliente.
Las competencias para cada componente en muchos casos no estaban ubicadas en un solo sitio,
sino que se distribuían a varias ubicaciones. Además, una sola característica podría abarcar varios
componentes, lo que requiere una experiencia diferente para desarrollar.
Ericsson ha utilizado tradicionalmente un proceso de software basado en planes. Sin embargo,
durante los últimos años, la compañía comenzó una adopción global de desarrollo de software ágil.
La organización estudiada comenzó su transformación, o "el viaje ágil", como lo llaman, a fines
de 2012 y el primer equipo piloto ágil se formó a principios de 2013. Esta transición ha sido
particularmente desafiante, ya que el crecimiento organizacional ha sido significativo y rápido.
Durante la transformación, que todavía está en curso.
2. Problema de investigación
La alta competitividad en los mercados digitales exige a las empresas un proceso de cambio, tanto
en la organización como en la cultura de la misma, en los equipos y en la propia reestructuración
de las dinámicas de trabajo.
Muchas organizaciones grandes están adoptando el desarrollo ágil de software como parte de su
impulso continúo hacia una mayor flexibilidad y tiempos de entrega más cortos, sin embargo,
3
existe un vació literario científico en las investigaciones acerca de su implementación, desafíos y
éxitos sobre transformaciones ágiles a gran escala, lo que genera dudas de las empresas frente la
decisión de implementar transformaciones agiles y/o continuar competiendo en el mercado con
metodologías tradicionales (Dikert et al. 2016 ).
3. Propósito de la investigación
El propósito del artículo científico en estudio, es aportar información científica para llenar el vacío
en la literatura actual sobre transformaciones ágiles a gran escala en la industria. Tomando como
caso de estudio, el desarrollo de un nuevo programa de desarrollo de productos que utiliza una
plataforma XaaS 1 y un conjunto de servicios de I + D a gran escala dentro de Ericsson, quienes
adoptaron métodos ágiles a escala.
La presente investigación, nos revela, como Ericsson, impulsó su motivación para la
transformación, los pasos tomados, los desafíos encontrados, así como las medidas de mitigación
tomadas para enfrentarlos.
4. Naturaleza del estudio
El enfoque de investigación que utilizaron los autores del artículo de transformación ágil a gran
escala en la empresa Ericsson, fue un enfoque cualitativo, utilizando el paquete de software
Atlas.ti. Mediante el cual, se codificaron los datos en seis categorías principales: cuatro temas
principales de acuerdo con las preguntas de investigación y dos categorías de contexto, es decir,
la estructura de la organización y los antecedentes del caso.
El tipo de alcance de esta investigación fue exploratoria, cuyo fin fue conocer el contexto del
fenómeno de la transformación ágil a gran escala en la empresa Ericsson. Su objetivo fue encontrar
4
todas las pruebas relacionadas con el fenómeno del que no se tiene ningún conocimiento y
aumentar la posibilidad de realizar una investigación completa.
La recolección de datos se realizó entre septiembre de 2013 y septiembre de 2014. Utilizando tres
fuentes de datos: 1) entrevistas, 2) observaciones y 3) documentos internos de la compañía.
Los tres primeros autores recogieron los datos juntos. El cuarto autor, un representante de la
organización, fue la persona de contacto principal durante el estudio, así como uno de los
informantes clave. Contribuyó a seleccionar a los entrevistados y organizó el acceso a los eventos
que se analizaron. La figura 1 muestra la línea de tiempo de recolección de datos.
Ilustración 1.Cronología recolección de datos
Se realizaron un total de 45 entrevistas semiestructuradas en tres rondas: 1) 31 entrevistas sobre el
viaje de transformación, 2) doce entrevistas sobre talleres de valor (que fueron uno de los pasos
principales durante el viaje de transformación que se describe más adelante) y 3) Dos entrevistas
de validación después de analizar los datos.
Para apoyar las entrevistas, se llevaron a cabo cinco sesiones de observación de un total de 31,5
horas durante siete días. Los eventos observados se seleccionaron cuidadosamente para respaldar
el respectivo estudio: 1) para ver cómo se implementaron las prácticas básicas de Scrum en la
5
organización de casos. 2) Para comprender cómo funcionaron en la práctica los principales eventos
de coordinación, 3) Para seguir los principales eventos de transformación.
Además, se recabaron una serie de documentos de los entrevistados. Estos documentos se
utilizaron para triangular y complementar la información recibida en las entrevistas.
En el momento de la recopilación de datos (2013 -2014), la organización Ericsson, se distribuyó
en cinco sitios en tres países, cuatro de los sitios estaban en Europa y uno en Asia.
5. Preguntas de investigación / hipótesis
Los autores del artículo en mención, plantearon las siguientes preguntas de investigación:
RQ1: ¿Por qué la organización inició una transformación ágil?
RQ2: ¿Cómo procedió la transformación?
RQ3: ¿Qué desafíos enfrentó la organización?
RQ4: ¿Cómo mitigó la organización los desafíos?
6. Marco teórico
El aumento de la presión para reducir el tiempo del ciclo, mejorar la calidad y reaccionar
rápidamente a los cambios en las necesidades de los clientes está impulsando a las empresas,
grandes y pequeñas, a adoptar un desarrollo ágil de software (VersionOne 2016). El desarrollo ágil
puede mejorar la eficiencia y la calidad (Livermore 2008a) y permitir tiempos de entrega más
cortos y un mayor enfoque en las necesidades de los clientes (Petersen y Wohlin 2010).
A pesar de que los métodos de desarrollo de software ágil se diseñaron originalmente para equipos
pequeños y medianos, durante los últimos años, las grandes organizaciones los han adoptado cada
vez más (Hossain et al. 2009; Larman and Vodde 2010; Leffingwell 2007). Una reciente revisión
sistemática de la literatura (Dikert et al. 2016) reveló la falta de estudios sistemáticos sobre grandes
organizaciones de desarrollo de software que adoptan métodos ágiles. La revisión identificó solo
6
seis estudios científicos sobre transformaciones ágiles a gran escala, ya que casi el 90% de los
artículos incluidos eran informes de experiencia. Según la Encuesta Estado de Agile (VersionOne
2016), El 43% de los encuestados auto-seleccionados trabajaron en organizaciones de desarrollo
y más del 50% de los equipos utilizaron ágil, mientras que solo el 4% de los encuestados declararon
que ninguno de sus equipos era ágil y el 62% de casi 4.000 encuestados procedían de una
organización con más de cien personas en desarrollo de software. Si bien la encuesta no es
científica y es problemática desde un punto de vista metodológico (Stavru 2014), es la encuesta
recurrente más grande sobre adopción ágil, e indica que un número significativo de grandes
organizaciones lo utilizan ágil. Además, los profesionales de la conferencia de XP en 2010
mencionaron el tema "Proyectos ágiles y grandes" como la pregunta de investigación principal
más importante (Freudenberg y Sharp 2010).). En los talleres recientes sobre desarrollo ágil a gran
escala, la introducción de métodos ágiles fue uno de los temas resaltados que necesitaban más
investigación (Dingsøyr y Moe 2013; 2014).
Las organizaciones grandes a menudo tienen grandes proyectos ejecutados por organizaciones de
desarrollo grandes y distribuidas, que requieren métodos ágiles para escalarse. Según (Leffingwell
2007), el escalado implica muchos desafíos, incluida la coordinación entre varios equipos ágiles,
la falta de una arquitectura inicial, la falta de análisis de requisitos, así como todos los desafíos de
los proyectos distribuidos, ya que se distribuyen muchas organizaciones grandes. A pesar de estos
desafíos, muchas empresas grandes han optado métodos ágiles, a pesar de que la investigación es
escasa sobre cómo escalar métodos ágiles para proyectos a gran escala (Hossain et al. 2009) y
sobre cómo realizar con éxito transformaciones ágiles en grandes organizaciones falta en gran
medida (Dikert et al. 2016).
7
6.1. Desarrollo ágil a gran escala

Los métodos ágiles se desarrollaron originalmente para organizaciones pequeñas y, a pesar de las
historias de éxito, la aplicación a gran escala ha resultado ser un desafío (Dybå y Dingsøyr 2008).
Los desafíos en las adopciones ágiles a gran escala se relacionan en parte con el tamaño de la
organización que genera inercia, lo que ralentiza el proceso de cambio (Livermore 2008b). Otro
desafío es la necesidad de interactuar con los procesos existentes y las estructuras organizativas
(Boehm y Turner 2005).
6.2. Motivación para iniciar una transformación ágil.

Según la literatura, una de las principales razones para que una gran organización de desarrollo de
software inicie una transformación ágil es reducir el tiempo de comercialización (Gat 2006; Goos
y Melisse 2008; McDowell y Dourambeis 2007; Prokhorenko 2012; Silva y Doss 2007), a medida
que la competencia y la situación del mercado cambian hacia entregas más rápidas (Greening
2013). Las empresas quieren mejorar su competitividad, o incluso temer que están perdiendo
competitividad. Por lo tanto, su respuesta es mejorar la velocidad de entrega y la capacidad de
respuesta al cambio.
6.3. Desafíos y factores de éxito de las transformaciones ágiles a gran escala.

Cualquier transformación organizacional que involucre a numerosos individuos enfrentará
desafíos. Una revisión sistemática de la literatura (Dikert et al. 2016) identificó 29 factores de éxito
para transformaciones ágiles a gran escala agrupadas en 11 categorías y 35 desafíos en 9 categorías.
La revisión identificó los siguientes desafíos principales para las transformaciones ágiles a gran
escala: otras funciones que no están dispuestas a cambiar (mencionadas por el 31% de los casos
informados), falta de orientación de la literatura (21%), y vuelven a la antigua forma de trabajar
(19 %) y malinterpretación de conceptos ágiles (19%). Las principales categorías de desafíos
8
mencionadas fueron ágiles, difíciles de implementar, que integran funciones de no desarrollo,
resistencia al cambio y desafíos de ingeniería de requisitos.
7. Definición de términos
 Métodos ágiles:
Los estudios secundarios sobre ingeniería de requisitos ágiles han sido realizados recientemente
por Inayat et al. (2015) y Heikkilä et al. (2015a). Sus conclusiones se resumen a continuación. Por
definición, las metodologías ágiles son aquellas que permiten adaptar la forma de trabajo a las
condiciones del proyecto, consiguiendo flexibilidad e inmediatez en la respuesta para amoldar el
proyecto y su desarrollo a las circunstancias específicas del entorno.
 Gestión de proyectos agiles.
Se denomina Agile Project Management a un conjunto de metodologías que permiten el desarrollo
de proyectos que precisan de una especial rapidez y flexibilidad en su proceso y en especial,
aquellos desarrollados en entornos dónde encontramos una incertidumbre muy alta. Se diferencia
de la Gestión Predictiva o tradicional de los proyectos en que esta define con detalle cuál es el
producto entregable previsto a desarrollar, elaborando un plan para el desarrollo que permite
seguimiento y control para evitar desviaciones.
 Gobernanza del proyecto.
Plumptre y Graham (1999) plantean que gobernanza es el arte de manejar sociedades y
organizaciones.
 Gestión del portafolio de proyectos (PPM).
Es la gestión a nivel central y superior de una organización de uno o más portafolios, lo que incluye
la identificación, priorización, autorización, administración y control de los programas, proyectos
9
y otras actividades o trabajos que permiten alcanzar los objetivos estratégicos de la organización
o negocio. La gestión de portafolio combina: a) un enfoque en ámbito de la organización que
asegura que los proyectos de inversión seleccionados respondan a la estrategia del portafolio; con
b) el enfoque de la administración de proyectos para que estos contribuyan efectivamente al
portafolio. Rónald Miranda. Sinopsis de la gestión de portafolios. Enero del 2010.
 Gestión de programas.
La gestión de programas es el proceso de negocios que se encarga de coordinar las complejas
interdependencias que existen entre un grupo de proyectos de desarrollo de productos
relacionados, en particular los que están regidos por un contrato entre empresas. J.S. Pennypacker
“The Value of Project Management,” (2002) Center for Business Practices, PM Solutions
 Gestión de proyectos.
La gestión de proyectos es la disciplina que estudia el planeamiento, la organización, la motivación
y el control de los recursos con el propósito de alcanzar uno o varios objetivos.
8. Limitaciones
Como parte de este estudio, los investigadores visitaron todos los sitios europeos donde Ericsson
tenía oficinas. Pero debido a restricciones presupuestarias, no se visitó el subcontratado de Asia,
Sin éstos resultados, la investigación se focalizó en los principales sitios de Europa, ya que fue allí
donde tuvo lugar la transformación ágil a gran escala. El sitio en Asia, como un sitio externo, no
se incluyó activamente en la transformación.
9. Hallazgos principales
A continuación, le detallamos los principales hallazgos y lecciones aprendidas.
 Motivación para las transformaciones ágiles.
10
En esta sección, los autores discuten y analizan la primera pregunta de investigación, RQ1: ¿Por
qué la organización inició una transformación ágil?
La organización tenía tres motivaciones principales para la transformación: alineación con la
estrategia corporativa, insatisfacción con la forma actual de trabajar y la necesidad de habilitar
entregas rápidas de características y despliegue continuo.
Las dos últimas motivaciones también han sido ampliamente divulgadas en la literatura. Varios
casos discuten problemas y disfunciones con sus procesos anteriores como motivadores para
adoptar ágil, (por ejemplo, O'Connor 2011; Chung and Drummond 2009; Vlaanderen et al. 2012;
Hansen y Baggesen 2009; Murphy and Donnellan 2009). La necesidad de entregas rápidas y el
despliegue continuo se relacionaron con la necesidad de obtener nuevas funciones para el mercado
más rápidamente, es decir, reducir el tiempo de comercialización, informado anteriormente (por
ejemplo, Gat 2006 ; Goos y Melisse 2008 ; Greening 2013 ; McDowell y Dourambeis 2007 ;
Prokhorenko 2012; Silva y Doss, 2007 ).
 Fases de transformación ágil a gran escala
En esta sección, los autores del artículo en estudio, desarrollan la segunda pregunta de
investigación, RQ2: ¿Cómo se produjo la transformación?
La transformación comenzó con una fase piloto con voluntarios trabajando en un equipo ágil. Esto
funcionó notablemente bien, lo cual no fue inesperado, ya que varios autores lo mencionaron, (p.
Ej., Berczuk y Lv 2010; Chung y Drummond 2009; Fecarotta 2008; O'Connor 2011). El equipo
piloto se desmanteló y se inició una transformación a gran escala después de poco tiempo por dos
razones: el equipo pudo demostrar rápidamente que Agile podía funcionar bien en la organización
y las otras partes de la organización comenzaron a sufrir. Los voluntarios para el piloto eran
desarrolladores altamente calificados y activos, y su ausencia de sus equipos componentes se sintió
11
profundamente, ya que ahora se convirtieron en un equipo "estelar", que no era óptimo desde el
punto de vista de la organización. Este problema relacionado con el piloto se ha discutido en
(O'Connor 2011).
Debido a la naturaleza distribuida de la organización, los diferentes sitios tenían opiniones
divergentes con respecto al futuro del producto y la forma de trabajar. Por lo tanto, era necesario
alinear las distintas partes de la organización para hacer un trabajo ágil y crear una identidad
organizativa y de producto sólida. Con este fin, la organización organizó "talleres de valor", en los
que se discutieron los valores organizacionales comunes, y las personas de los distintos sitios
pudieron reunirse cara a cara.
 Desafíos y mitigaciones en las transformaciones ágiles a gran escala
En esta sección, los autores del artículo en estudio, desarrollan la tercera y cuarta preguntas de
investigación, RQ3: ¿Qué desafíos enfrentó la organización? y RQ4: ¿Cómo mitigó la
organización los desafíos?
Durante la transformación, la organización enfrentó varios desafíos que intentaron mitigar. A
continuación, se relacionan los desafíos y las mitigaciones de acuerdo con la clasificación de
desafíos por (Dikert et al. 2016, Tabla 11, p. 95), con el fin de facilitar la comparación con la
literatura.
La primera categoría, “resistencia al cambio”, un problema común en las transformaciones ágiles
a gran escala (Dikert et al. 2016), también fue visible en el caso de estudio. La transformación tuvo
desafíos al principio, ya que todos los miembros del equipo de liderazgo no apoyaban
completamente la agilidad y querían enfocarse en las entregas en lugar de transformar la
organización. La situación se resolvió reorganizando el equipo de liderazgo para involucrar a más
personas con experiencia ágil.
12
La categoría “falta de inversión”, contiene los elementos de falta de capacitación, falta de
entrenamiento, carga de trabajo demasiado alta, compromisos antiguos y desafíos en la
reorganización de los espacios físicos.
La categoría "Ágil, difícil de implementar", contiene los elementos que malinterpretan los
conceptos ágiles, la falta de orientación de la literatura, la ágil personalización deficiente, el retorno
a la antigua forma de trabajar y el entusiasmo excesivo. En nuestro caso, la organización mencionó
la falta de orientación de la literatura. De manera similar a (Benefield 2008), la organización tuvo
problemas para encontrar un buen equilibrio entre control y autonomía, dando a los equipos
demasiada libertad, ya que no se enfatizó un marco ágil común.
La categoría "Desafíos de ingeniería de requisitos" no fue, inesperadamente, bastante visible en el
caso. El estudio de la literatura menciona problemas con la gestión de requisitos de alto nivel, los
desafíos de refinar los requisitos, la dificultad de definir y estimar historias de usuarios, así como
una brecha entre la planificación a largo y corto plazo.
En el estudio de caso estudiado, se recopilaron cuatro lecciones que podemos aprender de esta
organización de casos.
 Lección 1: Enfoque de transformación experimental:
La organización de casos adoptó una "mentalidad ágil" en su enfoque de transformación
experimental. La razón de esto fue que era difícil determinar por adelantado cómo realizar la
transformación, a pesar del hecho de que parte de la organización tenía experiencias previas en la
transformación de un gran programa de desarrollo de productos de cascada a ágil.
 Lección 2: Transformación por pasos
Como una adopción ágil y ágil a gran escala es una gran empresa, Ericsson, realizó paso a paso.
En lugar de tratar de cambiar todo a la vez, se enfocaron en un cambio a la vez. Primero, se
13
centraron en los equipos: experimentaron para encontrar una configuración de equipo de trabajo y
lograr que todos los equipos ágiles funcionen bien. En segundo lugar, pretendían unificar la
organización altamente distribuida y encontrar una dirección común mediante la creación y el
trabajo con valores comunes. En tercer lugar, invirtieron en la creación de sistemas de
automatización y pruebas de CI, así como en la capacitación de toda la organización para poder
contribuir a esta nueva forma de trabajar.
 Lección 3: Intercambiabilidad limitada del equipo
Al comienzo de la transformación, la organización tenía el objetivo de que cualquier equipo ágil,
multifuncional y de componentes cruzados pudiera implementar cualquier característica desde la
parte superior de la acumulación común. Sin embargo, pronto se dieron cuenta de que esto no era
factible, debido a la complejidad del producto y la asimetría de las competencias. El producto
estaba compuesto de varios componentes, cada uno de los cuales requería profundos
conocimientos técnicos. Los especialistas en componentes no se distribuyeron uniformemente a
diferentes sitios. Además, cada característica no tocaría todos los componentes, sino solo un
conjunto limitado.
 Lección 4: Falta de un marco ágil común
La organización dio a los equipos un margen de maniobra en la forma en que implementaron ágil,
quizás demasiado. La organización comenzó optando por Scrum y organizó capacitaciones en las
que, sin embargo, no todos participaron. Los antecedentes ágiles de los miembros del proyecto
variaron entre los sitios distribuidos dentro y fuera, ya que algunos habían participado en
capacitaciones y proyectos ágiles antes, mientras que otros había no.
10. Estudios relacionados
14
Durante los últimos años, varios consultores han sugerido marcos para escalar el desarrollo de
software ágil, por ejemplo, Scaled Agile Framework (SAFe) (Leffingwell 2015 ), Large-Scale
Scrum (LeSS) (Larman and Vodde 2015 ), y Disciplined Agile Delivery (DAD) (Ambler 2012 ).
Sin embargo, las experiencias documentadas sobre el uso de estos marcos aún son escasas, por
ejemplo, cómo se usan, a qué tipo de circunstancias son más adecuadas y cuáles son los desafíos
y los factores de éxito de su uso. Encuesta sobre el estado de Agile (VersionOne 2016) muestra
que un gran número de empresas parece estar usando algún marco, ya que el 27% de los
encuestados informó que usó SAFe, 6% LeSS y 4% DAD. Además, la mayoría de los encuestados
(72%) declararon usar Scrum o Scrum-of-Scrum para ayudar a escalar (los encuestados podrían
hacer selecciones múltiples).
Una reciente revisión sistemática de la literatura sobre transformaciones ágiles a gran escala
(Dikert et al. 2016) informó que solo seis, o el 12% de los 52 informes existentes eran científicos.
La mayoría de los artículos seleccionados fueron informes de experiencia publicados en las
conferencias de XP y Agile, que muestran el interés de los profesionales en el tema y que la
investigación académica se está quedando atrás.
Ninguno de los estudios científicos incluidos en la revisión sistemática de la literatura de (Dikert
et al. 2016) se centró directamente en el proceso de transformación, aunque lo describieron
brevemente. Dos de los documentos (Abdelnour-Nocera y Sharp 2007; 2008) que informaron
sobre el mismo caso se concentraron en los efectos de la transformación ágil. Un estudio sobre
Ericsson R&D Finland (Rodríguez et al. 2013) 2 se centró en cómo se implementa el pensamiento
Lean, sin embargo, la atención se centró principalmente en el estado actual en lugar del proceso
de transformación. Un artículo de Nokia Siemens Networks (Korhonen 2012).) estudiaron si la
visibilidad, la velocidad de reacción, la calidad o la motivación habían cambiado, comparando la
15
situación antes y después de la transformación. (Murphy y Donnellan 2009) estudiaron los
aspectos buenos y malos de la comunicación durante una transformación ágil y (Vlaanderen et al.
2012 ) en su estudio de casos múltiples de dos casos analizaron las rutas de introducción de Scrum.
Al evaluar la relevancia de cada uno de los trabajos de investigación con respecto a qué tan bien
proporcionan información sobre transformaciones ágiles a gran escala en una escala de 1 a 5 (1:
algunas oraciones revelan factores relacionados con la transformación, 5: todo el documento se
centra en describir cómo se realiza la transformación procedió). (Dikert et al. 2016) dio dos de los
documentos (Abdelnour-Nocera y Sharp 2007; 2008) (informando sobre el mismo caso) la
calificación 3, mientras que el resto recibió solo 1 (un documento) o 2 (3 documentos). Esto revela
cómo la investigación actual sobre las transformaciones ágiles a gran escala se está quedando a la
zaga del estado de la práctica.
11. Conclusiones.
El artículo científico en estudio, describe la transformación ágil a gran escala de un programa de
desarrollo de productos de Ericsson que desarrolla una plataforma XaaS y un conjunto de servicios
hacia su objetivo futuro de entrega continua de funciones. Los Autores presentan los pasos
tomados, los desafíos enfrentados y las medidas de mitigación tomadas, así como cuatro lecciones
aprendidas, de gran aplicabilidad a otras organizaciones.
Como se señaló en (Dikert et al. 2016 ), las transformaciones ágiles a gran escala rara vez son
fáciles, y la literatura ofrece pocos consejos sobre cómo proceder con éxito. Por lo tanto, estudios
de casos como este pueden ayudar a proporcionar una base para una comprensión más profunda
de las transformaciones ágiles en diversos contextos que se pueden usar para sintetizar, la
investigación de la construcción de la teoría.
16
Hay pocas investigaciones sistemáticas sobre la adopción ágil a gran escala (Dikert et
al. 2016 ). La literatura profesional sugiere varios marcos de escala que son promovidos
activamente por sus desarrolladores. Sin embargo, todavía faltan experiencias documentadas de
forma independiente sobre el uso, la personalización y los beneficios de estos marcos. Por lo tanto,
encontrar soluciones validadas sobre cómo debería verse el resultado final de una transformación
o qué pasos tomar es difícil.
Como los enfoques ágiles actuales no proporcionan buenos planos para el aspecto que debería
tener una organización ágil escalada, y los marcos de escalamiento recientes están en gran parte
sin validar, parece ser necesario que la organización adapte su enfoque ágil para que se ajuste a su
propio negocio organizativo y contexto del producto. En nuestro estudio de caso, por ejemplo, los
diversos enfoques para la organización en equipo y la introducción de flujos de negocios se pueden
ver como personalizaciones exitosas.
Si bien todas las organizaciones pueden sentir la necesidad de personalizar su enfoque ágil, los
problemas relacionados con la organización circundante, la complejidad de un producto grande y
la necesidad de competencias específicas parecen aumentar la necesidad de personalización del
método. Por lo tanto, creemos que esta necesidad es especialmente relevante en contextos ágiles a
gran escala.
Para futuras investigaciones, los autores del artículo, sugieren realizar estudios de casos
adicionales sobre transformaciones ágiles a gran escala, ya que la investigación en esta área es
escasa. Como lo demostró la revisión de la literatura (Dikert et al. 2016), solo existen algunos
estudios de caso, aunque el tema parece ser muy relevante para las grandes organizaciones de
desarrollo de software que se están moviendo a ágil. Especialmente, sería interesante adaptar y
personalizar un enfoque ágil para adaptarse a diferentes tipos de organizaciones a gran escala.
17
Además, el uso de marcos de escalamiento ágil, como SAFe, LeSS y DAD, sugerido por
consultores, empresas de interés. Sin embargo, casi no existen estudios científicos sobre su uso o
adecuación a diferentes entornos.
12. Referencias
1. Dikert, K., Paasivaara, M., y Lassenius, C. (2016). Desafíos y factores de éxito para
transformaciones ágiles a gran escala: una revisión sistemática de la literatura. Revista de
sistemas y software, 119, 87-108. doi: 10.1016 / j.jss.2016.06.013
2. Stavru, S. (2014). Un examen crítico de encuestas industriales recientes sobre el uso de
métodos ágiles. Revista de sistemas y software, 94, 87-97. doi: 10.1016 / j.jss.2014.03.041.
3. Lindsjørn, Y., Sjøberg, DIK, Dingsøyr, T., Bergersen, GR, y Dybå, T. (2016). La calidad
del trabajo en equipo y el éxito del proyecto en el desarrollo de software: una encuesta de
equipos de desarrollo ágil. Revista de sistemas y software, 122, 274-286. doi: 10.1016 /
j.jss.2016.09.028
18

Transformación Ágil A Gran Escala en Ericsson

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Transformación Ágil A Gran Escala en Ericsson

Cargado por

Copyright:

Formatos disponibles

TRANSFORMACIÓN ÁGIL A GRAN ESCALA EN ERICSSON: UN ESTUDIO DE CASO.

Autores: Paasivaara, M., Behm, B., Lassenius, C., y Hallikainen, M. (2018).

1. Antecedentes del problema de investigación .................................................................. 2

1. Antecedentes del problema de investigación

la metodología de estudio de caso (Yin 2009 ), en una organización de desarrollo de software en

cliente. En el momento de la investigación, el producto estaba en su ciclo de vida inicial con

producto tenía un gran potencial de mercado.

Arquitectónicamente, el producto consistía en módulos, posteriormente denominados

desarrollo de los componentes requirió experiencia altamente especializada debido a su

Ericsson adquirió el producto en 2011. Antes de la adquisición, aproximadamente 30 a 35

personas, incluidos contratistas externos y consultores, desarrollaron toda la plataforma. Como

parte de la adquisición, Ericsson contrató a unos diez expertos en dominios de la organización de

adquisición, la organización, en nueva construcción tuvo que centrarse en la transferencia de

La organización de desarrollo en Ericsson creció rápidamente: de dos equipos a fines de 2011 a 10

equipos en la primavera de 2013 y 15 equipos en la primavera de 2014. Se agregaron nuevos

desarrolladores y equipos a la organización gradualmente. Los mayores aumentos se produjeron a

equipos ágiles, parte de los cuales se reasignaron de otro proyecto en Ericsson.

consistían de 7-9 personas), propietarios de productos, arquitectos, entrenadores ágiles, gerentes

y soporte y operaciones al cliente.

componentes, lo que requiere una experiencia diferente para desarrollar.

Ericsson ha utilizado tradicionalmente un proceso de software basado en planes. Sin embargo,

particularmente desafiante, ya que el crecimiento organizacional ha sido significativo y rápido.

Durante la transformación, que todavía está en curso.

en la organización como en la cultura de la misma, en los equipos y en la propia reestructuración

de las dinámicas de trabajo.

existe un vació literario científico en las investigaciones acerca de su implementación, desafíos y

decisión de implementar transformaciones agiles y/o continuar competiendo en el mercado con

metodologías tradicionales (Dikert et al. 2016 ).

plataforma XaaS 1 y un conjunto de servicios de I + D a gran escala dentro de Ericsson, quienes

adoptaron métodos ágiles a escala.

La presente investigación, nos revela, como Ericsson, impulsó su motivación para la

tomadas para enfrentarlos.

4. Naturaleza del estudio

escala en la empresa Ericsson, fue un enfoque cualitativo, utilizando el paquete de software

la estructura de la organización y los antecedentes del caso.

aumentar la posibilidad de realizar una investigación completa.

fuentes de datos: 1) entrevistas, 2) observaciones y 3) documentos internos de la compañía.

que se analizaron. La figura 1 muestra la línea de tiempo de recolección de datos.

Ilustración 1.Cronología recolección de datos

Se realizaron un total de 45 entrevistas semiestructuradas en tres rondas: 1) 31 entrevistas sobre el

de validación después de analizar los datos.

de coordinación, 3) Para seguir los principales eventos de transformación.

Además, se recabaron una serie de documentos de los entrevistados. Estos documentos se

utilizaron para triangular y complementar la información recibida en las entrevistas.

En el momento de la recopilación de datos (2013 -2014), la organización Ericsson, se distribuyó

5. Preguntas de investigación / hipótesis

RQ1: ¿Por qué la organización inició una transformación ágil?

RQ2: ¿Cómo procedió la transformación?

RQ3: ¿Qué desafíos enfrentó la organización?

RQ4: ¿Cómo mitigó la organización los desafíos?

2016), El 43% de los encuestados auto-seleccionados trabajaron en organizaciones de desarrollo

organización con más de cien personas en desarrollo de software. Si bien la encuesta no es

científica y es problemática desde un punto de vista metodológico (Stavru 2014), es la encuesta

organizaciones lo utilizan ágil. Además, los profesionales de la conferencia de XP en 2010

mencionaron el tema "Proyectos ágiles y grandes" como la pregunta de investigación principal

investigación (Dingsøyr y Moe 2013; 2014).

medida (Dikert et al. 2016).

6.1. Desarrollo ágil a gran escala

(Boehm y Turner 2005).

6.2. Motivación para iniciar una transformación ágil.

competitividad. Por lo tanto, su respuesta es mejorar la velocidad de entrega y la capacidad de

6.3. Desafíos y factores de éxito de las transformaciones ágiles a gran escala.

para transformaciones ágiles a gran escala agrupadas en 11 categorías y 35 desafíos en 9 categorías.