EL ÉXITO DE PEARSON: PONER AL CLIENTE PRIMERO EN LA TRANSFORMACIÓN DE PROCESOS

DE DESARROLLO DE PRODUCTOS

"Complacency Kills" fue marcado con un círculo y subrayado en las notas de Greg Adams-
Woodford. Era la imagen de esas palabras que se habían quedado con él durante el fin de
semana. Ahora era lunes y, como vicepresidente de gestión de productos, llegó el momento de
determinar el plan de desarrollo del producto para los próximos cinco años.
Para Adams-Woodford era difícil creer que solo había pasado un año desde que se unió a
Pearson por primera vez. Estaba orgulloso del impacto positivo que su trabajo tuvo en mejorar
la posición de mercado de la versión más nueva del producto SuccessMaker en tan poco
tiempo.
Cuando Adams-Woodford se unió por primera vez a Pearson, toda la división de aprendizaje
digital estaba en medio de la primera gran actualización de su producto SuccessMaker.
SuccessMaker fue el principal producto de software de Pearson para ayudar a los estudiantes
de primaria y secundaria a mejorar sus habilidades matemáticas y de lectura, por lo que esta
actualización fue un proyecto estratégicamente importante para la empresa. La actualización
implicó cambios significativos en la tecnología básica del producto, desde un modelo de cliente-
servidor anterior a un nuevo Internet.
ot entregado modelo - y una completa renovación de todo el contenido de instrucción en el
producto. A pesar de los mejores esfuerzos de los involucrados, las nuevas versiones de
SuccessMaker no cumplían con los objetivos internos de Pearson y las necesidades de sus
clientes más importantes. La dificultad de la situación quedó ilustrada dolorosamente en una
carta no solicitada de un cliente estratégico entregada al principio de la gestión de Adam-
Woodford. En esta carta, el cliente se quejó amargamente de las promesas incumplidas y las
expectativas perdidas desde que comenzó a trabajar en la nueva versión 18 meses antes. Esta
carta finalmente se convirtió en el grito de batalla para una reingeniería completa del proceso
de desarrollo de productos de SuccessMaker. Adams-Woodford y su equipo llevaron a cabo un
corte de flash completo 1
desde un proceso de desarrollo más tradicional y establecido (cascada) hasta una nueva (y no
probada dentro de Pearson) metodología de desarrollo (Agile) (ver Anexos 1 y 2). El enfoque de
Agile en las iteraciones cortas de desarrollo y la comunicación sobre la documentación era
fundamentalmente diferente del enfoque de cascada que habían utilizado previamente, que
enfatizaba la documentación completa y detallada antes de que comenzara el desarrollo.
Ahora, un año después, muchos de los desafíos anteriores estuvieron detrás de ellos. Tanto los
clientes clave de Adams-Woodford como los grupos internos acordaron que SuccessMaker
había pasado por una transformación completamente positiva. Adams-Woodford estaba
complacido de que su visión clara para el futuro haya superado muchos de los problemas más
importantes con el desarrollo de SuccessMaker.

1 "Flash-cut" es un término estándar para la implementación inmediata de una nueva

metodología o sistema.
El nuevo camino hacia adelante no fue tan claro, sin embargo. El equipo de desarrollo comenzó
a experimentar dolores de crecimiento con la metodología ágil específica que eligieron para
implementar: Scrum. Algunos miembros influyentes del equipo propusieron que Scrum se
abandonara en favor de un sistema Kanban. Kanban se desarrolló en la industria manufacturera
y se centró más en la administración de tareas individuales, mientras que Scrum se centró en
ciclos cortos de desarrollo llamados sprints que incluían todo un conjunto de tareas (ver Anexo
3). Estos miembros del equipo de confianza consideraron que la metodología de Scrum no
encajaba con la fase del ciclo de vida actual del producto. Los datos parecían respaldar esta
conclusión ya que los aumentos iniciales en la productividad del equipo estaban comenzando a
tendencia hacia abajo. Si bien Kanban fue claramente exitoso en las empresas manufactureras,
Adams-Woodford no tenía experiencia personal al usarlo como una metodología de desarrollo
de software. Su reacción inicial fue quedarse con lo que sabía. Adams-Woodford había abogado
continuamente por la metodología de Scrum durante el año pasado; así que la idea de tirar
esos procesos e implementar un nuevo sistema no le cayó bien a él.
También estaba la cuestión de si extender a Agile a otros equipos involucrados en el desarrollo
de SuccessMaker. En sus reuniones de planificación estratégica de la semana anterior, varios de
los pares de Adams-Woodford sugirieron que tomara un rol más amplio dentro de Pearson,
ayudando a otros grupos de desarrollo a implementar el sistema Agile. Si bien la nueva
responsabilidad era atractiva, Adams-Woodford se preocupó de que estos nuevos desafíos
pusieran en peligro su enfoque durante un momento crítico para el equipo de SuccessMaker
cuando evaluaron la transición a un nuevo sistema Agile más allá del desarrollo de software.

