Cómo escribir un libro con Scrum

¿Cómo utilizar Scrum para crear y publicar libros por parte de persona o equipos pequeños de manera efectiva? En este artículo te damos nuestro enfoque.

 ¿Por qué este artículo?

En diversas ocasiones he pensado en escribir un libro sobre metodologías y agilidad, pero diferentes aspectos me han echado atrás, relacionados con la disponibilidad de tiempo, la temática y con quien abordar una aventura de tal complejidad. Ahora tengo en mente un nuevo intento relacionado con Scrum y quería comenzar el año con un primer artículo en este blog que hable de como Scrum puede hacer más factible escribir un libro en paralelo a tu trabajo.

 Un libro es un producto complejo

Veamos una breve teoría de porqué Scrum es un buen enfoque para escribir libros. 

Un libro es un producto. Según la wikipedia un producto es una opción elegible, viable y repetible que la oferta pone a disposición de la demanda, para satisfacer una necesidad o atender un deseo a través de su uso o consumo. Al ser un producto de tipo fundamentalmente intelectual, de la misma manera que el software, su creación del libro es un proceso de diseño que realizan los creadores en su entorno, mientras que su producción se realiza por separado en la imprenta y entonces se consume por los clientes.

Un libro es complejo. Según la Matriz de Stacey, aunque la tecnología para escribir y publicar libros es simple, determinar qué hay que escribir (los requisitos del contenido) es difícil, y todavía lo es más determinar como va a reaccionar el público que lo lea y lo referencie (o no) a terceros. También es complejo el trabajo en equipo si es la primera vez que realizas algo así.

Dado pues, que un libro es un producto complejo, el marco de trabajo Scrum, con un equipo integrado para la toma y ejecución rápidas de decisiones, así como su ciclo de vida con iteraciones frecuentes para aprender (inspección y adaptación) respecto a como debe ser el libro que satisfaga al cliente, y como el equipo puede trabajar de manera efectiva.

El artículo Coordinación editorial: tareas y responsabilidades da una buena visión general de las actividades y roles de las iniciativas de una editorial.

 Equipo Scrum en la creación de un libro

Además del rol evidente del escritor, existen muchos otros roles necesarios en mayor o menor medida en una iniciativa editorial, como p.e.:

• lectores profesionales,
• correctores,
• maquetadores y diseñadores,
• fotógrafos y infografistas

Respecto a los roles del equipo Scrum:

• Equipo de  desarrollo. Adaptando Scrum a una iniciativa modesta de un libro basado en autoedición, está claro que no se puede contar con estos roles a tiempo completo para formar parte de un equipo, y que sus actividades se tendrán que suplir con trabajo de los propios autores, y también de colaboraciones de conocidos o de profesionales externos, estos últimos a tiempo parcial y probablemente no sincronizados temporalmente con los autores. Esta es una limitación directa a la existencia al Equipo de Desarrollo autosuficiente y autogestionado que pide Scrum.
• Product Owner. Por los mismos motivos de viabilidad económica, no se podrá contar con un editor que gestione el proceso de creación y publicación del libro. Serán los autores quienes hayan de realizar esta actividad.
• Scrum Master. Así mismo, difícilmente se podrá contar con un rol con experiencia en el mundo editorial, que mentorice y entrene a los autores en esta iniciativa. Éstos deberán informarse sobre como realizar las actividades de la creación y publicación del libro, y utilizar el feedback que puedan obtener de las personas con las que interaccionen y el que puedan generar durante las retrospectivas.

Así pues, los roles no podrán ser encarnados por personas dedicadas, pero no por ello deben ignorarse. Aunque sea a tiempo parcial, los autores deberían considerar las responsabilidades de cada rol y tenerlas en cuenta durante la realización de todas las actividades, aunque hacerlo así lo haga más difícil.

 Planificación

Una iniciativa compleja debe planificarse, almenos a a alto nivel, antes de comenzar para que sea factible. Se necesita involucrar a diferentes personas y comprometer un esfuerzo significativo, aunque sea personal. Esto supone determinar aspectos como:

• Qué actividades son necesarias y quien las realizará, incluyendo el presupuesto de colaboradores externos.
• Qué alcance tendrá el libro (contenidos) y que esfuerzo se requerirá para realizarlos.
• Qué dedicación y ritmo tendrán los autores para realizar el grueso de las actividades.

 Visión del producto

