• Saltar a la navegación principal
  • Saltar al contenido principal
Icono Jeronimo Palacios

Jeronimo Palacios & Associates

Transformación digital

  • Agile Academy
    • Scrum Mastery
  • Próximos cursos
  • Scrum.org
    • Applying Professional Scrum
    • Applying Professional Scrum for Software Development
    • Professional Scrum Master
    • Professional Scrum Master II
    • Professional Scrum Product Owner
    • Professional Scrum Product Owner Advanced
    • Scaled Professional Scrum
    • Professional Agile Leadership
    • Professional Scrum with Kanban
  • Kanban University
    • Team Kanban Practitioner
    • Kanban System Design
    • Kanban Systems Improvement
  • Servicios
    • Formación
      • Management 3.0
      • SAFe 5.0
      • Lean Change Management
      • DevOps Institute
    • Agile Coaching
      • Discover and deliver Agility
      • Solicitud de propuesta de servicios profesionales
    • Software
      • Diagnóstico de Arquitectura de Software
    • Recursos
  • Blog
  • Guías
    • Método Kanban
    • Nexus
    • Definitiva Scrum
    • Oficial Scrum
  • Acerca de
    • Videos sobre Scrum y Kanban
  • Contacto
  • Show Search
Hide Search

Jerónimo Palacios Vela

Hablemos de desarrollo de Software

Hace más de 15 años que monté mi primera empresa de Software. Por aquel entonces era un chaval que tenía más energía y curiosidad que conocimiento, y que junto con un par de socios decidió embarcarse en el mundo de la web. Hacía poco de la explosión de la burbuja .com y los congresos de webmaster todavía eran algo a lo que iba la gente.

Hoy las cosas han cambiado. La carrera programador, analista y jefe de proyecto que vino después ha dejado paso a una aceptación de que los proyectos están muertos y que la mentalidad de producto pesa en una generación que es digital-first. Las empresas necesitan cambiar el time-to-market. Para eso necesitamos cabezas pensantes, no monos ejecutores.

Esto ha provocado un cambio en el mercado del desarrollo de Software. Aproximadamente hace cuatro años empezaron a romperse los techos de cristal del mundo del desarrollo en España. Cuando nuevos productos irrumpen en un mercado dominado por las tarifas por hora, los mejores desarrolladores deciden abandonar el barco y mejorar sus condiciones económicas y laborales. Coincide con la etapa final de la web 2.0.

Dejé de programar profesionalmente hace más de 10 años, después de pelearme con Java y comenzar a amar Ruby on Rails, que introdujo conceptos que para mi eran completamente desconocidos, tales como el desarrollo ágil de Software, los tests continos, behaviour-driven development y gestión de la configuración con Puppet.

Durante estos últimos años dedicado a llevar agilidad a compañías, primero como Scrum Master, luego como Agile Coach y posteriormente como Professional Scrum Trainer, no he dejado de pensar en lo que disfrutaba desarrollando Software. Creo que es imposible quitarse la mentalidad de resolver problemas una vez que la tienes.

He tenido que aprender a lidiar y a explicar conceptos básicos como la necesidad de hacer tests o invertir en un stack de integración continua desde el punto de vista de negocio y no de desarrollo. Porque al final quien pone el dinero para que esas cosas ocurran son personas que, en la mayoría de las ocasiones, no tienen experiencia en desarrollo. Y eso está bien. Si Mahoma no va a la montaña, la montaña irá a Mahoma.

Hoy hace apenas dos años que trabajaba sólo y decidí hacer un llamamiento a gente que, pensando como yo, viniendo del mundo del Software, hubiera andado el camino hacia transformar organizaciones y no puedo más que alegrarme del éxito que ha tenido. Hoy nuestra facturación se mide en siete cifras y somos 16 compañeros. No parece que lo estamos haciendo mal.

Sin embargo, nunca he dejado de pensar en que lo que a mi me gusta es crear cosas. La transformación es una experiencia interesante y de un ámbito distinto. El problema del Software es que requiere de capital, paciencia y tiempo, sobre todo si quieres hacer las cosas distintas en un mercado que es más maduro que incipiente.