APRENDIZAJE DIGITAL PEARSON Y PEARSON

Cotiza en las bolsas de valores de Londres y Nueva York (LSE: PSON, NYSE: PSO), Pearson tenía
tres unidades de negocio principales. La unidad de educación de Pearson se centró en el
mercado de la educación y fue una de
las empresas líderes que desarrollaron productos de aprendizaje para maestros y estudiantes.
El grupo Financial Times brindó servicios de publicación de noticias comerciales y financieras y
servicios en línea. El grupo Penguin publicó libros en una amplia gama de géneros bajo la marca
Penguin.
Pearson reportó $ 8,7 mil millones en ingresos en 2010 (ver Anexo 4). El grupo Pearson
Education fue la mayor de las tres divisiones y representó el 80 por ciento de las ganancias de la
empresa. El mercado educativo de América del Norte fue el segmento de negocios más grande
para Pearson y representó el 46 por ciento de los ingresos mundiales de la empresa.2
La empresa mantuvo su crecimiento incluso durante la profunda recesión de 2007-2008.
MyLab de Pearson - un servicio digital de aprendizaje, tarea y evaluación - creció a más de 7.3
millones de estudiantes registrados en 2010. Un conjunto de tecnologías de administración del
aprendizaje recientemente presentado dirigido al mercado de educación superior - eCollege y
Fronter - también tuvo inscripción en línea de estudiantes de más de 8.3 millones . Pearson
Digital Learning se enfocó en productos suplementarios digitales, vistos como un segmento de
mercado con gran potencial de crecimiento.
A pesar de un récord general de crecimiento sólido, Pearson Education enfrentó algunos
obstáculos en su camino hacia 2011.
El lento crecimiento económico continuo ejerció una presión considerable sobre los
presupuestos de educación en los Estados Unidos. La crisis presupuestaria tuvo un efecto
directo en los presupuestos de educación en todos los niveles. Pearson intentó abordar estos
dificultades del mercado con un enfoque en proporcionar productos y servicios premium.
Además, buscaron aprovechar el cambio de las escuelas al currículo digital y en línea, en lugar
de depender exclusivamente de la demanda de libros de texto tradicionales. Pearson también
realizó algunas adquisiciones clave para seguir ofreciendo una amplia gama de servicios para el
mercado educativo. La firma reconoció los cambios tecnológicos como el mayor riesgo para
todos
sus líneas de productos y servicios. Debido a estos cambios, la transformación de los productos
y servicios de Pearson Education para canales digitales fue un elemento clave de la estrategia
de crecimiento de la empresa.
2 www.pearson.com/investor/ar2010/performance/education/north-american-education.html
visitado el 12 de enero de 2012.

