CAS2013: Scrum y management, ni cerdos ni gallinas.

Scrum y management: ni cerdos ni gallinas. from Jose Ramón Díaz

Puedes ver el video: Joserra Díaz, scrum y management.

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!!

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:

• Lean/Kanban en Madrid, 15-16 Abril (ATENCION, que las fechas han cambiado).
• Lean/Kanban en San Sebastian/Donostia, 25/26 Abril.

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.

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.

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.

El mito de la organización ágil (presentado en la CAS2012)

Este post es la explicación de mi presentación en la conferencia Agile-Spain 2012. Podeis encontrar la presentación en slideshare: El mito de la organización ágil.

Cuando hablamos de organizaciones ágiles, podemos hablar ya de varios modelos sobre los que se está trabajando, como por ejemplo:

• La organización conectada, de Dave Gray. Nos muestra una organización como una serie de células, equipos aut
• El modelo de BetaCodex, de Niels Pflaeging, en donde insiste en que el management es innecesario, y habla de dos niveles, donde unos atienden al mercado, y otros dan servicios centrales, también como organización de equipos autoorganizados.

Sin embargo, no es de los modelos de lo que quiero hablar, si no de lo que nos mueve a hablar de organizaciones ágiles. A pequeña escala, a mi me transformó la idea ya comentada en este blog de que Equipo = Producto. Esta simple igualdad me hizo cambiar el chip, como responsable de equipos, desde la visión de construir software, a construir equipos capaces de hacerlo. Y ser consciente que lo bueno que fuesen los equipos, así sería el producto que produjesen.

A nivel organizativo podemos escalarlo exactamente igual, y ya había una Ley que lo enunciaba:

Ley de Conway:
Las organizaciones que diseñan sistemas están limitadas a producir diseños que son copias de las estructuras de comunicación de estas organizaciones.

Es decir, si tu organización es una basura, solo generará más basura.

Todos conocemos casos donde las organizaciones son el principal problema de la gente que se encuentra dentro de ellas. Solo tenemos que echar un vistazo a TrabajoBasura.com para observar cómo se han convertido en un verdadero problema para muchas personas.

¿qué clase de decisiones toman las organizaciones de hoy en día que nos han llevado a tenerlas como fuente de muchos problemas? ¿cuando descolgarán el teléfono de su conciencia?

NUNCA. Nunca lo harán, básicamente, por que las organizaciones NO existen. No hay nada en lo que nos podamos excusar para hacer/no hacer algo echando la culpa a una "organización". No hacemos nada por la "organización". Como ente jurídico tendrá algo de sentido, pero no en realidad, es solo una abstracción, una metáfora. ¿dónde está la organización en vuestras reuniones?

Una organización está compuesta "simplemente" de RELACIONES. Tenemos que entender qué ata a las personas para actuar cómo actúan  Entonces empezaremos a comprender ese sistema que llamamos organización. Estamos atados a otras personas, a hechos sucedidos o por suceder, y a sentimientos como el miedo o la ilusión. Esa maraña de hilos forma un sistema complejo que debemos tratar de cambiar, actuando sobre las relaciones tanto como sobre las personas.

Generalmente las organizaciones parece que nos arrollan cuando queremos realizar alguna iniciativa de cambio. Debemos conocer qué ata a cada persona dentro de un sistema para poder entenderla. Movernos a una organización ágil no será cuestión tan simple como implantar un modelo o metodología. Igual que implantar Scrum en un equipo no es tan solo hacer las reuniones y artefactos, una organización ágil debe compartir misión, principios y valores:

• Una misión: Las personas necesitamos saber el POR QUÉ. Aquello que nos mueve y nos guía. Una misión compartida creará una dirección por la que identificamos que debemos movernos. Y puede haber varias escalas de misiones, como cuando en mi pequeño equipo en Biko hacíamos retrospectivas anuales para decidirlas, o les ponía retos como convertirnos en el "mejor equipo de desarrollo de Gipuzkoa"
• Con autonomía y respeto: La autonomía es básica para poder llegar a tener equipos autoorganizados, y el respeto la base para ello. Desarrollar productos debe empezar por desarrollar y permitirle hacerlo a las personas involucradas. Son la gente que debe aprender. Se deben crear equipos capaces de definirse sus objetivos, y capaces de conseguirlos.
• Sumando diferencias: La creatividad juega un papel muy importante en nuestras organizaciones hoy en día. Nunca sabes quien puede aportar la idea brillante o sorprendente. No solo ya las cuestiones técnicas son básicas, si no que las habilidades sociales se han vuelto imprescindibles en la nueva economía.
• Con absoluta transparencia: La transparencia se convierte en una vara de medir. Si algo te da miedo a ser transparente, es posible que no vaya alineado con una organización ágil. Es un valor básica para la autonomía de los equipos, para que la información fluya entre todas las relaciones personales sin crear silos ni malentendidos.
• Donde el dinero es una consecuencia: Las organizaciones deben ser rentables y conseguir beneficios, ¡sin duda! Estamos diciendo que la consecuencia de gente motivada, con una misión, trabajando por resultados, que se autoorganiza, va a ser conseguir beneficios.

