En este blog comento experiencias del ámbito laboral y del educativo. Principalmente temas o situaciones de las cuales aprendí y me gustaría compartir. También recomendare libros, herramientas, software y buenas prácticas.
Kanbanize es una herramienta web gratuita para gestionar proyectos con la metodología Kanban. Me la recomendaron y la estoy comenzando a usar en un proyecto de desarrollo evolutivo y correctivo, donde Scrum no me sirvió ya que cambiaban las prioridades día a día y no logramos cerrar ni una iteración. Hace mucho que quiero comenzar a trabajar con Kanban y por suerte este proyecto me dio la oportunidad.
Sobre la herramienta, se pueden agregar n columnas y también separar el tablero en distintas filas. Sobre las tarjetas Kanban, se pueden personalizar de muchas maneras: ponerles un deadline, asignarlas a algún miembro del equipo, asignarles el esfuerzo y adjuntarle archivos, entre otras cosas.
Tiene un poderoso motor de métricas que recién estoy comenzando a aprovechar. Inicialmente se puede fácilmente ver cuánto tiempo cada tarea estuvo en cada columna para ver qué proceso lleva más tiempo. Tiene un montón de gráficos para visualizar por ejemplo la distribución de tareas por tipo o miembro del equipo, la duración del ciclo para cada tarea y el flujo de las mismas, entre otros. ¡Se las recomiendo!
Siempre tuve inquietud de cómo se siente estar del otro lado, de no ser más un alumno y ver cómo se maneja un grupo desde la docencia. Sin dudas, espero aprender un montón en esta nueva experiencia en la que estoy embarcándome. Ya en las pocas clases que asistí adquirí conceptos muy interesantes.
La materia está muy ligada a lo que amo y a lo que me dedico, el project management. El programa se basa en los siguientes temas:
Proyectos, estrategia y gobierno
Gestión estratégica
Gestión financiera
Gestión de riesgos
Gestión de portafolio y evaluación de proyectos
Técnicas tradicionales y alternativas de evaluación de proyectos
Además, los alumnos tienen que ir desarrollando un business case de un producto o servicio novedoso y presentarlo como trabajo final.
Esta materia la curse en el 2007, la disfrute mucho, y luego seguí en contacto esporádico con el profesor y con uno de mis compañeros con quien hicimos el trabajo práctico, quien es hace años ayudante de esta materia. Espero aprender mucho de ellos, el resto de los docentes y obviamente de los alumnos.
Les dejo este interesante video que me pasaron, disfrutenlo:
La zona de confort es ese lugar mental en el que estamos a gusto con
todo, y no pensamos en cambiar nada de nuestras vidas, Pero estar a
gusto con todo, no necesariamente es bueno. Algunas personas están
simplemente a gusto con la pobreza, con la gordura y con con el fracaso
en general, El problema de la zona de confort que tenemos como personas,
es que nunca nos podemos liberar de ella.
Es decir que en vez de
salirnos de nuestra zona de confort, lo que hacemos es expandirla.
Bueno, es posible salirnos por instantes, pero si convertimos en un
hábito, salir de nuestra zona de confort en cierto aspecto específico de
la vida, lo que realmente terminará pasando, es que nuestra zona de
confort se expandirá, para comprender esos límites, Es como si fuese una
membrana de la que por instantes nos salimos, pero para protegernos,
crece y nos vuelve a cubrir.
Es importante considerar, que si
bien no es posible librarnos de nuestra zona de confort definitivamente,
lo mejor entonces es hacerla crecer al máximo posible, Y para hacer
crecer o expandir nuestra zona de confort, lo que deberemos llevar a
cabo son actividades que nos incomoden, pero que nos lleven al éxito,
Llevar a cabo trabajos incómodos sin objetivo alguno, nos saca de
nuestra zona de confort, pero no nos lleva realmente a ninguna parte.
En
este artículo tratamos una temática poco usual por este blog. Un ámbito
de psicología y desarrollo personal, que queramos o no, forma parte de
nuestra salud mental y de nuestra calidad de vida. Os presentamos un
vídeo que nos servirá para pensar en cómo estamos viviendo nuestra vida y
hacia donde queremos ir. Un consejo rápido por si no tienes tiempo de
leer el artículo: sal de tu zona de confort y ten éxito en tu vida.
Zona
de confort : Como se menciona en el video, la forma de conseguir tu
meta es soñar con lo que quieres, ponerle fecha de caducidad a tu sueño y
luego trabajar para alcanzarlo. En todo esto juega un papel
determinando el cada vez más conocido concepto -- zona de confort.
Nuestra zona de confort es aquella en la que las cosas nos resultan
conocidas y cómodas, donde estamos acostumbrados a vivir.
Tu zona
de confort la comprenden muchos factores. Entre ellos destacan tus
hábitos, tus rutinas, tus conocimientos, tus habilidades, tus actitudes y
tus comportamientos. Es todo aquello conocido para ti y a lo que estás
acostumbrado.
Zona de aprendizaje : A continuación de tu zona de
confort se encuentra la zona de aprendizaje,donde sales a ampliar tu
visión del mundo, y esto se consigue aprendiendo idiomas, viajando a
nuevos países y conociendo nuevas culturas, aprendiendo o modificando
hábitos, etc.
Existen personas que realmente disfrutan en esta
zona de aprendizaje mientras que otras no se sienten nada a gusto,
intentando volver y permanecer en su zona de confort.
Zona de
pánico vs Zona mágica : ¿Cuántas veces has pensado o te han dicho -- y
si te sale mal?. Pues ésta es esa zona de pánico. La zona desconocida a
la que poca gente se aventura por que se desconoce lo que hay en ella.
La zona donde la gente no entra por miedo al fracaso o al que dirán.
Los
más visionarios, optimistas y aquellos que han conseguido alcanzar el
éxito y sus sueños llaman a ésta la zona mágica, la cual desconoces
porque todavía no has estado allí. Ésta es la zona en la que te pueden
ocurrir cosas increíbles. Saliendo de la zona de confort
Uno
de los motivos por los cuales no se suele salir de la zona de confort es
por el miedo a no poder volver a ella, lo cual no es cierto ya que tu
zona de confort siempre permanece ahí, de hecho, puedes incluso
aumentarla.
Por eso, lo que realmente ocurre es que al salir se
extiende tu zona de confort y aprendizaje. No se trata de un cambio en
el que pierdes lo que ya tenías si no que es un proceso de desarrollo
personal en el cual añades conocimientos, habilidades, experiencias,
etc.
Para poder progresar tu motivación debe vencer a tus miedos.
Miedo al que dirán, miedo a fallar y miedo al ridículo o vergüenza.
Cuando seas capaz de modificar tus miedos crecerá tu autoestima,
necesaria para una nueva visión de la realidad. ¿Qué es lo que te
motiva?. Pues lucha por ello.
Pero el camino no es fácil. Al
salir de tu zona de confort tendrás que luchar. Al principio te sentirás
vulnerable y débil ante esa nueva situación, pensarás que es muy
arriesgado. Es normal que te sientas así, eres humano. Pero esto
significa que estás aprendiendo y avanzando hacia tu sueño.
Recuerda
: Fuera de tu zona de confort se encuentra un mundo lleno de
posibilidades donde se encuentran tus sueños. Encuentra tu motivación y
sal de esa zona de confort, si te quedas en ella nunca llegará lo que
deseas. Ten paciencia, planifica y prepara tu estrategia, sé
perseverante, positivo y sobre todo cree en ti. Lucha por tu vida.
El libro "La gestión exitosa de Proyectos según el estándar del Project Management Institute (PMI) " de Alberto Allami es el material de lectura oficial del Posgrado en Gestión de proyectos que estoy cursando en la Universidad Tecnológica Nacional. Como el título lo indica, esta basado en el estándar del PMI, en la quinta edición del PMBOK que salio a fines del 2012.
El libro es un resumen del estándar, con el aporte de ejemplos, casos, reflexiones, actividades, experiencias y consejos del autor que no se pueden encontrar en el PMBOK. Gracias a esto, este libro es más ameno, pero no deja de ser un enfoque de un estándar, es muy difícil de lograr que sea entretenido. El libro recorre todas las áreas de conocimiento del PMBOK, y todos sus procesos, con las entradas, herramientas, y salidas.
El libro cuenta con un extenso caso de uso que abarca todas las áreas de conocimiento, plantillas de los documentos más utilizados por el estándar y finalmente da una interesante introducción a otras metodologías y estándares, como ser PRINCE2, ITIL, metodologías ágiles, CMM y RUP.
Este libro es recomendable para quien quiera tener una visión a grandes rasgos del estándar, sin entrar en tanto detalle y resultando más ameno que el PMBOK.
En Scrum, el product owner es la persona que guía al equipo en todo lo que se refiere al producto que se está construyendo, generalmente representando al cliente. Describe lo que hay que hacer (lo entiende), lo prioriza (buscando siempre dar valor cuanto antes, siendo responsable de la rentabilidad o ROI del proyecto), está en contacto con el equipo para responder dudas y maneja el roadmap y los lanzamientos del producto. Debe estar en las ceremonias principales, como el planning y la demo, y dar feedback constantemente.
Viéndolo del lado negativo, podemos hablar de los Product Owner Anti-Patterns. Uno cuenta con un mal Product Owner si:
El PO no viene a la demo.
El PO no viene al sprint planning.
El PO no puede explicar bien las historias durante Sprint Planning.
El PO no está disponible cuando el equipo lo necesita durante el Sprint.
El PO no está manteniendo el Product Backlog actualizado y en perfecto estado.
El PO no está autorizado a priorizar el backlog, y tiene que andar validando todo lo que hace con el cliente o un gerente a nivel micro-management.
El PO no tiene autoridad suficiente como para negociar entre todos los stakeholders, en el caso de hacer de ‘embudo’.
Contar con un PO involucrado es clave para el éxito del proyecto. Si se detecta uno o más de estos síntomas, trabaje sobre ellos para cambiar.
En Febrero del 2001 Elisabeth Hendrickson presentó "Better Testing, Worse Quality?" en una conferencia de la industria. Para resumirles ella enuncio que al invertir en testing, no se logra mejorar la calidad del software desarrollado. Al mejorar el equipo y los procesos de testing en una empresa, los desarrolladores pueden tender a relajarse al codificar, dejando de probar ellos mismos lo que desarrollan, defiriendo la detección de errores a los testers. Eso es un efecto negativo causado por la mejora. Ciertos defectos que los desarrolladores podrían haber encontrado salen a producción ya que cuantos más bugs existan, más salen a producción sin ser detectados. La solución propuesta fue reforzar el mensaje a los desarrolladores que prueben su trabajo, y esforzarse para prevenir defectos. La prevención puede lograrse mejorando los requerimientos, entrenando a los desarrolladores y aplicando buenas prácticas de desarrollo. Les dejo un mail de un tech lead a su equipo:
As you know, there's a large, growing backlog currently in test.
Development MUST produce bug-free code to ensure that the testers can pass our work quickly to release. Therefore, PLEASE test every component THOROUGHLY and do
what you can to make sure it's bulletproof BEFORE requesting a build. Just because a project is in the queue for test doesn't mean you should leave it as-is - PLEASE consider performing a few hours of testing to ensure that it is working as well as possible!
Thanks for your careful testing!!!
La moraleja de la historia nos enseña que invirtiendo en testing solamente no se mejora la calidad del software. Para lograr una mejora, hay que invertir para que los bugs puedan encontrarse y resolverse cuanto antes, como enuncian las metodologías ágiles hoy en día.
Si les intereso, les recomiendo que lean el paper de Elisabeth para entrar más en detalles sobre lo enunciado.
The Art Of Agile Development de James Shore y Shane Warden es un libro que engaña desde su título. Esperaba encontrarme con un libro generalista sobre desarrollo de software ágil y en su lugar me encontré con un libro dedicado a Extreme Programming. Esperaba encontrarme con un libro teórico, enfocado en el arte del desarrollo ágil (como el título bien dice), pero me encontré con un libro que explicaba prácticamente una por una las ~treintas prácticas de XP. Solo al final el autor se desarrollaba sobre teoría ágil, y muy brevemente.
Me sirvió para entrar en detalle en ciertas prácticas de XP que no recordaba. XP es muy valioso como complemento de Scrum, ya que este último solo da un marco de trabajo, mientras XP entra en detalle sobre como trabajar técnicamente para tener éxito, por ejemplo aplicando TDD. Igual si quieren leer sobre XP les recomiendo Extreme Programming Explained de KentBeck y CynthiaAndres, ese libro no tiene desperdicio y es un clasico.
Finalmente, me llevo mucho tiempo y me costó mucho terminar este libro. Yo leo generalmente en el tren al ir o volver del trabajo, y casi siempre preferí sacar mi celular y jugar al Angry Birds antes que tomar este libro, cosa que no me pasa con libros interesantes. La redacción no es para nada amena y es mejor para tener como un libro de consulta sobre las prácticas de XP, y leer un capitulo cuando se tiene una duda de algo. No lo recomiendo.
Un "Retro Heat Map" es uno de los tantos instrumentos radiadores de información (o information radiators) de las metodologías ágiles. No voy a traducirlo porque realmente no encuentro una buena manera de nombrarlo en castellano, pero seguro van a entender de que se trata con la explicación del artefacto a continuación.
En una retrospectiva lo ideal es que todos hablen, opinen e intercambien ideas para que el equipo mejore. Siempre hay gente que es más tímida o más reservada que otros, y también gente que ama el sonido de su propia voz y siempre quiere hablar. Si son muchos, es difícil notarlo bien, para eso una persona ideó el "Retro Heat Map", donde uno marca en una hoja un punto al lado del nombre de cada persona cuando expone una idea en una retrospectiva. Como ven en el ejemplo de la derecha, es fácil de ver que el equipo está perdiendo contribuciones de ciertos miembros en las retrospectivas.
Luego, con esta información, podemos ir a charlar con la gente que no hablo mucho para obtener su feedback y levantar esos temas en la próxima retrospectiva e incitarlos a que lo expliquen y empiecen a sentirse mas cómodos hablando más. También podemos ir a charlar con los que hablan mucho, mostrarles el diagrama, y lograr que traten de dejar algunos de sus comentarios al final para darle oportunidades a sus compañeros más callados que hablen.
Una versión más avanzada de este diagrama puede hacerse con flechas de una persona a la otra para ver entre que miembros del equipo hay más interacciones.
Hace pocos días un colega me comentó sobreasana.com, una aplicación web colaborativa para el manejo de tareas y administración de proyectos. Es una aplicación bastante nueva (se lanzo en noviembre del 2011) y es gratuita para equipos de menos de 30 personas. Por ahora comencé a utilizarla yo solo, para manejar mis tareas laborales personales. Se pueden crear distintos espacios con sub-proyectos y tareas. Se pueden crear tareas recurrentes, fijar deadlines, asignarles tags y adjuntar archivos (esta integrada con dropbox también).
Finalmente, esta integrada con Google, así que uno se puede autenticar con su cuenta y también sincronizar las tareas a un calendario.Creo que esta aplicación va a remplazar a Stickies, mi bloc de notas que utilizo en mi laptop laboral, cuya principal desventaja es que es una aplicación de escritorio y solo se puede acceder desde una única computadora. Pruébenlo, se los recomiendo, esta evolucionando, creciendo y la usa mucha gente. Espero que sea un hit y la compre Google o alguna otra empresa similar.
En muchas empresas de desarrollo de software, se asigna en el rol de ScrumMaster a un Project Manager, al mismo tiempo en el mismo proyecto. A mí me paso y pensaba que era lo correcto, que tenía sentido, hasta que me encontré con un artículo que me voló la cabeza. Citando a Steven Hundon:
Contrary to popular belief, the ScrumMaster and project manager roles are highly different and shouldn't be confused. As more companies migrate their project management to Agile, many do so without a proper understanding of what they're aiming for. In particular, there are incorrect assumptions made about the roles in Agile; people often expect that the shift from Waterfall practices includes a wholesale shift of roles. The ScrumMaster, however, does not play the part of the traditional project manager. Traditionally, the project manager is a leader, a decision maker, a planner, someone who manages the project and the team and is the person accountable to the business for accomplishing the project objectives. The ScrumMaster's role is more that of coach and facilitator, a role that sits between the project and the customer. The ScrumMaster doesn't manage the team that produces the work; instead, he supports the product owner, coaches the team, and makes sure that Scrum processes are adhered to. The ScrumMaster is responsible for the Scrum process, its correct and continuous implementation, and the maximization of its benefits.
Esto realmente tiene todo el sentido del mundo. En Scrum, se distingue la persona que da soporte al equipo en QUE hace y COMO lo hace, mediante el Product Owner y el ScrumMaster respectivamente, siendo dos personas distintas con objetivos distintos. Veamos el siguiente diagrama:
¿Porque el ScrumMaster y el Project Manager no pueden ser la misma persona? En Scrum no se le puede pedir a alguien que sea responsable del QUE y del COMO a la misma vez porque bajo presión, se va a favorecer a uno u a otro. Si el ScrumMaster toma decisiones sobre el producto, Scrum no está correctamente implementado ya que da lugar a conflictos y confusiones.
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.
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.
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.
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.
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
Bug causes system crash or data loss.
Bug causes major functionality or other severe problems; product crashes in obscure cases.
Bug causes minor functionality problems, may affect "fit and finish".
Bug contains typos, unclear wording or error messages in low visibility fields.
Priority
Must fix as soon as possible. Bug is blocking further progress in this area.
Should fix soon, before product release.
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.
"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:
Separar la gente del problema, la idea es no dañar la relación con la persona que tenemos enfrente.
Enfocarse en los intereses, no es posiciones. Pensar en el problema en cuestión, preguntar, encontrarle la vuelta.
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.
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.
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.
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
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:
Asegurar que los valores y las prácticas de Scrum se respeten y se cumplan.
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.
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).
Prestar atención en las reuniones diarias. Seguir los temas abiertos en ellas. Asegurarse que las conversaciones sigan fuera de esta reunión.
Moderar las reuniones diarias para que no sean innecesariamente largas.
Asegurarse que el product backlog este priorizado (Push al product owner) y estimado (asegurando que los poker plannings se hagan).
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
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.
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.
Asegurarse que los analistas funcionales trabajen en el acceptance criteria de las historias del product backlog de mayor prioridad junto al product owner (Grooming)
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.
Preparar la presentación con las métricas del sprint para presentar en el sprint review, antes o después de la demo.
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.
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.
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.
Facilitar la comunicación del equipo con el product owner.
En algunos casos, liderar sin autoridad formal, sin títulos. El ScrumMaster es un servidor y líder a la vez.
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.
Asegurarse que todos sepan usar la herramienta de administración del proyecto que se use, entrenar al equipo.
Proteger al equipo de influencias externas. Ser el punto de contacto principal para cualquier persona externa al equipo. Encargarse de las tareas burocráticas.
Comunicarse e informar el estado del proyecto y del equipo a sus superiores dentro de la empresa.
Organizar eventos cuando se llega a hitos importantes.
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.
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.
