I´m seeing many job posts requesting for Scrum Masters for all type of companies. Seems like more and more Scrum Masters are on high demand as they´re perceived as the ultimate professionals in our field. Still perceptions can be misleading, so let me take you back to the very definition of what an Scrum Master is (or should be).
• A Scrum Master is somebody from the team, not an outsider.
• A Scrum Master does engineering work; this is not a management position.
• As a result a Scrum Master is only assigned to one team. Actually is not assigned, is more like somebody from the team that bubble up as a potential Scrum Master.
• Scrum Masters are Scrum champions and enthusiasts, not “master” in the sense that they have the more in deep knowledge of Scrum. They know Scrum well enough to make it work for a team and guide others to learn and practice good Scrum.
• The Scrum Master title is nothing more like a role that an engineer in the team takes. Is not a position per se, is more like a role that can and should rotate among team members.
• Scrum Masters are not responsible for team´s success or failure; at the most they are responsible for the team making good or bad use of Scrum principles.
• Scrum Masters are not necessarily technology masters, they don´t have all the answers, but they can help their teams to find the right answers via collaborative work.
• Scrum Masters in reality are masters in finding ways for keeping their teams aligned and pushing in the same direction.
• Scrum Masters are like “buffer men”, they keep outsiders at the bay but are wise enough to allow the team to open for not becoming a silo.
• Good Scrum Masters are individuals that volunteer for taking the challenge to learn and help their teams to practice good Scrum.
A quick note here, what is good Scrum? Is short, this is a simple set of principles that works for your team but that still fall inside the Scrum framework. Scrum Master are not there for reinventing Scrum, just for digesting it and being humble enough to serve their teams in the journey of learning and practicing Scrum.
Wednesday, July 21, 2010
Monday, May 31, 2010
Agile 2010
The Agile Alliance has confirmed that the 2010 conference will be in Orlando-Florida the second week of August
http://agile2010.agilealliance.org/
I´ll be there and hopefully this time I´ll have some time to visit Disney World :)
http://agile2010.agilealliance.org/
I´ll be there and hopefully this time I´ll have some time to visit Disney World :)
Friday, April 23, 2010
Agile Estimation and Planning: Demystifying the Black Art
This article is not about how to do estimation and planning in detail for Scrum teams, no magic recipes or silver bullets, it´s not also about numerical models or techniques one hundred percent bullet proof. This is more about what I saw that it works in practice and how this correlates with Agile and Scrum values.
That been said and if still have your attention, let me start saying that I´ve borrowed the phrase "Demystifying the Black Art" from a Steve McConnell´s book. I did this for a very good reason, I´ve read that book many times and my only conclusion is that is impossible to provide accurate estimations for the simple reason that no one can predict the future. Understanding this simple fact prepare us for start doing Scrum estimations. Part of the preparation is, if you´re a manager, that you´ll need to resign to have everything accurately estimated before work even started.
But then what? Are Scrum projects totally chaotic? In a way, yes they are, the great difference though is that Scrum publicly recognizes that chaos is there, embraced it and prepares your mind set to cope with continuous change and adaptation.
Reestimate, Reestimate, ….
So, the new game becomes now not how good am I estimating, but rather how often I reestimate. Estimations in Scrum are not cemented deals, they are negotiable as work progresses through sprints, but then, how I can keep things under control without exhausting my team by adding more and more work? Answer is simple; if you add work then you move less priority work to the backlog and reestimate accordingly.
Again, is not a matter of having precise estimations, is a matter of being prepared to reestimate whenever is necessary. Further, there´s a learning curve that Scrum take full advantage of it. For instance, if you estimate a task and then keep your estimations even if you know they are not longer valid, then there´s no chance to refine them with new information and experience. Scrum on the contrary favors that you look and your estimations and make them up as many times as you feel so.
Last part sounds like nightmare for many managers, but come on, reestimating not only means that the number of hours will increase; frequently reestimations take things in the other direction. After all, everybody knows that people try to be over-conservative when providing initial estimations. So if you reestimate, there´s a fair good chance that you reduce the initial slack that you put just in case things get ugly.
No Black Art Anymore
But wait, estimation is still black art, something is missing and that is how to actually estimate. You can read many good books on the subject written by Mike Cohn, even attend to his seminars if you can afford it, but here´s is my simple and free advice: use group estimation. Estimations that are provided not only by one individual but by a group have more value and more chances to be not so much off the mark, why? Only because group estimations force the group to think it through before putting estimates.
Another piece of free advice, actually this comes from McConnell, estimate using ranges like thinking first in worst case estimates, then in best case estimates and put your more realistic estimate somewhere inside that range. Again, if you think in this as a group exercise you´d have more chances to make it successful, at least it won´t be boring :)
But what if the group can´t come to an agreement? Well you can buy the Cohn´s planning poker decks; note that you´ll need one deck per each individual in your team. I offer you a cheaper and in some cultures more fun solution: just vote using your fingers to indicate numbers, like one finger for one, two fingers for two and so on.
Team Alignment is Key
If we reach this far you’re almost ready to discover the secret behind planning: the truth is that Scrum planning is not more than a short meeting (by short I mean less than four hours) divided in two halves whereas the first half is for understanding what user stories are and the second for providing estimations. Again nothing new here, Scrum has been talking about planning meetings for quite a while now. Understanding what to do seems to be crucial, but wait we´re doing Scrum, aren’t we? Don´t fall in the trap of trying to understand what needs to be done to the last detail even before coding a single line, the only way to truly understand something is when you actually do the work.
What´s the value of having planning meetings? The answer is quiet simple: you get all your team in room and make them talk about their understanding of what needs to be done. That simple exercise will do the magic of aligning everybody´s energy and attention towards a common goal (a.k.a. Sprint goal). Like Jeff Sutherland said "Scrum is all about aligning your team in the same direction" and hence is the true value of planning meetings.
That been said and if still have your attention, let me start saying that I´ve borrowed the phrase "Demystifying the Black Art" from a Steve McConnell´s book. I did this for a very good reason, I´ve read that book many times and my only conclusion is that is impossible to provide accurate estimations for the simple reason that no one can predict the future. Understanding this simple fact prepare us for start doing Scrum estimations. Part of the preparation is, if you´re a manager, that you´ll need to resign to have everything accurately estimated before work even started.
But then what? Are Scrum projects totally chaotic? In a way, yes they are, the great difference though is that Scrum publicly recognizes that chaos is there, embraced it and prepares your mind set to cope with continuous change and adaptation.
Reestimate, Reestimate, ….
So, the new game becomes now not how good am I estimating, but rather how often I reestimate. Estimations in Scrum are not cemented deals, they are negotiable as work progresses through sprints, but then, how I can keep things under control without exhausting my team by adding more and more work? Answer is simple; if you add work then you move less priority work to the backlog and reestimate accordingly.
Again, is not a matter of having precise estimations, is a matter of being prepared to reestimate whenever is necessary. Further, there´s a learning curve that Scrum take full advantage of it. For instance, if you estimate a task and then keep your estimations even if you know they are not longer valid, then there´s no chance to refine them with new information and experience. Scrum on the contrary favors that you look and your estimations and make them up as many times as you feel so.
Last part sounds like nightmare for many managers, but come on, reestimating not only means that the number of hours will increase; frequently reestimations take things in the other direction. After all, everybody knows that people try to be over-conservative when providing initial estimations. So if you reestimate, there´s a fair good chance that you reduce the initial slack that you put just in case things get ugly.
No Black Art Anymore
But wait, estimation is still black art, something is missing and that is how to actually estimate. You can read many good books on the subject written by Mike Cohn, even attend to his seminars if you can afford it, but here´s is my simple and free advice: use group estimation. Estimations that are provided not only by one individual but by a group have more value and more chances to be not so much off the mark, why? Only because group estimations force the group to think it through before putting estimates.
Another piece of free advice, actually this comes from McConnell, estimate using ranges like thinking first in worst case estimates, then in best case estimates and put your more realistic estimate somewhere inside that range. Again, if you think in this as a group exercise you´d have more chances to make it successful, at least it won´t be boring :)
But what if the group can´t come to an agreement? Well you can buy the Cohn´s planning poker decks; note that you´ll need one deck per each individual in your team. I offer you a cheaper and in some cultures more fun solution: just vote using your fingers to indicate numbers, like one finger for one, two fingers for two and so on.
Team Alignment is Key
If we reach this far you’re almost ready to discover the secret behind planning: the truth is that Scrum planning is not more than a short meeting (by short I mean less than four hours) divided in two halves whereas the first half is for understanding what user stories are and the second for providing estimations. Again nothing new here, Scrum has been talking about planning meetings for quite a while now. Understanding what to do seems to be crucial, but wait we´re doing Scrum, aren’t we? Don´t fall in the trap of trying to understand what needs to be done to the last detail even before coding a single line, the only way to truly understand something is when you actually do the work.
What´s the value of having planning meetings? The answer is quiet simple: you get all your team in room and make them talk about their understanding of what needs to be done. That simple exercise will do the magic of aligning everybody´s energy and attention towards a common goal (a.k.a. Sprint goal). Like Jeff Sutherland said "Scrum is all about aligning your team in the same direction" and hence is the true value of planning meetings.
Orlando Scrum Gathering
What a fantastic conference this has been! Check this link for a promotional video
http://www.scrumalliance.org/pages/media
And this other one for the presentations
http://www.scrumalliance.org/resources?tag=2010+Orlando+Gathering
Hope the Scrum Alliance continue organizing such great conferences
http://www.scrumalliance.org/pages/media
And this other one for the presentations
http://www.scrumalliance.org/resources?tag=2010+Orlando+Gathering
Hope the Scrum Alliance continue organizing such great conferences
Monday, April 19, 2010
Agiles 2010
La conferencia Latinoamericana de Metodologías Agiles ya está en marcha, más información aquí http://agiles2010.agiles.org/lang/es/
Herramientas Electrónicas y Scrum
Veo un tema que se repite una y otra vez en varios foros y grupos de discusión, siempre hay alguien que repite la misma pregunta, ¿cuál es la mejor herramienta para hacer buen planning y tracking con Scrum?
Dependiendo del grado de conocimiento y experiencia de la gente de estos grupos de discusión, las respuestas varían desde herramientas sofisticadas y costosas como VersionOne, Rally o ScrumWorks hasta cosas más simples como Scrumy o algo en el medio como Xplanner o PivotalTracker. Inclusive Microsoft hizo su aporte con su herramienta-super-complicada-apta-para-todo-uso Team Fundation Server.
Desde luego siempre habrá buenos vendedores que recomendaran utilizar sus herramientas ofreciendo soporte, descuento por licencias o quien sabe que otro atractivo. Pero hay algo de más de fondo, ¿qué tan exitosa puede ser una herramienta en un equipo que no crea en su uso? Más aun, las herramientas por si solas no harán ningún bien, más bien complicaran el trabajo de un equipo creando un overhead a la hora de registrar user stories y horas.
Yendo un paso mas atrás, ¿porque se deben utilizar herramientas electrónica para hacer tracking del progreso? La respuesta Scrum a la pregunta es porque tenemos un equipo distribuido, de los contrario deberíamos volver la vieja y efectiva escuela del post-it.
Una paso mas atrás todavía, ¿de qué sirven las herramientas si los equipos nos tienen sólidos principios ingenieriles y de trabajo en equipo? En mi experiencia las herramientas no hacen ningún bien por si solas sino vienen acompañadas de una solida base en Agile, XP, Scrum y otro sabores agiles.
Ahora bien, una experiencia interesante es introducir herramientas en paralelo a la introducción de conceptos agiles. Esto puede tener sentido ya que el equipo recibe la influencia directa de la herramienta y puede corresponderla con los conceptos.
Finalmente, la utilización efectiva y constante de las herramientas dependerá de cuan convencido de su utilidad el equipo este. Los buenos vendedores pueden vender licencias, mas son los coaches los que llevan a los equipos a su utilización efectiva, constante y productiva.
Dependiendo del grado de conocimiento y experiencia de la gente de estos grupos de discusión, las respuestas varían desde herramientas sofisticadas y costosas como VersionOne, Rally o ScrumWorks hasta cosas más simples como Scrumy o algo en el medio como Xplanner o PivotalTracker. Inclusive Microsoft hizo su aporte con su herramienta-super-complicada-apta-para-todo-uso Team Fundation Server.
Desde luego siempre habrá buenos vendedores que recomendaran utilizar sus herramientas ofreciendo soporte, descuento por licencias o quien sabe que otro atractivo. Pero hay algo de más de fondo, ¿qué tan exitosa puede ser una herramienta en un equipo que no crea en su uso? Más aun, las herramientas por si solas no harán ningún bien, más bien complicaran el trabajo de un equipo creando un overhead a la hora de registrar user stories y horas.
Yendo un paso mas atrás, ¿porque se deben utilizar herramientas electrónica para hacer tracking del progreso? La respuesta Scrum a la pregunta es porque tenemos un equipo distribuido, de los contrario deberíamos volver la vieja y efectiva escuela del post-it.
Una paso mas atrás todavía, ¿de qué sirven las herramientas si los equipos nos tienen sólidos principios ingenieriles y de trabajo en equipo? En mi experiencia las herramientas no hacen ningún bien por si solas sino vienen acompañadas de una solida base en Agile, XP, Scrum y otro sabores agiles.
Ahora bien, una experiencia interesante es introducir herramientas en paralelo a la introducción de conceptos agiles. Esto puede tener sentido ya que el equipo recibe la influencia directa de la herramienta y puede corresponderla con los conceptos.
Finalmente, la utilización efectiva y constante de las herramientas dependerá de cuan convencido de su utilidad el equipo este. Los buenos vendedores pueden vender licencias, mas son los coaches los que llevan a los equipos a su utilización efectiva, constante y productiva.
Monday, April 5, 2010
Agile Course Related Blogs
Some of the guys in the last Agile Course have been kind enough to publish in their blogs some notes and comments, check this link
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.
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.
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
Friday, January 22, 2010
Splitting User Stories
I've heard many times from my teams that they have a hard time estimating user stories that are moved from the backlog to the Sprint, the most commonly sited problems are related to the size and ambiguity of user stories. I believe that this happens partly because the confusion about the backlog, more precisely, teams tend to think that there's only one backlog.
It's crucial that Scrum teams to recognize that in fact there are two backlogs, one Product Backlog and one Sprint Backlog. I describe below some characteristics of both:
It's crucial that Scrum teams to recognize that in fact there are two backlogs, one Product Backlog and one Sprint Backlog. I describe below some characteristics of both:
- The Product Backlog contains high level user stories created mainly by the Product Owner. Those user stories has to have business value and usually will require a lot of man-hours to implement.
- User Stories in the Product Backlog has to be prioritized by the Product Owner based on her perception of business. Of course teams can have an stake on this but business value should be the key driver.
- During the planing stage, teams take user stories from the top of the Product Backlog, digest them and decide what to include in the Sprint Backlog. Teams are expected to split Backlog User Stories in smaller chunks if necessary. Actually, it's highly recommended that they do so. Note that Product Backlog User Stories are high level whereas Sprint Backlog User Stories has to be good instruments for estimation, planning, and tracking. The 'devide and conquer' principle is applicable here.
- Even before deciding what to move to the Sprint Backlog, teams need to considered their velocity (measured in story points or hours) to have a feel of their capacity. Velocity is a great indicator that helps preventing teams for overcommitting, of course that for this to be effective, teams need to have a clear perception of their velocity.
- A crucial point here is that teams and not Product Owners decide what to move to the Sprint Backlog. Of course that the PO can influence and negotiate, but she shouldn't be allowed to overload teams beyond their capacity. Successful teams don't refuse to work on something, they accept to work on that something in exchange of something else.
- A symptom-at least in early Sprints-for things not going that well is that the Sprint Backlog would be bigger than the Product Backlog, this might indicate that: A, the Product Backlog doesn't exist or still in process of being created or B, the team is overcommitting and trying to complete too many User Stories in an Sprint. A could be a also a indicator that the PO is not involved in the project. B typically happens when teams aren't aware of their own velocity.
Thursday, January 21, 2010
User Stories Size, Having a Problem Estimating Them?
Estimating user stories size can become a dangerous obsession, I mean, what are the changes that you can accurately estimate the size of a piece of work in a changeable and fuzzy domain like software development? The more experience that you acquire on this, the more that you'd tend to answer that chances are very slim. And why is that? Part of this is because you don't have fixed requirements, actually you don't want to have fixed requirements, we're doing Agile remember?
But then, how can you provide estimates to keep your bosses happy? You might try to provide extra-super-pessimistic estimations to create some buffering in case things get ugly, but this might create the false perception in management that you are inefficient or at least lazy-not a bad estimator which in reality you maybe are.
So, the advice that I can provide is first start evaluating your user stories to order them from ultra-complex to piece of cake. Knowing that something would be twice as complex as something else will provide you visibility on what should be tackled first or by whom in the team. Once you have your user stories ordered, you can add a countable unit (like story points, complexity level, effort or whatever that you consider appropriate) to your user stories. By doing this, management would perceive the complexity (and hopefully the cost) of implementing something and would be able to pick what should be implemented first or what is more crucial.
Shifting management's focus from accuracy in estimations to complexity could give you some degrees to maneuver. At least you won't have to worry because you offset the mark for X number of hours. You'd be worried instead for keeping complexity under an manageable level.
But then, how can you provide estimates to keep your bosses happy? You might try to provide extra-super-pessimistic estimations to create some buffering in case things get ugly, but this might create the false perception in management that you are inefficient or at least lazy-not a bad estimator which in reality you maybe are.
So, the advice that I can provide is first start evaluating your user stories to order them from ultra-complex to piece of cake. Knowing that something would be twice as complex as something else will provide you visibility on what should be tackled first or by whom in the team. Once you have your user stories ordered, you can add a countable unit (like story points, complexity level, effort or whatever that you consider appropriate) to your user stories. By doing this, management would perceive the complexity (and hopefully the cost) of implementing something and would be able to pick what should be implemented first or what is more crucial.
Shifting management's focus from accuracy in estimations to complexity could give you some degrees to maneuver. At least you won't have to worry because you offset the mark for X number of hours. You'd be worried instead for keeping complexity under an manageable level.
Subscribe to:
Posts (Atom)
