Scrum Managers Blog

Porque nos gusta la agilidad, y aportar mejoras en las partes que no nos convencen,  hace un año nos pusimos manos a la obra, porque:

• Preferimos la síntesis entre agilidad y procesos, a su oposición.
• Preferimos la aplicación flexible de la agilidad a la fundamentalista: adaptando las prácticas a la empresa y no al revés.
• Preferimos la formación libre y asequible, y las certificaciones rigurosas, a las caras y cuestionables.

y no queriamos decirlo, queríamos hacerlo
Sólo ha pasado un año y estamos más que contentos del resultado:

• La mayor comunidad profesional ágil hispana: más de 2.000 miembros.
• Una plataforma de formación abierta: Open Knowledge Scrum con tres cursos y un taller por los que han pasado más de 1.000 alumnos
• Un modelo innovador de certificación: para obtenerlo no es necesario pagar, pero sí demostrar el conocimiento: más de 400 profesionales certficados.
• Cursos presenciales a menos de la mitad del precio habitual de mercado, que están completando los aforos en casi todas las convocatorias, y terminan con valoraciones como estas:

Hacía mucho que un curso no me mantenía tan atento y motivado, me quedo con ganas de mucho más.

Juan Manuel Barroso. Desarrollador de software (Novasoft)

Me ha encantado el curso. Ya había realizado el curso on-line, y a pesar de ser el mismo temario, considero que es muy útil aisstir al curso presencial. Te da más riqueza cuando “discutes” las problemáticas del día a día en grupo y a la cara.

Mª Luz Carmona. Jefa de proyectos (Contactel)

Curso recomendado, pues es muy práctico y en donde hay mucha discusión, exposición de casos reales. Se comparte realmente el conocimiento y las experiencias.

Rafael Hernampérez Martín. IT Project Manager

Me parecieron muy buenos los cursos on line, pero el curso presencial impartido por Juan Palacio me ha parecido impresionante. Muy recomendable, tanto el curso como los comentarios fuera de clase.

Eduardo Ferro Aldana.

Recomiendo a cualquier persona que tenga programadores a su cargo, e incluso no programadores, que haga el curso, porque pienso que mejorará su tarea.

Paco Monfort. Director de Desarrollo, DCCOM

El curso me ha parecido muy práctico y sobre todo real, porque ha bajado al mundo real y no se ha situado en el mundo teórico.
Los ejercicios son muy útiles y sirven muy bien para asentar los conceptos e ideas comentadas durante el curso.

Fco. Antonio Pomata, Equipo de desarrollo, Teralco.

Curso imprescindible para el conocimiento de la metodología ágil Scrum. Sales del curso con una motivación extra para su aplicación.

Javier Ortiz. Consultor tecnológico.

[...]

¡¡ Gracias a todos los que lo estáis haciendo posible !!

En Scrum, a diferencia de los modelos de procesos, (CMMI, ISO15504…) la calidad del resultado no depende de la calidad el proceso, sino de las personas.

Si una pianola no suena…  es una mala pianola.

No ocurre lo mismo con los pianos.

Poner las pruebas (el testing) delante de la programación ha marcado un hito en las prácticas de programación, un antes y un después, que ha transfromado a la “cenicienta” del testing en princesa; de trabajo indeseado (probar lo que iban terminando los programadores) a tarea “cool” de diseño y pre-codificación.

TDD ha hecho que sean las pruebas las que tracen la pauta al desarrollo, y no al revés, y al hacerlo ha abierto dos dimensiones nuevas al testing tradicional: documentación, y sobre todo: diseño:

• Se empiezan a escribir pruebas unitarias con herramientas como JUnit o NUnit.
• Empieza a aumentar la confianza en el código, en la misma proporción que el volumen de pruebas que se va generando.
• Al escribir las pruebas en primer lugar, el código gana simplicidad, programándose lo extrictamente necesario.
• Las pruebas van tomando una nueva dimensión: “documentación”, porque cuando se retoma código ya olvidado,  son las que mejor explican qué es lo que hace ese código.
• Poco a poco se empieza a descubrir la segunda dimensión: desarrollar pruebas revela el “API” del código, y pasa entonces a ser también un proceso de diseño.

A partir de este punto se empieza a plantear olvidar el origen de TDD, quitar el foco del “testing” de unidades de código, y llevarlo hacia diseño y comportamiento funcional, pasando de TDD a BDD (Behaviour Driven Development)

