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,

Mobile developer / Survival Kit

This is my first post in English, I decide to switch the usual language of the blog to arrive to most people, according to the visits of the blog. So, be comprehensive ... ;-)

As a Software Engineer, every day we have more and more applications and tools to improve our life and be more productive, is part of our professional commitment to be alert about them and try to aggregate to our work method.

We will not discuss about general tools for code storage, continuous integration, continuous delivery, and other essential tools. I'll assume is part of your life.

I will focus on:

• Beta distribution
• Quality Assurance: Crash Report Management
• Analytics
• Multi-language distribution

TestFlight | www.testflightapp.com

If you are developing for Android, Windows Phone or BlackBerry maybe is not the most interesting tool for you, all of these platforms allow you to distribute your beta versions easily through any way (e-mail distribution, cloud storage services like dropbox, box, ... and so force)

But for the iOs development Team, TestFlight is a "MUST" on our survival kit. You could manage some applications, and some distribution list, you can also contact with testers ... but in general, the most important thing, at least based on my requirements:

You could distribute your beta releases periodically to partners, stakeholders, customers, testers before release your final version to the app store.

In general, on the Apple market is critical to guarantee the stability of the release, according to the distribution lifecycle (5-6 business days). You could try to use the fast release way if you make the mistake to release a buggy version ... firstly because this way has a limited number of bullets ... but the most important reason because you should guarantee your customer confidence.

Crittercism | www.crittercism.com / BugSense | www.bugsense.com

The second weapon to store in our survival kit is the crash report management, in order to control the customer crashes that our users are suffering. 

