¿SCRUM es poderoso o es eficiente?

¿Por qué SCRUM es más eficiente que las metodologías tradicionales?

Si creemos que Scrum es poderoso porque es una religión…

Scrum es todopoderoso porque es nuestra religión. Si quieres alcanzar el cielo de la tecnología, ese lugar idílico donde todos los proyectos finalizan en plazo, debes seguir puntualmente cada uno de sus ritos.

En los tiempos oscuros, los profetas Brooks y DeMarco nos advirtieron que nos enfrentamos a problemas extremadamente complejos en los que podemos trabajar por los siglos de los siglos. Inspirados por el espíritu de los nuevos tiempos propusieron abordar la solución mediante pequeñas iteraciones, analizando junto con el cliente qué se ha conseguido en cada una de ellas y qué se debería hacer a continuación.

El ritual SCRUM que nos inspiraron es como sigue:

El Account Manager descubre una necesidad del cliente y junto con el Sumo Sacerdote o Product Manager, preparan una oferta que tiene plazo y presupuesto definidos pero cuyo alcance queda indeterminado. Realizan sacrificios a Poseidón y ofrendas a Baco para que el cliente la firme.

La Sagrada Firma es el ritual más complicado y al que menos atención se presta en los Textos Sagrados. Los clientes no iniciados se resisten a comprometer presupuestos determinados a cambio de productos indeterminados. Es inútil explicarles que en los proyectos realizados según los ancestrales ritos de Waterfall, aunque el alcance estaba definido, en media sólo se entregaba el 50% de lo especificado.

Tras la Sagrada Firma, en un concilio, cliente, Account ManagerProduct Manager, y Product Owner, hacen una descripción de alto nivel del sistema en las tarjetas sagradas llamadas Epics y Features, que describen las principales funciones del sistema en un párrafo. El Product Backlog es un altar de corcho donde se exponen a los fieles las sagradas tarjetas para que puedan consultarlas a voluntad.

En sucesivos aquelarres, el Product Manager y los programadores, descomponen Epics y Features en nuevas tarjetas llamadas Historias de Usuario, que tienen la forma ‘Como usuario <perfil de usuario> soy capaz de hacer <tarea> y así consigo <valor para el negocio> ’. Exponen a los fieles su trabajo en un nuevo altar de corcho, el Team Backlog.

Es el momento de comenzar los ritos de implementación.

El primero es formar los escuadrones de desarrollo, con un Product Owner, un Scrum Master y entre tres y cinco consultores. Sus puestos de trabajo deben estar próximos entre sí y se encargarán de implementar de extremo a extremo las Historias de Usuario de una parte concreta de la aplicación. Deberán definir la arquitectura, hacer el diseño, codificar, probar, integrar y documentar.

Cada iteración comienzan con la ceremonia del Sprint Planning. El squad se reúne con el cliente para decidir qué Historias de Usuario van a intentar implementar durante el Sprint, que durará entre tres y cuatro semanas. El cliente sabe qué historias de usuario son prioritarias. El squad tiene una estimación de su velocidad de ejecución.

Todas las mañanas del sprint, el squad se reune para maitines, también conocido como daily. Durante el resto del día, diseñan las Historias de Usuario, las codifican, desarrollan las pruebas unitarias y prueban el software construido. Sólo si el código supera las pruebas se considera finalizado y apto para entregar al cliente.

El Product Owner ayuda a los programadores a interpretar las sagradas Historias de Usuario. El Scrum Master vela por la pureza de los rituales.

Finalizado el Sprint, el squad celebra el Sprint Review, ceremonia en la que el código desarrollado se entrega al cliente y las Historias de Usuario que no se han completado se devuelven al team backlog.

La ceremonia final es el Sprint Retrospective. Aquí Product Owner, programadores y testers reconocen sus faltas y hacen propósito de enmienda, con el fin de mejorar sus habilidades y ser más productivos en las siguientes iteraciones.

Sigue religiosamente este ritual y tus proyectos llegarán a buen puerto con la bendición de los Dioses.


Cómo orientar tu carrera profesional

Cómo orientar tu carrera profesional usando el test de Gallup

Estás haciendo un gran trabajo, y como premio te han propuesto cambiar de rol. Quizás te han pedido que lideres a un grupo de consultores recién incorporados, o tal vez que acompañes al responsable de cuenta a una reunión de ventas.

