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,

2012 Retrospective

Una vez llegado el final del 2012, a nivel de equipo creo que es un momento excelente para reflexionar e identificar oportunidades de mejora de cara al 2013. No tienen por que ser ejercicios anuales, pero creo que como mínimo un ejercicio anual se hace imprescindible.

Para dinamizar el ejercicio del año utilizamos la técnica Starfish, podéis encontrar una lista muy interesante de posibles retrospectivas en este link.

Como se puede observar, tenemos tanto por adoptar y hacer, que no hay casi nada en Less Off y Stop Doing. A ver que sucede en las futuras retrospectivas.

En nuestro caso las revisiones de proceso se hacen imprescindible, dado el proceso de continuo cambio en el que vivimos, no tan solo por que somos un startup y debemos convivir con el chaos si no también, por el volumen de crecimiento en el que estamos sumergidos.

Las líneas maestras de nuestro proceso de trabajo se resumen en la siguiente presentación que tengo pública en prezi.

Pero de cara al 2013 tocaba concretar medidas, y aprovechar sin lugar a dudas el feedback aportado por todos.

Los puntos de mejora identificados, además de ilustrar las carencias actuales que tenemos en el método de trabajo individual (sobretodo en lo referente al testing unitario/integración) también ilustraba las carencias como equipo ...

• Falta de visibilidad sobre el calendario
• Falta de implicación en la planificación
• Falta de implicación en toma de requisitos

Algunos de estos puntos pueden parecer obvios, pero no lo son. Hay medidas o guidelines de agility que están totalmente enfocadas a mejorar estos puntos, pero a veces no sabes encontrar el momento para empezar a implantarlos.

Pues el momento es ahora.

En el siguiente post introduciré brevemente el método de trabajo, que se basa en encadenar sprints para integrar los outputs del equipo de user experience con el de desarrollo y posteriormente con el de quality, siguiendo esquemas similares a los expuestos en el User Agile Development LC.

Un abrazo,

Nuevos horizontes - Tritium Software

Bueno, llevaba semanas queriendo escribir este artículo, pero no había encontrado el momento.

Como alguno de vosotros ya sabéis hace ya unas semanas que acepté un nuevo reto profesional, después de una larga y, por que no decirlo, dura pausa. Durante este tiempo he aprovechado para estudiar mucho, cumplir una de mis cuentas pendientes - User Agile Development), y cuidarme menos de lo que me habría buscado.

La incertidumbre te atenaza, más de lo que jamás habría pensado.

He participado en multitud de, agotadores, procesos de selección, y la decisión no fue nada fácil. Me siento muy afortunado, en primer lugar por poder haber podido decidir, y además por haber encontrado un lugar en el que, pese que voy a currar de lo lindo (es lo que quiero, lo que me gusta, y lo que me llena) voy a seguir trabajando en un start-up, dentro del ámbito de producto, y teniendo la oportunidad de crear y liderar el equipo de trabajo.

Tritium Software, S.L. es una compañía catalana, que acaba de cerrar su primera ronda de financiación, y que dispone de un producto CRM (para los no iniciados - una herramienta de gestión de clientes (Customer Relationship Management) ofreciendo una clara orientación a movilidad, ofreciendo clientes para iPhone, Android, BlackBerry y próximamente para iPad y Playbook.)

Como buena startup todos tenemos que empujar en todas direcciones, pero mi responsabilidad es la de dirigir el equipo de producción, consolidar el uso de buenas prácticas (basándome dentro de lo posible en metodologías ágiles, perfectas en este contexto)

Para ello, después de evaluar diferentes herramientas  TeamBox, GoPlan, Assembla ... y como no JIRA, la decisión ha sido continuar con el mismo sistema que utilizamos en Grouxo, y no es otro que Assembla.

Los motivos son los siguientes:

• Ofrece un repositorio SVN integrado con la herramienta colaborativa. Git es una propuesta de lo más interesante, y mucho más potente que SVN, pero exige cierta disciplina y experiencia en el uso de repositorios (Algo que no tiene por que estar asegurado en nuestro contexto)
• Dispones de herramienta wiki integrada en el portal
• Dispones de issue traking totalmente adaptado para metodologías ágiles, con un Cardwall que hace las delicias como un perfecto Task Board, unas gráficas BurnChart suficientes, y una sección StandUp para los informes matinales de actividad de todo el equipo
• Además los planes básicos, aunque se me antojan algo limitados ya que solo permiten 1 espacio y 1 Gb de espacio, tienen un precio de lo más razonable 9$ /mes (90$ / año)

A medio/largo plazo mi opción predilecta es JIRA, que en su versión cloud integra confluence, greenhopper, subversion, fisheye, bamboo ... es decir lo ideal para tener un entorno de integración continua completo. No se si es buena opción en cloud o gestionado por nosotros mismos si disponemos de los recursos necesarios, eso nos permitiría por ejemplo incluir Sonar, etc.

En fin, una aventura muy interesante. 

Estamos en un momento de consolidación/constitución del equipo, no dudes en hacernos llegar tu CV si te gusta la iniciativa y consideras que puedes aportar tu granito de arena.

Un abrazo,