SUCCESSMAKER
SuccessMaker fue uno de los productos de Pearson Digital Learning (PDL) enfocados en ayudar
a los estudiantes de primaria y secundaria a aprender a leer y matemáticas a su propio ritmo.
SuccessMaker fue un producto totalmente digital y fue muy popular entre los estudiantes que
lo usaron. El software también proporcionó a los docentes valiosos datos de evaluación, lo que
permitió intervenciones específicas y entrenamiento. SuccessMaker se personalizó para
mercados individuales para cumplir con los estándares establecidos por el estado en cada nivel
de grado.
El producto SuccessMaker se derivó de uno de los primeros trabajos de investigación sobre
aprendizaje asistido por computadora. Los investigadores Patrick Suppes y Richard Atkinson
lideran el desarrollo de una teoría de decisión
basado en el programa de instrucción en la década de 1960 que finalmente fue comercializado
por Computer Curriculum Corporation. En 1990, Simon & Schuster adquirió Computer
Curriculum Corporation. Pearson hizo una oferta exitosa por las operaciones educativas de
Simon & Schuster (incluido el producto SuccessMaker) y
creó la unidad de negocios digitales de Pearson en 1998.
El enfoque subyacente al diseño de SuccessMaker se mantuvo sin cambios desde su creación.
Los estudiantes recibieron asignaciones específicas para completar por el profesor en el
programa SuccessMaker (ver Anexo 5). En función de cómo respondieron los estudiantes a
estas asignaciones, el software utilizó un algoritmo sofisticado y predictivo para mover a los
estudiantes a través de múltiples niveles de habilidades del plan de estudios. Los estudiantes
que dominan rápidamente las habilidades pueden avanzar más rápido que los estudiantes que
requieren asistencia adicional. El software fue lo suficientemente inteligente como para saber
no solo dónde ubicar inicialmente a los estudiantes en un conjunto determinado de currículos,
sino también la forma óptima de guiarlos a través del mismo. Mediante el uso diario de
SuccessMaker,
los estudiantes a menudo lograron resultados significativamente mejores en las pruebas
estandarizadas en comparación con los estudiantes que utilizan otras metodologías o
productos de instrucción.
Si bien SuccessMaker experimentó muchas mejoras a lo largo de los años, la versión más
reciente formó parte de una importante actualización de tecnología y contenido que comenzó
en 2005. Esta nueva versión, con el nombre en código SuccessMaker: Next Generation,
pretendía ofrecer a los clientes una plataforma más sólida y escalable. como un plan de
estudios más moderno. Este nuevo plan de estudios utilizó una variedad de nuevas
herramientas de instrucción que incluyen animación 3D y un avatar interactivo para guiar al
alumno a través del programa.
Si bien la intención del nuevo lanzamiento era abordar problemas críticos del mercado, la
realidad era que le faltaba la marca. Cuando Greg se unió a Pearson en 2007, le dijo al
vicepresidente senior de gestión de productos: "Hemos gastado $ 30 millones en el nuevo
desarrollo de SuccessMaker e incluso de seis a ocho.
meses después de lanzar la primera versión, no ha sido bien adoptado por el mercado. Los
primeros adoptantes se quejaron de que no cumplía con ninguno de sus requisitos ".
Una de las primeras ideas de Greg sobre la causa raíz de los problemas de SuccessMaker fue
que el equipo de desarrollo impulsaba todas las decisiones en lugar de la gestión de productos.
Como resultado, hubo poca comunicación directa entre el equipo de desarrollo y los clientes, lo
que provocó que muchas características bien intencionadas pasasen completamente por alto
cuando se lanzaron. El equipo de SuccessMaker utilizó la metodología de desarrollo de cascada
(ver Anexo 1), enfatizando el congelamiento de los requisitos del producto al comienzo de
un ciclo de desarrollo a través de documentación formal. Con una porción importante de
software que se desarrolla en alta mar en la India, la falta de comunicación entre los equipos de
desarrollo en la India y los Estados Unidos era una ocurrencia común. Debido a restricciones
contractuales, los cambios en las características del producto a mitad de camino durante el
ciclo de desarrollo fueron costosos o imposibles.
El proceso de cascada también requirió que la organización se comprometiera con un mapa de
varios años de características que no permitían cambios significativos en el alcance. Estas
características se presupuestaron individualmente y se comprometieron en el plan estratégico
de la unidad de negocios. Cualquier cambio en el mapa de ruta fue generalmente visto
negativamente. El equipo se refirió a tales cambios usando el término peyorativo de la industria
"scope creep". El proceso de cascada hizo más fácil la planificación interna ya que el alcance se
congeló esencialmente por varios años.
También significó poco esfuerzo para confirmar que las características comprometidas
satisfagan las necesidades de los clientes o que exploren características alternativas e
imprevistas una vez que se estableció el mapa de ruta.
EL PULSO PARA LA METODOLOGÍA ÁGIL
Adams-Woodford utilizó con éxito metodologías de software Agile en dos empresas en etapa
inicial antes de unirse a Pearson. La metodología ágil de desarrollo de software abogó por un
enfoque iterativo y evolutivo
al software en comparación con el modelo de escenario formal del enfoque de cascada. La
metodología ágil impuso un enfoque de desarrollo impulsado por el cliente con ciclos cortos de
desarrollo, típicamente dos "sprints" de dos semanas que entregan un pequeño subconjunto de
características del producto utilizando muy poca documentación formal. En resumen, las
"historias de usuario" escritas en una sola tarjeta de índice reemplazaron los documentos de
requisitos de más de 100 páginas del pasado.
No hubo compromiso con los sprints futuros hasta que se completó el anterior. Este enfoque
de compromiso diferido permitió a los equipos adaptar, diseñar y priorizar las características
del producto a través de la retroalimentación constante de los gerentes de productos y clientes.
Una suposición clave de la metodología fue que la gestión del producto era propiedad del
producto, no de los desarrolladores. Adams-Woodford dio una conferencia al equipo de
desarrollo sobre el papel de un gerente de producto: "Los clientes no le pagan por crear
documentos; ellos quieren que crees un producto. Gestión del producto
debe entender el mercado, competencia distintiva, escuchar a sus clientes y priorizar las
características que crean el mayor valor para sus clientes ".
La primera tarea de Adams-Woodford fue cambiar la estructura básica y la cultura de la
organización, empezando por el equipo de desarrollo de software, incluidos los desarrolladores,
los ingenieros de control de calidad (QA) y los gerentes de producto. El equipo general de
desarrollo de productos estaba compuesto por un grupo diverso de personas con experiencia
en diferentes áreas dentro de Pearson: gerentes de producto, desarrolladores de software,
expertos en control de calidad, analistas de negocios, expertos en contenido / currículo,
diseñadores instruccionales, animadores y artistas. Antes del cambio formal a Agile, Adams-
Woodford hizo la transición de todo el desarrollo de software offshore a la propia empresa
mediante la contratación de varios nuevos desarrolladores de software en Arizona. La
metodología ágil requería una estrecha cooperación entre los miembros del equipo casi a
diario. La comunicación con el equipo extraterritorial había sido un punto constante de disputa
tanto con el equipo de Pearson como con su proveedor. Adams-Woodford se dio cuenta de que
tenía que crear un diálogo más productivo centrado en construir un mejor producto.
EL MOVIMIENTO A AGILE
La transición se ejecutó como un flash-cut del proceso de cascada anterior a la nueva
metodología ágil. El viernes, los equipos de desarrollo de software habían estado siguiendo el
proceso de cascada y cuando regresaron el lunes siguiente, eran 100% ágiles. El movimiento se
programó justo después de que la segunda versión principal del producto se lanzó a la
fabricación (grabación en DVD / CD). Este cambio dramático se encontró con el escepticismo de
un subconjunto vocal de los miembros del equipo. Adams-Woodford destacó
la transición fue tanto un cambio cultural como un cambio en los procesos. Algunos miembros
renunciaron cuando se realizaron los cambios.
Tan pronto como se realizó el corte, se entregó capacitación a todos los desarrolladores de
software, ingenieros de control de calidad y gerentes de producto, detallando la nueva
metodología y el rol de cada uno dentro de ella. Adams-Woodford trajo un entrenador ágil
independiente para enseñar al equipo sobre la nueva metodología de desarrollo. Todos los
equipos pasaron dos días completos con el entrenador y el entrenamiento se llevó a cabo en
tres fases. La primera fase se centró en explicar la lógica subyacente de un enfoque ágil para
asegurar que todos entendieran
osthe core Principios ágiles. La segunda fase abordó el trabajo dentro de un marco de
desarrollo ágil, discutiendo las prácticas de trabajo específicas requeridas. La fase final se
centró en el equipo de SuccessMaker, pidiendo a los miembros que analicen por qué Agile no
trabajaría en su entorno. El entrenador de Agile sugirió abordar de forma proactiva estas
inquietudes, ya que había observado preocupaciones persistentes sobre Agile que a menudo se
manifestaban en el comportamiento del equipo semanas o incluso meses después de pasar de
procesos más tradicionales.

Como todos los equipos y su alta dirección estuvieron presentes en las sesiones de
capacitación, los equipos exploraron conjuntamente la solución de la mayoría de los problemas
que surgieron. Gastaron una cantidad considerable
de tiempo discutiendo cómo algunos grupos que no iban a estar en modo Agile interactuarían
con desarrolladores y grupos de administración de productos dado que todavía eran parte
integral del esfuerzo de desarrollo más grande. Otro tema que se debatió fue que los equipos
de desarrollo y QA habían trabajado por separado
y grupos mayormente autónomos previamente. Se acordó que los dos equipos tenían que
combinarse en un entorno Ágil, con un amplio entrenamiento cruzado en sus respectivas
especialidades. Bajo este nuevo sistema, el cambio más importante implicó cómo la gestión de
productos se relacionaría con el desarrollo. La gestión del producto ahora impulsaría todos los
esfuerzos de desarrollo y la priorización de nuevas características. La gestión de productos
debería priorizar las historias de los usuarios de acuerdo con las necesidades del mercado de
forma continua, un cambio incómodo tanto para el desarrollo como para los grupos de
productos. Adams-Woodford y Eric Wagner, el vicepresidente de los equipos de desarrollo
recientemente contratados, trataron de ayudar al equipo de SuccessMaker con esta transición
al asegurar que ambos fueran consistentes e inquebrantables en su aplicación del proceso ágil.
Los equipos de desarrollo se reorganizaron para SuccessMaker Release 3 cuando finalizaban su
trabajo relacionado con el desarrollo para la Versión 2. Después de algunas experimentaciones
iniciales con diferentes tamaños de equipo, el equipo de desarrollo se dividió en cuatro grupos.
Dos equipos fueron responsables del trabajo de desarrollo
involucrando el lenguaje de programación Java. Un equipo fue responsable de manejar la
codificación de informes y la lógica del currículo. Otro equipo creó todas las animaciones
basadas en Adobe Flash requeridas para el producto. Además de estos equipos, se designó un
maestro de scrum en cada equipo para ayudar al equipo a eliminar cualquier obstáculo.

DOLORES CRECIENTES PARA LA LIBERACIÓN 3

