jueves, diciembre 13, 2012

La Ciencia de la Productividad


Les dejo un muy buen video sobre la ciencia de la productividad. En tres minutos podremos entender como los seres humanos funcionamos y aplicar estos tips científicos en el trabajo para aprovechar todo nuestro potencial.

 

Si les gusto, les recomiendo que sigan a AsapSCIENCE en Youtube, sacan un video por semana. Son muy interesantes y entretenidos.

domingo, noviembre 25, 2012

Ingeniero en Informática


Finalmente, luego de muchos años, logre recibirme en la Facultad de Ingeniería de la Universidad de Buenos Aires como Ingeniero en Informática, luego de presentar mi trabajo profesional.
Ahora, mis estudios académicos continuaran en la Universidad Tecnológica Nacional, donde cursare el Posgrado en Gestión de proyectos durante el primer semestre del 2013, para luego certificarme como Project Manager Professional (PMP).

¡Los mantengo al tanto!

domingo, noviembre 18, 2012

Ágiles @ Argentina

El lunes pasado (12/11/2012) concurrí por primera vez a una de las reuniones organizadas por el grupo Ágiles Argentina. Las reuniones se hacen una vez por mes y tratan temas diversos, todos relacionados con las disciplinas ágiles de desarrollo de software. En esta ocasión, dos Australianas contaron sus experiencias con las metodologías Ágiles y Lean a toda la audiencia presente. Realmente fue muy interesante y me dieron ganas de seguir yendo de ahora en más. El título de la charla fue: "Implementing and Adapting Agile and Lean: Real World Examples" y les dejo la descripción de la misma:
The concepts of Agile and Lean have been around for years. However, there is a big difference between knowing about Agile and Lean from reading books and living it (using it) every day. This talk will cover some of the basics of Agile and Lean and then discuss how they are put into practise - why, when, and how to use them. We will review many real world examples showing how companies and teams are implementing (and adapting) Agile and Lean concepts to manage their product development and customer projects. Agile and Lean were developed to help us manage change and as a result, the processes themselves morph and grow as teams face today's continuously changing business and economic conditions. We will look at some amazing real-world examples of how teams are changing the processes themselves to help them make sense of the chaos.
Para ir, les recomiendo anotarse en el meetup del grupo (para recibir alertas de futuras reuniones y confirmar su presencia) También pueden ingresar en la lista de emails y en el grupo en LinkedIn.

miércoles, noviembre 07, 2012

La Primera Directiva de las Retrospectivas

Al iniciar una Retrospectiva luego de la finalización de un Sprint, vale la pena recordar a todo el equipo la siguiente frase:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

Esta es la primera directiva de las retrospectivas de Norman Kerth. El objetivo de esta directiva es crear un ambiente seguro donde todo el equipo pueda examinar el proceso, las herramientas utilizadas y el trabajo hecho durante el Sprint sin buscar culpables. Uno de los miedos más comunes que la gente tienen cuando comienzan a participar en retrospectivas es que el ritual va a ser una sesión negativa, con el equipo buscando culpables y atacándose entre ellos.

Claramente un evento de estas características no contribuye mucho al aprendizaje, por eso, la clave para que esta ceremonia sea exitosa es asegurarse que todos los participantes adhieran a esta directiva. Si alguien no adhiere, no se debería hacer. Una forma interesante que aprendí es preguntar uno por uno y esperar una respuesta verbal. Crease o no, cuando alguien abre la boca para decir algo en una reunión, ya lo predispone a seguir hablando y participar mas activamente en ella.

Al finalizar un Sprint uno aprende. Naturalmente descubrimos cosas que desearíamos poder haber hecho de otra manera. Toda esta sabiduría adquirida es una ocasión para celebrar, no para hacer un juicio de valores sobre alguien.

Igual esto no es un hechizo, no es magia. Uno tiene que hablar con cada miembro del equipo sobre esto en las reuniones 1:1 y lograr la confianza de cada uno de ellos.

martes, octubre 30, 2012

Diferenciando la Prioridad y la Severidad de un Defecto

Aunque sean dos atributos distintos, mucha gente se confunde entre la severidad y la prioridad de un defecto. Uno puede llegar a preguntarse, ¿Qué es más importante, un defecto con prioridad alta o severidad alta? Antes de responder la pregunta, veamos que nos dice la teoría sobre cada uno de estos atributos.

La prioridad viene del negocio. En este caso uno se pregunta cuán importante es para el negocio que se arregle este defecto. La severidad es técnica. La mayoría de las veces un defecto de alta severidad se convierte en un defecto de alta prioridad, pero no siempre. Hay casos que defectos de alta severidad tienen una prioridad baja y viceversa: defectos de baja severidad son de alta prioridad.

La severidad, además de ser un atributo técnico, está enfocada en la experiencia del usuario con la aplicación. Asignar la severidad de un defecto es simple, los testers lo pueden hacer teniendo conocimiento del proyecto. Sin embargo, asignar la prioridad es más difícil. La severidad es uno de los factores que se toma en consideración cuando se asigna la prioridad de un defecto. Otros de los factores son: cuanto tiempo queda para salir a producción, cuánto tiempo lleva resolver el defecto, quien está disponible para arreglarlo, cuán importante es para el negocio arreglarlo, cual es el impacto, cual la probabilidad de ocurrencia y cuál es el grado de efectos colaterales que puede causar el defecto.

En muchas organizaciones, defectos de cierta severidad deben ser al menos de cierta prioridad. Por ejemplo, los defectos que llevan a cerrar el sistema o a le hacen perder datos al usuario tienen que ser prioridad uno si se puede reproducir siempre. S pasa el 1% de las veces, seria ultima prioridad, manteniendo la severidad alta. Una falta de ortografía en la página principal de un sitio web es un defecto de severidad baja, es muy fácil de arreglar, pero para el negocio su prioridad es alta ya que afecta la imagen de la compañía. 
Otra forma de verlo es la siguiente: la prioridad es relativa y la severidad es absoluta. La prioridad puede cambiar con el tiempo, dependiendo el calendario y que otros defectos hay en la lista. La prioridad puede pensarse como el orden con el que los defectos tienen que ser resueltos en un cierto momento. En cambio, la severidad es un análisis de técnico del bug, sin importar el calendario.

Microsoft usa una escala de cuatro puntos para describir la severidad de los defectos y una escala de tres puntos para describir su prioridad:

Severity
  1. Bug causes system crash or data loss.
  2. Bug causes major functionality or other severe problems; product crashes in obscure cases.
  3. Bug causes minor functionality problems, may affect "fit and finish".
  4. Bug contains typos, unclear wording or error messages in low visibility fields.
 
Priority

  1. Must fix as soon as possible.  Bug is blocking further progress in this area.
  2. Should fix soon, before product release.
  3. Fix if time; somewhat trivial. May be postponed.

Para cerrar el artículo, puede valer la pena no utilizar el campo severidad. Son pocas las situaciones donde sirve tenerlo, contrastando con el tiempo y esfuerzo que se necesita para definir el valor y utilizarlo. Si a uno le piden utilizar el valor de severidad, pregunte la razón.

Fuentes:
  • http://www.softwaretestingclass.com/what-is-difference-between-priority-and-severity/
  • http://quality-intelligence.blogspot.com.ar/2010/08/bug-severity-vs-priority.html
  • http://c2.com/cgi/wiki?DifferentiatePriorityAndSeverity
  • http://geekswithblogs.net/srkprasad/archive/2004/08/20/9961.aspxhttp://www.stickyminds.com/sitewide.asp?ObjectId=6323&Function=DETAILBROWSE&ObjectType=COL

domingo, octubre 21, 2012

Getting To Yes

"Getting To Yes: Negotiating Agreement Without Giving In" de Roger Fisher y William Ury es un clásico libro de negociación donde los autores nos explican su método para maximizar los resultados en todas las negociaciones que encaremos en nuestra vida. 

Generalmente en las negociaciones cada lado toma una posición, pelea por ella y da concesiones hasta llegar a una solución de compromiso que conforma pero no deja contentos a ambas partes. Con este método nunca se llega al mejor resultado posible y se corroe la relación con la persona con quien negociamos.

Un punto a resaltar del libro es que está repleto de ejemplos, desde negociaciones políticas históricas a negociaciones del día a día en una pareja, que enriquecen la teoría.

Un ejemplo simple del libro son dos hermanas peleando por una naranja. Ambas la quieren y terminan negociando cortar la mitad para cada una. Luego volveremos a este ejemplo.

El método que plantean los autores es simple:
  1. Separar la gente del problema, la idea es no dañar la relación con la persona que tenemos enfrente.
  2. Enfocarse en los intereses, no es posiciones. Pensar en el problema en cuestión, preguntar, encontrarle la vuelta.
  3. Inventar opciones para que ambas partes se vean beneficiadas. La idea es que la negociación no sea combativa, ambas partes tienen que exponer todos los datos que tienen del problema para que la negociación se vuelva un trabajo en conjunto entre ambas partes, con el objetivo de lograr el mejor resultado.
  4. Insistir en usar criterios objetivos. Buscar precedente, estándares, expertos, todo ayuda para lograr un resultado más justo.
El concepto es simple y lógico, hay que ver a la persona con la que negociamos como un aliado y trabajar en conjunto para lograr el mejor resultado para ambas partes. Continuando con el ejemplo, una hermana quería solo la cascara de la naranja para hacer una torta, la otra quería comerse el contenido. En la negociación original tomaron la posición de que querían la naranja, sin exponer sus necesidades, y una tiro la cascara de su mitad y la otra el interior de la naranja de la suya.

Les recomiendo el libro, es entretenido, corto y está lleno de ejemplos.

sábado, septiembre 29, 2012

Atributos de un buen ScrumMaster

Hace poco me encontré con un excelente artículo de Mike Cohn, quien describía los seis atributos que un buen ScrumMaster debe tener y demostrar ante un equipo. Les dejo un extracto para que lo disfruten:

Responsable
Un ScrumMaster no asume la responsabilidad del éxito del proyecto, eso es responsabilidad del equipo. Sin embargo un ScrumMaster asume la responsabilidad de que el equipo adopte el framework y las prácticas de Scrum. El rol de un ScrumMaster es similar al de un conductor de orquesta; ambos deben guiar y liderar a un grupo de individuos talentosos que se unen para crear algo que ninguno de ellos puede crear solo.

Humilde
Un buen ScrumMaster va a enorgullecerse con lo que el equipo pudo lograr, con la ayuda que él le brindo al equipo, no en lo que logro individualmente. Las necesidades del equipo siempre están primeras, y tiene que hacer todo lo necesario para que el equipo alcance su objetivo. Los ScrumMasters humildes reconocen el valor en cada uno de los miembros del equipo y lideran dando este ejemplo.

Colaborativo
Un buen ScrumMaster trabaja para asegurarse que una cultura colaborativa exista dentro del equipo, que cualquier miembro se sienta libre para levantar la mano y que se sientan apoyados al hacerlo. El ScrumMaster debe dar el ejemplo e instaurar la colaboración como la norma en el equipo.

Comprometido
Aunque el rol de ScrumMaster no requiere siempre a alguien comprometido 8 horas por día, se necesita a alguien que se comprometa con el rol. Esta persona se debe sentir tan comprometido con el proyecto y el objetivo del Sprint como el equipo. Los días de un ScrumMaster no deben terminar con impedimentos levantados por el equipo sin tratar, aunque haya temas que tarden días en resolverse.

Influenciador
Para ser exitoso, un ScrumMaster necesita influenciar personas dentro y fuera del equipo. Por ejemplo, algunos miembros del equipo tienen que ser influenciados para que se comprometan más con el proceso o sean más colaborativos. También un ScrumMaster tiene que influenciar al equipo para utilizar nuevas prácticas como TDD. Un ScrumMaster debe saber cómo influenciar al equipo con conocimiento, sin utilizar poder ni dar órdenes.
A veces hay que influenciar gente fuera del proyecto, como por ejemplo convencer a un director de QC que dedique testers full time al proyecto.
Finalmente, un ScrumMaster debe saber cómo utilizar su influencia política dentro de la empresa, para el bien del equipo.

Sabio
Los mejores ScrumMasters tienen el conocimiento técnico, de negocio o para ayudar al equipo a conseguir su objetivo. Un conocimiento detallado de como algo funciona aumenta las chances de que un líder ayudando al equipo encuentre problemas o detecte riesgos que tienen que tratarse.

lunes, septiembre 10, 2012

My Job Went to India

My Job Went to India and All I Got Was This Lousy Book (52 ways to save your Job), escrito por Chad Fawler, nos cuenta como sobrevivir en el nuevo marco mundial del offshoring. El libro esta principalmente dirigido a desarrolladores de Estados Unidos cuyos puestos de trabajo se ven amenazados por desarrolladores de India, con sugerencias para mantenerse empleable frente a esta nueva realidad.

Chad Fawler estuvo viviendo un tiempo en India, armando un centro de desarrollo y nos cuenta su experiencia de trabajo en ese país. Es muy interesante conocer ciertos aspectos de la cultura India. Por ejemplo, en India no está bien visto decir no a algo. Esto puede ser ante un pedido para hacer algo para cierta fecha, y cuando esta se acerca y no lo terminaron, aunque sabían que era imposible, pero no lo dicen por costumbre, siempre piden unos días más para cerrar la tarea. Otro ejemplo es cuando uno explica algo, hay que asegurarse de que lo entendieron, y no conformarse con un sí de ellos. El autor (ni yo) intenta menospreciar a los desarrolladores de India, solo comentar su forma de trabajar. , yo también viví estas situaciones con miembros de equipos en India.

Chad piensa que la carrera de una persona es como el ciclo de vida de un producto, y provee tips y ejemplos prácticos para tomar. Sus consejos son muy buenos, por ejemplo, es común que los desarrolladores no quieran participar de proyectos de mantenimiento de un sistema, pero el autor destaca que luego de la primer línea de código, todo proyecto se transforma en un proyecto de mantenimiento, donde se tiene que agregar funcionalidades o resolver problemas sobre código existente, y recomienda no menospreciar estos proyectos. También recalca que la presencia de uno en la empresa es importante, y que como un producto, uno tiene que hacer marketing de sus habilidades y fortalezas.

Aunque la portada del libro no es de lo mejor y el título puede tener un tono agresivo, los tips del autor son muy interesantes y la redacción es muy entretenida. Por suerte la segunda edición del libro cambio a un título más apropiado: The Passionate Programmer: Creating a Remarkable Career in Software Development

martes, agosto 28, 2012

¿Qué hace un ScrumMaster durante el día?

Para ver que hace un ScrumMaster durante un día de trabajo, citemos una definición de ScrumMaster:

Scrum is facilitated by a ScrumMaster, whose primary job is to remove impediments to the ability of the team to deliver the sprint goal. The ScrumMaster is not the leader of the team (as they are self-organizing) but acts as a buffer between the team and any distracting influences. The ScrumMaster ensures that the Scrum process is used as intended. The ScrumMaster is the enforcer of rules.

Muy concisa… pero ¿Qué hace realmente un ScrumMaster durante el día? Déjenme enumerar específicamente las (principales) tareas que realiza durante la jornada laboral:

  1. Asegurar que los valores y las prácticas de Scrum se respeten y se cumplan.
  2. Quitar impedimentos al equipo. Conseguir o perseguir a quien sea para que cualquier problema sea resuelto cuanto antes y el equipo pueda trabajar sin nada que los frene. Lograr que el equipo sea híper productivo. Lograr el éxito en el proyecto.
  3. Asegurarse de que las reuniones diarias ocurran, que haya una sala reservada (física o virtual para tele o video conferencias), y que todos los miembros del equipo vayan, como un pastor que guía a sus ovejas (Estimo que mi analogía pueda herir la susceptibilidad de cierta gente, pero es cierta).
  4. Prestar atención en las reuniones diarias. Seguir los temas abiertos en ellas. Asegurarse que las conversaciones sigan fuera de esta reunión.
  5. Moderar las reuniones diarias para que no sean innecesariamente largas.
  6. Asegurarse que el product backlog este priorizado (Push al product owner)  y estimado (asegurando que los poker plannings se hagan).
  7. Asegurarse que el sprint backlog este actualizado, que el remaining time de las tareas se cargue diariamente y estos cambios se puedan observar en el burndown
  8. Asegurarse que el Sprint planning se haga, que las user stories sean separadas en tareas estimadas por las personas que las vayan a hacer, y que queden asignadas a ellos.
  9. Proteger al equipo cuando se pide mucho de ellos, que no se comprometan a más de lo que puedan hacer, y también que no se vuelvan complacientes. Esto es más difícil, ya que si el equipo no quiere dar lo mejor y apunta a menos, hay problemas graves de motivación que tienen que solucionarse.
  10. Asegurarse que los analistas funcionales trabajen en el acceptance criteria de las historias del product backlog de mayor prioridad junto al product owner (Grooming)
  11. Asegurarse que se hagan las Demos, que el equipo se prepare para ellas y que alguien (no siempre la misma persona) muestre las nuevas funcionalidades de la aplicación.
  12. Preparar la presentación con las métricas del sprint para presentar en el sprint review, antes o después de la demo.
  13. Asegurarse de que se hagan las retrospectives, y que los tres puntos más importantes levantados por el equipo se resuelvan o se intenten resolver durante el siguiente sprint. Detectar otras oportunidades de mejora.
  14. Asegurarse de que se hagan las release planning meetings, para organizar el product backlog en releases. Con la métrica de la velocidad se debe saber cuándo se va a terminar todo el product backlog que uno tiene estimado. Trabajar junto a los stakeholders del cliente para seguir de cerca el plan a largo plazo del proyecto.
  15. Asegurarse que el equipo complete el done criteria. No dejar que se cierren tareas (Se sumen story points) hasta que algo no este desarrollado, testeado, aprobado por el cliente, o lo que diga el done criteria que se haya especificado.
  16. Facilitar la comunicación del equipo con el product owner.
  17. En algunos casos, liderar sin autoridad formal, sin títulos. El ScrumMaster es un servidor y líder a la vez.
  18. Tener reuniones 1:1 con todos los miembros del equipo. Hacer seguimiento de cada miembro del equipo. Escuchar a la gente. Asegurarse de que el equipo este bien.
  19. Asegurarse que todos sepan usar la herramienta de administración del proyecto que se use, entrenar al equipo.
  20. Proteger al equipo de influencias externas. Ser el punto de contacto principal para cualquier persona externa  al equipo. Encargarse de las tareas burocráticas.
  21. Comunicarse e informar el estado del proyecto y del equipo a sus superiores dentro de la empresa.
  22. Organizar eventos cuando se llega a hitos importantes.
  23. Comprar comida al equipo cuando se trabaja hasta tarde. Asegurarse de que tengan café.

Seguro que hay más que no tuve en cuenta, pero espero que este artículo les dé un pantallazo general de las tareas de un ScrumMaster.

sábado, agosto 04, 2012

Planificando en Scrum

Uno de los temas que muchos comentan pero del que realmente pocos se ocupan es de planificar en Scrum. En vez de hablar de ese tema hay que ponerse a trabajar y armar un plan, lo suficientemente bueno como para poder llegar a satisfacer al cliente. Sin embargo el objetivo de Scrum no es tener un plan, es entregar features completos de un producto. Un plan nos ayuda a manejarnos en el corto y largo plazo.

En Scrum hay muchas oportunidades para planificar, ejecutar y entregar software. La razón para usar Scrum es simple: la necesidad de entregar algo de valor para el cliente, reduciendo riesgo, entregando periódicamente, inspeccionando y adaptándonos a las necesidades.

Se puede hacer planificación a largo plazo en el Product backlog mediante Release planning. Se puede hacer planificación a corto plazo a nivel de Sprint backlog mediante Sprint planning. Finalmente se puede hacer planificación diaria y ajustes mínimos en el Daily Scrum. Y el progreso de todo esto se puede seguir en diferentes Burndown charts.

¿Que quiere el cliente realmente? Quiere que le entreguemos software que funcione, que haya cumplido con el criterio establecido para determinar que lo que entregamos este realmente completo. Pero también es necesario planificar en Scrum. 

¿Le importa al cliente el plan? No si uno falla con los compromisos de fechas que se asumen. En ese momento el plan se convierte en un problema que atenta contra la confianza entre el equipo, el cliente y todos los interesados. Project Managers tradicionales luego utilizan el plan para atacar a miembros del equipo por no cumplir con las fechas.

Hay que detener ese ciclo, hay que planificar lo suficiente. Esta es una de las conversaciones difíciles que hay que tener con el cliente y tus superiores. No es fácil.

¿Quien es responsable de entregar software que funcione en un equipo Scrum? El equipo. Como ScrumMaster uno es responsable de facilitar el framework de Scrum, asegurar que el equipo comprenda los roles, que se hagan las ceremonias establecidas, trabajar con el product owner y el resto de los interesados, entre otras cosas. Pero en la realidad, en las empresas, un ScrumMaster es el Project Manager y es el máximo responsable.


¿Cómo podemos asegurarnos el éxito? Entregando software y cumpliendo con    los compromisos. Las conversaciones con el cliente y todos los interesados se convierten en algo increíble cuando esto pasa, créanme.

Al principio va a ser difícil. Scrum no es una bala de plata, entregando software se construye y fortalece la confianza entre las partes. Hay una estadística que nos dice que hay que un equipo tiene que trabajar junto varios Sprints para que sus estimaciones sean productivos. El primer plan del Sprint no se va a cumplir. El primer Release plan que se prepare va a estar muy lejos de la realidad. Hay que aclarar esto al principio, manejar las expectativas correctamente. También hay que revisar nuestras estimaciones iniciales al hacer el segundo Release plan, y el tercero, hasta lograr un plan a largo plazo que nos sirva a todos.

Se puede. Inténtenlo.

sábado, julio 28, 2012

No abandonemos las Sprint Retrospectives

Cuando hay problemas, la ceremonia del Sprint Retrospectives es la primera que el equipo abandona. A muchos nos pasó de no darle tanta importancia a esta reunión, hasta que vivimos y experimentamos su utilidad en uno o más proyectos. Ver al equipo crecer y mejorar Sprint a Sprint es algo increíble y reconfortante. Irónicamente, esta ceremonia es más valiosa cuando estamos bajo presión o las cosas no salen como uno esperaba, ya que nos permite visualizar esos problemas y tomar acción para resolverlos. Hay que mantener la disciplina y el la Retrospective tiene que hacerse siempre al final de los Sprints sin importar el ruido al rededor del equipo y del proyecto.

Los valores de Scrum tienen que ser aplicados con rigor en las Retrospectives. Sin transparencia o honestidad nunca vamos a llegar al fondo de los problemas. Sin coraje, el equipo no va a querer afrontar los problemas. Sin respeto los problemas no van a ser presentados constructivamente y sin dedicación y compromiso a nadie le va a importar resolver los problemas para salir de la situación en la que estamos.

Para tener una buena Retrospective, es bueno que el equipo venga preparado con una lista de temas a charlar sobre el proceso, la comunicación, las herramientas, el scope, la calidad, los ambientes, sus capacidades y cualquier otro tema relacionado. Una forma de lograr esto es utilizar una herramienta colaborativa (Google Spreadsheet por ejemplo) para que el equipo vaya dejando sus notas durante el sprint ahí. Como ScrumMaster hay que reforzar y recordar al equipo durante el Sprint que vayan aportando sus pensamientos en esa herramienta para que la reunión sea exitosa.

Durante la Retrospective, es bueno enfocarse en dos preguntas: ¿Qué puede mejorar? y ¿Qué salió bien? Proyectando los comentarios en la herramienta colaborativa, podemos separar en dos los resultados basándose en esas preguntas, mientras vamos leyendo los comentarios y discutiendo entre todos sobre ellos.

Finalmente, sobre los puntos a mejorar, no hay que comprometerse a tratar todos los problemas para la próxima Retrospective. Todos los problemas de las sesiones (y las cosas que salieron bien) tienen que documentarse, y solo hay que elegir no más de tres problemas a tratar. Cuando uno promete de más y luego no cumple, pierde credibilidad. Acciones tienen que acordarse basándose en esto tres problemas y miembros del equipo tienen que ser asignadas como sus respectivos dueños. El ScrumMaster tiene que tenerlas en cuenta para que se traten durante el siguiente Sprint.

Para cerrar, pase lo que pase, mantengamos la disciplina y estas ceremonias para asegurar que el equipo mejore y los problemas se traten ordenadamente como el framework de Scrum nos pide.

miércoles, junio 13, 2012

Diarios de Praga II: Implementación de Scrum sin éxito

Luego de un comienzo alentador, de haber convencido a mis superiores  que Scrum podía ayudar y solucionar ciertos problemas que experimentaban los proyectos de la empresa, me choque con la dura realidad y mi intento de aplicar Scrum, o un hibrido adaptado a sus necesidades, falló. Les recomiendo que lean mi artículo anterior para conocer en profundidad mis hallazgos iniciales.

Pronto entrare en detalles, pero en resumen mi intento fue muy apresurado, no llegue a conocer bien a la empresa, a su gente, su cultura, su forma de trabajar y los problemas actuales que tienen con los clientes. Solo había estado con ellos un mes. Tuve apoyo interno inicialmente y un cliente aprobó la implementación, pero por diversos problemas periféricos que estábamos experimentando en el proyecto en ese momento, no se tuvo la paciencia necesaria para aplicar el proceso y volvimos todo atrás. 
La situación no era buena,  se habían retrasado muchas entregas y últimamente no podíamos cumplir los compromisos asumidos. Otra causa relacionada es que el cliente no era una empresa de desarrollo, sino una empresa de retail que tenia su sitio de e-commerce, y su área de sistemas no estaba al tanto de Agile ni de Scrum.

Otro tema fue el interno, no logre apoyo suficiente para lograr el cambio. Aunque tuve apoyo inicial, cuando surgió el primer inconveniente con el cliente perdí la confianza y el apoyo de la empresa. El problema principal fue que no logre un completo consenso interno antes de lanzar este proceso con el cliente. Lo ideal hubiese sido aplicar cambios graduales y luego cuando todos estén listos, hacer el cambio  definitivo.

También el cliente creía que el proceso era una bala de plata que iba a resolver todos sus problemas. Empezaron a hacer pedidos irreales, como por ejemplo que el proceso soportase incrementar y disminuir el output de desarrollo de una semana a la otra sin retrasar las funcionalidades planeadas, que eliminase la posibilidad de que existan defectos y también que provea fechas para todas las fases del desarrollo de cada funcionalidad (Fechas para la finalización todos los estados: especificación, desarrollo, testing y UAT).

Volvimos a manejar todo con planes en un Gantt. El cliente prefiere tener un plan con fechas para todo, aunque no sean reales y luego se retrasen. Es un círculo vicioso, porque siempre se llega a situaciones límite con el cliente por retrasos entendibles y relacionados a la naturaleza del desarrollo de software. El cliente tiene la suficiente fuerza como para que en la empresa  se pongan fechas irreales y luego siempre se retrase todo, se llegue a un conflicto, y se re-planifique. Es una forma de trabajar muy poco sana Hay presión, negatividad y muchas veces se hace overtime sin necesidad.

En la empresa siguen apoyando la idea de tomar ideas agiles, pero saben que no es el momento. Mi experiencia sirvió para hacerles dar cuenta que tienen que ir paso a paso. El problema principal es la gente, ya que la empresa cuenta con un pequeño equipo técnico que maneja varios proyectos a la vez y la todos van saltando de un proyecto a otro apagando incendios y resolviendo defectos. La idea de tener un equipo dedicado a nuevas funcionalidades y otro a resolver defectos no es posible en este momento, no se puede tener un equipo fijo que es uno de los principales requisitos de Scrum, ya que sin un equipo no se puede lograr medir la velocidad de desarrollo para lograr un planeamiento a largo plazo (Release planning).

Aunque interpretarse como un fracaso, yo tomo lo positivo de esta experiencia. Me sirvió para aprender que para aplicar procesos tengo que tomarme más tiempo para estudiar la realidad de la empresa, lograr un consenso total de todos los involucrados (y uno mayor de la gente de arriba), e ir aplicándolo gradualmente los cambios para que las posibilidades de tener éxito sean mayores. También fue mi primera experiencia con una empresa no dedicada al desarrollo de software, la diferencia realmente es abismal. De todo se aprende.

miércoles, abril 25, 2012

Diarios de Praga I: Como Aplicar Scrum en un Ambiente Desfavorable

Praga es una ciudad hermosa, con una historia muy interesante, una arquitectura impresionante, mujeres hermosas y cerveza de excelente calidad a un precio muy accesible (increíblemente es más barata que el agua).

La razón por la que fui llamado de esta empresa de Praga es simple, no consiguieron Project Managers experimentados en el mercado local. Contrataron un par, pero no tenían la experiencia necesaria o eran muy estructurados o poco flexibles para adaptarse al trabajo.

Esta empresa desarrolla sitios de E-Commerce y provee servicios de hosting y soporte sobre ellos. Adicionalmente realizan campañas de marketing para estos clientes y los asesoran en cualquier tema relacionado. El equipo humano es muy bueno (en general), pero hay innumerables as aspectos para mejorar que les voy a comentar:
  • No utilizan procesos formales, y tienen a un mismo equipo desarrollando nuevas funcionalidades y resolviendo bugs. Trabajan con un SLA con los clientes, ya que al tratarse de sitios transaccionales donde grandes sumas de dinero están en juego. Claramente no se pueden dar el lujo de no resolver bugs críticos inmediatamente luego de recibirlos. El equipo de desarrollo recibe tareas de dos fuentes, la gente de soporte que recibe los bugs del cliente y del Project Manager que maneja el desarrollo de nuevas funcionalidades (su humilde servidor).
  • Los clientes tiene una mala imagen de la empresa porque bajo estas condiciones los planes de desarrollo de nuevas funcionalidades no pueden cumplirse ya que la resolución de bugs en el sitio en producción rompe con cualquier tipo de plan.
  • Otro tema es que los clientes tardan mucho en responder preguntas, aprobar especificaciones y diseño. Esto también hace que las funcionalidades se retrasen y el cliente piensa que el equipo se sienta de brazos cruzados en ese tiempo.
  • Los clientes no son empresas de software con las que siempre trabajé, sino empresas muy tradicionales que tienen un sitio web de E-Commerce, y la gente de sistemas son generalmente dinosaurios incompetentes pro PMI con nula capacidad de cambio.
  • Finalmente, sus procesos técnicos son medievales, no hacen code reviews, no automatizan tests, no hacen unit tests, no corren pruebas de regresión, no tienen ambientes de staging (solo tienen ambientes de QA y producción bastante distintos entre ellos). Ni hablar de test driven development (algo con lo que francamente nunca trabaje todavía) o metodologías agiles.
  • Como los clientes no confían completamente en ellos, no lograron estar contratados como time and materials. Tienen un contrato fijo de soporte y hosting, y luego por cada nuevo feature que se desarrolla, se prepara un contrato de costo fijo, incluso para cambios de pocas horas. Con ese esquema es imposible controlar costos, manejar un P&L o hacer un forecasting.
  • Los clientes tienen picos de trabajo descontrolados, urgencias todo el tiempo, y esperan una reacción rápida a estos pedidos.
Estoy tratando de implementar scrum tailorizado a su forma de trabajo. Por suerte logre convencerlos de que es la solución para ellos, pero todavía no sabemos como aplicarlo en este esquema.  Con la necesidad de resolver bugs por el mismo equipo (con el SLA) la capacidad del equipo nunca va a ser igual y la velocidad va a fluctuar. Nunca se va a poder hacer un release planning (tener un plan a largo plazo)  predecible y confiable.


En fin, además de darme la posibilidad de viajar por Europa los fines de semana, el trabajo un gran desafío, con muchos problemas para resolver. Espero mantenerme entretenido en los próximos meses. Los mantengo al tanto, Na shledanou!

jueves, marzo 29, 2012

¡Project Management en Praga!

Estas últimas semanas fueron bastante movidas. Hace dos miércoles, volví de vacaciones, vi una oferta laboral interna para trabajar como Project Manager onsite en Praga y me postulé. Ya había trabajado con ese cliente hace unos años, así que sabía como se manejaban y me interesó la propuesta.  El viernes tuve una entrevista que fue un trámite (tengo varios contactos en Skype de esa empresa que activé para lograr que me elijan). En tres días cambio mi vida. Este lunes parto a Praga, por 6 meses o más. Esta experiencia me va a marcar mucho profesionalmente, pero bastante más personalmente.

Praga, República Checa
Estimo que recolectare varias experiencias interesantes sobre management en Praga. Lo raro es que no voy a manejar proyectos ni equipos de mi empresa desde ahí, sino que voy a trabajar como manager de un equipo de Checos. ¡No cambien de canal!

domingo, febrero 05, 2012

The Deadline

"The Deadline: A Novel About Project Management" fue escrito por Tom DeMarco, coautor del famoso "Peopleware: Productive Projects and Teams". Como su título lo indica, el libro es una novela sobre gerenciamiento de proyectos, muy amena y entretenida.

La historia comienza cuando el protagonista, Mr. Tompkins es despedido de su trabajo y abducido por una espía de un país emergente cuyo objetivo es mejorar la industria de software local. El objetivo de Mr. Tompkins es terminar ciertos proyectos para una fecha específica, de ahí el título del libro. El recorrido es muy interesante, nos enteramos de como arma el equipo, como organiza los proyectos, como selecciona líderes y como resuelve todo tipo de problemas, desde personales hasta políticos.

Este libro fue escrito en 1997, y tiene varios conceptos que ya no aplican o por lo menos no son compatibles con mi orientación y "mindset" ágil. Por ejemplo, recomienda hacer un diseño detallado del software y recién escribir el código en los últimos meses, y también se utiliza mucho el método de punto de funciones para medir el tamaño del software.

Para resaltar los aprendizajes que el autor nos quiere dejar sobre project management, Mr. Tompkins completa un diario personal al final de cada capítulo, con los aforismos o puntos más importantes aprendidos luego de cada situación. Se los dejo, estimo estar de acuerdo con un 90% de estos puntos, disfrutenlos!
Four Essentials of Good Management:
·         Get the right people.
·         Match them to the right jobs.
·         Keep them motivated
·         Help their teams to jell and stay jelled
       (All the rest is Administrivia)
Safety and Change 
·         People can’t embrace change unless they feel safe.
·         Change is essential to all success in project work (and in most other worthwhile endeavors).
·         A lack of safety makes people risk-averse.
·         Avoiding risk is fatal, since it causes you to miss out on the associated benefit as well.
·         People can be made to feel unsafe by direct threats, but also by the sense that power may be used against them abusively.
Negative Reinforcement
·         Threats are an imperfect way to motivate performance.
·         No matter how serious the threat, the work still won’t get done on time if the time originally allocated for it was not sufficient.
·         Worse still, if the target doesn’t get met, you may actually have to make good on your threats.
The Manager’s Essential Body Parts
·         Management involves heart, gut, soul, and nose.
·         So ……  lead with the heart,
                      trust your gut (trust your hunches),
build soul into the organization,
develop a nose for bullshit.
Battle Command As a Metaphor for Management 
·         By the time the battle begins, the manager’s real work is already done.
Interviews and Hiring
·         Hiring involves all the managerial body parts: heart, soul, nose, and gut (but mostly gut).
·         Don’t try to do it alone  --- two guts are more than twice as good as one.
·         Ask new hires to undertake one project at exactly the level of competence they have already proved, to defer real stretch goals till the next time.
·         Ask for pointers: The person you are most inclined to hire may well know of other good possibilities.
·         Listen more than you speak.
·         All of these things work better if you stack the deck.
Productivity Improvement
·         There is no such thing as a short-term productivity fix.
·         Productivity improvement comes from long-term investment.
·         Anything that promises immediate term results is likely to be snake oil.
Risk Management
·         Manage projects by managing their risks.
·         Create and maintain a census of risks for each project.
·         Track the causal risks, not just the ultimate undesirable outcomes.
·         Assess each risk for probability and likely cost.
·         Predict, for each risk, the earliest symptom that might indicate materialization.
·         Appoint a risk officer, one person who is not expected to maintain a Can-Do attitude.
·         Establish easy (perhaps anonymous) channels for bad news to be communicated up the hierarchy.
Playing Defense
·         Cut your losses.
·         You can improve overall performance more by containing your failures than by optimizing your successes.
·         Be aggressive about canceling failed efforts early.
·         Don’t take chances on team jell if you don’t have to. Seek out and use preformed teams.
·         Keep good teams together (when they’re willing) to help your successors avoid problems of slow-jelling or non-jelling teams.
·         Think of a jellied team – ready and willing to take on a new effort – as one of the project deliverables.
·         A day lost at the beginning of project hurts just as much as a day lost at the end.
·         There are infinitely many ways to lose a day . . . but not even one way to get one back.
Modeling and Simulation of the Development Process 
·         Model your hunches about the processes that get work done.
·         Use the models in peer interactions to communicate and refine thinking about how the processes work.
·         Use the models to simulate results.
·         Tune the models against actual results.
Pathological Politics 
·         You have to be willing to put your job on the line any day . . .
·         … but that doesn’t guarantee that pathological politics won’t affect you.
·         Pathological politics can crop up anywhere, even in the healthiest organization.
·         The defining characteristic of pathological politics is that goals of personal power and influence come to override the natural goals of an organization.
·         This can happen even when the pathological goal is directly opposed to the organizational goal.
·         Among the bad side effects of pathology: It becomes unsafe to have a leanly staffed project.
Metrics 
·         Size every single product.
·         Don’t sweat the units -- while you’re waiting to achieve objective metrification, use subjective units.
·         Form synthetic metrics from all the primitives (countable characteristics of the software) available to you.
·         Collect archeological data to derive productivity trends from now-ended projects.
·         Tinker with the formulation for your synthetic metric until its values give the best correlation to Effort for the set projects in your archeological database.
·         Draw a trend line through your database, showing expected Effort as a function of values of the synthetic metric.
·         Now, for each new project to be estimated, compute value of the synthetic metric and use it to pick off expected Effort from the trend line.
·         Use the noise level around the productivity trend as an indicator of what tolerance to apply to the projections. 
Process and Process Improvement
·         Good process and continually improving process are admirable goals.
·         They are also very natural goals: good technical workers will focus on them whether you tell them to or not.
·         Formal process improvement programs cost time and money; a given process improvement effort may well set project work back.  Even if productivity gains materialize, they are unlikely to offset the time spent on process improvement for those projects that host the program.
·         A project can hope to gain enough from a single well-chosen method improvement to repay the time and money invested in the change.
·         Projects cannot realistically hope to accommodate more than one method improvement over their duration.  Multi-skill improvement programs (for instance, increasing by an entire CMM level) are most likely to make projects finish later than they would have without the program.
·         The danger of standard process is that people will miss chances to take important shortcuts.
·         Particularly on overstaffed projects, standard process will be observed rigorously as long as it generates sufficient work (useful or not) to keep everyone busy.
Changing the Way Work Gets Done 
·         There is no way to get projects to perform substantially beyond the norm without making large reductions in the total amount of debugging time.
·         High-performing projects spend proportionately far less of their time in debugging.
·         High-performance projects spend proportionately far more of their time in design.
·         You can’t get people to do anything different without caring for them and about them.  To get them to change, you have to understand (appreciate) where they’re coming from and why.
The Effects of Pressure  
·         People under pressure don't think any faster.
·         Extended overtime is a productivity reduction tactic.
·         Short bursts of pressure and even overtime may be a useful tactic as they focus people and increase the sense that the work is important, but extended pressure is always a mistake.
·         Perhaps managers make so much use of pressure because they don't know what else to do, or are daunted by how difficult the alternatives are.
·         Terrible suspicion: the real reason for use of pressure and overtime may be to make everyone look better when the project fails.
The Angry Manager 
·         Anger and contempt in management are contagious.  When upper management is abusive, lower management mimics the same behavior (much like abused children who go on to become abusive parents). 
·         Managerial contempt is supposed to act as a goad to get people to invest more in their performance. It is the most frequent "stick" of carrot-and-stick management.  But where is the evidence that contempt has ever caused anyone to perform better?
·         A manager's use of contempt to goad workers is more a sign of the manager’s inadequacy than of the workers'. 
Ambigous Specification  
·         Ambiguity in a specification is a sign of unresolved conflict among various system stakeholders.
·         A specification that doesn’t contain a complete census of inputs and outputs is a nonstarter.  It simply doesn’t begin to specify.
·         Nobody will tell you if a specification is lousy.  People are inclined to blame themselves rather than it.
Conflict  
·         Whenever there are multiple parties to a development effort, there are bound to be conflicting interests.
·         The business of building and installing systems is particularly conflict-prone.
·         Most system development organizations have poor conflict-resolution skills.
·         Conflict deserves respect.  Conflict is not a sign an unprofessional behavior.
·         Declare up front that everybody’s win conditions will be respected.  Make sure that win conditions are elicited at all levels.
·         Negotiation is hard; meditation is easy.
·         Arrange up front that when win conditions are mutually exclusive or partly so, the parties will be expected to move into mediation to resolve conflict.
·         Remember:  We are both on the same side; it is the problem that’s on the other side. 

