Tritium Software - ForceManager | Lessons learned

Qué difícil me resulta escribir este artículo, que por otra parte se podría perfectamente titular "O cómo la teoría de la relatividad cae como una losa sobre nosotros"

Quizá esa sería la mayor lección que me llevo de este maravilloso proyecto al que nos hemos dedicado en cuerpo y alma los últimos 2 años largos.

Cuantas veces habré leído de la importancia de los pactos de socios, desde esa primera lectura hace ya no se cuantos años del Libro Negro del Emprendedor (Trias de Bes) En este caso no era viable escribir un pacto de socios, cuando yo me incorporé a la iniciativa me incorporé como trabajador, pero con ciertos commitments verbales, que se han quedado ahí ... en verbales.

Ahora en perspectiva, debatir quien tiene razón, que habría pasado si las cosas hubieran ido mal, que habría pasado si las cosas hubieran ido menos bien, o si hubieran ido mejor, que... son valoraciones subjetivas que no vienen al caso. Y que cómo son subjetivas guardaré privacidad.

Creo que si en su día se hubiera dejado claro todo, vesting, maturity, porcentajes, etc. ahora no habría margen para la subjetividad. Simplemente se cumpliría lo pactado, ni más ni menos. Si con el vesting y el maturity no es suficiente, hay fórmulas dinámicas, etc. que protejan tanto al emprendedor como al profesional que también asume riesgos, renuncia a situaciones más estables, mejores salarios, así como el coste de oportunidad de dedicar su esfuerzo, su pasión, a otras aventuras profesionales.

Fin de tema, a partir de ahí vamos con lo interesante.

Achievements del equipo:

• Implantación desde cero de una adopción completa de desarrollo de producto agile. Adoptando guidelines de Scrum, Kanban, Lean ... y empezando a adoptar principios de CI y TDD.
• Implantación de toda la infraestructura colaborativa completa, iniciada con el sistema cloud (Assembla para producto y TeamBox para servicios) para acabar adoptando la suite Atlassian (JIRA, GreenHooper, Confluence) más Jenkins
• Consolidación de un equipo multi-disciplinar (8 personas) en entorno multi-producto exigente (backend, web, web configuración, android, black berry, windows 8, iOS)

Achievements de empresa:

• Consolidación de equipo humano de los 3 originales que éramos a los más de 20 actuales
• Crecimiento sostenido del MRR de la compañía, no daré datos por confidencialidad, pero muchos startups actuales con mucho más impacto mediático envidiarían el MRR de ForceManager, su LifeTime Value y el User Value
• Adopción completa de metodología de implantación e industrialización del despliegue de la plataforma, liderado por Santi Trenchs
• Cierre de segunda ronda de financiación en diciembre 2012

Fails:

• No he conseguido evangelizar con metodología Lean a nivel de empresa, es decir solo el equipo de desarrollo ha adoptado estos cambios metodológicos... Stakeholders, pruebas de validación de assessments, etc. iban por libre, no orientábamos nuestra labor ni la evolución de producto a KPI o a Customer Development si no a lo que últimamente viene a denominarse Sales Driven Development, lo respeto y lo valoro (es algo fantástico tener ventas) pero si no lo gestionas adecuadamente puedes perder el foco y convertirte en una empresa de servicios. Fue durante mucho tiempo mi lucha interna, la lucha de todos, pero fracasé... Y a la compañía no le va mal, por lo que no tengo por que pensar que yo estaba en lo cierto.
• No he ayudado lo suficiente al equipo de fundadores a liberarse de la plataforma tecnológica, para ser honesto ellos no tenían especial interés en liberarse, pero en última instancia era mi responsabilidad y habría sido beneficioso para todos que así fuera
• Como no... hemos fracasado en el proceso de negociación, es evidente que ha finalizado como un lose-lose
• Y seguro que muchos más que dejo en el olvido ...

Por último, me gustaría agradecer a Xavi y a Óscar la oportunidad que en su día me dieron, las cosas podrían haber sido diferente, pero ahora lo que importa es que la cosa siga yendo viento en popa y os deseo todos los éxitos.

Así mismo, me gustaría tener una mención especial para Jordi Coscolla, alguien que me ayudo a descubrir una nueva manera de vivir mi profesión, consolidando maneras de hacer que admiraba de Stefan Klumpp en nuestra época de bliquo.

Por último, gracias a Andrea y Santi  llegasteis en el momento preciso y oportuno sois dos enormes profesionales qué realmente hacéis que el día a día sea más fácil. Gracias por vuestro apoyo y por vuestra complicidad siempre que la he necesitado.

Y para finalizar, gracias a Laia, Roger, Bruno, Josep, Ricard, Xavi y Álex... muchas gracias por creer, sois un equipo profesional y ejemplar como pocos.

Como bien sabéis os echaré de menos.

Un abrazo,

2013 Product Development Chain

