Thursday, March 25, 2010

Total Football and Scrum

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.

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.

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.

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.

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.