Scrum with Asana in 7 steps

In this post, in only seven steps, I will try to show how I use Scrum with Asana, just by using lists. Here is a short video in Spanish.

When I start a Scrum Project, the first thing I do is to create a new workspace in Asana named after the project. Then I invite team members to join (usually no more than 9) and some business representatives (no more than 4). In order to reach more stakeholders and keep communication fluent among the team and between team and business people, I create a private channel in Slack.

In Asana I start creating these 6 public projects:

• PROJECT MANAGEMENT: For tasks regarding up front planning, reference notes, documentation links, etc.
• BACKLOG: For the tasks representing product backlog items (user stories and epics).
• REL1: First Release Backlog items (user stories and epics).
• SPR1.1: First Sprint Backlog for the first release (technical tasks).
• SPR1.2: Second Sprint Backlog for the first release.
• REL2: Second Release Backlog list is convenient when moving stories from release #1.

Product Owner is supposed to manage the backlog and the releases lists. Team members are supposed to manage sprint lists.

Now let's see step by step how to use Asana on some key points during the agile project lifecycle.

Scrum en las aulas

En el libro Scrum: el nuevo y revolucionario modelo organizativo que cambiará tu vida, Jeff Sutherland explica, como solo puede hacer él, los orígenes y el porqué de cada rol, artefacto, ceremonia, etc. Este libro se publicó en  2014 bajo el título Scrum: The Art of Doing Twice the Work in Half the Time. La traducción al español, salvando el título, me parece bastante buena. Se trata sin duda de una lectura muy recomendable para cualquier project manager (también para los que dirigen proyectos predictivos). Lo recomiendo encarecidamente.

En el capítulo 9, titulado “Cambiar el mundo”, el co-autor de Scrum también trata de convencernos de que Scrum no solo aplica al software sino a cualquier ámbito del trabajador del conocimiento. Especialmente ilustrativa resulta la experiencia de un instituto holandés que desde 2011 practica el método Scrum en clase, gracias a la iniciativa del profesor de química Willy Wijnands, que bautizó el método con el nombre de eduScrum y están logrando tener mucha difusión a través de una página web, un blog, YouTube, etc. El artículo que pueden leer en este enlace cuenta cómo empezó todo. En este otro enlace presentan evidencias sobre las mejoras que aporta este método de aprendizaje.

Estas experiencias reales me han llevado a pensar que quizá ¿el futuro de la educación secundaria debería ir por ahí? A mí personalmente no me gusta que a mis hijos les hagan memorizar, pienso que no se les está preparando bien para trabajar en equipo ni para desenvolverse con eficacia en un mundo cada día más colaborativo. Hasta ahora yo me quedaba en la queja, no me imaginaba cómo podía ser la solución.

The New Asana

Last September Asana founders Dustin Moskovitz and Justin Rosenstein launched the new Asana. The video recording, with a duration over half an hour, is so interesting that I cannot help sharing it here. I think it could represent which are the trends not only in Asana, but in the general landscape of collaborative software in 2016.

Cut 1/9: Tyranny of work about work. The problem: When we have to work together we spend more time working on how to work than working properly. Why is that? We need to focus more on results and less on processes based on emails, files, messages, meetings, etc.

Asana 2016

El pasado 30 de septiembre de 2015 los fundadores de Asana Dustin Moskovitz y Justin Rosenstein anunciaron el lanzamiento de la nueva versión de Asana. El vídeo de la presentación de más de media hora me parece tan interesante que me gustaría difundirlo también desde aquí. Creo que resume muy bien por dónde van a ir las tendencias en 2016 no solo de Asana, sino en el mapa general de las herramientas para el trabajo colaborativo.

Parte 1/9: Tyranny of work about work. El problema: ¿Por qué cuando tenemos que colaborar nos pasamos más tiempo trabajando sobre cómo trabajar que trabajando propiamente? Se necesita más orientación a resultados y menos orientación a procesos (con la consiguiente sobrecarga de correos, ficheros, mensajes, reuniones, etc.)

No preguntes el % completado