Descubrirás que hay actividades que te son tan naturales cómo respirar y otras en las que, a pesar de tu esfuerzo, sólo recibes disgustos. ¿Cómo saber si la jugosa manzana está envenenada?

Para responder a esta pregunta vamos a utilizar el test de fortalezas de Gallup. Si todavía no lo has hecho tienes el enlace aquí. Considera estos veinte dólares como una de las mejores inversiones de tu vida.

Este test te descubre tus cinco principales fortalezas, es decir, los tipos de talento que has desarrollado de forma natural. Gallup distingue entre treinta y cuatro fortalezas que se agrupan en cuatro ámbitos:

  • Fortalezas de ejecución. ¿Qué es lo siguiente que tengo que hacer? Si tu única recompensa es un trabajo bien hecho o eres incapaz de buscar excusas para no completar una tarea, eres un auténtico ejecutor.
  • Fortalezas de pensamiento. ¿Qué es lo que mejor que podemos hacer en este momento? ¿Cuál es la mejor forma de hacerlo? Si no puedes dejar de estudiar o tienes una potente capacidad analítica eres todo un pensador.
  • Fortalezas de relación ¿Cómo construyo vínculos con los demás? Si ves rápidamente cómo son las personas, o para ti lo más importante es el ambiente de trabajo, tienes este tipo de fortalezas.
  • Fortalezas de influencia. ¿Cómo consigo que los demás trabajen para mi? Si siempre tienes en la boca la palabra adecuada o te encanta ganarte a la gente, considérate un influencer.

Tras miles de años en que las fortalezas más valoradas eran las de ejecución (agricultura, ganadería) a finales del siglo XX aparece el sector tecnológico, donde, por primera vez en la historia, se necesitan de forma masiva las fortalezas de pensamiento (programadores, analistas, técnicos de sistemas, hackers).

Aunque no todos los roles técnicos precisan de las mismas fortalezas. En los primeros test de Gallup que realizamos, descubrimos que los mejores programadores combinaban fortalezas de pensamiento y relación. Pronto nos dimos cuenta que, para programar, los vínculos emocionales son determinantes, porque facilitan la construcción de las especificaciones y la coordinación de las tareas.

En resumen, si tus fortalezas son de relación y pensamiento, la programación se te dará bien de forma natural.

Sin embargo, si la mayoría de tus fortalezas son de pensamiento, estarás más cómodo en roles con más complejidad y menos relación, como la administración de sistemas o la ciberseguridad.

Si tus fortalezas son sobre todo de relación, busca trabajos donde tengas que estar en contacto con el cliente.  Y si a las fortalezas de relación se suman las de influencia, tu sitio está en el departamento de ventas. Aquí tu misión es crear un vínculo con el cliente y convencerle de que ponga una firma. ¡Como pueden pagar esas comisiones por un trabajo tan sencillo!

Para liderar equipos siempre son interesantes las fortalezas de influencia. Cuantas más aparezcan en tu test de Gallup, más cómodo te sentirás con cada ascenso. Descubrirás que buena parte de los directores son perfiles de pensamiento que solo saben decir lo que piensan.

Si la mayoría de tus fortalezas son de influencia, acabarás en la alta dirección. Algunos te llamarán trepa pisacuellos y aunque quizás no eres el mejor técnico, siempre sabes lo que tienes que decir y esas habilidades te llevarán a poner una C en tu cabecera de Linkedin.

Cuando tu trabajo está alineado con tus fortalezas, te pagan por hacer lo que se te da bien de forma natural. En el caso contrario también puedes hacer un trabajo brillante, aunque a costa de un mayor desgaste personal.

¿Quieres saber que actividades son mas adecuadas para ti? Envíanos el resultado de tu test de fortalezas y te explicaremos cómo acertar al cambiar de rol.


La tragedia del analista programador

El rol de Analista/Programador es la primera promoción dentro de la carrera tecnológica, y es una trampa que debes conocer.

Con un poco de paciencia, en dos o tres años serás el programador más veterano dentro de un grupo de cinco o seis consultores, lo que te convierte de facto en su Líder Técnico. Aquí aparece el primer dilema de los profesionales del mundo IT.

¿Dedico mi tiempo a realizar mi [importante] trabajo técnico o a formar a los recién incorporados?

Existen tres soluciones posibles:

1. Dedicas la mayor parte de tu tiempo a realizar tu [crítico] trabajo técnico y sólo ratos sueltos a dar soporte a los nuevos. Éstos aprenden lentamente ya que no puedes encargarles tareas complejas. Es el caso más habitual, representado en la gráfica por la línea roja. Conseguirás una alta rotación entre los recién llegados y mucha presión para que el equipo mejore sus resultados.

2. Haces tu [complejo] trabajo técnico y además dedicas mucho tiempo a formar a los nuevos. El volumen de horas necesario para realizar ambas tareas te llevará a presentar la baja voluntaria o la baja por depresión.

3. Dedicas la mayor parte de tu tiempo a formar a los nuevos consultores hasta que son capaces de trabajar con autonomía. Es el caso menos habitual, representado en la gráfica por la línea verde. El equipo tendrá resultados pobres durante los primeros meses pero a largo plazo construirás un Equipo de Alto Rendimiento. Si consigues soportar la presión, claro.

La gráfica presenta los resultados obtenidos por un equipo siguiendo las diferentes estrategias.

Como puedes ver, las tres estrategias ofrecen resultados que están por debajo de las expectativas del cliente, lo que se traduce en presión; retrasos, lista de tareas pendientes que tiende a infinito y tensas reuniones con el cliente.

En siguientes post estudiaremos estrategias que consiguen resultados que superan las expectativas del cliente. Y también veremos los nuevos problemas que eso genera.


Las cuatro leyes de la gestión de proyectos tecnológicos

Tan solo cuatro leyes gobiernan la gestión de los proyectos tecnológicos:

1ª ley. Las especificaciones son inciertas, imprecisas e infinitas.

2ª ley. One project, one team, one site.

3ª ley. Presión x Talento = Constante.

4ª ley. Alcance, Plazo y Calidad. Si fijas dos de ellas, la tercera se degrada porque es la variable de ajuste.

La primera ley asume que no disponemos de una herramienta para transmitir las instrucciones técnicas. La comunicación se hace mediante sucesivas iteraciones soportadas en relaciones personales. Corolario: Especifica menos y relaciónate más.

La segunda ley nos indica cómo fomentar las relaciones personales; los equipos de diseño, desarrollo, pruebas, integración y delivery están en una única oficina y cada consultor trabaja para un único proyecto. Las software labs y las organizaciones matriciales son ineficientes.

La tercera ley anticipa que si incrementas la presión de trabajo, obtienes menos producto. El desarrollo tecnológico es más inspiración que transpiración. Deja que el equipo encuentre su ritmo y gestiona las expectativas del cliente.

La cuarta ley nos propone cómo gestionar las expectativas del cliente. Dado que las especificaciones son infinitas, uno de los tres parámetros debe degradarse y lo habitual es fijar Alcance y Plazo, degradando la Calidad. La propuesta de SCRUM es fijar Plazo y Calidad mientras el Alcance se determina con el cliente en sucesivas iteraciones. La propuesta de TIME & MATERIAL es fijar Alcance y Calidad, sin plazo cerrado y facturando por el tiempo dedicado.

Son pocas y son fáciles, y sin embargo buena parte de las organizaciones, como consecuencia de la herencia cultural de la ingeniería industrial, trabajan contra ellas preparando extensos documentos funcionales, deslocalizando parte de los equipos, trasladando la presión del cliente a los desarrolladores y fijando en los contratos alcance y plazo de entrega.

Quizás la magia no está en conocer las cuatro reglas, están ahí a disposición de cualquier gestor que quiera aplicarlas. Lo difícil es comprender la psicología que hay detrás de cada una de ellas, de forma que puedas adaptarlas a tu organización. Las referencias básicas son ‘Introducción a la PNL’ de Seymour, ‘The mythical man-month’ de Brooks, ‘Peopleware’ de DeMarco y ‘Drive’ de Pink.

Por eso cuando hay retrasos en los proyectos, se forman silos dentro de las organizaciones o los resultados se evaporan sin razón aparente, algunas empresas contratan un análisis estratégico y otras invitan a su coordinador de Novanotio a tomar un café y le preguntan la forma más sencilla de aplicar las cuatro reglas a su caso particular.

Si quieres ayudar al desarrollo del sector, puedes compartir experiencias sobre proyectos en los que se trabajó a favor o en contra de las cuatro leyes. También puedes proponer nuevas leyes y abrir un debate sobre por qué son necesarias y por qué tienen un carácter universal.