Básicamente es lo mismo, pero con unos cambios clave: La unidad de prueba ya no es una unidad de código (unit) sino un comportamiento. Los estados pasan a comportamientos y los marcos “xUnit” a “rSpec”.

La verdad es que en nuestra industria la espiral de conocimiento está girando muy deprisa. Si tuviéramos que dibujar su avance en el campo del testing podría ser algo así:

Más información

Herramientas BDD

• Java: JBehave , JDave , Instinct , beanSpec
• C: CSpec
• C#: NSpec
• .NET: NSpec , NBehave
• PHP: PHPSpec
• Ruby: RSpec , Shoulda , test-spec & Bacon , Cucumbe
• Javascript: JSSpec , jspec

• Vídeo e introducción a BDD de Dave Astels (inglés).

“El producto previsto, en el tiempo planificado y por el presupuesto estimado” Vs. “Valor rápido, y de forma continua, en intervalos breves u regulares”.

Reproduzco a continuación el mensaje recibido de mi compañero de Scrum Manager Agustín Villena:

Scott Ambler y yo hemos preparado una encuesta que investiga las técnicas de comunicación de los equipos ágiles. La URL de la encuesta:
http://www.surveymonkey.com/s/agilecommunication

Los objetivos de la encuesta son los siguientes:

(1) Describir las técnicas de comunicación de los equipos de desarrollo ágil y
(2) Determinar los efectos de los métodos de comunicación, la
experiencia y el lenguaje en la calidad del software

Hay mucho de retórica rondando, pero pocos datos duros, haciendo difícil a las organizaciones el tomar decisiones basadas en hechos respecto de la forma más eficiente y eficaz para facilitar las comunicaciones a través de los proyectos ágiles. Tú puedes ayudar a corregir este problema llenando esta encuesta tan honesta y detalladamente como sea posible. Esta encuesta le llevará alrededor de 5-7 minutos. Los resultados serán resumidos en un boletín informativo proximamente en Dr. Dobb’s Journal y en línea en http://www.ambysoft.com/surveys/

Además, después de que encuesta se cierre, vamos a regalar de 10 copias del libro de Mike Cohn “Suceeding with Agile”. Para obtener más información sobre el libro, visita
http://www.mountaingoatsoftware.com/books/7-succeeding-with-agile-software-d

Gracias de nuevo por tu ayuda.

Ronzelle Green & Scott Ambler

Por favor, cumplimenta la encuesta.

El concepto original “Campo de Scrum” definido por Nonaka y Takeuchi describe un entorno de trabajo con principios ágiles en equipos motivados, con delegación y  “empowerment”, que desarrollan proyectos de forma iterativa a incremental, que no dividen el ciclo de desarrollo en fases, comparten el conocimiento por socialización (comunicación directa)…

La implementación de un campo de scrum no depende de las prácticas empleadas (Backlog – Burndown / historias de usuario / Etiquetas kanban …) o del ámbito de aplicación (proyecto, producto o empresa).

La implementación que Jeff Sutherland realizó en 1993 en su equipo en Easel Corporation, a nivel de proyecto, que Ken Schwaber  documentó, en el libro Agile software development with scrum y que difunde la Scrum Alliance, es una implementación concreta, como lo son tambien cada una de las desarrolladas originalmente por Canon, NEC, Xerox, hp, Honda,  Epson… Es buena, pero nada impide diseñar un campo de scrum con flexibilidad en las prácticas para  adecuarlas a cada realidad, y con ámbito de proyecto, producto o de empresa, según sea para un equipo, departamento (por ejemplo de I+D en una software factory de procesos), o de organización en su conjunto.

Tomando el concepto original de Scrum y “des-monopolizándolo” de la Scrum Alliance, es posible plantear implementaciones con diferentes prácticas y también a nivel de producto o de empresa. Con esta visión de Scrum Manager la agilidad da su mejor resultado cuando se implican y alinean los diferentes ciclos de la empresa: estratégico, proyectos y producción.

(more…)

Me ha parecido muy interesante la propuesta de Tommy Norman para poder compartir un tablero Scrum en una proyección con un coste muy bajo, como se puede ver en su artículo Virtual Sprint Task Board Using a Wii Remote, siendo tamién muy interesantes los comentarios que ha recibido.

Pero no olvidemos que quizás el origen de este tipo de soluciones vienen de Johnny Chung Lee cuyo video Low-Cost Multi-touch Witheboard using the Wiimote podemos ver a continuación:

Están disponibles, con muy buena calidad por cierto,  las presentaciones y los vídeos de todas las ponencias que se presentaron el pasado en el AgileLeanDayChile 209, entre ellas, la que hizo Claudia Ruata del proyecto Scrum Manager.