Adams-Woodford hizo un punto de caminar por los pasillos e interactuar con tantos miembros
del equipo como sea posible para mantenerse en contacto con sus sentimientos y actitudes
sobre los cambios en curso. Después de que la novedad inicial de la nueva metodología
comenzó a desvanecerse, Adams-Woodford observó que los equipos de desarrollo intentaban
reintroducir algunos de sus procesos previos de cascada. Específicamente, notó que el equipo
de control de calidad no se sentía cómodo con sus nuevos roles. Mientras conversaba
informalmente con los miembros de este equipo, se hizo evidente que muchos de ellos no
estaban seguros de cómo hacer sus trabajos sin poder contar con documentos de requisitos
detallados como lo habían hecho en el pasado. Esto afectó las relaciones del equipo con los
desarrolladores, quienes sintieron que las personas en el equipo de QA no estaban
comprometidas con los principios fundamentales de la metodología Ágil (ver Anexo 2) y
estaban tratando activamente de regresar a las prácticas anteriores.
La principal dificultad que enfrenta el equipo de QA fue su responsabilidad conjunta con los
desarrolladores por la calidad del lanzamiento. Esto significaba que las líneas previamente
claras entre lo que hacía un desarrollador y lo que hacía un ingeniero de control de calidad se
había borrado. Anteriormente, los ingenieros de control de calidad no interactuaban con los
desarrolladores y simplemente esperaban que Do Not Copy o Post el código se completara para
que pudieran verificarlo en los casos de prueba desarrollados independientemente
deldocumentos de requisitos originales y muy detallados. Si descubrían defectos de software, la
única responsabilidad de los ingenieros era identificar los problemas y transmitirlos al equipo
de desarrollo. En el nuevo modelo, no había documentos de requisitos y todo el equipo
(desarrolladores e ingenieros de control de calidad) era responsable de entregar el código de
trabajo al final del sprint definido. Este enfoque de equipo significaba que todos debían
contribuir con poca consideración a los roles funcionales formales. Individuos en el equipo de
QA
lucharon no solo con esta ambigüedad, sino también con lo que percibieron como una falta de
responsabilidad y rastreabilidad para las características que estaban desarrollando.
Adams-Woodford también notó que los gerentes tanto de los desarrolladores como de los
ingenieros de QA estaban cada vez más involucrados con la administración de tareas en los
equipos de sprint. El proceso de scrum permitió a los gerentes asistir a la reunión diaria de
stand-up, pero también dictaminó que nadie más que los miembros deberían participar en la
toma de decisiones a nivel de equipo durante estas reuniones. Las reuniones se llamaron stand-
ups dado que todos los asistentes estuvieron de pie durante la reunión con el fin de alentar al
equipo a ser conciso y mantener la reunión a no más de 15
minutos. Adams-Woodford asistió a todos los stand-ups y descubrió que cada vez más tenía
que recordar a los gerentes que los equipos debían ser autogestionados en relación con el plan
diario. Adams-Woodford creía que a menos que los gerentes estuvieran completamente
comprometidos con sus empleados que manejan el trabajo diario, los beneficios de Agile se
reducirían significativamente.
De todas las personas con las que habló durante sus conversaciones en el pasillo, los gerentes
de productos y propietarios parecieron ajustarse más rápidamente y experimentaron el cambio
más dramático en sus perspectivas para el futuro. En el proceso de scrum, los gerentes de
producto y los propietarios de los productos fueron los representantes comerciales
responsables de crear y priorizar las historias de los usuarios para cada sprint de desarrollo.
Adams-Woodford recordó sus primeros días en Pearson cuando estos individuos eran, con
mucho, los más hastiados y ambivalentes de cualquiera de los equipos interfuncionales. Todos
parecían resignados a tener poco control sobre lo que producían los equipos de desarrollo. La
mayor parte de su tiempo lo dedicaba a controlar los daños cuando los nuevos lanzamientos no
cumplían con las expectativas. Ahora, sin embargo, estos gerentes y propietarios estaban
comprometidos con la nueva metodología, convirtiéndose en francos defensores de la
mentalidad Agile en toda la unidad de negocios. Varios se encargaron de tomar clases y unirse a
grupos de discusión sobre la metodología, mientras que muchos establecieron
buenas relaciones tanto con los clientes como con el equipo de ventas.
Cuando Adams-Woodford no estaba hablando con los equipos, estaba en su oficina revisando
las métricas de rendimiento clave para los equipos de desarrollo. Desde el cambio a Agile, la
base de código para SuccessMaker se redujo a la mitad incluso cuando el número de funciones
aumentó hasta en un 75 por ciento. Las nuevas características habían sido recibidas muy
favorablemente por los clientes. El tamaño del equipo de desarrollo también se redujo en al
menos un tercio, principalmente a través de la eliminación de equipos de desarrollo
extraterritoriales. A pesar de estas mejoras, los primeros sprints de la Versión 3 mostraron una
degradación significativa del rendimiento en la velocidad de los desarrolladores.
La velocidad se calculó convirtiendo cada historia de usuario en una medida estándar de
esfuerzo como puntos de historia y determinando cuántos puntos se completaron en cada
carrera. Adams-Woodford no pensó que era una coincidencia cuando la velocidad comenzó a
disminuir a medida que los equipos comenzaron a retroceder en sus procesos de cascada
anteriores. Este desarrollo llevó a los desarrolladores clave de Adams-Woodford a sugerir un
cambio de Scrum a Kanban para acelerar la velocidad general del equipo.

EL CAMINO HACIA ADELANTE

Si bien el paso al desarrollo Agile mejoró la posición de SuccessMaker tanto con los clientes
como con el equipo de ventas, una serie de desafíos quedaron fuera del equipo de desarrollo
de software. De varios equipos multifuncionales diferentes, el equipo de desarrollo de software
fue el único grupo funcional para la transición No copiar o Publicar a Agile. Otros equipos
involucrados con el producto como el equipo de contenido todavía usan una cascada