There are a lot of competitors in this market, but after a product research my decision was to integrate crittercism for iOS and Android solutions, they also support HTML5 and the Windows 8 Beta is announced (we're waiting for...)

BugSense seems also a very nice alternative, I meet with the CEO on the last Tech Mobile event at Barcelona. He was one of the Pitch elevator competitors.

The reason to integrate one of these tools is not only according to collect information of the crashes, and solve in next releases. Is also to have critical KPI related to the quality assurance of the product, and also analytics about the customers.

For example with crittercism you could evaluate (using the Trends Analytics) insights like:

• DAU - Daily active users
• MAU - Monthly active users
• # Application loads - Number of loads of your application
• # Crash - Number of crashes
• % Loads with a crash
• % Users affected by at least one crash
• ...

All the information segmented by the version of the application.

In my opinion you have enough KPI hear to define goals for you (your team) to succeed (In quality assurance terms)

Crittercism | www.crittercism.com / GA | www.google.com/intl/es/analytics/

You can get this information using crittercism or other consolidated products like flurry or AdMob, but I decided to integrate with Google Analytics, the main reason was because it is a familiar tool for me. And, although is not a mobile specific tool, is one of the best tools for analytics ... 

The mission of the analytics tools is evaluate the engage of the users, the usual navigation path ... and a lot of insight you could get from your customers using these tools. Please take a look for example to the Web Analytics 2.0 (Avinash Kaushik) book.

The best development decision here, is create a wrapper for logging the user action when the view controller is loaded for example, in order to maintain your code clean to the partners SDK's. Then, create a wrapper in your code where integrate with these partners.

For example, in iOS application, I setUp the session for crittercism and google Analytics when the AppDelegate has been started. But after that I have a logger shared instance, who is the responsible to manage the tracking of the users activity, now for crittercism and google analytics, maybe tomorrow with other tools. 

OneSkyApp | www.oneskyapp.com/

The last weapon I want to include in my survival kit is not just for mobile developers, in any case, for me is one of the most customer designed tools I had been evaluated the last years.

We're on a global age, and we should provide our products in as many languages as we can. Manage the translation of your application is usually dangerous, keys without all the translations, different words and phrases in different applications ... and so force.

And is difficult to have a global visibility of the situation. One Sky is a product focus in help you on that purpose. You could create as many application as you have in your solution, upload the files in the original format, evaluate the state of the translations (All the language's resources files have the same keys? All the translations have a similar length? ...) Contract the translation for a new language? Define a glossary for all the application ... And, at the end of the process, download the translation on the native resource format that you need.

Simply amazing!

Waiting for your contributions.

Best regards,

User Agile development. Is it posible?

Existen diferentes propuestas existentes de la integración de ambas iniciativas, aunque lamento deciros que en realidad es un ejercicio que deberéis hacer para vuestra organización personalmente, o incluso en función del cliente y los recursos disponibles.

A partir de lo expuesto hasta la fecha, hay evidentes e interesantes goals compartidos, que podemos resumir con desarrollar software de calidad. En cualquier caso, quizá analizando sus diferencias obtengamos los puntos que debemos atar con cariño.

Agile Software Development - Conclusiones Pro's y Contra's

Las metodologías de desarrollo ágil surgieron como remedio a los problemas vividos con métodos tradicionales. Focalizándose en reducir los riesgos de crear un mal producto por no trabajar bien los requerimientos con el cliente, no mostrar rápidamente resultados para obtener su feedback, estar predispuesto y preparado al cambio basado en ese feedback.

A partir de ahí, métricas de calidad como la integración continua, orientación del código al test,  etc. que bien pueden tener cabida en un modelo tradicional. 

Inherentemente las metodologías ágiles mejoran el control del proyecto, para gestores y clientes. Pero también enfatizan la visibilidad del grado de avance para el equipo, algo igualmente beneficioso.

Así mismo, promueve un elevado de comunicación mediante organización de equipos unidos, reuniones diarias, y posteriores a cada hito de interés (sprint, entrega, etc) haciendo transparente la situación del proyecto y facilitando una correcta toma de decisiones. Anticipar el feedback del cliente reduce el coste y el impacto, incluso diría yo el desgaste, que supone identificarlo a posteriori.

Agile Software Development - Prácticas y métodos

La totalidad de metodologías ágiles incluyen una relación de prácticas y técnicas que definen como deben generarse requerimientos, diseños, desarrollo, test y gestión de proyecto.

Una de las más recientes sería la de Jurgen  Appelo, 2009. Pueden existir tantas listas diferentes como organizaciones que implementen una metodología ágil. Por compartir una con vosotros, voy a extraer la propuesta de por Pirkka Rannikko en su Tesis.

Project Management

• Pequeñas entregas. Iteraciones cortas, que producen funcionalidades completas y con tareas no variables durante la ejecución del Sprint. 
• Planificación. Se trata del trabajo de creación, elección del siguiente Sprint, a partir del backlog, la lista priorizada y estimada de tareas. Elementos o conceptos requeridos:
• Product, Release y Sprint Backlog
• Sprint Burndow chart / Story Cards
• Ritmo sostenible. El trabajo debe ser realizado bajo un ritmo que sea sostenible indefinidamente. El equipo crea código mejor y de mayor calidad cuando se encuentran en situaciones "saludables", están motivados y disfrutan de su trabajo. La sobrecarga suele suponer un impacto inverso y causar problemas mayores
• Equipos auto-organizados. Durante el Sprint el equipo es responsable para lograr los objetivos del Sprint, y tienen la autoridad/responsabilidad para ejecutar ese trabajo y planificar para conseguirlo, no siendo responsabilidad del project manager dirigir al equipo, si no ayudar a cumplir los objetivos
• Retrospectiva. Reuniones realizadas después de cada Sprint, Entrega o Proyecto donde el equipo comparte sus experiencias y deciden posibles medidas de mejora 
• Meeting diario. Breve encuentro diario para que el equipo coordine su trabajo, el esfuerzo diario, revise el sprint y comparta bloqueos o problemas.

Agile Software Development - Ciclo de vida

Trabajar con una metodología ágil, aplicando modelos iterativos e incrementales requiere disciplina, mucha disciplina a seguir. El proceso está compuesto de mini-proyectos y entregas.

En otras palabras, se deben realizar múltiples entregas antes de la entrega definitiva del sofware, por lo que debemos dividir el proyecto en esa cantidad de entregas parciales con su propio alcance y planificación. 

(Consideraciones: Las entregas no tienen que ser siempre externas, ni tienen por que ser desplegadas, pero sí deberían ser desplegables)

Paralelamente a la evolución de las iteraciones incrementales, el proyecto debe seguir su propio ciclo de vida global. Para mi este es el punto más complejo de gestionar. Ya sabéis eso de que "los árboles no te dejan ver el bosque" es decir, cuando te encuentras en situaciones de micro-gestión ... existe un elevado riesgo de perder de vista el alcance temporal y en coste global del proyecto. 

Estas fases, aunque existen diferentes denominaciones, son:

• Inception. Creación - Fases iniciales de definición de requisitos, análisis y constitución del equipo
• Elaboration. Elaboración - Continuación sobre el análisis y el diseño, inicios de las iteraciones de construcción (con sus respectivos test)
• Construction. Construcción - Continuación con los mini-proyectos pero con inicios de despliegues y gestión de la configuración
• Transition. Fase final en la que se dedica más esfuerzo en las iteraciones finales, despliegues finales, y gestión de la configuración

Se puede observar mucho más claramente en el siguiente diagrama de Leffingwell y Widrig, 2003.

Agile Software Development - SCRUM

SCRUM es una metodología que enfatiza una relación de valores y prácticas relativos a la gestión de proyecto por encima de los orientados a requisitos, la implementación etc. Y puede ser utilizado conjuntamente con otras metodologías, por ejemplo con XP.

Personalmente he vivido una interesante integración con KANBAN, que explicaremos en siguientes artículos.

SCRUM fue creado por Jeff Sutherland y Ken Schwaber con una primera publicación en 1995. Siendo una metodología dirigida por 5 valores principales: compromiso, foco, franqueza, respeto y coraje. El ciclo de vida de un proyecto SCRUM se divide en iteraciones de 30 días denominadas SPRINT, con reuniones de diarias para tener seguimiento del progreso y posibles bloqueos del equipo. (Daily SCRUM)

En un proyecto SCRUM tenemos 4 roles diferenciados:

• Product owner. Representante de los promotores ante el equipo, todo requisito debe canalizarse a través de él. Se encarga de mantener el product backlog (relación de tareas pendientes) así como priorizar, decidir el contenido de cada SPRINT y revisar el producto con el resto de promotores después de cada SPRINT (Stakeholders)
• Scrum master. Se trata de un desarrollador a tiempo parcial y un leader el resto del tiempo, que trabaja para salvaguardar el progreso y el seguimiento de las prácticas SCRUM.
• Scrum team members. Responsables de entregar evoluciones de producto potencialmente entregables en cada SPRINT, así como actualizar la el backlog de tareas o el WBS. 
• El resto.

 

Imagen extraída de Wikipedia

Agile Software Development - Extreme Programming

XP fue creado por Kent Beck entre otros mientras trabajaba para corporación Chrysler, publicada por primera vez sobre el 1999. El nombre refleja la idea que el modelo quería conceptualizar, los ingenieros debían llevar las buenas y probadas prácticas de ingeniería al extremo.

XP busca estresar la satisfacción del usuario, con rápidas creaciones de software operativo, con técnicas sostenibles de desarrollo buscando la agilidad ante la necesidad de respuesta ante el cambio.

XP aboga por los siguientes valores: Comunicación, simplicidad, feedback y valentía. Pudiendo ser caracterizado por 5 principios:

1. Feedback rápido
2. Asunción de simplicidad
3. Cambios incrementales
4. Aceptación del cambio
5. Realización de un trabajo de calidad

 

Agile Software Development - Introducción

El concepto Ágil se focaliza no a la programación en si misma sino a la gestión de proyectos y el trabajo en equipo. Ágil está asociado a una relación de metodologías que comparten principios como la comunicación, el equipo, la habilidad de adaptarse a los cambios por encima de procesos, procedimientos o herramientas.

Surgieron en respuesta a las deficiencias vividas en el proceso tradicional, o en cascada.  El término agile software development fue un concepto aceptado cuando en 2001 17 de esas nuevas metodologías escribiendo juntas el Agile Manifiesto que se fundamenta en los siguientes 4 estamentos:

1. Individuos e interacciones por encima de procesos y herramientas
2. Software operativo por encima de documentación comprensiva
3. Colaboración con el cliente por encima de negociación de contratos
4. Capacidad de respuesta ante el cambio por encima del seguimiento del plan