Una función básica de la gestión del producto es definir su visión para alinear a todos los participantes e intentar discernir su viabilidad. Una herramenta sencilla para esto es el «Value Proposition Canvas«, que nos obliga a pensar primero en el cliente para averiguar que necesita y contrastar si nuestra idea encaja con dichas necesidades. Aunque sea duro, una de las decisiones más valiosas es cancelar una iniciativa con baja viabilidad y dedicar los recursos y tiempo necesario a otras. Considerando las casillas de este lienzo:

• Deseos. ¿Qué es lo que desea conscientemente el potencial cliente? ¿Es p.e. un jefe de proyecto tradicional que quiere certificarse para entrar con mejor pie en empresas ágiles? Encajar la temática (y hasta el título) del libro con este apartado es vital, pues los libros un libro novedoso enganchara al lector por estas aspiraciones y no será tan evidente (ni tendrá tanta competencia) como uno titulado «Creación de blogs con WordPress».
• Necesidades. ¿Qué es lo que necesita el cliente pero posiblemente no lo sepa conscientemente? Frecuentemente estos criterios no serán los más importantes a la hora de escoger el libro, a no ser que se perciban como no existentes. P.e. ¿es un libro práctico? ¿está escrito en el idioma que quiere el lector? Así pues, también es importante tenerlos en cuenta.
• Temores. Tener en cuenta estos aspectos es vital para evitar que el potencial cliente se decida a comprar. P.e. qué percepciones pueden echar atrás al cliente a la hora de elegir el libro. ¿Es un libro caro? ¿No lo ha escrito o lo recomienda un autor de prestigio? 

Por el lado del diseño del producto, tener en cuenta la experiencia de lectura y los beneficios que debe tener el lector es imprescindible para que, una vez que se haya leido el libro, lo recomiende a terceros. La reputación de los libros y los comentarios en las webs de compra son vitales para dar el paso de compra. Por último, muchos lectores escogen los libros según sus características (p.e. índice de contenidos, que debe contener los temas y conceptos que espera el lector).

Otra recomendación es usar la herramienta «Personas» para crear un perfil de los tipos de clientes a los que nos dirigimos, y posiblemente también algún otro al que NO nos dirigimos. Esto nos ayudará desde el principio a escoger los temas, y durante la redacción del contenido a ajustar el estilo, nivel técnico y otros aspectos. Para ello será bueno tenerlos bien visibles, p.e. colgando estas Personas en la pared.

 Hoja de ruta del libro

La naturaleza de esta iniciativa se parece más a un proyecto que al ciclo de vida de un producto de software, especialmente por el hecho que existe una fabricación del producto (impresión). Por ello la planificación a alto nivel de dicha iniciativa tendrá fases, y dos de ellas (la creación de los contenidos y la recogida de feedback) tendrán sprints. Los grandes hitos de la iniciativa son los siguientes:

• Visión del libro y planificación básica
• Creación de contenidos en Sprints (incluye revisión)
• Publicación de beta en web y recogida de feedback (con Sprints)
• Autopublicación online
• Promoción (p.e. redes sociales y referencias)

Independientemente de usar una planificación híbrida entre proyecto predictivo y Scrum, usaremos todas las prácticas y herramientas ágiles a nuestro alcance, como herramientas colaborativas, gestión visual del trabajo, etc.

 Definición de hecho

Definir «hecho» es clave para entender como ha de ser la colaboración de todos los roles implicados. 

Durante los sprints de creación de los contenidos, la Definición debería contener p.e.:

• Creación de la sección o gráfico en la herramienta colaborativa (p.e. Google Doc).
• Revisión cruzada entre los autores (peer review), incluyendo ortografía, guía de estilo y contraste con Personas.
• Revisión por un externo (p.e. colaborador o profesional)

y durante la fase de Recogida de feedback con un grupo más amplio de colaboradores (beta readers) la Definición añadiría:

• Recogida de comentarios con externos y valoración de cambios.
• Revisión cruzada de los cambios por los autores.