enfoque. Los líderes de equipo en el equipo de software también reconocieron una serie de
problemas que requieren atención inmediata más allá de las preocupaciones de los ingenieros
de control de calidad sobre sus roles y pruebas de software. Las pruebas de integración de
extremo a extremo y la automatización completa de los procedimientos de prueba todavía
estaban en proceso. Hubo una tendencia a seguir un enfoque de mini cascada cuando se
requirieron estas pruebas. Los equipos querían evitar esta tendencia en el futuro.

En cuanto a la planificación de la versión final, que se compone de muchos sprints, los

propietarios del producto se complacieron en observar que pudieron planear hasta dos sprints
para cada equipo de desarrollo con precisión. Como todos los equipos alcanzaron niveles más
altos de madurez en la metodología ágil, esperaban planificar de tres a cuatro iteraciones. Esto
requirió una mayor estabilidad y predictibilidad para lograr los objetivos de iteración. Adams
Woodford se dio cuenta de que esta debilidad era un obstáculo importante que superar, al
afirmar que "los equipos no siempre entienden cuál es su velocidad. Todavía no pueden estimar
con precisión la cantidad de puntos que pueden desarrollar en un período de planificación. Esto
hace que sea difícil comprometerse con los lanzamientos con los clientes ".
Adams-Woodford también se preocupó de que los equipos se centraran demasiado
internamente en la estimación de un retraso acumulado de funciones. A menos que también
estuvieran continuamente validando que los requisitos en la cartera de pedidos eran los más
importantes para el mercado, estos equipos podrían comenzar a caer nuevamente en
características de desarrollo que no pueden satisfacer las necesidades del mercado.

Más allá de la planificación de los sprints, las actividades dentro de un sprint individual tenían
margen de mejora.
David Foster, arquitecto jefe de la división, destacó los equipos de desarrollo de productos
involucrados en el cambio de contexto. En otras palabras, los equipos de desarrollo a menudo
cambian de una función a otra característica distinta dentro de la misma iteración de
desarrollo. Esto dio como resultado una velocidad reducida, ya que los desarrolladores tenían
que revisar y familiarizarse con los aspectos técnicos de los componentes del sistema cada vez
que pasaban de una función a otra. Para eliminar el cambio de contexto, Foster señaló la
necesidad de que los equipos de productos y desarrollo reconozcan el mapeo entre las
características y los componentes del sistema.
Foster también observó: "No hemos llegado a ser muy eficientes en las versiones de
mantenimiento. Con Scrum, no debería importar, pero aún no nos sentimos cómodos con ellos.
Ese sigue siendo un punto difícil ".

Adams-Woodford a menudo insistió en que los desarrolladores adoptaran una mentalidad de

inicio, declarando, "Estamos diversificando nuestras líneas de productos rápidamente. Vamos a
tener que ser creativos para convertir algo que algunas personas puedan pensar que es
realmente aburrido en algo muy convincente y centrarnos en nuestra competencia distintiva ".
Para que esto suceda, notó que necesitaba mantener sus equipos de desarrollo frescos y llenos
de energía. Los marcos de desarrollo ágiles pueden hacer que el desarrollo de software sea
"rutinario" y monótono. Por lo tanto, era importante para él mantener a sus desarrolladores
involucrados con los productos y clientes. Para mantenerlos inspirados y motivados, Adams-
Woodford alentó el despliegue entre equipos de los miembros del equipo de desarrollo en toda
la familia de productos.

Adams-Woodford también vio desafíos en la posición estratégica del producto en el mercado,

al afirmar: "Cuando usa SuccessMaker, todavía se siente como un producto anticuado. Hemos
avanzado mucho en la tecnología de plataforma, pero nuestra hoja de ruta de contenido se ha
mantenido esencialmente igual durante los últimos tres años. El producto también es costoso
de mantener en comparación con otros productos de próxima generación basados en la web.
Tenemos que ofrecer diferentes opciones: alojamiento, servicio basado en suscripción, etc. Hay
tantas funciones que
puede agregar al producto La estrategia es tomar la buena marca, crear productos auxiliares,
llegar al hogar y conectarse con los padres y estudiantes. Tenemos que hacer que el producto
sea entretenido para que los niños jueguen solos en casa, mientras informa a los maestros y a
los padres. Debemos usar los datos, hacerlo interoperable a nivel de distrito.
Dentro de Pearson, debemos asegurarnos de que los datos se transfieren a todos los productos;
esto es realmente importante."

Todos estos problemas giraban en torno a la mente de Adams-Woodford mientras consideraba

cómo abordar el nuevo mapa de ruta de productos y dónde enfocaría sus esfuerzos en el
futuro. Aunque Adams-Woodford había progresado mucho en Pearson al implementar Agile
con los equipos de desarrollo, los desafíos a los que se enfrentaba ahora eran mucho más
complejos y potencialmente más importantes a largo plazo para las perspectivas de su cartera
de productos.

