I was looking for a good analogy to compare the lack of specialization that Scrum suggest for teams, and in my search came to memory that wonderful spectacle that Johan Cruyff http://en.wikipedia.org/wiki/Johan_Cruyff and the Dutch National Football Team offered in 1974 and 1978 Football World Cups. For those of you who are not too old, that was the point in time when the 'Total Football' http://en.wikipedia.org/wiki/Total_football concept was globally introduced.
Total Football like Scrum proposes no specialization, except for the goal keeper of course, and by doing this unleashes the talent and creativity of all team members. Having no roles implies a lot of discipline and superbly physical and mental condition. Flexibility come to the team but no at no cost, the team needs to realize that switching positions on the field implies greater synchronization and responsibility.
One of the principles behind Total Football is that in theory every player can score, so why constraining all that potential? Of course chaos happens if everybody tries to score at the same time, hence the importance of discipline in self-organizing teams.
Scrum teams should run by the same venue, just think in teams with no formal roles and cross-functionality at its best. Of course chaos is there, but good chaos that foster creativity and invention. Self-discipline and team alignment are crucial though.
Following this rationale, Scrum teams with specialized team members like developers and quality engineers are in disadvantage compared to fully cross-functional ones. Further, having only four guys out of seven producing code while the rest three are testing doesn't sound like the more beneficial approach, at least not production wise. Again, unleashing everybody's potential for writing code-both product and automation code-looks more beneficial.
Thursday, March 25, 2010
Wednesday, March 17, 2010
Scrum en Sencillo
¿Qué es Scrum?
Scrum es un marco de trabajo que define roles, artefactos y ceremonias que los equipos pueden emplear para trabajar más efectivamente.
¿Qué no es Scrum?
Scrum no es una metodología de desarrollo de software, una metodología es una secuencia ordenada de pasos realizados con algún fin. Scrum no sigue ninguna secuencia, no recomienda el orden de aplicación de sus componentes, simplemente los propone para que los equipos los utilicen en paralelo y durante todo el ciclo de desarrollo.
¿Por qué se invento Scrum?
Scrum se inventó ante la necesidad de tener alguna cosa que funcione en dominios caóticos con requerimientos cambiantes. Scrum pretende hacer que los equipos que lo utilicen se vuelvan hiperproductivos, estudios empíricos reportan mejoras hasta del 80% en diferentes indicadores.
¿En que se inspiró Scrum?
Scrum recoge mucho de la influencia del Toyota Production System y la escuela de Lean Development Software que se inspiró en los principios de Toyota. Scrum también se basa en los principios del Manifiesto Ágil.
¿Scrum hace énfasis en principios ingenieriles?
No, por el contrario enfatiza en principios humanos de colaboración y trabajo en equipo. Sin embargo Scrum se complementa perfectamente con enfoques más prescriptivos como eXtreme Programming que hace fuerte énfasis en los aspectos ingenieriles del desarrollo de software.
¿Cuáles son los valores de Scrum?
Scrum promueve la auto organización de los equipos reduciendo las labores asociadas con management. Scrum creen en empowerment del equipo pero a la vez trata de mantener una alineación de pensamiento y acción que hace que los miembros de un equipo apunten a trabajar en la misma dirección y con los mismos objetivos. Otro de sus valores claves es la inspección y adaptación que conducen a la mejora continua.
¿Scrum es solo aplicable para el desarrollo de software?
No, Scrum es apto para aplicarse a cualquier campo o industria en las cuales se tengan equipos de personas trabajando. Como se dijo antes, Scrum se inspiró en la industria automotriz y se aplicó a la industria del software, pero en esencia es aplicable a diferentes industrias.
¿Quiénes deben aprender Scrum?
No solamente los managers ya que los equipos son los que se auto organizan, por el contrario es recomendable que todos los miembros de un equipo aprendan Scrum y luego entre ellos decidan que roles asumirán.
¿Dónde reside el poder de Scrum?
En la simplicidad de su enfoque y en su filosofía que permite a los miembros de un equipo ser autocríticos y buscar la innovación y mejor continuas.
¿Es difícil aprender Scrum?
No, son principios son simples pero requieren de una gran disciplina para ser aplicados. Constancia y perseverancia son necesarias. Scrum es una de esas cosas, como las artes marciales, que son sencillas de aprender en principio pero difíciles de aplicar y perfeccionar.
Scrum es un marco de trabajo que define roles, artefactos y ceremonias que los equipos pueden emplear para trabajar más efectivamente.
¿Qué no es Scrum?
Scrum no es una metodología de desarrollo de software, una metodología es una secuencia ordenada de pasos realizados con algún fin. Scrum no sigue ninguna secuencia, no recomienda el orden de aplicación de sus componentes, simplemente los propone para que los equipos los utilicen en paralelo y durante todo el ciclo de desarrollo.
¿Por qué se invento Scrum?
Scrum se inventó ante la necesidad de tener alguna cosa que funcione en dominios caóticos con requerimientos cambiantes. Scrum pretende hacer que los equipos que lo utilicen se vuelvan hiperproductivos, estudios empíricos reportan mejoras hasta del 80% en diferentes indicadores.
¿En que se inspiró Scrum?
Scrum recoge mucho de la influencia del Toyota Production System y la escuela de Lean Development Software que se inspiró en los principios de Toyota. Scrum también se basa en los principios del Manifiesto Ágil.
¿Scrum hace énfasis en principios ingenieriles?
No, por el contrario enfatiza en principios humanos de colaboración y trabajo en equipo. Sin embargo Scrum se complementa perfectamente con enfoques más prescriptivos como eXtreme Programming que hace fuerte énfasis en los aspectos ingenieriles del desarrollo de software.
¿Cuáles son los valores de Scrum?
Scrum promueve la auto organización de los equipos reduciendo las labores asociadas con management. Scrum creen en empowerment del equipo pero a la vez trata de mantener una alineación de pensamiento y acción que hace que los miembros de un equipo apunten a trabajar en la misma dirección y con los mismos objetivos. Otro de sus valores claves es la inspección y adaptación que conducen a la mejora continua.
¿Scrum es solo aplicable para el desarrollo de software?
No, Scrum es apto para aplicarse a cualquier campo o industria en las cuales se tengan equipos de personas trabajando. Como se dijo antes, Scrum se inspiró en la industria automotriz y se aplicó a la industria del software, pero en esencia es aplicable a diferentes industrias.
¿Quiénes deben aprender Scrum?
No solamente los managers ya que los equipos son los que se auto organizan, por el contrario es recomendable que todos los miembros de un equipo aprendan Scrum y luego entre ellos decidan que roles asumirán.
¿Dónde reside el poder de Scrum?
En la simplicidad de su enfoque y en su filosofía que permite a los miembros de un equipo ser autocríticos y buscar la innovación y mejor continuas.
¿Es difícil aprender Scrum?
No, son principios son simples pero requieren de una gran disciplina para ser aplicados. Constancia y perseverancia son necesarias. Scrum es una de esas cosas, como las artes marciales, que son sencillas de aprender en principio pero difíciles de aplicar y perfeccionar.
Wednesday, March 10, 2010
Sutherland y su definicion de Scrum
El otro dia escuche a Jeff Sutherland dando una deficion muy simple de lo que es Scrum, segun decia Scrum es algo que permite alinear a la gente de un equipo y hacer que se muevan en la misma direccion, algo como canalizar la energia de un grupo de personas.
Suena simple pero en esencia eso es lo que es Scrum, no es algo que funcione o haya sido pensado para que una persona sea mas productiva, por el contrario es algo que se penso para que un equipo sea hiperproductivo.
Mas aun, segun Jeff Scrum tiene valor cuando la gente hace de esta su herramienta y la adapta a sus necesidades. Jeff sin embargo decia que esta no es una adaptacion libre, por el contrario es una adaptacion que se debe basar siempre en adoptar principios que hagan al equipo mas production. En otras palabras, las adaptacion que uno haga del marco de Scrum deberian caer dentro de los principios de Agile y Lean.
La suposicion que muchas veces se hace es que los equipos que produscan mas seran automaticamente mas felices, cosa que no necesariamente es cierta. No debe olvidarse la esencia humana, de lo contrario se corre el riesgo de hacer de Scrum una herramienta de explotacion del capital humano de un equipo.
Suena simple pero en esencia eso es lo que es Scrum, no es algo que funcione o haya sido pensado para que una persona sea mas productiva, por el contrario es algo que se penso para que un equipo sea hiperproductivo.
Mas aun, segun Jeff Scrum tiene valor cuando la gente hace de esta su herramienta y la adapta a sus necesidades. Jeff sin embargo decia que esta no es una adaptacion libre, por el contrario es una adaptacion que se debe basar siempre en adoptar principios que hagan al equipo mas production. En otras palabras, las adaptacion que uno haga del marco de Scrum deberian caer dentro de los principios de Agile y Lean.
La suposicion que muchas veces se hace es que los equipos que produscan mas seran automaticamente mas felices, cosa que no necesariamente es cierta. No debe olvidarse la esencia humana, de lo contrario se corre el riesgo de hacer de Scrum una herramienta de explotacion del capital humano de un equipo.
Tuesday, March 9, 2010
Artful Making
Ayer estuve en un workshop con Lee Devin, uno de los autores de un libro buenisimo llamado Artful Making
Lee tiene una carrera bastante larga y exitosa como actor profesional y director de obras de teatro. Toda esa experiencia la volvo a ensenar teatro y eventualmente conocio al coautor del libro con el cual se animo a escribir acerca de como los ejercicios de relajacion y concentracion que utilizan los actores podrian ayudar a que la gente que trabaja en software pueda trabajar mejor.
El libro fue un exito y ahora son muchos managers e ingenieros al rededor del mundo lo leen. Definitivamente hay cosas en comun, el trabajo de los artistas es altamente desafiante e intelectualmente complicado-al igual que el nuestro. Basta con imaginarse la cantidad de parlamentos que los artistas tiene que memorizar y la gran capacidad de improvisacion que tiene que tener para cada obra. A esto hay que sumarle la gran capacidad de concentracion que deben tener para concentrarse en lo suyo y abstraerse de todo lo demas que pasa en el set de filmacion.
Desde la perspectiva de un manager hay mucho que copiar y aprender de un director de cine, despues de todo ambos dirigen grupos de individuos altamente talentosos y creativos. Dejar fluir esa creatividad es como dirigir una obra, es darle poder de decision y accion a los actores para que creen sobre la marcha pero siempre siguiendo un objetivo comun.
Lee tiene una carrera bastante larga y exitosa como actor profesional y director de obras de teatro. Toda esa experiencia la volvo a ensenar teatro y eventualmente conocio al coautor del libro con el cual se animo a escribir acerca de como los ejercicios de relajacion y concentracion que utilizan los actores podrian ayudar a que la gente que trabaja en software pueda trabajar mejor.
El libro fue un exito y ahora son muchos managers e ingenieros al rededor del mundo lo leen. Definitivamente hay cosas en comun, el trabajo de los artistas es altamente desafiante e intelectualmente complicado-al igual que el nuestro. Basta con imaginarse la cantidad de parlamentos que los artistas tiene que memorizar y la gran capacidad de improvisacion que tiene que tener para cada obra. A esto hay que sumarle la gran capacidad de concentracion que deben tener para concentrarse en lo suyo y abstraerse de todo lo demas que pasa en el set de filmacion.
Desde la perspectiva de un manager hay mucho que copiar y aprender de un director de cine, despues de todo ambos dirigen grupos de individuos altamente talentosos y creativos. Dejar fluir esa creatividad es como dirigir una obra, es darle poder de decision y accion a los actores para que creen sobre la marcha pero siempre siguiendo un objetivo comun.
Equipos Hiperproductivos
En el Scrum Gathering de Orlando 2010 acabo de escuchar una presentacion de Jeff Sutherland que para empezar fue buenisima y para continuar me hizo pensar en algunas cosas que no son tan evidentes.
Primero, segun Jeff la razon por la que el y Ken Schwaber crearon Scrum fue para poder tener proyectos exitosos en dominios caoticos como el de desarrollo de software. Jeff, que de formacion es piloto de combate y medico, se dio cuenta cuando paso a trabajar en la industria del software que ninguno de los principos tradicionales de ingeniria eran aplicables, habia que crear algo que se adaptase constantemente a circunstancias extremas.
Segundo, Scrum tiene por objetivo hacer que los equipos trabajen cuantitativa y cualitativamente mejor. Segun Jeff equipos que mejorarn un 20% despues de comenzar a utilizar Scrum practican algo que el llama "low Scrum", es decir, usan Scrum pero todavia no le sacaron todo el provecho que podrian. Razones para estas hay varias, desde falta de conocimiento hasta falta de apoyo de las organizaciones.
Tercero, los equipos hiperproductivos de los que hablar Jeff son equipos que mejoraron 100% o mas despues de usar Scrum. Suena extremo pero segun Jeff hay evidencia empirica y practica de que esto puede pasar.
Hablando de evidencia Jeff menciono algo interesante y basico a la vez, decia que si en un user story se tiene 20% de implementacion y 80% de testeo y bug fixing entonces la tasa neta de produccion es de apenas el 20%. Si esto podria invertirse y tener 80% desarrollo y 20% testeo mejoraria sustancialmente la produccion y la calidad del codigo en general. Esto segun Jeff ya implica una mejora cuanti y cualitativa.
Finalmente Jeff hablo acerca de la integracion de Scrum con CMMI, parece interesante y es un tema que estudiare mas a detalle. La verdad no estoy muy familiarizacon con CMMI asi que sera mi proximo objetivo de investigacion.
Primero, segun Jeff la razon por la que el y Ken Schwaber crearon Scrum fue para poder tener proyectos exitosos en dominios caoticos como el de desarrollo de software. Jeff, que de formacion es piloto de combate y medico, se dio cuenta cuando paso a trabajar en la industria del software que ninguno de los principos tradicionales de ingeniria eran aplicables, habia que crear algo que se adaptase constantemente a circunstancias extremas.
Segundo, Scrum tiene por objetivo hacer que los equipos trabajen cuantitativa y cualitativamente mejor. Segun Jeff equipos que mejorarn un 20% despues de comenzar a utilizar Scrum practican algo que el llama "low Scrum", es decir, usan Scrum pero todavia no le sacaron todo el provecho que podrian. Razones para estas hay varias, desde falta de conocimiento hasta falta de apoyo de las organizaciones.
Tercero, los equipos hiperproductivos de los que hablar Jeff son equipos que mejoraron 100% o mas despues de usar Scrum. Suena extremo pero segun Jeff hay evidencia empirica y practica de que esto puede pasar.
Hablando de evidencia Jeff menciono algo interesante y basico a la vez, decia que si en un user story se tiene 20% de implementacion y 80% de testeo y bug fixing entonces la tasa neta de produccion es de apenas el 20%. Si esto podria invertirse y tener 80% desarrollo y 20% testeo mejoraria sustancialmente la produccion y la calidad del codigo en general. Esto segun Jeff ya implica una mejora cuanti y cualitativa.
Finalmente Jeff hablo acerca de la integracion de Scrum con CMMI, parece interesante y es un tema que estudiare mas a detalle. La verdad no estoy muy familiarizacon con CMMI asi que sera mi proximo objetivo de investigacion.
Thursday, February 25, 2010
Sabores Agiles
La forma más fácil de ejemplificar el movimiento Ágil es pensar en un helado, no por lo fresco y frio sino porque viene en capas y sabores y a todo el mundo le encanta :)
La base del cono de los sabores agiles reside en toda la teoría que trae consigo el Toyota Production System que luego evoluciono hacia el Toyota Way. Subiendo un poco más hacia arriba vemos que lo anterior dio origen a la escuela de pensamiento Lean que Mary and Tom Poppendiek magistralmente plasmaron en su propuesta de Lean Software Development[1].
Lean fue uno de los puntos de inspiración para la redacción del Manifiesto Ágil[2]. Este manifiesto ha sido leído, consultado y citado en innumerables publicaciones. Sin embargo, por si solo el manifiesto no es algo que pueda ponerse directamente en la práctica.
De hecho tanto Lean como Agile son en esencia herramientas de razonamiento[3] que permiten observar, pensar y actuar de cierta forma. Por ejemplo el Lean sugiere principios como eliminar desperdicios[4] que lo que hacen es colocarnos en un estado mental predispuesto para identificar tareas que no contribuyan directamente a la generación de valor en el producto-desperdicio y que por tanto deban ser eliminadas.
En consecuencia alguien podrá decir “yo pienso agile o yo pienso lean” pero no podrá decir “yo implemento agile o yo implemento lean”. La diferencia entre el pensar y el hacer es lo que separa el cono de los sabores del helado.
El primer sabor es XP (eXtremme Programming[5]) y como en la figura es el sabor sobre el cual se apilan los demás. XP aglutina un conjunto de prácticas de ingeniería pensadas y orientadas totalmente al desarrollo de software. Consecuentemente las practicas de XP son cosas de las cuales no se puede (ni debe) prescindir en cualquier proyecto de desarrollo de software.
Me encanta hacer la analogía entre XP y un auto de F1 que fue construido con un único propósito: correr lo más rápida y efectivamente posible. A un F1 no es posible (bueno posible si pero peligroso :)) recortarle piezas; ya es una joya de ingeniería en sí que tiene lo mínimo necesario para correr. Similarmente XP es una obra maestra de buenas prácticas que deben existir (insisto todas) en un proyecto de software. XP ya es ligero como es, no hay necesidad de recortarle nada. En este sentido XP es el más prescriptivo de los sabores agiles.
El siguiente sabor es Scrum[6] que se concibió como un marco de trabajo[7] ligero que sugiere (no impone) roles, artefactos y ceremonias. Scrum es un marco de trabajo no necesariamente asociado a desarrollo de software, de hecho es tan flexible que puede ser adaptado a otros dominios de aplicación. Un ejemplo interesante ocurre en mi organización donde se está usando Scrum para impartir cursos de inglés.
Scrum formalizo-y porque no mejoro-algunas de las buenas prácticas agiles que existían desde hace tiempo como iteraciones y user stories. Una de las grandes ventajas-o desventajas como quiera verse-es que Scrum tiene detrás una organización sin fines de lucro: el Scrum Alliance[8] que es especialmente activa proporcionando entrenamientos y certificaciones.
La cereza sobre el helado es kanban[9] que es una gran mejora sobre el taskboard recomendado por Scrum.
Helado sin cono
¿Es posible aplicar kanban sin hacer Scrum/XP y pensar en Agile/Lean? Equivale a preguntarse ¿es posible tener solo el ultimo sabor del helado y además sin el cono? La respuesta es obvia, desde luego que si pero uno acaba perdiéndose los demás sabores y comodidad de tener un cono que sostenga el helado mientras uno se lo come.
¿Sería posible aplicar solo Scrum sin nada de XP? Desde luego que sí, pero en algo que no tenga que ver con software. Por ejemplo, ¿de que me serviría utilizar a cabalidad Scrum si mi proyecto no cuenta con un build machine que garantice la integración continua del código producido?
¿Tiene sentido aplicar los principios de XP sin pensar en Agile y Lean? Muchos equipos lo hacen, pero por mas fuertes que sean los principios XP estos no hacen hincapié en los factores humanos (me encanta llamar a esto peopleware) que son el gran capital de un proyecto. Lean es especialmente útil aquí, después de todo Lean es aquella cosa mágica que permitió que Toyota llegue donde llego, algo de bueno ha de tener como para dejarlo pasar :)
[1] Lean Software Development: An Agile Toolkit (Agile Software Development Series) by Mary Poppendieck and Tom Poppendieck (Paperback - May 18, 2003)
[2] http://www.agilemanifesto.org/
[3] Traduccion literal de “thinking tools”
[5] http://xprogramming.com/index.php
[8] www.scrumalliance.org
[9] http://www.infoq.com/minibooks/kanban-scrum-minibook
Friday, February 5, 2010
And Who Should Estimate?
Who is responsible for providing estimations? This is a question that is frequently being asked by teammates, especially when tasks are divided in development and testing tasks.
Some points that might answer this question below:
Some points that might answer this question below:
- User Stories should be estimated from the time they'll start until the time they'll be completed
- All related work has to be estimated, including of course testing work
- Developers and quality engineers might estimate their individual tasks but User Stories has to estimated in conjunction. There has to be agreement around how much it'll take to complete a User Story and not only about how long it will take to implemented it or just testing it
- Providing estimations is a collaborative tasks, actually it's a team effort so everybody has to be involved
- Teammates needs to be aware of the 'broader picture'. Sometimes teammates just care about their piece of work but forget about how that is connected to other's work
- At the end doesn't really matter who provide what estimation, what it matters is that the team feels comfortable with the estimations. Being comfortable means that the team has a gut feeling that estimations don't see to far stretched from reality
Subscribe to:
Posts (Atom)