Las personas que trabajamos en un entorno como el desarrollo de software, nos vemos completamente influenciadas por el entorno en el que lo hacemos. De hecho, creo que somos el sector laboral en el que más nos afecta. Nuestro trabajo es el más intangible, y el menos técnico en realidad (¡de verdad!). La mayoría de nuestros problemas en los proyectos no son técnicos, son sociales, de comunicación, de colaboración. Y es por ello que el mundo "Agile" se está volviendo tanto hacia las organizaciones.

Y debemos mirar también alrededor nuestra, y sumar fuerzas con muchos movimientos que vienen hablando de las nuevas formas organizacionales desde otras perspectivas. Creo que será enriquecedor para todos conectar con las ideas de Lean, Worldblu o Koldo Saratxaga entre otros.

Mención especial merece, bajo mi punto de vista, el llamado "Culture Hacking". La idea es que el mismo movimiento ágil es un hack de la cultura: procedimientos y valores que podemos usar para cambiar nuestras organizaciones.
En definitiva, las organizaciones ágiles quizás no se diferencien demasiado en su estructura organizativa de las actuales (que lo harán), si no por el cambio de mentalidad en la búsqueda de la creación de equipos autoorganizados, en la visión de cada y una de las personas del sistema global, y en métricas añadidas a las financieras, como la satisfacción de cualquier persona relacionada con esa organización, interna o externa. No importará el "dibujo" de tu organización, si no el tipo de relaciones que vamos a crear diferentes entre las personas.

No olvidemos que podemos cambiar aquello que nos incomoda o molesta, mejorar nuestro mundo alrededor. Espero veros en la CAS2013 ;)

Próximos talleres en Pamplona: Lean/kanban y Retrospectivas

ACTUALIZACIÓN FEB. 2013: Cursos de Lean/Kanban en San Sebastian y Madrid.

En Noviembre hemos organizado junto con CEIN dos diferentes talleres, de una mañana de duración, sobre temáticas ágiles.

Taller Lean/Kanban
El primer taller se realizará el 9 de Noviembre, sobre Kanban. Veremos cuales son los conceptos que podemos aplicar de esta metodología de manera práctica. Hablaremos sobre los principios ágiles y Lean, realizaremos una simulación, dibujaremos nuestro panel kanban... todo en 6 intensas horas de aprendizaje y experiencia.
Puedes encontrar más información e inscripciones en la web de CEIN.

Taller de retrospectivas eficientes
El segundo taller es el día 28 de Noviembre y girará alrededor de las retrospectivas y la mejora continua de los equipos. Veremos técnicas y tácticas para esta reunión tan importante en los equipos ágiles. Se tratará de aprender nuevas maneras de realizar retros, mejorar la efectividad de las mismas, y comprender la importancia de generar aprendizaje de manera constante en los equipos.
Puedes encontrar más información e inscripciones en la web de CEIN.

Si llevo Kanban, también llevo los principios ágiles

Recientemente se está hablando de si kanban es una metodología ágil o no. Creo que la primera vez que me lo plantee fue al leer una serie de magníficos posts de Michael Sahota sobre la cultura de las organizaciones.

NOTA: Es realmente curioso que un tema tan específico haya llegado a una revista como Forbes. Steve Denning, al que debeis seguir atentamente si no lo haceis ya, está "fusilando" las ideas de Agile, pero moviendolas exactamente allá donde las necesitamos: en el mundo fuera de IT, hablando a la gente de siglas raras (CEOs, CTOs,...) y el resto de "managers" que no entienden el mundo IT.

M. Sahota empezó identificando los principios ágiles sobre una clasificación de culturas organizacionales.

Este modelo, de William Schneider, tiene dos ejes, uno para la orientación a realismo/posibilismo y otro para la orientación de orientación a las personas o a la compañía. Sahota clasifica las regiones COLABORACIÓN y CRECIMIENTO como las que encajan con la cultura Ágil. En resumen, establece los principios alineados con la cultura más adecuada a cada uno de ellos, y es donde se situan la mayoría de los 12 principios del manifiesto.
Posteriormente analizó kanban como metodología, aplicando el mismo sistema, y Kanban según él, pertenece a al cuadrante de CONTROL.

 Se centra en el sistema, en los procesos, y únicamente hace una pequeña (aunque importante) referencia a mejorar colaborativamente. No quiere decir esto que kanban no pueda dar soporte a los principios ágiles, todos tienen cabida.