"Bueno", pensó Adams-Woodford para sí mismo. "Si Agile trabaja para el desarrollo, tal vez
funcione para mí". Adams-Woodford fue al área de planificación de los desarrolladores y trajo
un paquete de fichas a su oficina. Adams-Woodford comenzó a delinear las historias de los
usuarios sobre cómo implementaría el mapa de ruta del producto, su lugar dentro de él y el
esfuerzo Agile más amplio en Pearson.
Exhibición 1
RESUMEN DEL ENFOQUE DE DESARROLLO DE SOFTWARE DE CASCADA

Los equipos de software tradicionalmente han seguido un enfoque por etapas cuando
construyen sistemas. El término "cascada" se refiere a la rigidez inherente en el ciclo de vida del
desarrollo donde se supone que una fase comienza solo después de la finalización de una fase
previa. Sin embargo, es común ver que los equipos de software iteran entre fases. Las fases
principales en el ciclo de vida de desarrollo de software (SDLC) incluyen: (1) análisis de
requisitos, (2) diseño, (3) desarrollo, (4) pruebas, (5) implementación y (6) mantenimiento.
Los gerentes hacen hincapié en la necesidad de analizar y documentar de forma exhaustiva los
requisitos del usuario, ya que consideran que los cambios realizados en los requisitos y el
diseño durante las últimas etapas del ciclo de vida del desarrollo son muy costosos y
perjudiciales. Como resultado, los modelos de desarrollo por etapas requieren mucha
documentación.

Una suposición clave de un enfoque por fases es que la dependencia entre fases es lineal y
unidireccional. Sin embargo, en la mayoría de los proyectos de software, las dependencias
entre los componentes son complejas y bidireccionales. Para abordar esta complejidad, los
gerentes intentan dividir los proyectos en módulos relativamente independientes e integrar los
módulos hacia el final del ciclo de vida del proyecto.

A pesar de las adaptaciones al concepto básico de un modelo de "cascada", esta filosofía de

desarrollo tiene muchos inconvenientes. En la mayoría de los casos, es difícil para los usuarios
comprometerse con los requisitos, ya que tienen dificultades para visualizar el producto final.
Además, los requisitos del negocio pueden cambiar durante el curso del desarrollo y hacer que
el proyecto retroceda a fases anteriores, lo que conduce a esfuerzos desperdiciados.
Las dependencias no realizadas entre sistemas, componentes o módulos pueden provocar
largas demoras durante la integración de los sistemas. Como resultado, muchos proyectos de
desarrollo de software han adoptado enfoques de desarrollo iterativos como el desarrollo de
aplicaciones en espiral, rápido o modelos ágiles.
Fuente: Richard E. Fairley, Managing and Leading Software Projects, John Wiley, Hoboken,
Nueva Jersey, 2009, pp. 55-58.
Prueba 2
METODOLOGÍA AGILE DE DESARROLLO DE SOFTWARE
Para comprender la filosofía de las metodologías de desarrollo Agile, es útil tener en cuenta los
doce principios propuestos por Agile Alliance:
Nuestra máxima prioridad es satisfacer al cliente mediante la entrega temprana y continua de
un software valioso.
Bienvenidos los requisitos cambiantes, incluso tarde en el desarrollo. Los procesos ágiles
aprovechan el cambio para la ventaja competitiva del cliente.
Entregar el software que funciona con frecuencia, de un par de semanas a un par de meses,
con preferencia a la escala de tiempo más corta.
Los empresarios y los desarrolladores deben trabajar juntos a lo largo de todo el proyecto.
Desarrollar proyectos en torno a personas motivadas. Bríndeles el entorno y el apoyo que
necesitan, y confíe en que hagan el trabajo.
El método más eficiente y efectivo para transmitir información a un equipo de desarrollo y
dentro de él es la conversación cara a cara.
El software de trabajo es la medida principal de progreso.
Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores, desarrolladores y
usuarios deberían poder mantener un ritmo constante de manera indefinida.
La atención continua a la excelencia técnica y al buen diseño aumenta la agilidad.
Simplicidad: el arte de maximizar la cantidad de trabajo no realizado, es esencial.
Las mejores arquitecturas, requisitos y diseños surgen de equipos autoorganizados.
A intervalos regulares, el equipo reflexiona sobre cómo ser más eficaz, luego sintoniza y ajusta
su comportamiento en consecuencia.
La metodología ágil tiene un enfoque adaptativo para el desarrollo. Al final de una iteración
(conocida como sprint), el equipo entrega un conjunto de características específicas que se
prueban e integran en el producto. Los equipos tienen la oportunidad de revisar el progreso y
revisar los requisitos del usuario al comienzo de cada iteración.
Como resultado, todas las partes interesadas tienen la oportunidad de reaccionar a las
cambiantes necesidades de los productos y proporcionar información sobre las características
del producto en evolución.
Una de las variantes más populares de un proceso ágil es el enfoque de Scrum. En un equipo de
scrum, el scrum master representa a los desarrolladores y administra el proceso de desarrollo.
El propietario de un producto prioriza las características según las necesidades de las partes
interesadas; y los equipos de desarrollo involucran directamente a los propietarios del producto
y otras partes interesadas relevantes de forma continua durante todo el proceso de desarrollo.
El acuerdo sobre qué características desarrollar en un ciclo de sprint se realiza durante una
reunión de planificación. En un ciclo de sprint, el desarrollo
el equipo se esfuerza por cumplir los compromisos adquiridos durante la reunión de
planificación. Los equipos y las partes interesadas normalmente se reúnen al final del ciclo de
sprint para revisar el progreso y descubrir oportunidades para la mejora continua.
Fuente: www.agilealliance.org/the-alliance/the-agile-manifesto/the-twelve-principles-of-agile-
software/ visitado el 12 de enero de 2012.
Exhibit 3
KANBAN
Kanban es un término japonés (看板) que literalmente se traduce como "letrero". Kanban
como proceso de producción tiene sus raíces en la fabricación ajustada y el sistema de
producción de Toyota (TPS). Kanban se enfoca en optimizar el flujo del trabajo a través de todo
el proceso de producción administrando las solicitudes de
componentes / trabajos adicionales de funciones ascendentes. Estas solicitudes se realizan a
través de tarjetas kanban que las funciones descendentes pasan a funciones ascendentes
cuando se requieren más componentes. Las tarjetas son visibles durante todo el proceso de
producción, por lo que es posible ver literalmente el flujo de trabajo al examinar todas las
tarjetas y sus colas. Kanban es una herramienta que se usa comúnmente en la fabricación Just
in Time (JIT) dado que el inventario adicional solo se solicita cuando es necesario. Kanban
también se conoce como un sistema de "extracción" dado que los procesos descendentes
extraen trabajo adicional de las funciones ascendentes mediante el uso de estas tarjetas. Más
allá del uso de tarjetas, un sistema Kanban incluye el análisis y la optimización del flujo de
producción para disminuir el desperdicio (conocido como muda o 無 駄) al imponer límites a la
cantidad de trabajo que está en proceso dentro del sistema y las funciones individuales. Esta
optimización busca mejorar el rendimiento general del proceso de producción.