• Casos de Éxito

Proyecto ProAud: Ricardo Jara (Continuum, Chile)
NameAction: Philippe Camacho (Leansight Consulting, Francia)

• ScrumManager: Modelo de Formación Ágil Libre y Abierta: Claudia Ruata (HorusMS, Argentina)
• Lean & Kanban: Agustín Villena (DCC U. de Chile / LeanSight Consulting, Chile)
• The HashRocket Way: Desi McAdam (Hashrocket, EE.UU.)
• Innovación descentralizada a través de las nuevas tecnologías de la Web de Datos (Web 3): Aldo Bucchi (Linktegration, Chile)
• MicroCharlas
• Agile Perú y la próxima conferencia latinonamericana en Lima Ágiles 2010: Raúl Uribe (Perú)

Scrum Manager bit: La motivación extrínseca es adecuada en trabajos relativamente mecánicos y entornos industriales, pero puede ser contraproducente en empresas del conocimiento.

Ambiente Industrial	Campo de Scrum
Los principales responsables de la calidad del resultado son los procesos y la tecnología	Los principales responsables de la calidad del resultado son las personas
cc by cloneofsnake	cc by Dan Zen
Las personas ayudan a los procesos y la tecnología	Los procesos y la tecnología ayudan a las personas
La mayoría de principios y prácticas de gestión en cualquier nivel y en sus relaciones (empresa, proyecto o producto) son diferentes.
La motivación extrínseca es una prescripción relativamente válida para los primeros, y  normalmente contraproducente para los campos de Scrum.

En esta conferencia Itay Talgam nos desgrana distintos estilos de dirección de orquesta, totalmente trasladables a la dirección de proyectos o empresas:

Un director de orquesta afronta el máximo reto de liderazgo: crear armonía perfecta sin decir una palabra. En esta encantadora charla, Itay Talgam muestra el estilo único de seis grandes directores del siglo XX, ilustrando lecciones cruciales para cualquier líder

Puedes ver el vídeo con subtítulos en español o inglés desde la web de TED.

Itay nos va llevando por distintos tipos de liderazgo, desde el más autoritario de Riccardo Muti, cuya descripción cierra con la anécdota de la petición realizada por los 700 músicos de La Scala para que dimitiese, hasta el último cuyo nombre no dice y que no reconozco, que dirige a la orquesta solo con los movimientos de su cara.

Itay va avanzando, director a director, en el grado de excelencia en la dirección, no como posición autoritaria sino como facilitador. Veamos los pasos que nos muestras:

• Riccardo Muti, autoritario, explícito, no deja espacio para que los músicos se desarrollen y estós terminan pidiendo su dimisión.

• Richard Strauss, deja que todo suceda por sí mismo, sin interferir, pero dentro de un espacio delimitado, sin muchas opciones a la creatividad.
• Herbert von Karajan, dirige sin dar instrucciones, la música está en su mente, “el peor daño que podría causarle a mi orquesta es darles una instrucción clara porque eso impediría la unión, escucharse unos a otros, lo cual es necesario en una orquesta”, llega a manifestar en una ocasión. Es un control muy espiritual, pero sin embargo firme, que causa una gran presión a los músicos que deben descifrar los mensajes del director.
• Carlos Kleiber tampoco da instrucciones, en su lugar abre un espacio para que los músicos añadan otra capa de interpretación. Carlos conduce la representación disfrutando, viviendo la música. Cada músico sabe lo que tiene que hacer y se crea un espacio de compañerismo. Pero no solo motiva, también mantiene la autoridad ganada por su profesionalidad. Kleiber no solo crea un proceso, crea las condiciones para que ese proceso fluya. Todo esto es muy emocionante para los músicos, para el equipo.
• Kenny Bernstein, el profesor de Itay, es otro ejemplo de dejar fluir a los músicos, de disfrutar y transmitir ese gozo. Si amas algo, déjalo ir dice Itay que le dijo una vez su amigo Peter y aquí lo utiliza para describir a Kenny Bernstein.

No he podido evitar pensar en los modelos de dirección de proyectos y en el proceso y las condiciones que se crean en las metodologías ágiles. Aunque esta forma de dirigir o gestionar no es exclusiva de SCRUM o del agilismo si es una de las características inequívocas de estas metodologías y una de las causas también de sus éxitos. ¿Son Kleiber o Bernstein SCRUM conductors?

Gracias a José de la Peña por la referencia de la conferencia.