Algunas otros elementos de la Definición de Hecho completa (p.e. la maquetación y las verificaciones finales de aspecto), se tendrán que retrasar a la fase de autopublicación. Dividir esta Definición en tres partes, ligadas a una fase concreta, ciertamente es contrario al mandato de Scrum, donde no hay fases y esforzarnos por conseguir la Definición en cada Sprint nos da transparencia. En esta iniciativa, habrán elementos del Backlog que se daban por hechos en las fases de Creación de contenidos o de Recogida de feedback que serán reabiertos, pero es este tipo de iniciativas es muy difícil aplicar Scrum de manera completa. Viéndolo de manera optimista, ya estamos mejorando mucho respecto a la transparencia y al ciclo de feedback respecto a la manera tradicional de gestionar estos proyectos.

 Backlog del libro y estimaciones

El backlog se basa en los capítulos (épicas), y en sus secciones u otros elementos como fotos o gráficos (historias). Aquí el uso propio de las historias de usuario para facilitar la interacción con los usuarios no es aplicable, pero es una nomenclatura común que ayuda a transmitir el tipo de paquetes de trabajo que contendrá el Product Backlog y su nivel de granularidad. Aunque es extremadamente poco preciso hace estimaciones sin tener un referente de haber escrito un libro similar, se puede intentar utilizar p.e. puntos historia y posteriormente monitorizar como funcionan, p.e.:

• 1 – Gràfico sencillo | Sección pequeña y sencilla
• 2 – Gràfico medio | Sección mediana y sencilla
• 3 – Sección grande y sencilla
• 5 – Gràfico complejo | Sección mediana y compleja
• 8 – Sección grande y compleja

Los capítulos y cualquier otro elemento mayor que 8 debería desglosarse en cosas menores para acotar mínimamente las desviaciones. Esto es simplemente un ejemplo para fijar ideas, y debería desarrollarse más. 

 Los Sprints

El objetivo de los Sprints en la fase de Contenidos es desarrollar partes del libro «hechas». Esto se concreta en escribir y revisar un grupo de secciones y elementos adicionales como gráficos, figuras, etc., buscando un equilibro en que queden suficientemente maduras para que sufran pocos cambios en la fase de feedback por lectores pilotos, pero que no se haga un sobreesfuerzo buscando un redactado «perfecto» que ralentice el avance de la creación de contenidos.

Para que el Sprint produzca un «incremento hecho» y que no queden muchos elementos (ítems) del Sprint Backlog a medias, es imprescindible:

• Fijar una duración adecuada para el Sprint. Teniendo en cuenta que los autores probablemente trabajen en el libro a tiempo parcial, no se pueden proponer duraciones cortas (p.e. una semana), pero se debería intentar no ir a duraciones más largas de lo imprescindible para mantener el foco y contrastar frecuentemente lo que es posible hacer en un Sprint. 
• Una buena coordinación entre los autores (equipo de desarrollo) y las figuras externas que deben colaborar (p.e. revisores o diseñadores gráficos), comenzando por una planificación conjunta del Sprint para consensuar que es viable completar. Esto también incluye posiblemente herramientas de gestión visual del trabajo, como un tablero digital compartido (p.e. Trello).

Por otro lado, es importante determinar una estrategia para definir la hoja de ruta de la creación de contenidos. Los procesos creativos como este no suelen ser lineales, por tanto difícilmente se escriban los capítulos por el órden del índice por varios motivos:

• Existen capítulos que los autores tendrán más claros que otros antes de comenzar.
• Existen dependencias entre los contenidos de los capítulos que obligan a iterar frecuentemente entre ellos.
• La creación de ciertos contenidos de capítulos posteriores obligará a revisar y replantear los creados en momentos anteriores.

Por todo ello es conveniente definir «partes» que articularán los Sprints. Esto se parece bastante a las metas de los sprints, y de forma natural deberían determinar el «alcance» que definirá el Sprint Backlog.

 Conclusión

En este artículo hemos visto: 

• Porqué un libro es un producto de tipo complejo que se beneficia del enfoque incremental y empírico de Scrum.
• Qué roles y actividades se requieren para escribir un libro, y como puede implementarse un «equipo de producto» Scrum con roles internos y externos.
• Cómo planificar a alto nivel una iniciativa de creación de un libro en forma de una hoja de ruta, roles y responsabilidades.
• Cómo definir la visión de un libro centrada en el usuario con técnicas como el Value Proposition Canvas o las Personas.
• Como la «Definición de hecho» ayuda a la coordinación de los diferentes roles.
• Como planificar los Sprints con protagonismo para una estrategia de división del contenido en «temas» (metas para los Sprints) transversales al índice.