The road to wisdom, well, it’s plain    
     and simple to express,
Err and err and err again,
    but less and less and less.
                                                - Piet Hein

Roll of the Catalyst 
·         There is no such thing as a catalytic personality.  Such people contribute to projects by helping teams to form and jell, and to remain healthy and productive.  Even if our catalysts did nothing else (they usually do a lot else), their catalytic role is important and valuable.
·         Mediation is a special case of the catalytic role.  Mediation is learnable with a small investment.
·         The small ceremony beginning, “May I help by trying to mediate for you?” can be an essential first step in conflict resolution.
Human Error 
·         It’s not what you don’t know that kills you; . . . it’s what you know that isn’t so.
Staff Level 
·         Early overstaffing tends to force projects into short cutting the key design activity (to give all those people something to do).
·         When work is divided over a large staff prior to completion of design, the interfaces among people and among work groups are not minimized.
·         This leads to increased interdependence, meeting time, rework, and frustration.
·         Ideal staffing requires a small core team for most of the project, and then significant numbers of people added later in the process (as late as the last sixth of scheduled time).
·         Awful suspicion: Projects that set out to ‘achieve’ schedules probably take longer to complete than they would have if started with more reasonable schedules.
Project Sociology 
·         Keep meetings small by making it safe for unessential people not to attend.  A published agenda, rigorously followed, is the easiest way to make nonattendance safe.
·         Projects have need of ceremony.
·         Use ceremony to focus attention on project goals and ideals: small meetings, zero-defect work, etc.
·         Take steps to protect people from abusive anger.
·         Remember:  Anger = Fear: Managers who inflict abusive, angry behavior on their subordinates are almost always doing it because they’re afraid.
·         Observation:  If everybody understands that Anger = Fear, anger will be a transparent signal that the angry person is afraid; since there is an inclination not to reveal fear, he or she won’t be able to vent the anger anymore.  (This doesn’t solve the angry person'’ problem, but it sure can make it easier on everyone else.)
Pathological Politics (Again) 
·         You can’t expect to cure pathology from beneath.
·         Don’t waste your time or jeopardize your position by trying.
·         Sometimes, your only option is to bide your time, waiting for the problem to resolve itself, or for a good opportunity for you to move on.
·         Miracles may happen (but don’t count on them).
Lean and Mean 
·         Lean and Mean is a formula developed in failing companies by the people responsible for the failure.
·         It is the opposite of any organization’s natural goal: to be prosperous and caring.
·         Whenever you hear the phrase “lean and mean” replace it with what it really connotes: failing and frightened. 
Radical Common Sense  
·         A project needs to have both goals and estimates.
·         They should be different.