La clave para mi es la siguiente: Una vez comenté en un tweet, imposible de encontrar ya :(, que Kanban bien hecho llevaría a terminar haciendo Scrum. Por supuesto hablaba del desarrollo de producto, donde encaja muy bien Scrum. Pero a lo que realmente me refería, es que no concebía kanban sin aplicar los principios ágiles. Buscando la mejora continua con los valores y principios ágiles, en los cuales Scrum se fundamenta. Sin principios ágiles no hay Scrum. Sin embargo, sí podrías hablar de kanban sin esos principios.

En realidad, kanban, como todas las herramientas es absolutamente agnóstica en cuanto a principios y valores. Más de una vez he insistido en la idea que podría parecer que hacer Scrum, sin hacerlo realmente. Si utilizas las reuniones, roles y artefactos de Scrum, pero no buscas la aplicación de los principios en los que se basa, no estás haciendo Scrum.

 Así que cuando voy a trabajar con un equipo que utiliza o empeiza a usar kanban, siempre llevo en la maleta los principios ágiles. El concepto de la gestión del flujo de trabajo y minimizar el trabajo en progreso de kanban, más los principios ágiles que nos guíen en nuestra mejora continua, crean una combinación ideal: un punto de partida muy útil para aquellos equipos que por las razones que fuera no pueden o no quieren empezar a trabajar con Scrum.

 Actualización Enero 2013: Un enlace interesante con la misma idea: Kanban Values or How I Almost Attacked a Manager With Hot Coffee

 Actualización Noviembre 2018 (!): Mi última visión sobre los principios ágiles. ¿los hemos perdido?

 Actualización Diciembre 2018: Sobre el Agile Manager.

Agilar: jugando en equipo

Uno de los comentarios más certeros sobre mí, me lo dijo un buen amigo al decirme: "Tú eres un jugador de equipo". Esto dicho cuando te acabas de poner como freelance para buscarte la vida por tu cuenta, puede sonar a golpe bajo (¡ouch!), ¿para que quieres tener un coach personal teniendo amigos así? :) Pero en realidad, no le faltaba razón.
Lo cierto es que me gusta trabajar en equipo. Compartir los objetivos. Compartir las alegrías y problemas del camino. Ayudar. Y es algo que cada vez iba a hacer menos trabajando por mi cuenta. En realidad, me han salido muchísimas colaboraciones y propuestas con más personas. Pero cada vez, las decisiones y los objetivos eran más individuales.

Así que ahora, al cruzarme con un proyecto para trabajar en equipo (¡y vaya equipo!) no me ha costado demasiado trabajo decidirme. Me uno a Agilar para continuar desarrollando mi camino como "Agile Coach". Agilar está en un momento muy interesante, reinventándose como organización. Tenemos mucho trabajo por delante para crear la clase de organización que se adapte al agilismo y a nosotros. X. Quesada lidera la idea de crear la organización que este fundada por los valores ágiles. No podría estar más de acuerdo :)

Sigo siendo autónomo, freelance. Tengo muchas colaboraciones entre manos, independientemente de este proyecto todavía. Dependo de mis propios pasos para llegar donde quiero (como todos en realidad, ;) supongo...). Pero ahora juego en equipo.

Open Space, para un roto o para un descosido

NOTA: Estoy escribiendo la guia de facilitación de Open Space.

Hemos hablado varias veces aquí ya de los Open Space como un formato increible para la organización y facilitación de conferencias. En Agile-Spain hemos organizado ya tres a nivel nacional, y han surgido multitud de pequeños "opens" para tratar muchos temas alrededor del agilismo.
Si no sabes qué es un Open Space, echa un ojo a esta explicación, o no entenderás demasiado el siguiente post :)
Pero un Open Space puede servir más que para la organización de conferencias. Veamos una definición usada en http://www.openspaceworld.org/:

Open Space Technology is one way to enable all kinds of people, in any kind of organization, to create inspired meetings and events. Over the last 20+ years, it has also become clear that opening space, as an intentional leadership practice, can create inspired organizations, where ordinary people work together to create extraordinary results with regularity.

Me gusta por que coincide con uno de mis mantras: "De lo racional a la inspiración". Se puede usar el formato de Open Space como herramienta de gestión del cambio en las organizaciones. Es un formato que ensalza la participación, y que crear espacios de colaboración realmente potentes.
Hasta ahora había visto este formato más como organización de conferencia o encuentros. Pero he visto el verdadero poder al facilitar un Open en una organización. Cuando participamos en un Open como formato de conferencia, cada uno se lleva lo que escucha y lo que aprende. Cuando realizamos un Open en una organización, es importante que quede constancia de los temas que se traten y las conclusiones a las que se llega. Es un regalo para la organización. Un punto de partida desde el que trabajar, donde la gente interesada ha participado para crearlo. Co-crear el cambio en una organización es un punto clave para que sea aceptado, y vaya en la dirección adecuada.

• Intenta involucrar al mayor número de personas posibles, pero no obligues a asistir. Insiste ;) , pero no obligues.
• Calma en el momento de sacar temas. A veces parece que no salen nuevos temas, ten sangre fría :) siempre se generan muchas ideas.
• Controla los tiempos, es importante cumplir los plazos marcados en la agenda.
• Haz consciente a todos los asistentes que ni el facilitador ni la organización dirigen la reunión. Que un Open es SU reunión, SU agenda, y SUS conclusiones.
• Haz enseguida un plan de acción para tratar las conclusiones.

Dar la posibilidad a la gente de actuar en los cambios abre muchas puertas, muchas ideas, y genera una confianza increible en sus propias posibilidades. El camino del cambio en las organizaciones sufre muchas dificultades. Inspira a la gente hacia la dirección adecuada.

Agilismo sin software

Al establecerme como profesional independiente, queriendo ganarme las habichuelas como Agile Coach danzando al viento para esparcir los principios ágiles, no había pensado, que uno de mis primeros trabajos sería en una empresa NO relacionada con el desarrollo de sw.
Por casualidades de los contactos (¡gracias!) estoy colaborando con una empresa de fabricación de componentes mecánicos para aeronautica. (!) Y no producen software. Aquí trabajan con la creación del proceso de industrialización, antes de crear piezas en serie. Así que mi primera reacción ante la petición de ayuda fue pensar, "¿y qué hago yo aquí?" Sin embargo, viendo el objetivo de la organización: crear equipos, organizar el trabajo del conocimiento, realizar cambios culturales,... le di una vuelta, y me di cuenta que era en gran parte lo que había tratado de hacer estos últimos años.
Así que estoy trabajando con una organización que realiza industrializaciones de piezas de aeronautica, implantando Kanban, ayudando con la gestión de equipos, técnicas de retrospectivas y en general, ayudando a trabajar con una filosofía de mejora continua basada en Lean.

