Éste es el segundo de una serie de artículos (el primero habla del equipo) y tratará sobre la metodología de construcción de un producto à-la-startup y terminaremos próximamente con el último sobre tecnologías. Hablamos de qué es importante en sí de la metodología, dos ejemplos y reflexiones finales.
Llevaba un tiempo pensando en que sería una buena idea poner en claro parte de la experiencia acumulada en ya bastantes años de desarrollos tecnológicos para startups (propias o ajenas). Siendo la casuística relativamente acotada, como ahora comentaré, es probable que pueda ser útil a un conjunto concreto de personas que están a punto de emprender una aventura de un nuevo negocio en Internet en donde la tecnología no es un elemento “commodity”, sino la clave del éxito.
¿Startup tecnológica?
Estos artículos parten de una premisa sobre lo que entendemos por startup tecnológica y es aquella aventura empresarial que se dispone a resolver un gran reto tecnológico para proporcionar un producto o servicio ya sea B2C, B2B o ambos. Típicamente parte de cero y existe incertidumbre no solo sobre el modelo de negocio sino sobre la posibilidad de construir el producto. Para no repetirnos mucho, podéis leer más sobre este enfoque en el primero de los artículos.
¿Qué metodología le va mejor a una startup tecnológica?
En principio toda aquella que prime la capacidad de reducir desperdicio en los procesos siendo al mismo tiempo ágil y mutante cuando las circunstancias lo requieren. Dicho de otra forma, se seleccionan las metodologías que detectan los errores rápidamente, permiten aprender de ellos para inmediatamente aplicar medidas de corrección orientadas a entregar valor con el producto. Este valor es un peligroso intangible pero hay buenas prácticas para identificarlo, la mayoría de los cuales se refieren a valor percibido por un usuario que propone negocio en un entorno de producción o equivalente a producción.
Por muy clara que sea la idea detrás de una startup, la ejecución puede ser una montaña rusa en parte por las circunstancias cambiantes del entorno pero la mayoría de las veces por cambios de rumbo del propio equipo fundador al evaluar sus propias hipótesis. Toda metodología que fiscalice, penalice y estigmatice el cambio ya sea más abiertamente o más secretamente (enterrándola en procesos, gestiones y documentación) va a llevarse muy mal con un proyecto que en gran medida va de prueba y error. Asimismo, toda metodología que relegue la mejora continua y la medición recurrente de cómo se está desempeñando el propio proceso e insista en volver sobre sí misma para dar respuesta a todas las preguntas tendrá un encaje imposible en este tipo de desarrollos.
Una reunión de Kaleidos siguiendo una técnica específica
Actualmente, solamente las metodologías ágiles en sus diferentes “sabores” cumplen adecuadamente estas necesidades. Si vamos al Manifiesto por el Desarrollo Ágil de Software vemos el núcleo ideológico que cumplen todas.
- Individuos e interacciones sobre procesos y herramientas
- Software funcionando sobre documentación extensiva
- Colaboración con el cliente sobre negociación contractual
- Respuesta ante el cambio sobre seguir un plan
Esto es, aunque valoramos los elementos de la derecha,
valoramos más los de la izquierda.
¿SCRUM o KANBAN?
Lo primero que habría que decir de estas dos implementaciones “de moda” compatibles con el manifiesto ágil es que para Kaleidos siempre tiene prioridad el manifiesto ágil sobre las metodologías concretas. Esto es así porque muchas veces se asumen las metodologías como recetas a seguir cuando son los principios que representan lo que realmente importa.
Por ejemplo, si para el desarrollo de un producto estamos aplicando SCRUM pero solo lo siguen los “técnicos”, el manifiesto ágil chirría porque estamos, como mínimo, invalidando el primer principio que dice que los individuos y sus interacciones son más importantes que un proceso concreto (en este caso que un equipo use SCRUM y el resto otras cosas). Por cierto, éste es un error muy común que se da en muchas startups; los desarrolladores técnicos usan metodologías ágiles pero el resto de intervinientes maneja otras fórmulas que a medio plazo van a propiciar una colección infinita de malentendidos y frustraciones.
Un ejemplo de backlog y un sprint de SCRUM usando Taiga
Hecha esta aclaración, podemos identificar que SCRUM funciona en general mejor para equipos que pueden comprometerse a entregas parciales cada cierto tiempo (ciclos/sprints de x semanas) y cuando el número de injerencias exteriores (incluimos aquí injerencias internas de la startups pero ajenas al propio equipo) está muy acotado. Típicamente antes de una primera gran salida al público. Nuestra experiencia dice que los ciclos o sprints (planificación, ejecución, demo, retrospectiva, planificación) tienen que ser lo más cortos posibles y al mismo tiempo mantener el “overhead” de las liturgias asociadas a las diferentes reuniones “oficiales” dentro de un margen razonable para que no canibalicen el ritmo. El tamaño ideal de sprint suele ser 2 ó 3 semanas pero tenemos clara preferencia por 2 porque sprints de 3 semanas se nos hacen a veces muy largos para la autoevaluación.
Por el contrario, KANBAN no tiene per se bloques temporales donde entra “tarea” predefinida sino que atiende a un modelo más orgánico en donde se van tomando tareas de una bolsa y se van haciendo pasar por una serie de estados hasta su conclusión. Si SCRUM busca tener una velocidad predecible por sprint, KANBAN busca tener una velocidad predecible por ciclo de vida de una tarea. La diferencia no es nada sutil y hace que KANBAN, siendo aparentemente más sencillo, sea mucho más difícil de dominar y requiera equipos mucho más maduros. KANBAN presenta siempre una vista del To-Do de forma fluida, como una foto in media res y se requiere una gran capacidad de análisis para identificar dónde están los cuellos de botella. Por ello KANBAN viene de la mano del concepto de Work In progress Limit o WIP Limit, que por cada estado (Nuevo, En Progreso, En Pruebas, etc) marca el máximo de tareas que se admiten en ese estado. Si ese WIP Limit se supera, salta la alarma. KANBAN suele ser la opción por defecto cuando el entorno exterior al equipo tiene mucha ascendencia sobre prioridades cambiantes casi cada día y esto es más probable cuando un producto ya se ha lanzado y es inevitable la influencia de la comunidad de usuarios o clientes.
Un ejemplo de tablero KANBAN usando Taiga
Aun así, hay equipos que apuestan por KANBAN estando protegidos por la ausencia de versión pública así como equipos que mantienen SCRUM incluso cuando el producto lleva años en el mercado. Evidentemente, ambas metodologías son capaces de aguantar casi cualquier escenario, la clave son los principios y cómo el equipo los resuelve.
A partir de aquí surge la duda de cuánto adaptar cualquiera de estas metodologías a la casuística concreta de la startup. Y dejemos las cosas claras, todas las startups consideran que tienen una casuística particular que obliga a las metodologías a adaptarse. El problema es que esa adaptación puede esconder trampas que nos hacemos a nosotros mismos. Podemos querer ir a SCRUM y poder redefinir un sprint que está en curso o ejecutar KANBAN pero querer listados de funcionalidad concretos y comprometidos para tal fecha. Esto desemboca en una disfuncionalidad terrorífica.
Buenas prácticas en Kaleidos
Por nuestra experiencia desarrollando producto para startup (ya sea propia o ajena) hemos acumulado una serie de buenas prácticas que nos resuelven muy bien los límites difusos entre los principios y las propias metodologías. Estas buenas prácticas se asientan, es cierto, en equipos de altísima cualificación que muy rápidamente se “adueñan”, en el mejor sentido de la palabra, del producto que están construyendo pero pensamos que son de aplicabilidad general:
- SCRUM para pre-lanzamiento, KANBAN para post-lanzamiento salvo que haya demasiados stakeholders en fase pre-lanzamiento y entonces optamos por KANBAN.
- Incorporación de todos los perfiles relacionados con la construcción del producto en la metodología. Todos en Standup dailies, planificaciones, demos, retros… Y esto, por supuesto, incluye al cliente externo si existe. La transparencia es una fórmula de éxito en metodologías ágiles.
- Si estamos en SCRUM, solemos crear un sprint de diseño que va tomando user stories del backlog de alta prioridad y las va procesando para dejarlas listas para los sprints más orgánicos que las llevan hasta su conclusión en una demo.
- Una persona rotatoria asume el rol del “Pirata Roberts”, que sirve de QA y suele llevar la demo cada sprint. Amplía el bus factor y muchas veces hace innecesaria la figura de Scrum Master.
- Se da visibilidad a cuando una persona asume la responsabilidad de una user story que está fuera de su zona de confort. A eso le llamamos tomar una dosis de iocaína (veneno ficticio) sabiendo que en pequeñas dosis y a lo largo del tiempo esa persona se volverá inmune a una dosis grande e indefectiblemente letal.
- En KANBAN simulamos el concepto de sprint y fijamos demo, retrospectiva y pseudoplanificación cada x semanas (normalmente 2).
Un panel de retrospectiva en Kaleidos
¿Un buen día se decide aplicar una metodología?
No. Para tener ritmo a medio plazo hay que coger carrerilla. Nuestra carrerilla consiste fundamentalmente en dos fases antes de comenzar cualquier desarrollo en sí.
La primera es un conjunto de sesiones de trabajo para aterrizar bien la idea de producto. A esto lo llamamos la fase de Análisis y Definición y suele durar entre 2 y 4 semanas con entre 4 y 6 sesiones especializadas en diversos aspectos del proyecto. El resultado es una visión compartida entre todo el mundo en el proyecto (no es poca cosa) y un plan a ejecutar por fases.
La segunda es una reflexión del equipo de Kaleidos que ha participado en la fase anterior para decidir cuál es la mejor tecnología, la metodología más adecuada y, aunque pueda resultar antiintuitivo, cuál es el mejor equipo con la posibilidad de hacerse el harakiri si es la decisión más responsable (y entonces pedir la participación de otras personas en Kaleidos).
En esta segunda fase, a la que bautizamos como Fase Cylon, se barajan todos los aspectos metodológicos a tener en cuenta y se explicitan de forma clara atendiendo siempre a los principios que pretenden resolver.
Tras el Análisis y Definición y la Fase Cylon, puede comenzar la construcción del producto en sí (en términos de demo, porque la construcción per se ya comenzó en la primera sesión de la fase de Análisis y Definición). Tras una serie de iteraciones se pueden plantear modificaciones más o menos significativas de la metodología, desde decidir cómo integrar la resolución de errores a cambiar de “sabor” y migrar a KANBAN, por ejemplo.
Una nota aparte sobre el valor de estimar en metodologías ágiles
En Kaleidos asistimos con estupor a un mito muy extendido (en parte por algunos gurúes agilistas) en donde la estimación de las tareas es tabú y no se puede predecir qué será entregado en tal o cual fecha. Se trata de una media verdad que ha transmutado en un muy interesado malentendido (o quizá haya sido al revés). Estimar el trabajo, independientemente de la métrica usada, de una user story no es una práctica anti-agilista. ¿Por qué habría de serlo? Ayuda a clarificar la propia tarea y a relacionar el valor aportado con el tiempo que consumirá.
Una pantalla del proyecto secreto de Taiga SeedTime sobre estimaciones en agile que verá la luz pronto
Lo que sí es cierto es que por mucho que estimemos de forma individual una user story pasan dos cosas:
- Las user stories pueden mutar o ser relegadas rápidamente, haciendo que el esfuerzo de estimar alimente el desperdicio, algo a lo que las metodologías ágiles tienen alergia.
- Qué estará en producción a 10 sprints vista es imposible de predecir porque la metodología y los principios nos dotan de la posibilidad de pivotar cada pocas semanas.
Sobre todo este segundo punto es el que se esgrime para argumentar que “en agile no se estima ¿para qué?” pero esto es una falacia. Agile en general asegura que para cualquier fecha dada se habrá construido el producto con menor desperdicio y mayor valor entregado posibles. No dice qué contendrá pero sí su naturaleza y su orden de magnitud. Esto no es excusa suficiente para no estimar pero para aquellos equipos que están deseando no hacerlo, el malentendido sabe a maná.
¿Estimamos en Kaleidos? A veces sí, a veces no. Depende del proyecto y del equipo. En general tendemos a estimar solo aquello que tiene mayor prioridad y tiene visos de formar parte del trabajo de las próximas semanas. Asimismo, el trabajo previo de UX y UI facilita mucho la concrección de esta tarea de estimación que gana en calidad y exactitud. Sin embargo, una estimación general de un backlog es algo que forma parte de la Fase Cylon antes mencionada y da una idea del orden de magnitud del proyecto al que nos vamos a enfrentar.
Consideraciones finales
Muchas veces el cómo se hacen las cosas es el gran valor de un producto. Un ritmo sostenido, facilidad para adaptarse y una autoevaluación continua. Es clave la involucración de todo el mundo, especialmente del cliente, que tiene que sentir el proceso igual que todo el resto del equipo. Asimismo no hay “técnicos”, “creativos” y “marketing”, hay un equipo que trabaja siguiendo las mismas pautas y participando en el proceso cuando toca.
Una parte muy importante de la metodología para una startup es la transparencia del proceso. Estamos hablando del core de negocio de una nueva empresa y no valen medias tintas, lo cual rescata magníficamente el tercer principio del manifiesto ágil Colaboración con el cliente sobre negociación contractual y es que los productos tecnológicos no los desarrollan los contratos.
Espero que haya sido una lectura provechosa. En el último artículo de esta serie abordaremos el aspecto de la tecnología.