En este post quiero recordar a la gran Rita Mulcahy, una de las personas que más ha contribuido a nuestra profesión. Si bien muchos conocimos a Rita a través de su famoso libro para preparar el examen PMP, libro con el que yo me preparé y que sigo recomendado a pesar de haber escrito yo otro sobre el mismo tema (ante la calidad hay que descubrirse), estoy seguro de que cuando Rita brillaba más era en sus cursos y en sus ponencias. De todos los vídeos de Rita que yo he visto en YouTube, sin duda el que me parece más inspirador es este sobre cómo se debe controlar un proyecto:

Asana on Agile Projects

Long time ago I wrote a post proposing the use of Evernote as a virtual story board. In practice, I’ve been using this method myself on some projects, and I liked it for several reasons, mainly because of the great acceptance of Evernote and also because of the higher quality of the documentation I could see at project closing, since the tool makes it easy and quick for everyone to write about user stories, personas, retrospectives, impediments, and so on. However, this method had important issues. To name a few: the Product Owner had to share her user account, reprioritizing was tough, the technical team preferred other tools to manage tasks, etc.

Now I have to say I've changed my mind: Asana is my best option. I use Asana for getting things done, interacting with students and project teams, and even for tracking my children’s homework ;-) and also for agile projects, of course. In agile projects, Asana has always been my first option for sprint backlog virtual boards, but I insisted with Evernote for the other uses. When I used Asana not for agile, I liked Asana for documentation as well. I insisted with Evernote because I could work offline, but this is not a real issue nowadays, isn't it? If I don’t have access to a network wire, then I usually have access to a Wi-Fi network; if not I can always use my mobile Wi-Fi hotspot… In conclusion: I keep a tool for everything related to task management, and this tool is Asana, I don’t need any other one.

In this post I will try to explain how to use Asana on projects under Scrum methodology. If you want to see the example I’ve prepared (as if you were the Scrum Master) then you can go to:

• www.asana.com
• user: jose.barato@pmpeople.es
• password: pmpeople

Asana en Proyectos Ágiles

Hace un tiempo escribí un post titulado usar Evernote en Proyectos Ágiles, donde proponía usar Evernote como tablero virtual. En la práctica he usado este método en algunos proyectos y me ha gustado por varios motivos, principalmente porque es una herramienta que cuenta con mucha aceptación y sobre todo por la buena documentación que queda al final: Evernote es una herramienta que anima a a la gente a escribir sobre historias, personas, retrospectivas, impedimentos, etc. Este método que yo proponía, sin embargo, tiene varios inconvenientes: hay que compartir la cuenta del Product Owner, no es cómodo repriorizar historias, y el equipo técnico prefiere usar otras herramientas para manejar sus tareas.

Asana últimamente me está gustando más. Yo uso Asana para mi productividad personal, para interaccionar con los alumnos, en proyectos, para ponerles deberes a mis hijos... En los proyectos ágiles, Asana siempre ha sido mi opción de tablero virtual para el sprint backlog, pero me empeñaba en mantener Evernote para el resto de la documentación. Hasta que pensé: ¿Asana también serviría para documentar? Mi motivo principal para usar Evernote era que funciona offline, es decir, aun cuando la gente no esté conectada a Internet, pueden seguir escribiendo. Si no hay conexión, entonces Asana no se puede usar. ¿Esto es una verdadera limitación? Si no hay cable, hay wifi, y siempre puedo usar la wifi del teléfono… Conclusión: me quedo con una herramienta para todo lo que tenga que ver con gestión por tareas, y esa herramienta es Asana, no necesito más.

En este post voy a tratar de explicar cómo me propongo usar Asana a partir de ahora, como única herramienta de gestión bajo metodología Scrum. Si quieren ver en Asana el ejemplo que he preparado (como si fueran el Scrum Master) pueden usar este acceso:

• www.asana.com
• usuario: jose.barato@pmpeople.es
• password: pmpeople

Vídeos Ágiles

Aquí recopilo mis vídeos favoritos de introducción a los métodos ágiles. Con tantos vídeos divulgativos, los directores de proyectos ya no tenemos excusa para no saber cómo comportarnos en un proyecto adaptativo. Espero que le sean útiles.

Introductorios:

• Visión de Computer Associates (8'35")
• Scrum en 10 minutos (8'50")

I want to run an Agile Project:

• Parte 1 (10')
• Parte 2 (6'32")

Vídeos de Sally Elatta:

• Daily standup (10'31")
• Scrum basics (15'10")
• Scrum Process (5'33")
• Scrum Values (5'33")
• Scrum Terminology (3'59")

Vídeos de Henrik Kniberg:

• Product Owner (15'52")
• Spotify Culture 1 (13'12")
• Spotify Culture 2 (13'27")

Calculating the Project Buffer

The Critical Chain Project Management method recommends to make uncertainty explicit using buffers to protect critical and nearly critical paths in the project network schedule diagram. Expliciting buffers is a quite interesting practice for project governance, since KPIs like percent completed buffer can be easily monitored graphically, like this chart shows:

In this post we will see how to calculate the project buffer, following an example proposed by Mike Cohn: Agile Estimating and Planning, Prentice Hall, 2012.

Cómo manejar buffers en Microsoft Project

 

Una aproximación simple al método de cadena crítica con Microsoft Project consiste en añadir buffers de proyecto y buffers de alimentación para proteger el camino crítico y los caminos casi-críticos, respectivamente.

A continuación se describen los pasos para modelar el funcionamiento de un buffer en Microsoft Project:

1) Modelar un buffer como una tarea manual, con precedencia final a inicio después de la última tarea del camino que se desea proteger.

2) Cuando se consume algún día de buffer, esto se verá como una notificación en buffer (borde discontinuo).

3) Para hacer que Microsoft Project recalcule fácilmente el buffer: 1) Copiar fecha fin de buffer (CTRL+C); 2) Pulsar botón respetar enlaces; 3) Sobrescribir fecha de fin (CTRL+V).

Cálculo del Buffer de Proyecto

Como se vio en el post anterior, el método de cadena critica proponía explicitar la incertidumbre a través de colchones (buffers) para proteger los caminos críticos y casi críticos. El concepto de buffer de proyecto es muy interesante para la alta dirección, ya que indicadores clave de desempeño como el porcentaje de buffer consumido pueden monitorizarse de forma gráfica como se muestra en la figura:

En este post veremos a través de un ejemplo cómo calcular el buffer de un proyecto. El ejemplo se ha extraído del libro de Mike Cohn: Agile Estimating and Planning, Prentice Hall, 2012.

Agile Principles to Project Management

30

According to the Project Management Institute, an Agile Project Manager, on a regular basis, should explore, embrace, and apply agile principles and mindset within the context of the project team and organization. This implies some typical tasks included below:

1. Advocate for agile principles by modeling those principles and discussing agile values in order to develop a shared mindset across the team as well as between the customer and the team.
2. Help ensure that everyone has a common understanding of the values and principles of agile and a common knowledge around the agile practices and terminology being used in order to work effectively.
3. Support change at the system or organization level by educating the organization and influencing processes, behaviors, and people in order to make the organization more effective and efficient.
4. Practice visualization by maintaining highly visible information radiators showing real progress and real team performance in order to enhance transparency and trust.
5. Contribute to a safe and trustful team environment by allowing everyone to experiment and make mistakes so that each can learn and continuously improve the way they work.
6. Enhance creativity by experimenting with new techniques and process ideas in order to discover more efficient and effective ways of working.
7. Encourage team members to share knowledge by collaborating and working together in order to lower risks around knowledge silos and reduce bottlenecks.
8. Encourage emergent leadership within the team by establishing a safe and respectful environment in which new approaches can be tried in order to make improvements and foster self-organization and empowerment.
9. Practice servant leadership by supporting and encouraging others in their endeavors so that they can perform at their highest level and continue to improve.

In the center of these common tasks is the real understanding of the values and principles expressed on the Agile Manifesto published in 2001. The 4 values of the Agile Manifesto are stated as:

Behind these 4 values, there are 12 principles, which are transcribed below:

Principios Ágiles en Dirección de Proyectos

Según el Project Management Institute, un Director de Proyectos Ágil, en su día a día, debería explorar, fomentar y aplicar principios ágiles en el contexto del equipo del proyecto y la organización. Esto implica, entre otras, estas 9 tareas:

1. Fomentar los principios ágiles modelándolos y discutiendo los valores ágiles para desarrollar un entendimiento común dentro del equipo y entre el equipo y los interesados.
2. Ayudar a asegurar que todos tengan un entendimiento común de los valores y principios ágiles, de las prácticas ágiles y la terminología empleada para trabajar de manera efectiva.
3. Apoyar el cambio en la organización educando e influenciando sobre los procesos, comportamientos y personas para hacer la organización más eficaz y eficiente.
4. Practicar la visualización por medio de radiadores de información muy visibles que muestren el progreso y desempeño real del equipo para fomentar la transparencia y la confianza.
5. Fomentar un entorno de seguridad y confianza, permitiendo que todos experimenten y cometan errores para que puedan aprender y mejorar continuamente la forma de trabajar.
6. Mejorar la creatividad experimentando con nuevas técnicas e ideas sobre los procesos, para descubrir formas de trabajar más eficientes y eficaces.
7. Fomentar que los miembros del equipo compartan el conocimiento colaborando y trabajando juntos para reducir los riesgos de islas de conocimiento y cuellos de botella.
8. Estimular el liderazgo emergente dentro del equipo estableciendo un entorno respetuoso y seguro en el que puedan probarse nuevos enfoques para producir mejoras y fomentar la auto-organización y el facultamiento.
9. Practicar el liderazgo servicial soportando y estimulando a otros en sus esfuerzos, de manera que puedan trabajar a su máximo nivel y continuar mejorando.

En el centro de estas tareas se encuentra el verdadero entendimiento de los valores y principios ágiles expresados en el Manifiesto Ágil publicado en 2001. Los 4 valores del Manifiesto Ágil se enuncian así:

Detrás de estos 4 valores se detallan 12 principios, que se transcriben a continuación:

How to use Evernote as an agile virtual story board

I'm sure you are familiar with Evernote, the most famous tool for taking notes on a computer, laptop, tablet, smart phone, etc. Your notes are now stored “in the cloud”. You don't need physical notebooks any more. You can take notes everywhere and every time. As a knowledge worker, student, etc., you are so used to it that you can afford the premium cost of $5 per month (being the free version completely functional).

However, have you ever thought using Evernote as an virtual story board on agile projects? I have to say that Evernote is my favorite tool for agile teams (precisely: for not collocated teams). Think of all those features related to writing notes, labeling notes, moving notes from one notebook to another, searching, clipping, etc. Don't you think this is the “low-tech, high-touch” style we are always demanding for agile projects tools? For a collocated team, the best tool is a big wall in a comfortable dedicated room, of course. However, if two or three of the team members are in another sites, or the team is entirely virtual, a centralized repository for requirements and management information is the most useful.

If you are interested in the way I use Evernote as an agile virtual story board, please keep on reading...

The Agile Project Manager (and III)

... read the previous post

Agile methods will not fade away. They have been practiced for more than 15 years with outstanding results, not only on software projects but on many other fields. Some projects, especially knowledge worker projects occurring in fast-moving or time-constrained environments, call for an agile approach. If you take a course in Scrum, for instance, you will have solid resources to face an adaptive project. Being invented in the product management arena, agile methods can also be used in project management.

By means of the new credential PMI-ACP (PMI Agile Certified Practitioner), PMI is getting back the Project Manager on stage as the main character, also for adaptive projects. In order to get the credential, the candidate has to demonstrate they have real experience on agile projects, and also that they are capable to apply the whole set of tools, techniques, knowledge and skills needed on agile projects.

So far, PMI has not published a new standard to manage agile projects (there is no Agile Project Management Body of Knowledge), and there is no communication implying that. Instead, PMI recommends a series of 11 reference books, true master pieces on agile practices. With so good literature available, maybe this is the right approach (but those books are quite focused on software, though). On the other hand, unfortunately for those not having a good level of English, those 11 books are not translated to any language, and even worse, currently the PMI-ACP exam does not have translation aids. Nowadays, the candidate has to study lot of books and practe a lot of tests, in English.

Moreover, as far as I know, there are not many books aimed to PMI-ACP exam takers and also for those not needing the certification but to learn how to manage agile projects. Those books will come. Meanwhile, you cannot wait. Sooner or later, an agile project is going to cross your path. You better get prepared.

There is no other profession in the world more goal oriented than project management. Project Management is definitely not quite a rewarding profession: If goals are met, as they have to be, that is the reason you are in charge, then no one praise you. But if goals are not met, then the fault is only yours. While everything is doing okay, nobody says a thing, but if the outcome is not good, suddenly, everyone is talking about risk management, poor documentation, poor leadership, quality audits, communication problems, lack of social skills, convenience of coaching, etc. The result is always the same for the poor Project Manager: Everybody blames us and we don’t have good defense.

Project Managers don't need to reinvent the wheel. All they may need is already invented yet. This is the same case for adaptive projects. We don't need to invent methods to manage them. You need to adapt yourself to this new way of managing. If you don't, the next time somebody blames you for managing an adaptive project the traditional way, you will have to admit it this is entirely your fault!

Click here to read the Spanish version for this article

Click the label English to read other English written articles

The Agile Project Manager (part II)

... read the previous post

So, finally the project was a success, not because of you, but despite you. You wanted to impose unwise methods, now you realize that. Fortunately your team did not obey you. Now you know they were right, and you were not. You are also worried about the near future. Nowadays it is not very uncommon that projects are under continous change by nature. Knowledge workers have to give the most within the least time, adapting efforts to the changing needs from customers. Moreover, you feel this is not only a trend: this is like business as usual more and more. You recently did some research about agile methods. To your surprise, these methods are simple and easy to understand (the challenge is not about knowing them, but practicing them properly). You enjoy specially practical videos explaining the job of a product owner: http://goo.gl/NHYZWL; and this other one on daily stand-ups: http://goo.gl/EiXCGo

Why not using your project management knowledge, skills and experience on this kind of projects? 

The Agile Project Manager (part I)

Imagine this: You are a project manager with a lot of experience managing projects. You really love your job and consider it as a profession. You got your PMP® more than 10 years ago. Your boss and clients are used to congratulating you at project closures. You are a regular speaker on congresses about risk management, Microsoft Project, etc. You volunteer from time to time for PMI® projects and events. Everything seems to show that you are a highly rewarded professional: When you talk about project management, everybody listen. Many colleagues appreciate your expert judgment.

Now you have just closed your last project, but you are not happy at all. It was a consulting project for a big company, aimed to beat the competition through a new technology. Client representatives knew for sure that they could not remain as-is, but they did not know how to change what. Dissapointed by the poor progress of an internal SME team, they decided this was a case for procurement. Your company won the bid thanks to a project plan based on flexibility, adaptation and collaboration with the customer team throughout the project. Your company also included some experienced agile CVs.

From the very beginning, you were aware it was going to be easy to complete the requirements baseline. Very soon you realized that the client team would never sign off a document like that, not to mention the scope statement, WBS, cost baseline, detailed schedule, etc. How on earth could you avoid scope creep? The only planning information you had was about some given milestones and the final project deadline in nine months!

Regarding costs, the contract specified person-days by category, that's all. Having so much uncertainty, how would you develop the project plan? The customer wanted biweekly follow-up meetings. How would you report progress? Comparing to what baselines? Your boss told you not to worry because the team members had succeded on analogous projects before. You could trust them. They should do a great job...

However, you wonder: So, what am I supposed to do?

El Director de Proyectos Ágil

Imagine este caso: Usted es Director de Proyectos. Cuenta con mucha experiencia dirigiendo proyectos y siente verdadera vocación por esta actividad, que considera su profesión. Ya hace más de diez años que se certificó PMP®. Usted ha tenido continuas muestras de reconocimiento en sus proyectos, dentro y fuera de su empresa. Incluso ha impartido algún curso sobre fundamentos de gestión de proyectos, sobre gestión de riesgos, sobre la herramienta Microsoft® Project©, etc. También ha participado como voluntario en algún proyecto de PMI®, y le han invitado como ponente en un par de congresos. Todo parece indicarle que es un buen profesional, muy respetado. Cuando usted habla de algo relacionado con la gestión de proyectos, la gente le escucha con atención. Muchos colegas valoran su opinión experta.

Ahora acaba de cerrar su último proyecto y no está contento. Se trataba de un proyecto de consultoría para una gran empresa. El objetivo principal era posicionarse tecnológicamente por delante de la competencia. Los representantes del cliente tenían claro que no debían seguir igual, que debían cambiar, pero no sabían qué ni cómo. Asignaron un comité de expertos internos a la empresa, pero como no avanzaban se decidió contratar una empresa externa. Su empresa ganó el concurso gracias al enfoque orientado a la flexibilidad, adaptación y colaboración con el personal por parte del cliente y también gracias que los currículos de los miembros del equipo destacaban su experiencia en métodos ágiles.

En este proyecto, usted fue consciente desde el principio de que no iba a ser fácil elaborar un documento de requisitos completo, era improbable que el cliente lo aceptase formalmente. Tampoco podía comenzar trabajando una EDT, como es su costumbre. ¿Cómo evitar entonces la corrupción del alcance? La única información clara acerca del cronograma es que había ciertos hitos y el proyecto duraba nueve meses. Lo único claro sobre los costes era el número de horas contratado por perfil. Con tanta indeterminación, ¿cómo elaborar el plan para la dirección del proyecto? El cliente quería mantener reuniones de seguimiento bisemanales. ¿Cómo justificar los avances? Sus jefes le decían que no se preocupase porque los consultores de su equipo tenían mucha experiencia en proyectos parecidos, que confiara en que harían un buen trabajo.

Sin embargo, usted se preguntaba: Y entonces yo, ¿para qué estoy aquí?

Requisitos de un simulador de exámenes de PMI

Como sabe todo aquel que se haya preparado para obtener alguna certificación de PMI®, una vez se dominan los conceptos, es clave practicar tests parecidos a los del examen, cuantos más, mejor. Suelen ser exámenes con una restricción dura de tiempo, por lo que es vital haberse entrenado para responder las preguntas rápido y bien. Los que superan estos exámenes sin dificultad, comentan que los días previos realizan amplias baterías de tests que pueden equivaler a 2-3 veces la extensión del examen. Si hablamos del PMP, esto supone entre15-20 horas de esfuerzo para hacer y revisar unas 500 preguntas.

Si bien estos exámenes pueden practicarse en papel, es mucho más productivo utilizar alguna herramienta que permita realizarlos por ordenador. Si además hacemos la prueba CBT (Computer Based Testing) es importante que estos simuladores tengan una funcionalidad y apariencia lo más parecida posible a la aplicación que nos vamos a encontrar el día del examen.

En este post quiero compartir una forma de simulador de examen un tanto especial: No requiere instalar nada en el ordenador (PC o Mac). Tampoco requiere conexión a Internet. No hay que usar una base de datos ni programar.

A mí me sirve para preparar preguntas para mis alumnos y hacerles pruebas de nivel, para ensayar preguntas en clase, en webinars, etc. Como alumno, yo mismo he utilizado estos simuladores intensamente para preparar mi examen PMI-ACP.

El rol del Product Owner en la práctica

El Product Owner es un rol muy importante en los proyectos ágiles: Representa nada menos que la voz del cliente. Se asegura de que el equipo conozca la perspectiva del negocio. Gestiona las historias de usuario, las prioriza, y las mantiene en el product backlog. En un proyecto ágil, no es menos importante la figura del “coach” o ScrumMaster, ocupado principalmente en asegurar que se sigue el proceso y evitar impedimentos.

Personalmente, me interesa mucho el papel nos toca a los Project Managers en un proyecto ágil, pero no está claro si debe ser ScrumMaster, Product Owner, una mezcla de ambos, o bien depende del caso concreto. En las referencias más utilizadas no parece haber una opinión consensuada: En este post se comenta que el Project Manager podría ejercer cualquier rol, dependiendo del caso. Este otro va más en la línea de que el Project Manager debe corresponderse con el rol de Product Owner.

Para arrojar luz sobre el tema, lo primero es conocer en detalle qué se supone que debe hacer el Product Owner en la práctica. Con este fin les recomiendo que visiten este famoso vídeo titulado Agile Product Ownership in a Nutshell. También pueden ver esta otra versión del mismo vídeo subtitulada en español: El rol del Product Owner en la práctica.

A continuación pueden leer una transcripción traducida al español.