Los problemas que he encontrado son básicamente los mismos que en los equipos de desarrollo de software, solo que aquí no entiendo nada de lo que producen :) ... ¡y no importa! Es verdad que en este area no puedo recomendar montar un servidor de integración continua, o explicar como hacer TDD. Pero puedo hablar de comunicación, de gestión de equipos, trabajar con paneles kanban, trabajar la organización del proceso,... es decir, transmitirles algunos de los valores más importantes para mi con el agilismo: transparencia, mejora continua, trabajo en equipo.

La principal sorpresa fue trabajar con un panel kanban de más de 40 fases. Y comprobar que todos hacen falta. Olvidémonos de nuestro mítico análisis-diseño-desarrollo-testeo-deploy :)

El poder de reflejar el trabajo en un panel kanban es impresionante. De repente, tenemos información, y sobre todo, un lugar desde el que partir para mejorar. El equipo empieza a organizarse alrededor de ello. Y a contagiarse las ganas de hacer las cosas bien y mejor cada vez.

Las prácticas y principios que hemos aprendido desde el desarrollo de software y metodologías ágiles, son transportables a otros mundos, donde el principal problema en común es la gestión del conocimiento. Lugares comunes donde la inspección y adaptación y las personas, son los mejores enfoques para afrontar los problemas.

La pirámide de la organización ágil

Llevo tiempo dándole vueltas a la organización ágil como creación de un lugar donde se pueda convivir con los principios y valores del manifiesto. Así que ahora que soy consultor, lo voy a intentar reflejar en un modelo ;). Seguro que lo próximo será un cuadrante de dos variables para modelizar la realidad :P
Este es mi esquema básico:

La idea de representar esto es visualizar las areas de actuación, y sus niveles, para enfocarnos en el camino de organizaciones Lean o Agile. Cada elemento de la pirámide contiene al siguiente, obviamente lo que forma los equipos son las personas, y lo que forma una organización también. Los bordes de la pirámide son las relaciones externas o internas que deben trabajar para gestionarse.
Veamos cada elemento:

 - Personas: Personas y sus interacciones sobre procesos, ¿verdad? La base de la pirámide por tanto son, somos, las personas. Significa esto que debemos respetarlas, es decir, darles autonomía, visión sobre su trabajo, objetivos claros, ayuda y soporte. Y confiar en que van a hacer un buen trabajo, por que la mayoría de la gente es capaz de hacerlo.
Generalmente desconfio de alguien que empieza hablando de la importancia de las personas -y voy y hago lo mismo-, de que son lo primero, su "recurso más valioso", etc. Y no me fio demasiado hasta que demuestra que no es solo palabrería. Es un tema que se tiene que demostrar con hechos. (y supongo que a mi me juzgarán igual)

 - Equipos: El mito del equipo autoorganizado creo que en realidad está haciendo más daño si no se entiende bien. Llegar a tener un equipo autoorganizado requiere trabajo. Es verdad que depende de que personas estén en ese equipo, podría llegar a entenderse en un par de días, o no llegar nunca. Así que lo primero es entrenar el ojo y el corazón para ver y sentir estos temas.
   Hablamos de motivación, de liderazgo, de sentimientos. Pero también hablamos de compromiso compartido, de responsabilidad y visión compartidas. El equipo debe tener una dirección clara, y hay un problema cuando no todas las personas están alineadas en la misma dirección.

 - Organización: Alguien debe establecer una dirección hacia la que marcha una empresa (otro post si quereis hablamos de cooperativas o organizaciones "democráticas"). Pero la cuestión fundamental es que las personas que forman la organización deben darse cuenta del cambio de rol que se produce. Su trabajo va a ser poner las bases, facilitar, la creación de equipos, el crecimiento de las personas, para que cada vez puedan hacer méjor su trabajo. Creer que el equipo es el producto* es para mi la clave.

 Dentro de la pirámide invertida tenemos un problema, la estabilidad. Aquí hay dos métricas fundamentales: el beneficio y las personas. Estas métricas deben estar balanceadas de manera precisa. No puedes mantener una organización basada en la felicidad de las personas si no se mantiene económicamente. Básicamente, si no somos capaces siquiera de mantener un nivel higiénico en la economía, no llegaremos muy lejos. Sin embargo, centrarnos en la métrica de la rentabilidad, es crear empresas vacías, donde la gente está de paso, sin corazón. No hay duda que existen empresas que priman los beneficios -y les va bien en ese aspecto-, pero bueno, no hago todo esto para trabajar en/con una de ellas :)
 Mi corolario con este tema es, además, que contra más a gusto trabajen las personas, mayor visión compartida y mayor motivación, los clientes estarán más contentos y se acabará notando favorablemente en la cuenta de resultados.

 Tenemos más areas en la pirámide, que son las fronteras. Pero este post está quedando ya muy largo. Debereis esperar un par de días, para hablar de métricas, metodologías, espacios de colaboración, principios y valores.

 De momento esto no es ni un modelo, pero es un lugar para exponer ideas y temas. Todas las sugerencias son bienvenidas.

Metodologías Agiles y coaching

Este post tiene como raíz las conversaciones con Visi Serrano, otra emprendedora como profesional independiente, psicologa y facilitadora de procesos participativos, colaborativos y autogestionados y muchas cosas más que me sorprenden desde mi visión de ingeniero.

En las metodologías ágiles se habla mucho de la figura del Agile Coach, casi como el nirvana de la figura de un Scrum Master. El coaching aporta un valor inmenso a los que los que ayudamos en la implantación de metodologías ágiles, por su caracter enfoque de conseguir metas o habilidades personales.
En las metodologías ágiles, no es suficiente con hablar de procesos a seguir. Hay que hablar de principios y valores. Y es ahí donde el coaching más nos ayuda.
De todas maneras, siempre que me preguntan por al Agile Coaching, suelo indicar que no es realmente coaching. No el coaching que la mayor parte de las personas piensan cuando oyen esa palabra. El otro día, Tobias Mayer comentaba en Twitter:

for those who asked, Agile Mentor, Agile Guide or even Agile Sherpa are more accurate descriptors than Agile Coach, in almost all cases. https://twitter.com/#!/tobiasmayer/status/173280854108409856

   Y en general estoy de acuerdo con él. Lo que muchas veces llamamos coaching en el mundo de las metodologías ágiles, es realmente un mentoring, una guía, o simplemente una formación. Las diferencias fundamentales, 

• que el coaching trabaja con que la solución sale del coachee. Como Agile Coaches, muchas veces debemos forzar las soluciones, enseñar un camino claro.
• que el coaching no dirige, va donde el cliente quiere. Sin embargo, en el caso de un agile coach, obviamente, no se puede ir donde quieras. Si te dicen que quieren hacer waterfall, ¿les dejas? :D ¡No! 

   Y aún así, me he ido a recibir formación en coaching -un curso sobre coaching co-activo, por cierto, muy interesante. Me parece una de las herramientas más potentes para provocar el cambio en las personas. El conocimiento y las técnicas que aporta me resultan útiles para entender a los clientes, para entender a los equipos y para entender a las personas (no quiero decir que los clientes no sean personas! ;) ). El cambio cultural para una implantación de metodologías ágiles es un cambio imprescindible, y desde la perspectiva que nos proporciona el coaching, más facil de atacar y conseguir.
   A raíz de unos mensajes cruzados en Twitter, por intereses comunes -si no recuerdo mal fueron a partir de charlar sobre "Open Space Technology"- Visi Serrano y yo llevamos unas semanas preparando unos temas, donde podremos aunar la experiencia en metodologías ágiles de uno, y la experiencia en coaching y cambio organizacional de otra. Hemos visto claro que los dos campos son muy complementarios. Así que para centrarnos en la primera linea del manifiesto, una de las primeras cuestiones que deberíamos entender es como trabajar con personas, y eso es precisamente donde observo que el coaching más nos ayuda. Nos ayuda a ver las cosas desde la perspectiva de otras personas, a entenderlas y escucharlas. La creación de equipos auto-organizados siempre ha sido una especie de mito, y no es nada fácil de conseguir. El trabajo con un coach especialista en estas tareas, puede facilitar la labor de manera importante.
   Como autodenominados Agile Coach, sabemos hacia donde debemos dirigir a las personas y los equipos. Sabemos qué valores creemos, y debemos transmitirlos. Sabemos el por qué de estas metodologías y debemos cambiar nuestra parcelita del mundo. El coaching nos ayuda a que otras personas descubran y transiten ese camino más fácilmente, y nos da mejores herramientas para acompañarles.

   A raíz de las conversaciones con Visi, he visto que el coaching ontológico, y con su experiencia en trabajo de cambio en organizaciones,  podemos ofrecer las dos caras de la moneda que se complementan perfectamente. Pronto, más en sus pantallas y sus organizaciones ;)


PD: Este es el post cruzado de Visi: Psicología y Scrum: desarrollo ágil de equipos.

   

Organización ágil: de lo racional a la inspiración

En una organización ágil la cuestión que deberíamos creer es en las personas, que son capaces de hacer aquello que se proponen. Que son capaces de aprender para hacerlo. Y que tienen ganas de hacerlo.
Recientemente he leido un artículo, cuyo título es muy relevante: Knowledge workers respond to inspiration, not supervision. Y esa idea subyacente prevalece en el agilismo, en su manifiesto. Y responde a un principio básico de Lean: "Respeto a las personas".

Professionals require little direction and supervision.
What they require is protection and support.

Sin embargo, muchas veces actuamos más controlando el trabajo del resto de la organización, de nuestros subordinados, o incluso de los propios compañeros. Controlando en el sentido de querer que hagan las cosas como nosotros las haríamos. Esperando que respondan univocamente a nuestras órdenes o deseos, cuando no nos damos cuenta que es muy probable ni siquiera las hayamos expresado correctamente.
La pregunta que sale siempre tras este planteamiento es: ¿realmente podemos creer en todas las personas? Y si vemos que una persona no es capaz de seguir al resto, o boicotea al equipo, o simplemente consideramos que su rendimiento no es suficiente... ¿hasta cuando le tenemos que aguantar? La respuesta es muy sencilla... ¡depende! Intenta conocer las verdaderas motivaciones o problemas, el contexto que le mueve a comportarse de una manera u otra, y piensa primero por qué está sucediendo eso. La mayoría de las veces se le podrá poner remedio, y si no, soluciones drásticas en cuanto creas que no hay otra posibilidad. En una organización es cierto que hay una exigencia mínima, que de hecho es la que inicialmente crea el compromiso personal.
Un equipo es una pieza clave en el desarrollo de software, y las habilidades técnicas son tan importantes como las interpersonales. Tú, ¿de cual te olvidas?