Kanban como una metodología de desarrollo de software es una adaptación más reciente de la
aplicación de fabricación tradicional. Kanban en este contexto a menudo se asocia con procesos
de desarrollo de software Lean. En software, Kanban adopta la filosofía de la implementación
de fabricación y la aplica a varios pasos para desarrollar un producto o aplicación. Estos pasos a
menudo incluyen creación, desarrollo, prueba e implementación de historias de usuarios. A
diferencia de los procesos ágiles más tradicionales como Scrum, Kanban no utiliza un cuadro de
tiempo para cada sprint de desarrollo. En cambio, Kanban impone límites de trabajo en
progreso
para cada paso de desarrollo. El proceso general puede optimizarse imponiendo y ajustando
estos límites.
Los miembros del equipo se concentran en los cuellos de botella del sistema para reducir el
tiempo total de rendimiento de las funciones al eliminar el desperdicio (muda) durante todo el
proceso. A diferencia de otros procesos ágiles que usan la velocidad como su métrica clave,
Kanban utiliza el rendimiento para las características individuales como su métrica clave.
Kanban tiene algunas similitudes con los procesos ágiles más tradicionales, lo que incluye
permitir a los propietarios de negocios posponer los compromisos de las funciones hasta que la
característica ingrese al desarrollo y buscar permitir que los equipos trabajen juntos de manera
más colaborativa al hacer
el flujo de trabajo, que puede ser físico o componentes de una aplicación de software, visible
en la placa Kanban.

Fuente: D. Anderson, Kanban: Cambio evolutivo exitoso para su negocio tecnológico, Blue Hole
Press, Sequim,
2010, pp. 11-16.
PREGUNTAS DE TAREA

1. ¿Qué desafíos enfrenta Adams-Woodford mientras desarrolla su hoja de ruta de productos

de cinco años?
2. ¿Cómo influyen las metodologías de desarrollo de productos y software en la capacidad de
una empresa para responder a las demandas de mercado?
3. ¿Qué beneficios se dio cuenta Pearson al hacer el cambio de un proceso de cascada a uno
Ágil? ¿Qué desventajas podrían estar asociadas con este cambio? ¿Qué empresa o
circunstancias del mercado tienen más probabilidades de beneficiarse de una metodología
Waterfall o Agile?
4. ¿Cuáles son algunas de las cosas que Greg debería considerar al evaluar si continuará
enfocándose en el producto SuccessMaker versus involucrarse en una iniciativa ágil de toda la
compañía? ¿Qué enfoque debería seguir Greg? ¿Cómo podría optimizar este enfoque?
5. Dentro del equipo de SuccessMaker, ¿debería Greg aceptar seguir las recomendaciones de
sus desarrolladores para pasar de Scrum a Kanban? ¿Debería también presionar para mover a
todos los equipos restantes (el contenido / equipo de currículo) a Scrum o Kanban? ¿Qué
métricas debería usar para evaluar sus decisiones?