[fusion_gallery layout=”masonry” picture_size=”” columns=”” column_spacing=”” gallery_masonry_grid_ratio=”” gallery_masonry_width_double=”” hover_type=”” lightbox=”yes” lightbox_content=”” bordersize=”” bordercolor=”” border_radius=”” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=””][fusion_gallery_image image=”https://jeronimopalacios.com/wp-content/uploads/2019/10/CFD.png” image_id=”15240″ link=”” linktarget=”_self” /][fusion_gallery_image image=”https://jeronimopalacios.com/wp-content/uploads/2019/10/MTTR.png” image_id=”15241″ link=”” linktarget=”_self” /][fusion_gallery_image image=”https://jeronimopalacios.com/wp-content/uploads/2019/10/Historgram.png” image_id=”15243″ link=”” linktarget=”_self” /][fusion_gallery_image image=”https://jeronimopalacios.com/wp-content/uploads/2019/10/Unplanned-800×344.png” image_id=”15242|800″ link=”” linktarget=”_self” /][fusion_gallery_image image=”https://jeronimopalacios.com/wp-content/uploads/2019/10/Scatterplot-800×387.png” image_id=”15239|800″ link=”” linktarget=”_self” /][fusion_gallery_image image=”https://jeronimopalacios.com/wp-content/uploads/2019/10/JPA-Metrics-800×399.png” image_id=”15238|800″ link=”” linktarget=”_self” /][/fusion_gallery]

 

Con todo esto en mente, en Junio nos decidimos a abrir la tercera pata de JP&Associates, la del desarrollo de Software. Ha sido un lanzamiento de perfil bajo en donde nos hemos preocupado más de empezar a hacer que a contar. Estamos todavía incorporando compañeros y hemos desarrollado nuestro primer MVP: Metrics. Una aplicación para reportar métricas de delivery en equipos ágiles que ya estamos usando en cliente. Puedes pedirnos una invitación aquí.

Lo interesante no sólo es la aplicación, sino todo lo que hay detrás: Código limpio, testing, métricas de código y continuous delivery sobre contenedores para desplegar en cualquier plataforma en la nube, sobre un stack Java y React/Vue.

El futuro es incierto y queremos cambiar la forma de vender desarrollo de Software, desde proyectos cerrados hasta Sprints con incrementos de valor terminados y eso supone renegociar la forma de hacerlo con los clientes. Nuestra propuesta de valor de partida es clara: Ofrecer un equipo ágil completo capaz de entregar incrementos de valor y hacerlo a través de Sprints.

Estamos empezando a hablar con clientes que buscan nuevas formas de colaboración más centradas en el valor y menos en los contratos. Si piensas que tu o tu empresa pueden serlo, ponte en contacto con nosotros.

Chief Agile Officer

Imagina que has quedado para cenar con unos amigos en un buen restaurante. Mientras esperas con tu pareja, observas perplejo como entra una familia y toman asiento. Te frotas los ojos para comprobar lo que estás viendo, pero es cierto… todos van desnudos. Lo curioso es que nadie en el restaurante dice nada. No porque no se hayan dado cuenta, sino porque no quieren hablar de ello. Son elefantes en la sala.

El proceso de transformación

Cuando comenzamos a apoyar en un proceso de transformación, hay varios elefantes que tenemos que tener en cuenta: La cultura existente, la deuda técnica, o el papel de determinados roles dentro de un proceso de transformación. En esto nos vamos a centrar hoy.

Consideremos a Marta. Ha trabajado en la misma empresa durante los últimos 15 años, una multinacional. Recientemente su compañía ha decidido emprender un proceso de transformación y adoptar Scrum como marco de referencia. Por primera vez en mucho tiempo las normas de contratación ya no valen. Se han incorporado nuevos Scrum Masters y coaches que hablan de autoorganización, autogestión y eliminación de barreras.

El problema es que durante los 15 años que Marta lleva trabajando en esta empresa, se ha promovido todo lo contrario. Si querías sobrevivir, tenías que apalancarte en una cuota de poder, normalmente medida por el número de personas que tenías a tu cargo y el presupuesto que manejabas.

En los corros alrededor de la máquina del cafe siempre se ha hecho gala de las estrellas -en forma de cabezas de ganado- que se manejaban. Sin embargo, el nuevo liderazgo ha comunicado que se va a dar autonomía plena a los Equipos Scrum para decidir como quieren organizarse. Marta se pregunta: “¿Y entonces, cual es mi papel en todo esto?”

El papel del manager

Trabajando con muchos Managers a lo largo de los años, comprendo que esta situación genera una situación de incertidumbre y desconfianza, incluso rechazo hacia cualquier adopción de Scrum u otros métodos ágiles. Si siempre he sido necesario, ¿Por qué ahora voy a dejar de serlo?

Hay una buena y una mala noticia. Cuando desarrollamos productos en un entorno complejo, el papel del manager no es tanto optimizar y organizar como crear un espacio para que otros puedan tener éxito, tal y como ya publiqué hace tres años sobre el Management en el dominio de lo complejo.

Por otro lado, ese proceso no es inmediato, y hay muchas oportunidades para adaptar nuestro papel a un rol que es completamente necesario dentro de cualquier adopción ágil: El de engrasar y facilitar esa transformación mientras se mantiene el contacto con la organización. Ésto, que a priori puede resultar terrorífico -al fin y al cabo es frontalmente contrario a la cultura promovida hasta hoy-, es una pieza fundamental para que la transformación sea un éxito.

Hace tiempo ya exploré estas ideas en dos artículos sobre cómo formar equipos Scrum y cuál es el papel del Management en un entorno ágil. También mi compañero Alberto ha publicado varios artículos sobre como se aborda este proceso desde Management 3.0, hablando de valores organizacionales y principios guía.

Aprender más

Como no todo es lo que parece, hemos preparado un recorrido amplio sobre el papel de los managers en un entorno ágil en nuestro próximo curso Professional Agile Leadership – Essentials de Scrum.org. Es un curso en el que empresas como Heineken, SAP o ING han participado de sus propios retos y problemas para crear un espacio de conversación sobre el papel del manager en la transformación.

[hubspot type=cta portal=5055889 id=934d4360-2b81-41f6-8a5a-9ba537459f5b]

La realidad es que no es una cuestión de que si va a ocurrir o no, sino de cuando. Estar preparado, conocer Scrum y ser capaz de ofrecer una alternativa para subirse al carro de la transformación.

Reflexión sobre el 2018, inspección y adaptación para el 2019

Hace unas semanas que comenzó el 2019 y era justo el momento de hacer una pequeña reflexión sobre el año que ha terminado.

Sin ánimo de empezar una tradición –aquí puedes leer la del año pasado-, he creido interesante contar qué ocurre entre las bambalinas de la que hasta ahora es la experiencia profesional más alucinante que he tenido nunca.

Este artículo es un ejercicio de transparencia personal y desnudez profesional, así que si has venido aquí a aprender Scrum o Kanban, voy a decepcionarte.

Primero, mis impresiones.

Después, las esperanzas.

Por último, los números.

La sensación permanente de una piedra en el zapato

Cuando hace 15 meses lancé un llamada a crear la empresa de agilismo más increíble del mundo, lo hacía con una mente abierta a lo que viniera.

Al poco tiempo, Alberto Serrano y Carlos Iglesias se unieron para dar forma a lo que hoy es Jerónimo Palacios & Associates -del nombre hablo más adelante-.

Desde entonces, hemos hablado con cientos de personas, cientos de compañías y trabajado mucho. Estamos lejos de alcanzar todos los objetivos que me proponía en aquella newsletter, aunque cada día estamos un poco más cerca.

Lo que quizás me ha sorprendido más es, que a diferencia de cuando empecé a dar cursos de Scrum Master en 2015, donde me encontré con indiferencia por parte de los actores consolidados del mercado y TODOS se negaron a colaborar conmigo, esta vez me he encontrado con una hostilidad activa, especialmente a la hora de proporcionar servicios de consultoría.

Así, hemos tenido situaciones tan absurdas como perder un contrato ya negociado a causa de una llamada o intentar forzarnos a entrar a través de un tercero cediendo una comisión y con unas condiciones abiertamente insultantes.

Con los años he desarrollado una capacidad de endurecer la piel y centrarme en la profesionalidad como bandera; creo que esa cultura está muy incrustada en todos los que formamos parte de esto.

Sin embargo duele. Mucho.

No es tanto el esfuerzo de preparar, acunar y desarrollar una propuesta de calidad, sino el hecho de que absolutamente nada de lo que pudieramos haber hecho habría cambiado la situación.

Nos estaban jodiendo. Conscientemente. Y no nos dejamos joder.

Afortunadamente no ha sido lo habitual, y este año hemos participado en cuatro proyectos de consultoría muy satisfactorios. Nuestro equipo ha crecido y ha rotado. No puedo dejar de acordarme de compañeros como Fabiola, Pablo o Ellen que han compartido grandes momentos de trabajo con nosotros este pasado año.

En 2018 la consultoría ha despegado; nos ha llevado a cotas totalmente nuevas. En 2019 todavía estamos en fase de ascenso y tomando velocidad.

Lo mejor está por llegar.

Hace cinco años quería estar donde estoy ahora

Una de las últimas empresas en las que pasé muchos meses como Agile Coach fue Optiopay, una fintech de Berlin famosa por sus fiestas en sus oficinas de la segunda planta de Pirates Berlin.

Pasé ocho meses trabajando entre el Rio Spree y el Muro de Berlin

Fue en una de esas fiestas donde Marcus Börner me preguntó:

-¿Donde te ves en cinco años?
-En el mismo sitio. Quiero decir, no en esta terraza celebrando una barbacoa, sino en el mismo sitio emocional. Feliz, contento y disfrutando de mi vida y mi trabajo.

Por aquel entonces estaba comenzando como Professional Scrum Trainer.

Cuatro años después he de afirmar que me encuentro donde quería estar. Paso menos tiempo en Berlin pero más tiempo en Granada. Trabajo con gente que admiro y que se implica totalmente en lo que hace.

Tengo la oportunidad de generar impacto en muchas personas.

Soy libre.

Y somos libres.

Desde donde estamos, tenemos la oportunidad de generar impacto en muchas personas

Porque 2018 ha sido el año en que Jerónimo Palacios & Associates ha dejado de ser de Jero y ser de las personas que forman parte de ella.

En 2019, esta empresa es Alberto & Associates, Carlos & Associates, Laura & Associates o Nacho & Associates. Son ellos los que deciden, tiran y gestionan nuestro porvenir. Yo soy uno más. Y cada vez soy menos. Es lo que hubiera querido hace cinco años.

Un pequeño secreto: Nunca me hubiera imaginado que el nombre de nuestra empresa fuera tan irritante para personas que ni siquiera forman parte de ella.

2019 también será el año de incorporar más cosas increibles. En nuestro backlog hay un proyecto de abrir una linea en torno a DevOps, otra en torno a ALM con Microsoft y otra de aprendizaje transformacional transmedia.

Seguiremos formando e incorporando temas candentes, como Evidence Based Management, formación avanzada en diseño de producto y repetir nuestro éxito de final de 2018 con la facilitación gráfica.

La consultoría de excelencia (o boutique, como la llaman algunos), está llamada a convertirse en el servicio estrella.

Uno de los primeros proyectos que ha visto la luz ha sido el de nuestras instalaciones. Un espacio de más de 800 m2 en Madrid donde poder dar servicio y seguir desarrollando nuestro equipo y nuestro portfolio.

Hemos empezado a dar forma a este espacio de la mejor forma que sabemos: Inspeccionando y adaptando, de forma iterativa e incremental.

Hacerlo a lo grande nos hubiera quedado muy grande.

Por último, los números

En 2018 hemos formado a un 40,6% más de alumnos en nuestros cursos, lo que pone el listón en torno a los 1.400, que se suman a los más de 2.000 que ya tenía nuestra comunidad. Son lo más importante que tenemos, y tenemos que seguir aportándoles valor.

Nuestra facturación se ha quedado rozando el millón de euros. Nuestra puntuación NPS se mantiene por encima de 50, aunque ha bajado un poco con respecto al año pasado, dependiendo del curso y del cliente. Más o menos la mitad de nuestros alumnos llegan vía recomendación de otros alumnos.

Nuestra página web ha recibido 230.000 visitas y hemos servido casi 400.000 páginas vistas a más de 150.000 usuarios únicos.

Hemos participado en cuatro proyectos de consultoría, de los cuales tres ya están cerrados. En alguno de ellos, el cliente nos ha pedido hacer un caso de estudio que publicarán pronto.

Hemos participado y patrocinado los principales eventos de agilidad en España como el AOS, la CAS, Agile Kids o Agility 360. También hemos colaborado con el reciente estudio que han publicado McKinsey y Scrum.org, además de la revisión de los libros de Nexus y Professional Scrum Product Owner.

Aproximadamente el 25% de nuestro negocio sigue siendo internacional, aunque este año hemos tenido más presencia fuera de Europa que dentro. También hemos crecido en número de clientes, hasta los 244.

No tenemos deudas. Ni socios. Ni inversores. A dia de hoy podríamos operar durante seis meses ingresando CERO euros.

Al cierre de este post somos ya diez personas, con una más que se incorporara el próximo més de Febrero y seguimos en conversaciones con mucha gente.

Quizás dentro de un año seamos 50. O los mismos. Quizás no quedemos ninguno.

Eso es lo emocionante.

El Scrum Master vs el Agile Coach

En Septiembre estuve unos días trabajando en Colombia con el equipo de Scotia Bank, formando a futuros Scrum Masters y Product Owners. También estuve en las oficinas de Everis en Bogotá en un Meetup organizado por Agiles Colombia.

En ambos sitios me hicieron una pregunta que creo ronda la cabeza de más de uno, así que me anoté hacer la primera newsletter después de las vacaciones sobre este tema: ¿Que diferencia al Scrum Master del Agile Coach?

Los orígenes

Cuando Takeuchi y Nonaka, con la ayuda de Ken-Ichi Imai hicieron una investigación en 1986 sobre el rendimiento de determinados equipos de compañías líderes en el desarrollo de producto, hicieron un símil con el Rugby, y específicamente con las Melées (Scrum) para definir lo que hacía distintas a estas compañías de otros equipos.

En ese momento no hay ninguna mención a roles fuera del equipo de desarrollo de producto.

Posteriormente, cuando Ken Schwaber y Jeff Sutherland modelan y prueban un proceso de desarrollo de Software que presentan en 1995, tampoco incluyen la necesidad de un actor externo al equipo. Hay que hacer notar que Scrum podía basarse en los roles propuestos por Ian Graham y estaba fuertemente ligado a la programación orientada objetos.

En la primera versión de Scrum, no hay una mención explícita al Scrum Master. Tampoco hay una práctica de retrospectiva, pero de eso hablaré más adelante.

En 1999, Kent Beck publica el libro sobre Extremme Programming. Describe la necesidad de incluir roles claros dentro de XP, entre ellos el de Coach. Por primera vez menciona la necesidad de una persona que se encargue de tomar el rol de “Acompañar y entrenar” a los miembros del equipo. Durante los años 1999 a 2004, XP fue mucho más popular que Scrum.

Después de crear Scrum y con las experiencias acumuladas de Jeff Sutherland en Easel y Ken Schwaber en Fidelity, además de los trabajos de Kent Beck en XP y Martin Fowler sobre la integración continua, todos estos actores, junto con aquellos que había tenía mucho éxito en XEROX y 3M durante finales de los 80 y los 90, empezaron a intercambiar experiencias que dirigirían de manera definitiva todos estos marcos, metodologías y librerías de prácticas.

Un ejemplo de esto es el uso de retrospectivas, que sólamente se popularizó con la publicación del libro de Norman Kerth en el año 2002. Para entonces la Agile Alliance y la Scrum Alliance hacía tiempo que eran una realidad.

Ken Schwaber ya daba cursos de Scrum y hacía tiempo que había incorporado la figura del Scrum Master dentro de sus materiales, como se puede comprobar en este PDF que utilizaba para training en el año 2002.

De hecho, la figura de coach ya era popular en el año 2003 cuando se debatía sobre su rol en el éxito de compañías, como se puede comprobar en este paper resumen de la 18ª conferencia de la ACM.

¿Quien era un Agile Coach? Alguien que tiene una visión global y es capaz de promover cambios competitivos en una compañía a través de su experiencia en el campo de la gestión de desarrollo de producto.

¿Y el Scrum Master? Es, quien siendo miembro de un equipo Scrum, ayuda a éste y a la organización a mejorar el valor entregado a través de la entrega rápida de producto terminado.

Entonces la principal diferencia es que mientras el Agile Coach actúa principalmente a un nivel de departamento o de organización, el Scrum Master lo hace desde la entrega (delivery) y también la organización.

El Scrum Master y el Agile Coach en 2020

Recuerdo poco antes de la última CAS, cuando cenando con unos amigos, uno me dijo: “Después de escucharte he llegado a la conclusión de que yo también soy Agile Coach”. Eso me produjo una sensación de desasosiego. Estaba claro que algo había explicado mal cuando una persona que definitivamente no tenía ninguna característica que la resembrara a esos Agile Coaches de 2003 pudiera pensar que transformaba organizaciones.

Existe una confusión entre disciplinas. Aquellos que llegan de fuera del mundo del Software tras haber recibido una extensa formación de coaching que en algunos casos conlleva hasta cinco fines de semana, comprueban como no hay mercado más allá de formar a otros coaches, consideran que el Agile Coaching es una mezcla de Agile con técnicas de Coaching.

Mientras que las técnicas de Coaching pueden ser ciertamente efectivas como complemento, la figura de Agile Coach necesita tener un conocimiento profundo de Negocio, Procesos y Transformación como parte de su abanico de propuestas.

Es por eso que un rol de Scrum Master puede ser más asequible. Desde un equipo Scrum, es relativamente más sencillo aprender, practicar y adquirir experiencias transformadoras desde la entrega de valor para luego exportarlas al resto de la organización.

Sin embargo, ocurre una paradoja. Mientras que parece que el siguiente paso natural para un Scrum Master es convertirse en Agile Coach, no lo es en absoluto. Esto es porque estos roles se solapan, no expanden uno sobre otro. En ocasiones, el Agile Coach puede carecer incluso de conocimientos necesarios para mejorar el valor de la organización. En otras palabras: Puede que ni siquiera pueda justificar su alto coste.

Por lo contrario, un buen Scrum Master no solamente tendrá una gran demanda, sino que muy posiblemente sea capaz de hablar con distintas capas de la organización. A diferencia del Agile Coach, donde puede (o no) hacerlo en función de su experiencia para transformar, para el éxito de Scrum dentro de la organización, no queda más remedio que hacerlo.

Resumiendo, un buen Scrum Master siempre será un buen Agile Coach, mientras que un Agile Coach será bueno o no dependiendo de sus experiencias, que en mi observación, son extremadamente variables.

Uno de los motivos por los que en Otoño celebramos la primera edición del curso de Professional Scrum Master II es dar la oportunidad a aquellos que ya están experimentando cambios de relevancia en su organización una oportunidad para poder tener un espacio donde reflexionar más allá de las prácticas y aprender nuevas formas de facilitar el cambio en su trabajo diario. Este curso, al igual que el de Professional Agile Leadership, no está tan centrado en el conocimiento como en la práctica.

Como dice Ken Schwaber: “Scrum es simple de entender y muy difícil de dominar”. Hemos querido crear un espacio donde el acompañamiento y la mentorización sean el ingrediente fundamental para proporcionar a nuestro alumnos la posibilidad de seguir creciendo acompañados por nosotros.

El estado de Scrum en 2018

En 1991, Geoffrey A. Moore publicó un libro llamado “Crossing the Chasm” (En Español: Cruzando el Abismo). Es un libro que en su primera edición llegó sólamente a las 5.000 copias vendidas, y que en posteriores revisiones en 1999 y 2014 llegó a alcanzar las 300.000 copias. Este éxito se produjo principalmente a través del boca a boca. Si inicialmente el libro apeló a directivos de empresas tecnológicas, posteriormente lo hizo a ingenieros y por último ha terminado siendo referencia en las escuelas de negocio.

El libro, en resumen, es una descripción de las etapas que tienen que pasar los productos tecnológicos para llegar a la población y cuales son sus características de adaptación en el mercado. Desde los innovadores hasta los rezagados, los productos van evolucionando a través de su adopción en el mercado de esta forma.

La hora de los talibanes y de los agilistas malos

Hace tiempo tuvimos un amplio debate en twitter sobre el Sprint 0. El resumen es que hay quien apoya que Scrum y otros métodos deberían ser flexibles y los que opinan lo contrario.

Éste argumento: “Los agilistas sois talibanes y tenéis que madurar” es un argumento muy común, especialmente entre aquellos que no se sienten cómodos en el lenguaje de todo lo que hacemos. Más sobre este argumento en el blog de Café Ágil.

Lo curioso es que para rebatir, el argumento principal es: “Hay que estar más cerca del negocio”. Como si los que trabajamos en esto no lo estuviéramos. El problema es el mismo que planteaba Moore en “Cruzando el Abismo” y que se ve divertidamente reflejado en la viñeta que preside este artículo.

Las organizaciones se dan cuenta de que cada vez están más rezagadas en la competencia por un mercado -los millenials- que las ve cada vez más anticuadas, y han encontrado en todo lo que se llame digital una salida para intentar recuperar su posición en el mercado.

Como la transformación digital es para cada uno lo que quiere, han ido bajando hasta buscar métodos que les permitan competir en ese mercado, eso si, sin cambiar un ápice sus procesos internos. Así que demandan Scrum y Kanban para el desarrollo de sus productos y esto ha dado pie a un mercado en el que Scrum y Kanban son lo que a cada uno le viene bien. En esta línea iba mi artículo sobre el mercado de limones.

Y en ese lienzo, estamos algunos diciendo: Si no haces Scrum, no lo llames Scrum. Y aquellos que aprovechan esta situación -económicamente- te dicen que eres un talibán.

¿Innovators, Early Adopters, Early Majority o Laggards?

En ocasiones me pregunto, ¿En qué fase estamos con esto de la agilidad? Y creo que ya hemos cruzado definitivamente el abismo. Palabras como Scrum o Kanban, Sprint, Iteración o Scrum Master ya son parte del vocabulario normal de muchas compañías.

Es más, hemos invertido, tal y como describe Moore en su modelo, el proceso en el cual en lugar de vender innovaciones son los clientes los que las exigen. A su manera, pero lo hacen. Eso también abre la oportunidad a vender lo que consideramos oportuno cuando nos piden agilidad.

Cada vez más surgen voces que dicen “Yo no hago agilidad, yo hago [_____]”, lo cual me parece totalmente lícito. Sin embargo, creo que es deshonesto que te compren agilidad y venderle [_____], que es en definitiva lo que vamos viendo en muchos clientes que vienen rebotados y con malas experiencias.

En Scrum, no hay Sprint 0

Si vamos a la guía de Scrum, no encontraremos mención a ninguna de estas dos técnicas. La gestión de proyectos en Scrum se produce en un sólo Sprint y abarca todo el ciclo de vida del software: planificación, diseño, desarrollo, testeo y entrega en un sólo Sprint.

Tener un Sprint 0 es solo una manera de intentar hacer Scrum en fases o lo que es lo mismo, waterfall en Sprints. En Scrum siempre se comienza por el primer Sprint y al final del mismo se entrega una funcionalidad de negocio terminada. Eso permite enfocarse en lo que es realmente fundamental para entregar esa pieza de Software.

Existe una manera de tener el tiempo necesario para montar todo el despliegue usando Scrum, y esto es simplemente ajustando la longitud del Sprint. Esta depende de dos factores:

  1. El tiempo mínimo que el equipo de desarrollo necesita para producir valor: Si el equipo no es capaz de producir software terminado en dos semanas, ¿Para que poner Sprints de dos semanas? Si el equipo no es capaz de entregar software en 30 días o menos, hay que ver los impedimentos y eliminarlos.
  2. Un horizonte aceptable de riesgo para el Product Owner: El Product Owner, como responsable de gestionar la inversión del desarrollo, tiene que sentirse cómodo con el horizonte de planeamiento planteado por el equipo de desarrollo.

Si el equipo no puede entregar software en dos semanas, pueden tener Sprints de 3 o de 4 semanas. Scrum no dice: “Sprints de dos semanas”, sino “Software en 30 días o menos”.

¿Que sentido tiene hacer un Sprint 0 si las necesidades del proyecto pueden cambiar en dos, tres o cuatro Sprints? Scrum es desarrollo de Software iterativo e incremental, donde cada Sprint tiene varias oportunidades de inspeccionar y adaptar. Un Sprint es un proyecto completo.

Si tomamos todas las decisiones en el Sprint 0, no estamos haciendo mucho más que una fase de “preparación al desarrollo”, donde estaremos tomando muchas decisiones que luego pueden ser erróneas conforme vayamos descubriendo nuevas necesidades que antes no estaban claras. No es muy distinto de PMP o Prince2 y nos llevará al mismo problema.

Si soy completamente incapaz de entregar Software funcionando en 30 días o menos, igual Scrum no es para mi. Y eso está bien.

Tampoco inception

 

Un inception es una técnica que permite descubrir que se quiere hacer para poder llenar un Product Backlog. Es una reunión ligera, que puede durar unas pocas horas, y su lugar ideal de realización es durante el Sprint Planning del primer Sprint.

Sin embargo, muchas organizaciones intentan hacer inceptions que duran varios días y luego necesitan una o varias semanas para poder analizar con detalle cada uno de los Product Backlog Items para poder ordenar el Product Backlog.

Esto tiene otro nombre: Toma de requisitos. Da igual que ahora se haga con Post-its® y en una reunión facilitada, sigue siendo lo mismo que se lleva haciendo muchos años.

Los inceptions no forman parte de Scrum, son técnicas que no deben de interferir en el framework. Por lo que nos cuentas, querido lector, los coaches de tu organización, están adaptando el marco de trabajo Scrum a las técnicas que ellos conocen.

Todas estas técnicas funcionan muy bien con Scrum siempre y cuando asumamos que hay que entregar Software terminado en 30 días o menos. No Story Points. Software terminado.

Esto en realidad esto está inventado, y se llama Waterfall (o desarrollo por fases)

El problema es que en organizaciones en las que se dan estas situaciones, la inversión en agilidad está directamente desperdiciada. Es solamente ponerle distintos nombres a lo que se ha hecho siempre. Un proyecto se convierte en las siguiente fases:

  1. Inception: Conocido como la fase de toma de requisitos
  2. Sprint 0: Conocido como la fase de preparación de arquitectura/inraestructura. Algunos meten el Inception aquí
  3. Desarrollo
  4. Testeo
  5. Hardening o estabilización
  6. Despliegue: Conocida como fase de igual nos hemos equivocado en cosas y tenemos que volver a empezar

Asumiendo que cada una de esas fases dura 1 o 2 sprints, estamos poniendo Software enfrente del cliente cada 3 o 6 meses. Eso en el mejor de los casos. En el peor de los casos desarrollaremos durante un año sin que el cliente haya visto nada ¿En qué es distinto esto de los métodos tradicionales como PMP o Prince2? En nada.

La premisa de Scrum es: “Software terminado en 30 días o menos”, de forma iterativa e incremental. Todo lo que sea salirse de eso, llámese Sprint 0 o Inception no es Scrum y es una señal de organizaciones y equipos inmaduros.

Si no son capaces de hacer esto, es mejor empezar con otra técnica, como el Método Kanban, que permite una mejora evolutiva partiendo de un proceso ya existente. Seguir con Scrum es abocarse al fracaso en esta situación.

Por último y para cerrar las newsletters hasta Septiembre, recomiendo la lectura del libro de Ken Schwaber y Jeff Sutherland, creadores de Scrum: Software en 30 días o menos. En el mismo se explican las mecánicas básicas de como funciona Scrum y de cual es el ciclo de vida de desarrollo de software cuando se utilizan métodos ágiles.

  • « Ir a la página anterior
  • Ir a la página 1
  • Ir a la página 2
  • Ir a la página 3
  • Ir a la página 4
  • Ir a la página 5
  • Páginas intermedias omitidas …
  • Ir a la página 25
  • Ir a la página siguiente »

Mantente al día a través de nuestra Newsletter Susbribirse

Jeronimo Palacios & Associates

Copyright © 2023 · Jerónimo Palacios & Associates S.L.

  • Aviso legal
  • Condiciones de venta
  • Política de cookies
  • Política de privacidad