Organización ágil

¿De qué hablamos cuando nos referimos a una organización ágil? ¿existe eso?
En general oigo que es la organización que se adapta a los procesos de creación de producto basados en equipos multidisciplinares que trabajan de manera ágil. Es decir, que con un enfoque bottom-up, creamos la organización ágil. Los equipos con la nueva manera de trabajar son "raros" y acaban demandando a su propia organización que se adapte para el mejor funcionamiento de todos.
Me suena un poco extraño. Generalmente la organización funciona como alguien ha impuesto, o ha establecido. Además, el cambio bottom-up lo veo limitado hasta que encuentras un escalón demasiado duro para seguir creciendo. Y la cultura se come la estrategia para merendar, que dicen.
La otra cuestión sería realizar el cambio desde arriba, pero entonces perdemos la perspectiva de lo que es el agilismo, pues lo ágil, estrictamente hablando viene de su manifiesto, escrito para el desarrollo de software, NO para la gestión de empresas. Y debemos basarnos en otras fuentes (Lean o las nuevas corrientes de gestión organizativa). Lo denominado ágil, se "inventó" en un manifiesto que trata del desarrollo de software. Es tan bonito y tan perfecto ;) que extraemos conclusiones que afectan a organizaciones enteras, pero ¿deberíamos hacerlo realmente?
¿qué claves nos da el manifiesto ágil para poder extenderse a toda una organización? Veamos los primeros puntos:
Valoramos 

• A los individuos y sus interacciones por encima de los procesos y las herramientas.
• Trasladado al mundo organizativo: Confianza, coordinación, respeto.
• El software que funciona por encima de la documentación exhaustiva
• Trasladado al mundo organizativo: Orientación a resultados
• La colaboración con el lcliente por encima de la negociación de contratos
• Trasladado al mundo organizativo: Colaboración, compromiso
• La respuesta al cambio, por encima del seguimiento de un plan
• Trasladado al mundo organizativo: Aprendizaje, adaptación

Es decir, tenemos que basar una organización en la confianza, la coordinación y colaboración entre personas que se respetan, orientadas a resultados y comprometidas con los mismos, que aprende y se adapta al medio. Sin duda son un montón de cosas molonas y de buen rollo, pero, ¿cómo se trasladan a una organización? Sin duda también, se puede realizar.
Más en próximos capítulos. Stay Tuned.

Visión del desarrollo ágil de software

Me liaron para dar una charla en The Mêlée (yo encantado, claro), y me propusieron hablar desde mi experiencia con metodologías ágiles. Así que lo que intenté finalmente es exponer mis razones para considerar las metodologías ágiles, y cuales son las partes que más valoro actualmente.
Os escribo un pequeño resumen, y podeis encontrar alguna explicación más en la documentación adjunta en slideshare (desarrollo ágil de software). Mis tres razones básicas por las que he llegado al convencimiento de que las metodologías ágiles son las más adecuadas para desarrollar software son las siguientes:

1. El axioma Equipo = Producto
2. El software es un juego coaborativo, de comunicación y finito
3. El desarrollo de software se realiza sobre un sistema complejo

El primer punto fue el que empezó realmente a hacerme plantearme mi manera de pensar en este mundo del software. Yo debía hacer equipos capaces y sobresalientes, más que proyectos y productos. Ese cambio de responsabilidad, me implicaba centrarme más en las personas con las que trabajaba.

En ese momento, el manifiesto ágil encajó perfectamente en mi cabeza. Mi conclusión es que el objetivo principal es entregar valor al cliente, obviamente bajo la perspectiva de paso sostenible. Y los valores que he ido adquiriendo son:

• Colaboración: búsqueda de la visión compartida
• Mejora continua, sin descanso, y adaptándonos al cambio.
• Autoorganización de los equipos, obtener lo mejor cada persona.
• La Calidad es incuestionable.
• Las buenas prácticas son indispensables, pero cuidado que a veces nos hacen perder el objetivo.
• El camino de la mejora de gestión y técnico deben ir unidos.

Desarrollo ágil de software

View more documents from Jose Ramón Díaz

Lean: Eliminar la basura

Este principio -verdad subyacente que no cambia con el tiempo o el espacio- trata sobre la necesidad de eliminar los elementos que producimos y que no son realmente necesarios para crear el producto software que necesitamos hacer, que no le añaden valor.
El primer punto por tanto es averiguar qué es lo que da valor y lo que no. Identificar los procesos, artefactos o tiempos que no añaden nada a lo que el cliente necesita. Algunos ejemplos [1] de basura dentro de un proyecto pueden ser:

• Requerimientos que no se van a utilizar. Recordemos siempre la regla de Pareto. El 20% de las funcionalidades proporcionarán el 80% del valor del producto.
  
• Complicaciones de diseño/interfaz que no eran necesarias.
  
• Esperas entre etapas:
• Tiempo desde que se obtiene la información hasta que se usa.
• Tiempo desde que alguien necesita información hasta que la obtiene
• Tiempo desde que se crea un error hasta que se detecta/corrige.
• Otro tipo de esperas muy peligrosas, las producidas por la multitarea (o la procrastinación)
  
• Escribir demasiado código. Puede estar relacionado con el tema de la complejidad, o quizás simplemente es que no se supo hacer de una manera más sencilla. Pero si algo lo puedes hacer con la mitad de código, estás creando basura.
• Trabajo a medio hacer, sin terminar. Equivalente al inventario en sistemas de producción.
• Errores, cada bug creado en el desarrollo es un desperdicio. Suena obvio, pero a veces ponemos más enfasis en encontrar la basura que en no generarla.
• Actividades de gestión. Estas actividades no aportan valor directo a los productos, y aunque obviamente son muy importantes para el correcto funcionamiento de organizaciones y equipos, hay que vigilarlas para que no se conviertan en focos de desperdicio. Lo más típico: la burocracia.
  

Uno de las dificultades de este principio es discernir qué factores se pueden reducir o aligerar para eliminar basura. Identificar qué pasos en los procesos no producen valor para el cliente. No siempre valen las mismas conclusiones para todos los entornos. En algunos proyectos algunos tipos de documentación pueden ser un desperdicio, pero en otros, que por ejemplo ya sabes que después los vas a ceder a otro equipo o van a tener un mantenimiento muy prolongado, puede ser vital documentar exhaustivamente.
La herramienta propuesta por Lean[2] para la identificación de la "basura" es la creación de mapas de cadenas de valor, para analizar el flujo de aporte de valor de los procesos utilizados por el equipo para la creación del producto, desde su concepción hasta que llega al cliente. Los mapas ayudan a visualizar los tiempos que se pierden de manera gráfica.
Debes trabajar para poder ver las pérdidas de tiempo en un desarrollo de software. Determinadas veces serán obvias (burocracia, procesos de documentación que generan artefactos que nadie usa ni usará,...), pero otras no son tan claras, o lo que es peor, pueden no ser bien aceptados los cambios que necesitarías llevar a cabo para eliminarlos. La burocracia y las costumbres pueden ser dificiles de erradicar por que dan (falsa) seguridad y confianza[3].
Por lo tanto, ¿es este principio beneficioso para el desarrollo del software? Sin duda. Aporta mejoras en dos de las areas que comentamos en el primer post sobre Lean:

• Mejora la productividad de la "tubería-desarrollo". Hacemos más eficaz los equipos y la organización por que dejamos de realizar tareas que no aportan valor al cliente, que al final, es quien determina nuestro éxito o fracaso.
• Mejora las interacciones entre desarrollo y el resto de la organizacion. Recordemos que Lean se centra en la organización global. No debes dibujar un mapa de creación de valor para el departamento de desarrollo, si no para la organización completa! Seguro que salen muchas ineficiencias interdepartamentales.
  

Bibliografía:
[1] Implementing Lean Software Development
[2] Lean Software Development: An Agile Toolkit
[3] Eliminando obstáculos
[4] Gestionando la recesión con Lean, Agile y Scrum
[5] Los Poppendieck

Desarrollo software Lean

Uno de los temas en los que estoy más interesado ultimamente en este mundo del desarrollo de software es el "Lean Development". Es un conceto que surgio de la adaptación del modelo de Toyota de fabricación al software. Orginariamente parece que fueron "los Poppendieck" los inventores del término, en un par de libros que no te puedes perder:

• Implementing Lean Software Development: From Concept to Cash.
  
• Lean Software Development: An Agile Toolkit. Este lo tengo hace unos meses y me parece muy bueno. Enfoques diferentes para problemas tradicionales.

Lo importante de Lean, es que se basa en unos principios, adaptados del TPS. Y esto es una de las claves para su futuro éxito, que no son herramientas, no son pasos a dar o procesos a seguir. Son principios cuyo valor reside en su aplicabilidad independientemente del "estado del arte" en el que te encuentres. Las medidas las decides tú, los cambios guiados por principios son efectivos si los principios son adecuados. Así que llegamos a la cuestión, ¿son los principios Lean acertados para lograr un mejor desarrollo de software? (Ahí es nada, definimos mejor como de mejor calidad, mejor satisfacción del cliente, mejor ganancias para el proveedor,... mejor lo que quieras!)
¿Cuales son estos principios? (el orden no importa)

• Eliminar la basura
  
• Crear conocimiento
• Construir calidad inherente en el producto
• Retrasar el compromiso
• Entregar rápidamente
• Respetar a las personas
• Mejorar el sistema global

Iremos viendo cada uno, intentando adivinar si son beneficiosos para el desarrollo de software. (!me acabo de obligar a escribir al menos 7 posts!).
Otra pregunta que te sueles hacer cuando empiezas a conocer Lean es su relación con las metodologías ágiles. Básicamente creo que hablan de lo mismo, pero Lean está un paso por encima a nivel organizativo. Las metodologías ágiles (XP y Scrum al menos, que son las que más conozco, no olvidemos que existen otras) se focalizan en el equipo que desarrolla un proyecto. Lean complemente esa visión con principios aplicables a la organización que soporta los equipos, y que debe gestionar un portfolio de proyectos y equipos. Hay cuatro cuestiones que se deben lograr:

• Seleccionar las cosas adecuadas en las que currar (Lean Management). ¿te interesan todos los proyectos?
  
• Ajustar la carga de trabajo a la capacidad. Muchas veces ni siquiera conoces tu capacidad.
  
• Mejorar la productividad de la "tubería-desarrollo" (Lean-Scrum). Aumentar la capacidad del sistema.
  
• Mejorar las interacciones entre desarrollo y el resto de la organizacion. Recordemos que Lean se centra en mejorar el sistema global.
  

Recapitularemos tras ver los principios, y volveremos sobre estas cuatro cuestiones. Si quieres ir adelantando las ideas, aquí tienes una pequeña recapitulación de los principios.

P.1 Eliminación de la basura.
P.2 Creando conocimiento
P.3 Construir con Calidad

¿Es SCRUM una ventaja competitiva en una empresa de servicios?

Como ya sabeis, estamos "tonteando" con Scrum en la empresa. Puede ser que sea un idilio largo o no. El otro día nos dieron un curso francamente bueno, fue la empresa Proyectalis. Podeis echar un ojo al blog de Angel Medinilla, quien nos impartio el curso de dos días, muy bien planteado e interesante.
Lo que ahora me pregunto es hasta qué punto Scrum puede ser una ventaja competitiva frente a las demás empresas proveedoras de servicios en este mundo del desarrollo de software. Tengo claro que no debemos de tratar únicamente de cumplir con los requisitos del cliente cerrados en el contrato y punto final, si no asegurarnos que esos requerimientos son los que hacen "feliz" al cliente. En esa filosofía, la base de las iteraciones ayudan: el cliente pone el foco en lo que quiere realmente mucho antes.
Sin duda Scrum en estos momentos puede suponer una diferenciación en el mercado actual. Pero eso sí, posiblemente especializandose en determinado tipo de cliente. La estrategia ganadora no puede ser en este momento una diferenciación para todo el mercado, sino una especialización en un nicho muy concreto de clientes. ¿Aceptarían todos los clientes un desarrollo "Scrum"? ¿podrías competir con grandes consultoras en mega-proyectos? ¿puedes dar servicio a administraciones públicas que te piden METRICA3 (o 2)?... ¿interesa hacer todo esto?

Esta es solo una entrada de dudas/preguntas, pero mi opinión es que SCRUM es el buen camino, hacia el "norte verdadero" que nos decía Angel en su curso.

El círculo proceso-persona

Leyendo esta entrada sobre la idea recurrente de que lo más importante para hacer software son las personas, me ha venido a la cabeza una reunión de hoy que hemos tenido en Biko. Las mejoras en el desarrollo de software no se acaban nunca, y cuando tienes a medio hacer algo (podeis echar un ojo al documento libre sobre la implantación de técnicas ágiles con CMMI) ya estás pensando en lo siguiente.
Como decía, el post referenciado, me recordaba lo que hacemos cuando intentamos mejorar las cosas. En la mente tienes que lo importante son las personas, pero lo más facil ¿qué es? ¡¡Definir procesos!! Te pones a pensar: si hacemos las cosas así, o de esta otra manera, y luego nos sale esta otra situación, entonces lo que hay que hacer es... definimos cómo se debe hacer esto, para que después se haga igual...

Así que nos hemos ido a los procesos y parecería que nuestra intención es implantar CMMI nivel 4 o 5. (uf, y por cierto, no os olvideis de la encuesta, gracia). Yo siempre acabo diciendo que lo mejor es usar el sentido común, conociendo bien las herramientas disponibles y con la experiencia, se pueden tomar decisiones acertadas que son totalmente diferentes en el marco de un proyecto u otro. Pero siempre parece que tiras a definir los procesos, más que a pensar que la gente que tenga que resolverlos ya sabrá hacerlos, o que precisamente, a los que no sepan les vas a formar.

Es una dialéctica complicada, la de procesos contra personas planteada en el manifiesto ágil. Y cuesta romper. Supongo que tenemos hecha la cabeza de una manera (dura) que es dificil de cambiar la forma de pensamiento.
Todo esto está relacionado con lo que ya he comentado en otras ocasiones: ¿buenas prácticas o procesos? Al final, depende de la gente, a unos los puedes matar de aburrimiento siguiendo procesos muy formales, y a otros perderlos por el camino si no les pones las luces de aterrizaje bien claras.

Encuesta sobre CMMI

A raiz de este post que menciona que hay 85 empresas más en España este año que han obtenido una certificación CMMI, me ha picado la curiosidad, yestoy montando una pequeña encuesta con intención de recoger información de aquellas personas que trabajen en una empresa con certificación CMMI. He reducido bastante el número de preguntas que quería hacer, para que no se haga pesada (que es lo que a mi me suele echar atrás para rellenarla, sobre todo, ;) si como en este caso no hay premio por hacerlo).

Si te apetece, aquí tienes el enlace: Encuesta sobre CMMI.

Y si conoceis a gente que pueda encajar en el perfil para rellenarla, por favor, me encantaría que les distribuyeseis el enlace.
Obviamente, después publicaré los datos y la información que pueda extraer de ellos en esta misma página. ¡GRACIAS!