Como os introducía en el anterior artículo, fruto de las retrospectivas y con la motivación de concretar más nuestro método de trabajo, hemos iterado nuestro proceso de desarrollo.

El proceso se divide en tres grandes grupos y responde a las necesidades actuales, lo natural, en caso contrario deberíamos preocuparnos, es que lo volvamos a iterar en pocos meses:

• User Research & Design
• I+D
• Quality Assurance

El objetivo no es necesitar tres sprints para poder aportar valor al usuario, si no que el equipo de trabajo, disponga de horas durante el sprint para trabajar en la definición y estimación de las tareas que van a ser acometidas durante los siguientes sprints. Pero que el flujo de generación de valor sea contínuo durante los sprints (15 días)

El método individual debe ser igualmente madurado, introduciendo conceptos de TDD. Necesitamos mejorar la calidad de nuestros desarrollos, y el test coverage de nuestras producciones. 

Así mismo, un trabajo más real en las tareas de estimación y proveer a la compañía de un calendario de producto. Algo nada fácil dado el generoso alcance de ForceManager. Pero que es fundamental para una correcta toma de decisión.

Una necesidad clara que teníamos durante este pasado 2012, además de la disponibilidad pública de un calendario, era basar nuestro trabajo en métricas que dirijan a nuestro jinete (Switch).

Hemos definido KPI en tres grandes grupos:

• Método de trabajo. Insights que midan el seguimiento del método de trabajo definido
• Quality Assurance. Insights que midan el nivel de estabilidad de nuestros productos
• Customer Commitment. Insights que midan impactos positivos/negativos con nuestro cliente (consecución de calendario previsto, tiempo promedio de liberación de una nueva funcionalidad, tiempo medio de liberación de una incidencia)

Para compartir estas métricas con todo el equipo y toda la compañía, hemos seguido las buenas guías de Visual Management, y hemos creado diferentes cuadros.

Por una parte gestionamos el LogOfWork del equipo diariamente para todo el sprint, con el objetivo de incentivar en el uso de JIRA, todos sabemos lo importante que es conocer la velocidad como equipo. Así como la realización de los StandUp matinales.

A continuación un cuadro resumen de:

• Bugs graves reportados por clientes durante el sprint. El objetivo es durante el sprint meeting repasar los bugs y mediante técnicas como 5whys identificar oportunidades de mejora
• Customer Earned Value. Valor generado al cliente durante el sprint
• Feature Speed. Tiempo requerido para liberar funcionalidades e indicencias

Por último, hemos iterado el Cardwall del equipo, para ilustrar las nuevas fases de nuestro LC. Dando visibilidad a todo el equipo tanto del trabajo del presente sprint, como de lo que está por venir en los siguientes sprints.

Una última novedad en el modelo de trabajo ha sido la de incluir un SCRUM MASTER rotativo, de manera que todo el equipo en mayor o menos medida tiene que involucrarse en el método, y en algún momento del año, en realidad en varios momentos, va a ser responsable de liderar al grupo.

Tengo que decir que ya, en tan solo un sprint de 2013 hemos empezado a notar un cambio de dinámica positiva. Una imagen vale más que mil palabras (Velocity Report JIRA) ... apoteósico el cambio en el LogOfWork del equipo.

Un abrazo,

LSUX - Lean Startup User Experience

Este pasado sábado 14 de Julio pude disfrutar de un workshop de Lean User Experience organizado por La Salle.

La verdad es que ha sido un breve taller de 4 horas, pero tengo el feeling que va a suponer un gran cambio, y una apertura de nuevas iniciativas interesantes.

El workshop fue presentado por Albert Cubeles, Alexis Roqué y Marc Pifarré. Creo que vale la pena situar a las personas de referencia del Workshop por si fuera de interés poneros en contacto con alguno de ellos:

• Marc Pifarré - 
Investigador en User experience, responsable científico del Userlab de La Salle y Director del postgrado en experiencia de usuario (PUX). Licenciado en psicología es profesor de la facultad de ingeniería La Salle y lleva a cabo proyectos de usabilidad y experiencia de usuario para empresas de innovación de índole diversa, desde emprendedores que lanzan nuevos productos a multinacionales consolidadas.
• Alexis Roqué - 
Emprendedor y co-fundador de <Undefined>, agencia interactiva especializada en el diseño y desarrollo de aplicaciones web multidispositivo. En combina tareas directivas con gestión de producto y diseño de ux, desde la fase inicial hasta su lanzamiento. Tiene una gran experiencia a la hora de analizar las necesidades del producto y alinearlas con el diseño, el negocio y la tecnología con el objetivo de crear productos que ofrezcan experiencias memorables.
• Albert Cubeles
 - Director de los másters de Marketing y Digital Business y del International MBA de La Salle Campus Barcelona.

El objetivo del workshop era un vistazo general de los siguientes puntos. Quizá un alcance excesivo para el poco tiempo, pero fue una prueba piloto, desde mi punto de vista excelente.

El evento siguió el siguiente programa: