febrero 12, 2014

Scrum master a tiempo completo: 42 Tareas

Uno de los artículos que más referencio cuando hablo de las labores del Scrum Master es: 42-tasks-for-a-scrum-masters-job. Por alguna razón, todo el mundo parece entender que el Product Owner es un trabajo a tiempo completo, o ser miembro de un equipo también, pero que probablemente el rol del Scrum Master puede ser realizado a media jornada o incluso menos.
El scrum master también tiene mucho trabajo en equipos medianos o grandes, o nuevos. Y es preferible que se centre en sus tares como scrum master, compartiendo su trabajo entre dos equipos por ejemplo, que trabajar también con la gorra compartida de miembro del equipo. ¿Por qué? Por que las labores que tenderá hacer son las de desarrollador antes que las de scrum master.

He querido traducir este artículo, para que quede en castellano, con permiso de Bernd Schiffer, para que quede constancia, y pueda referenciarlo en nuestro idioma :)

Artículo original: 42 Tasks for a Scrum Master’s Job

Las siguientes preguntas aparecen a menudo cuando realizo formaciones o consultorías en Scrum:

¿Por qué los roles de Scrum Master y Project Manager deberían ser llevados por personas diferentes? (Quora)
¿Será el Scrum Master una ocupación al 100% o puede un programador ocuparse de ello si tiene mucha experiencia en planificación ágil? (Quora) 

Tras estas preguntas está la suposición de que el Scrum Master no es un rol a tiempo completo. Quien hace esas preguntas conjeturan con la posibilidad de ahorrar dinero juntando dos roles en una sola persona.

Las preguntas son realizadas por novatos como Scrum Masters, por product owners, por miembros del equipo, por managers, por stakeholders de cualquier tipo. De los tres roles en Scrum, todos parecen inferir inmediatamente que ser miembro del equipo es un trabajo a tiempo completo -por que desarrollan software el día completo - y que ser un product owner es también a tiempo completo - por que desarrolla el producto todo el día-, pero parece difícil de imaginar cual es el trabajo de un Scrum Master pueda ser y el por qué diablos sería un trabajo a tiempo completo, también.

¿Quizás esos que preguntan no sepan que es lo que un scrum master hace todo el día?

Aquí presento una lista de 42 cosas que diría que son parte del trabajo de un scrum master:

Reuniones
- Facilitar reuniones para el equipo. Esto incluye:
   - Preparar
   - Moderar
   - Postprocesar
 - Realizar retrospectivas, que son especiales, por consiguiente las cuento separádamente.

Dinámicas de equipo
 - Realizar coaching a los miembros del equipo (p. ej. coaching 1a1)
 - Mediar en los conflictos
 - Ayudar al equipo en la toma de decisiones
 - Fomentar la auto-organización del equipo
 - Mediar en el conflicto de objetivos entre el equipo de desarrollo (alta calidad técnica) y el product owner (más funcionalidad)

Aprendizaje
 - Continuar aprendiendo todo lo relativo a Agile (p. ej. visitar grupos de comunidades, atender a conferencias, leer libros, escribir blogs,…)
 - Asesorar a los miembros del equipo en todo lo relacionado con Agile.
 - Ayudar al equipo a crear radiadores de información.
 - Dar feedback al equipo.
 - Fomentar el uso de prácticas de ingeniería ágiles dentro del equipo de desarrollo (esto es un enorme trabajo para invertir el tiempo de un Scrum Master, incluyendo por ejemplo, publicación/releases automáticas, entrega continua, TDD, y muchos más).
 - Desafiar al equipo con nuevas ideas sobre Agile Management (p. ej. FedEx -Days).
 - Colaborar constantemente con otros Scrum Master en la organización (p. ej. a través de la comunidad de práctica).
 - Bajar al Gemba.

Producto
 - Ayudar a escribir o dividir historias de usuario.
 - Ayudar a escribir o adaptar la visión del producto.
 - Ayudar a ordenar los elementos de la pila de producto.
 - Ayudar con la planificación del sprint.
 - Estar familiarizado con el trabajo del equipo (p. ej. el producto)

Visión general
 - Juntar a la gente que debería hablarse entre ellos.
 - Estar en contacto con los stakeholders regularmente.
 - Ayudar al equipo a informar a management.
 - Ayudar a fortalecer la comunidad ágil dentro de la organización
 - Organizar eventos de intercambio como Open Spaces o World Cafes para el equipo, stakeholders y el resto de la organización
 - Compartir ideas y análisis en la compañía (micro-blogging, blogging, conferencias internas,…)
 - Ser la persona de contacto para todos en el equipo y los stakeholders en todo lo concerniente a Agile. 
 - Dar oportunidades de aprendizaje a la gente en la organización (p.ej. charlas o talleres) y permitirles aprender conceptos Agile importantes como p.ej. la deuda técnica.

Cambio
 - Ayudar al equipo a eliminar impedimentos.
 - Sugerir nuevas métricas para el equipo como catalizadores del cambio

Espejo
 - Reflejar los valores ágiles y de scrum al equipo.
 - Recordar al equipo sus acuerdos (p.ej. políticas)
 - Ayudar al equipo a mejorar constantemente sus procesos.
 - Reflejar los problemas al equipo a través de la observación desde fuera.
 - Hacer preguntas abiertas.
 - Comprobar los modelos que usa el equipo (p.ej. sprint backlogs, métricas, etc.) y mostrarles las diferencias entre el modelo y el mundo real.

Varios
 - Ayudar al equipo a mantener el foco (p.ej. actuando como un buffer entre las distracciones externas y el equipo)
 - Ayudar al equipo a mantener sus herramientas scrum (paneles, pilas de acciones, gráficas, backlogs,…)
 - Ayudar al equip y el product owner para encontrar los adecuados:
    - Definición de terminado (DoD).
    - Definición de preparado (DoR).

¿Has hecho o considerado todo lo mencionado anteriormente? Tomate un respiro, ¡debes estar agotado!



     Creemos que el scrum master es un rol a tiempo completo para una persona en un equipo Scrum. Scrum Master Manifesto.

octubre 13, 2013

CAS2013: Scrum y management, ni cerdos ni gallinas.



La metáfora de los cerdos y las gallinas es un drama. Y afortunádamente se dejó de usar en la guía de Scrum. Como chiste pase, pero diferenciar entre comprometida e involucrada en un proyecto, diferenciando su grado de compromiso es un poco anti-colaboración. Y con esos nombres... ¿algún cerdo en la sala? :\

Una de las gallinas es la capa de management, así que se supondría que no están comprometidas (sic) con los resultados de los proyectos (¿suena absurdo verdad?). 
  • Henry Fayol – “Gestionar (management) es prever y planificar, organizar, mandar, coordinar y controlar”
  • Control y gestión de los recursos de una organización para producir valor a los clientes
  • Managers are the people who interrupt the ones working. Jason Fried (37 signals)
  • Hay opiniones para todo, en general, Management es lo que hacen los managers. Así es más sencillo. Cada organización es un mundo
Ahora llegamos con una herramienta: Scrum. Que es el gran descubrimiento para el management. Lo dice Forbes nada menos, hace ya casi 3 años. ¡Ya les costó darse cuenta! ;) PERO, pero, hay algo que a veces no encaja… ¿qué tiene Scrum que no es una herramienta tan sencilla de utilizar en las organizaciones actuales?

Por alguna extraña razón la metáfora es entendida de otra manera. Y ni unos ni otros están del todo contentos con la nueva situación. El cambio de una mentalidad "command&control" a una verdadera autoorganización no es fácil, y no sabemos cómo usar esta nueva herramienta.
En general:

 - Mira la película completa, no microgestiones el equipo, sin tener en cuenta las influencias externas. El impacto en la organización completa.

 - Sal del edifico. Baja y comprueba in situ qué sucede, a la gente usando Scrum, a los equipos, a los usuarios, a los clientes,… ¡pasea por el gemba!

 - Cambia el foco: la gente sabe cómo definir procesos, planes y todo eso… eso es fácil. Cambia tu foco a las personas, mira si hay colaboración, comunicación, entendimiento,…

Así que si como manager quieres usar Scrum, ¿dónde te colocas?

- Si pasas a set product owner… o mejor no. NO lo hagas. Parece el camino más natural, pues controlas releases, planificaciones, hablas más con los usuarios, stakeholders, etc. Pero ser jefe de equipo, y product owner desequilibra la balanza PO <-> SM. Totalmente. Si no tienes tiempo para algo, será el equipo el que lo sufra. 

- Si eres un manager externo al equipo, y este cuenta con su PO y su SM, puedes tener la sensación de "y ahora, ¿qué hago?" Pero si la organización está arrancando con Scrum es fundamental su protección y ayuda al scrum master a que no se de cabezazos con el resto de la organización. Que el equipo no pierda de vista el propósito de lo que está haciendo. Ayúdales en eso.

- Si eres un manager de varios niveles superiores, pasea por el gemba, baja a ver qué sucede, atento a lo que suceda en los equipos scrum, las personas alrededor de los equipos en otras áreas de la organización, identifica a tu equipo de trabajo y trabajad para mejorar el sistema, y apoyar aquello bueno que emerja.

 - Si eres jefe de equipo, el paso lógico es ser scrum master. Recuerda, equipo = producto. Trabaja en el equipo. Cambia de chip, prueba la autoorganización, ayúdales… y dales espacio.

 En definitiva, una  organización que empieza a hacer Scrum requerirá que el management se centre en las personas y el sistema completo, y no luche contra la organización si no que colabore, haga amigos, y la transforme.


* Nota, hablo de Scrum como una herramientas… y en realidad NO lo es. Es mucho más, incluye valores, principios, cambio de mentalidad… ¡¡por eso es difícil!!


Visión personal de la CAS2013

La conferencia Agile-Spain 2013 ya ha sucedido.

Echando la vista atrás ya se han olvidado los ratos (largos) haciendo facturas, comprando billetes de avión, reservando hoteles, el esfuerzo de un equipazo de organización,… 

Ahora recordaré a la inspectora de la fundación tripartita y la casi-evacuación masiva del edificio donde tomaba lugar la conferencia (!), las risas del equipo de organización, la brillantez y calidez de los keynotes, el abrazo con Tobias Mayer, la cercanía de Koldo Saratxaga, la amistad de Ángel Medinilla, las numerosas gracias recibidas desde los asistentes, las sonrisas cómplices con los amigos que desde lejos te buscaban a ver si necesitábamos ayuda, las amistades que nacen y crecen en estas ocasiones, las cervezas con compañeros de viaje, y... más cosas ;)

Me dolerá de esta conferencia el tiempo robado a mi familia, el no habernos acordado de los vegetarianos para el catering, el no haber compartido más tiempo con viejos amigos, y el hecho de que no acabe la burocracia en el mismo momento que termina el evento :)

Y celebro haber ayudado a la comunidad, haber colaborado en el camino hacia la maestría de tanta gente, a que los asistentes disfrutasen de dos días alrededor de un tema que nos apasiona.

Equipo organización CAS2013



Así que debo agradecer esos ratos a todos y cada uno: Aitor, Iñaki, Abdul, Frank, Vicenç, Bea, Anaje, Gorka, Cristina, Joseba,… y a esos alumnos de la universidad, que lamentablemente me acabo de dar cuenta no sé ni sus nombres. GRACIAS.

mayo 23, 2013

Estimación ágil de proyectos (y 2): Equipo multiproyecto.

Hablábamos el "otro día" sobre la planificación ágil, y explicábamos el proceso para estimar un proyecto, y ver su evolución. Trabajábamos con la hipótesis de que era un proyecto para un equipo, un entorno que no siempre se da en las empresas.
El mecanismo que aplicamos en un entorno multiproyecto es básicamente el mismo, pero contamos con una nueva incógnita: la dedicación del equipo a cada proyecto.

Sabemos lo perjudicial que es para nuestra cabeza la multitarea, lo negativo que es para un equipo el multiproyecto y lo fatal para una organización la pérdida de foco y capacidad de ejecución. Sin embargo, en muchos entornos, se sigue empezando cualquier proyecto que se nos pase por la cabeza, antes que priorizarlos claramente y dedicar energías a aquello que nos aporta más valor. Este es un tema muy importante, y que influye poderosamente en la capacidad de trabajo de una organización.

Así que, si trabajas en un equipo multiproyecto, las posibilidades de tener un buen lío son abundantes. Y la estimación va a depender tanto o más de gerencia como del equipo. ¿por qué? Simplemente por que si la dedicación no es conocida, o no es sostenida, no puedes estimar. Así que añadimos una nueva hipótesis a la hora de dar fechas. Y es arriesgada, probablemente no cae en la responsabilidad del equipo.

Si decides trabajar en multiproyecto (recuerda, es una decisión, quizás no es tuya, pero es de alguien) a la hora de estimar, deberás asignar un porcentaje de dedicación a cada proyecto. Si tienes datos históricos de porcentajes de puntos historia por proyecto, te podrán ayudar a trabajar con una hipótesis lo más cercana a la realidad posible.



febrero 25, 2013

Próximos cursos Lean/kanban: Madrid y San Sebastian

En Abril, Ángel Díaz Maroto y yo, vamos a impartir dos cursos de Lean/Kanban. En Madrid, y además esta vez lo acercamos un poco por País Vasco, que parece que nunca se hacen cosas interesantes por aquí ;).
Las fechas y la información son:

Kanban es un sistema construido sobre los principios del pensamiento Lean. Este método nos ayuda a implantar un sistema de mejora continua de los procesos, y crear espacios de colaboración y transparencia. En su vertiente de gestión de proyectos nos guía para maximizar el valor entregado, eliminar los “desperdicios” y mejorar nuestra organización paulatinamente.
  • Kanban se orienta a la entrega continua de valor.
  • El trabajo y su flujo de proceso se hacen visibles. 
  • El trabajo en progreso se limita, y nos centramos en eliminar los problemas, y nos centramos en terminar trabajo, en vez de costosas multitareas y cambios de contexto.
  • Kaizen. Las mejora continua es parte del propio sistema.
El método Kanban es una aproximación a un proceso de cambio evolutivo e incremental para las organizaciones.

¿Dónde puedo utilizar kanban?

  • Proyectos y equipos de desarrollo de software.
  • Gestión de proyectos de gestión del conocimiento.
  • Pequeñas y grandes organizaciones.
  • Areas de soporte o servicios.

¿a quién le interesa este curso?

  • Jefes de proyecto y equipo
  • Gestores de áreas de servicio y soporte.
  • Miembros de equipos que quieren mejorar su efectividad.
  • Miembros de equipos Scrum que quieren seguir aprendiendo y mejorando.

¿por qué debería asistir a este curso? ¿qué aprenderemos?

El curso presenta de manera práctica los conceptos, y es impartido por personas con experiencia en proyectos reales. Los asistentes al curso serán capaces de iniciar una implantación del método Kanban en sus organizaciones, aplicando las nociones aprendidas.

Contenidos del curso:

  • Principios Lean
  • Kanban como herramienta de visualización y soporte a la colaboración
  • El método Kanban como proceso de mejora evolutivo.
  • Identificación de los "desperdicios" de Lean.
  • Patrones de diseño de procesos.
  • Patrones de colaboración alrededor de kanban.
  • Teoría de las limitaciones de Goldratt, cuellos de botella en los procesos.
  • Métricas
  • Implantación en las organizaciones.

febrero 10, 2013

La estimación ágil de proyectos, puntos-historia y velocidad

Uno de los temas más recurrentes, y que causa más dolores de cabeza es la estimación de proyectos. Trataré de explicar mi visión al utilizar una posible técnica: la estimación por puntos-historia utilizado típicamente en algunas de las metodologías ágiles.

Dejamos aparte por ahora el nirvana de no tener que estimar. Si ya has conseguido no tener la necesidad de estimar, enhorabuena, tus comentarios sobre el proceso serán bienvenidos :) A los demás: todo llegará ;)
Supongamos que en un determinado momento nos llega un proyecto, una visión, y nos hacen la pregunta del millón ¿para cuando estará? y sobre todo, ¿cuanto va a costar?
Es entonces cuando el equipo suspira, mira al techo, y tras asegurar que lo que vas a dar es una estimación aproximada, se pone a trabajar. Porque tus estimaciones las hará el equipo que va a hacer el trabajo, ¿verdad? ^_^

Historias de Usuario: Colaboración,
planificación, y requisitos. 

1) Obtención de las historias de usuario del proyecto

  Debemos averiguar con precisión aproximada lo que hay que realizar en el proyecto. Pero, ¿aproximada? Ten en cuenta que nunca nunca nunca se puede definir un alcance de un proyecto de manera cerrada y completa. Así que no merece la pena intentarlo. Hay que hacerse el suficiente detalle por si alguien necesita calcular el ROI o la inversión a realizar aproximado. Pero también hay que hacer ver que sabemos que va a haber cambios que imposibilitan la certeza absoluta. Y que desconocemos el el inicio de un proyecto, el alcance real. Recordad el cono de incertumbre.
 Con una visión de proyecto necesitamos hacer dos cosas: un Inception para bajarla a tierra y empezar a crear visión compartida. Y los talleres de historias de usuario que sean necesarios para generar un backlog con el que gestionar el alcance del proyecto. En este punto debes valorar el tiempo invertido en detallarlas. Es más importante lograr el máximo despliegue de historias que profundidad en cada una. Una gran técnica son los mapas de producto.

2) Aplicar la vara de medir del equipo

Planning poker
 Ahora debemos medir lo que queremos construir para saber cuando podemos terminarlo. No podemos decir el tiempo que podremos hacer en una carrera, si no sabemos la longitud de la misma. Asignar puntos en realidad no es estimar una historia, es solo medirla. Establecer el acuerdo por el que el equipo decide qué tamaño tiene. Esta es la razón por la que posteriormente las velocidades no son comparables entre equipos, simplemente porque cada equipo tiene su propia vara de medir. Y es subjetiva.
 ¿Te puedes equivocar asignando tamaños? Sí, pero NO. :) En realidad no importa mucho si te puedes equivocar o no. Lo importante es que seguro que te equivocas siempre de la misma manera, y eso nos dará predecibillidad. Asignar tamaños relativos nos ayuda a acertar por comparación, de manera que no nos hace falta demasiado detalle en cada elemento para relativizarlo unos respecto de otros.
 En mi experiencia funciona mejor crear una escala de tamaños de historia de usuarios relativa, ordenándolas de mayor a menor, y posteriormente asignándoles los puntos del "planing poker". Ver historia a historia, de una en una, y asignándole tamaños individualmente, genera reuniones tediosas y donde perdemos la visión comparativa entre historias.

3) Estimar la velocidad

 Es en este momento cuando realmente hacemos una estimación, respondiendo a la pregunta: ¿a qué velocidad avanzará este equipo en este proyecto? Esta es la verdadera piedra angular de la estimación y que nos dará como resultado una posible planificación temporal.
 La situación ideal se da en un equipo que tiene históricos anteriores. Guardamos las velocidades anteriores de los proyectos, y si el proyecto se da en condiciones parecidas, ¡la velocidad anterior la podemos proyectar al futuro!
 Cuando no tenemos históricos, es cuando realmente hacemos una estimación compleja. ¿cuantas historias de las definidas anteriormente creemos que podemos hacer por sprint? ¿vamos a ir más rápido o más lento construyendo el software? El equipo debe calcular cuanto será capaz de hacer por sprint, para estimar la velocidad. Juega siempre con un rango, una estimación pesimista y otra optimista. Es más fácil así dejar claro que es una estimación, y que puede tener un error.

4) Planificar

Índice de mi formación en Historias de Usuario.
 NO todo en esta vida, ni en los proyectos, son historias de usuario. NO intentes hacer que lo sean. A veces ;) hay que realizar formaciones, instalaciones de entornos, hacer spikes, etc. Hay que tenerlas en cuenta para calcular la fecha final, por si hay que sumar al tiempo de desarrollo, obviamente.
 Dada la velocidad y el tamaño del proyecto podemos hacer una simple regla de tres para conocer una posible planificación, entre la velocidad optimista y pesimista. Número de puntos totales dividido por la velocidad por iteración = número de iteraciones. Sumando imprevistos y cualquier cuestión que quede fuera de historias de usuario, tendremos nuestra primera aproximación al proyecto.

5) Asumir la realidad

 Esta es la parte más difícil de todo el proceso. Deja que el proyecto/producto evolucione y adáptate a los que vaya sucediendo.
 ¿el proyecto marcha a menos velocidad de la estimada? Calcula los nuevos costes, ¿son aceptables? ¿debes cortar en el alcance?
 ¿Surgen problemas que no habías previsto? Actualiza lo que vaya a afectar a la velocidad. ¿o necesitas nuevos perfiles? Actualiza el coste... compara la velocidad real con la planificada continuamente.

 En definitiva, no dejes que tu maravilloso plan arruine la realidad. Haz un chequeo a nivel global tras cada iteración, y no caigas en el optimismo de "ya mejoraremos" si tu gráfica de burn-down te dice que no hay tutía.






enero 18, 2013

Retrospectiva, un año


El año pasado me decidí finalmente a dar el salto al autoempleo. El día 18 de Enero ha hecho un añito. La verdad que Biko es un gran lugar para trabajar, pero tenía ganas de "ver mundo". Ganas de ayudar a más gente con lo que los últimos años creo que he hecho bien, con lo que he aprendido, y probar si me podía ganar la vida con ello.

El resumen muy rápido-rápido es: Ya sabía que iba a ser difícil, pero no tanto. :( Ya sabía que iba a ser divertido, pero no tanto. :)

La verdad que he repasado el 2012 y he hecho muchísimas cosas interesantes y he aprendido mucho, he cometido algunos errores, he disfrutado más tiempo con mi familia, y he sufrido algunas veces con mis propias decisiones. Ha sido un año apasionante en lo personal, pero eso es otra historia, algunas de las cuales no podría contar aquí. ;)

El pequeño paréntesis en eso, lo único, mi pequeño homenaje a Itsaso, que se merece con certeza mucho más de lo que le doy, y que me da una confianza sin la cual todo esto no habría sido posible. :')

Empecé el año con mucha fuerza, llegando a un acuerdo con mis amigos de Biko, que me respaldaba buena parte del año. Sin duda me daba tranquilidad, aunque también he de decir que me embotó un poco, e inicie las acciones adecuadas a la búsqueda de nuevos clientes demasiado tarde.
Una de las mejores cuestiones que han sucedido, son la gran red de profesionales y amigos con los que voy coincidiendo. La gente, al saber de mi nueva aventura profesional, se interesaron, y de hecho los primeros trabajos fueron todos por estas redes de colaboración. Gracias a todos los que en algún momento me habéis apoyado. 
He hecho bastantes temas de formación, hice un curso de coaching, asistí a la CAS2012 y AOS2012, he leído más libros que nunca sobre mi trabajo, asistí al taller de Betacodex y he compartido horas de vuelo con compañeros increíbles como X. Quesada, Ariel Ber, Leo Antolí o Jorge Uriarte.

Sobre el propio trabajo han sido retos que no esperaba. He estado 4 meses programando en Ruby on Rails. Resulta ¡que no he trabajado casi nada con Scrum! Kanban se ha llevado todo el éxito este 2012, aunque en realidad, yo siempre hablo de lo mismo: principios y valores, aprendizaje y adaptación.
Si he subido grandes cimas, ha sido
gracias a muchos apoyos.

Mi plan de marketing incluía crear mi propia marca, imitando un poco a Teresa ;) con Skok. Me parecía que podía ser como una herramienta útil de posicionamiento. Lo tenía todo preparado para lanzar Ynspira. :) (me encanta el nombre, y me lo guardo para otra ocasión). Pero algo se cruzó en mi camino: Agilar. La idea de una organización en construcción, que sería como la construyésemos, y la persuasión de X. Quesada ;) finalmente hicieron que me uniese a ese nuestro proyecto. Es cierto que todavía es una cosa un poco rara (como organización) pero por eso es genial. Le vamos dando forma poco a poco. Ahí he podido coincidir con Ariel, Leo, Xavi, Alan, Ángel, Tiago o Enrique. Y estoy aprendiendo mucho con ellos.

Bueno, vamos a lo mejorable de este año, que si no esto no sería una retrospectiva:
  • La búsqueda de nuevos cliente es hoy por hoy mi principal problema. Mi asignatura pendiente es mi propia zona, el País Vasco. Cuando trabajas, no siembras. Y eso se nota después. Debo afilar más mi hacha comercial :S
  • Los problemas de liquidez se me han agravado este fin de año, debería haberlos previsto. Y mira que es un clásico entre los autónomos! :\
  • Debo arriesgarme más con mis decisiones, mostrarme más como creo en las cosas. Creo que a veces me vence "el lado tradicional" y probablemente deba arriesgar más.
  • La decisión de los precios. Darle vueltas a los precios me rompe la cabeza. Esto es algo que tengo que establecer con más claridad. Pero tengo la impresión que hay sitios donde aporto más valor que en otros, ¿por qué no debería cobrar entonces diferente? Esto merecerá un post más adelante.
  • Mis ingresos reales han bajado respecto cuando era empleado por cuenta ajena, así que debo conseguir mayor facturación. Uno de mis objetivos también es ganar más dinero.
Y lo que más me ha gustado:
  • El curso con Ariel Ber de Agile Coaching. Espero que lo repitamos pronto. Hasta me hizo dibujar. ;) Y el primer CSM de co-trainer con X. Quesada, que es un crack.
  • Unirme al equipo de Agilar. Así como ratificar que el futuro está en las redes de colaboración, más que en las organizaciones formales. Conocer tanta gente.
  • Las charlas en la universidad con Jessi. Hay que evangelizar, y cuanto antes mejor :)
  • El foro de Adegi de emprendedores también ha sido un descubrimiento interesante.
  • Este año además volví a trabajar con mi coach. Y si me lo puedo permitir lo volveré a hacer en el 2013. Creo que ha sido una cuestión que me ha ayudado mucho.
  • Salir de mi zona de confort, taaantas veces. ¡Pero si en uno de mis primeros clientes ni siquiera desarrollaban software! Por cierto, genial ese proyecto y me consta que están muy contentos con los cambios. :)
 Gracias a un montón de gente por estar ahí. A algunos os he mencionado, a otros os he puesto alguna referencia que solo entendereis los aludidos ;) Pero ha habido mucha gente más este año que ha sido increíble. Gracias. Me acuerdo de todos :) 
 Y gracias especialmente a los clientes que este año han confiado en mi.
 El 2013 va a ser difícil, algo así dicen en las noticias todos los días, ¿no? Deje de leerlas el día que me puse a trabajar por mi cuenta, que para agobiarme ya me valgo solo demasiadas veces. Feliz año a todos. :)

enero 10, 2013

6 tendencias para el 2013 en "Project Management"

Me he quedado con una sensación rara tras leer este artículo del ESI. Y realmente no sabía muy bien por qué, creo que no lo llego a entender del todo :\. Así que he decidido que iba a escribir las tendencias que yo veo en la gestión de proyectos alrededor de mi, y posteriormente compararlas:

Mis predicción de tendencias en gestión de proyectos para este año (y "ad infinitum") son:

  • Las organizaciones se darán cuenta que no vale con tener líderes (expertos, PMs, ScMs,...), sino que hay que crear verdaderos equipos.
  • Algunas organizaciones triunfarán con la implantación de Agile, y se comerán a las que no consigan adaptarse. Otras fallarán, indudablemente.
  • Desaparecerá la "responsabilidad individual" de la gestión de proyectos: habrá que equipos, que simplemente, sepan -aprendan- lo que tienen que hacer para lograr el éxito.
  • Las PMOs desaparecerán para ceder el control de los procesos a la gente que realmente sabe de ellos, los que lo ejecutan. Existirán comunidades de práctica mejorándolos.
  • Los grandes proyectos plantean retos únicos que son cada vez más difíciles de superar. Sí. Debes contar con las armas adecuadas: gente motivada :)
  • Los "gestores de proyecto" irán dando paso paulatinamente a "facilitadores de valor para la organización". Se verá el sistema, no cada proyecto peleando por "los recursos", no habrá que gestionar  un portfolio, solo sumar valor.


No sé parecen mucho a las del ESI. Pero con eso me quedaría más tranquilo. Y además, se empiezan a ver alrededor.