"Cuando usted hace las cosas comunes en la vida de un modo poco común, usted mandará la atención del mundo." George Washington Carver
Innovación: La frontera sin limites
Una de las cosas mas preciadas de el proceso Scrum es un resultado indirecto del implemento de el proceso. Los resultados directos son el incremento en la calidad de la code, el acortamiento del tiempo de desarrollo, y la reducción del costo de desarrollar nuevos programas. Pero tiene otros resultados, uno importante siendo que el equipo técnico generalmente se siente mucho mejor yendo a el trabajo cada día. Los miembros del equipo se encuentran con mas tiempo, mejor balance de vida y se sienten como si tuvieran real importancia en la organización. Esto quizás sea un poco raro en Latinoamérica, pero en EEUU el sentimiento mayor de la gente de IT es que no se da la importancia o respeto al trabajo.
Cuando los miembros del equipo se sienten razonablemente cargados, y un poco cómodos, y además un poco felices – entonces una de las mejores partes de Scrum puede empezar a dar flor. Con el tiempo adecuado, y por las herramientas y el sistema (retrospectiva e “inspect and adapt”) los miembros de el equipo deberían de tener tiempo para innovar. Mucho valor se pone acá para la innovación, pero muy poca preparación se da para ello. Muchas compañías se valoran dependiendo a su innovación, y las que no se inventan directamente pro esto, cuando menos ven el valor de tener varios productos nuevos para ofrecer a sus clientes. Entonces, que se puede hacer para poder fomentar el medioambiente adecuado para la innovación? He aquí mi receta:
1. Correr Retrospectivas robustas
2. Hacer tiempo en cada sprint para pensar
3. Poner en lugar una área para que los equipos convivan en este modo de pensar
4. Deje que miembros de otros equipos participen cuando sea posible
5. Valore los resultados
6. Deje que los equipos se guíen solos
1. Por que las retrospectivas? Porque es aquí donde el equipo aprende a observarse y a pensar en la solución que ayudara a el equipo a salir a un nivel mas alto. Esto requiere los principios de la innovación, y guiar a el equipo en una propia retrospectiva lo ayudara muchísimo a poder pensar adecuadamente para innovar.
2. El Sprint siempre estará bajo el ataque. Si no es el ataque de sacar lo mas que se puede a el tiempo dado, o bajo el brazo pesado de un PO que quiere conocer los métricos o el equipo propio tratando de sacar código perfecto – es facilísimo destruir el sprint. Pero, si en el propio sprint se da un poco de tiempo para pensar sobre la innovación (ya sea reducción de deuda técnica, o pensar en nuevos productos, o nuevas herramientas) se da un paso muy fuerte adelante para el equipo y la compañía. Este paso se debe de tomar con el primer paso en efecto – si el equipo nada mas usa la retrospectiva para llorar y sentirse mal, este tiempo es “waste”!
3. 4. y 6. De los puntos este es mi favorito! Y tiene dos posibilidades – una mucho mas divertida que la otra. En mi trabajo de Scrum Coach, tuve el placer de trabajar con dos jefes que sabían valorar Scrum y la innovación. También tuve la oportunidad de añadir mis ideas en conjunto con las de mis jefes para ver un resultado muy bueno. Mi CIO empezó a dar valor a la innovación en la compañía al comenzar dos iniciativas, ambas caen en la primera categoría: La área de innovación dentro del trabajo.
El tenia una “junta” con todos los miembros de IT. Esta “junta” era un tiempo se 30 minutos cada semana, y estaba diseñada específicamente para tener el tiempo necesario para pensar y someter ideas inovativas para el concurso. El concurso se corría cada mes, y tenia premios medianos pero muy útiles. Esto funciono muy bien para un grupo selecto y pequeño de la organización. La mayoría de las personas en IT no entendían ni estaban cómodas con la estructura, ya que dependía en el individualismo.
Para mi, el mejor resultado salió de mantener esta área Fuera del trabajo, la que representa la segunda opción. No solo se presta para divertirse mas (Margaritas, Tapas, Sangría) pero se permite que personas de diferentes equipos se junten, y que hablen abiertamente de el trabajo y de sus ideas. De esta junta informal (los Jueves se mantenía la junta “Scrumarita”) salió la idea de un proyecto mediano que ahorro a la compañía unos 700 mil dólares mensuales, al formarse un equipo “pirata” de dos miembros con un ScrumMaster. En esta manera informal, muchas mas gentes estaban interesadas.
Con el ejemplo anterior, se puede ver el valor del punto 6. Dejando que se organicen a si mismo resulto en la identificación de intereses comunes, y rápidamente se resolvió una área que necesitaba atención. Generalmente, tener un intercambio que requiere pensamiento de resolución de problemas para el trabajo necesita que la localidad este fuera de el edificio de trabajo – ya que se remueven muchos obstáculos mentales.
5. Finalmente hay que encontrar manera de reconocer a las ideas que se sugieren por los equipos. Claro, no todo es posible de implementar, pero cuando menos se debería tener un programa de reconocimiento – quizás un poco de dinero, o un concurso para la mejor idea. A algunas gentes les agrada el tiempo libre – de alguna manera se debería de cultivar el proceso, para asegurarse que los equipos estén siempre pensando en ideas nuevas.
To keep this small, here goes in English:
"When you do the common things in life in an uncommon way, you will command the attention of the world." George Washington Carver
Innovation - the frontier without boundries
One of the most prized things that happen with the Scrum process is a side effect of implementation. The direct benefits of Scrum implementation include improvement on the quality of the code, the decrease of development time and the reduction of cost in the development of new programs. But there are other results, one of the more important ones is that a technical team will feel much better going to work each morning, having a better life/work balance and the team feels like they matter in the organization. This may be slightly different in Latin America, but in the US the majority of people in IT feel that they do not matter all that much and are not well respected.
When the members of the team feel reasonably tasked, and a bit comfortable, and possibly a little happy – then one of the best parts of Scrum can start to happen. With the right time, and the proper tools (retrospective) and due to the nature of the process (inspect and adapt) the team should have enough time to be able to start innovating. Although innovation is seemingly very valued here in the states. Very little preparation is taken to enable it. Many companies value themselves based on their innovations, and those that do not have this as a calling card at least see the value in bringing new products to market to offer their clients. So what can be done to modify the environment so it is adequate for innovation to take place? Here is my recipe for this:
1. Run Robust Retrospectives
2. Make time each sprint for thinking
3. Set aside a location for team members to collaborate while thinking (or their thoughts)
4. Allow members of other teams to also participate
5. Value the results
6. Let the teams manage themselves
1. Why Retrospectives? Because the retrospective is where the team learns to observe itself and provide a solution to help itself to higher levels of performance. This requires the basic principles of innovation, and guiding the team in a proper retrospective will help lots toward allowing them to think about innovation properly.
2. The sprint is always under attack. If it’s not trying to cram all we can in as little time as possible, or working under a heavy handed PO that wants to know the metrics or the team itself trying to develop “perfect code” – it is very easy to disrupt a sprint. But, finding time within the sprint to think about innovation (whether Technical Debt reduction, new product development or new tool development) you take a strong step forward for the team and the company to foster innovation. This string step needs to be taken only after step 1 is in place – if the team only uses retrospectives as a complaining session or to feel sorry for themselves, this time cam be classified as “waste” (Muda)!
3. 4. & 6. Of all the points this is my favorite! And it has two possible implementations – one much more fun than the other. In my role as a Scrum Coach, I had the pleasure of working with two bosses that valued Scrum and innovation. I also had the opportunity to add my ideas in conjunction with those from management to ensure a positive result. Our CIO started to value innovation at our company by starting two initiatives, both of which fit in the first category: A space for innovation within the work environment.
Our CIO called a “meeting” for all the people within IT. This “meeting” was a 30 minute window set aside each week and was specifically designated to think about and submit innovative ideas for the contest he ran. This contest was run monthly, and had mid range prizes that were neat and useful. This worked well for a select group of individuals within the organization. The majority of people within IT either did not understand or were not comfortable with the structure, however; as it relied heavily on individual contributions.
For me, the best result with this approach is to have a meeting outside of work – off site – which represents the second option. Not only can this meeting be a lot more fun (Margaritas, Appetizers, Sangria) but it allows for people from different teams to participate, and openly talk about work and their ideas. From this informal meeting (we had a Thursday meeting, “Scrumarita”) we had an idea for a mid size project that ended up saving the company 700K monthly, as we formed a pirate team of two members with a ScrumMaster. Many more people were interested in this informal forum.
With the last example, you can see the value of point 6. Leaving the team to self organize resulted in the identification of common interests and an area that sorely needed attention was tackled. Generally speaking, having an interchange of ideas that requires though for resolution of a problem with work requires a location outside of the work environment – because a lot of mental blocks are inadvertently removed.
5. Finally, you have to find a way to recognize the ideas that are suggested by the teams. Of course, not everything is worth pursuing, but at least there should be some sort of recognition program – maybe a small amount of money, or a contest to determine the best idea. Some people are motivated by time off – in some manner the process of innovation should be cultivated, so that you can ensure the teams will be thinking about new ideas.
Wednesday, September 2, 2009
Wednesday, August 5, 2009
La Santidad de la Sprint
Paciencia Por Favor!!
Estoy usando una nueva herramineta para traduccion (spelling y grammar). Por favor indiquenme si salio algo mal o no tan claro..
Ahora para el posting...
“Prefiero supervisar las operaciones enteras del gobierno yo mismo, más bien que confiar el negocio público a subordinados, y esto hace mis deberes muy grandes.”
Esta quotacion es un poco mas obscura – es de James K. Polk, el onceavo presidente de los Estados Unidos. En el tiempo que dijo esto, EEUU apenas llegaba al rio Mississippi, y la frontera del Oeste era la nueva acquicision de Louisiana. Aqui estaba a punto de poner un gran desservicio a la humanidad, con muchos de los lideres de pensamiento civil opuestos contra el cristalizando sus pensamientos (entre ellos Henry Thoreaou y Frederick Douglass) y dejando a la nacion de EEUU con las semillas de la impendiente guerra civil.
Que interesante comienzo! Que podríamos discutir que cuando menos se relate un poco a tan pesado propósito y sus graves resultados? Una de las mas contra intuitivas de las nomenclatures de Scrum es el Sprint mismo. El Sprint es dificultoso como concepto porque mucho de Scrum se propone el balance, la organización a si misma y la colaboración, donde el Sprint connota competición, enfoque y velocidad. Así que como es que una palabra tan cargada se usa para lo que queremos describir? Precisamente por la naturaleza de Scrum mismo y la importancia de la iteración de trabajo. La Sprint es el tiempo alocado para que el equipo termine su trabajo comprometido, ocurre después de el planeo y el compromiso del equipo, y acaba con la demostración. La junta diaria (standup) es el punto de toque diario para que el equipo mantenga informadas a todas la gentes que tengan interés del progreso; pero aun aquí, solo los marranitos (pigs) pueden hablar. Scrum, a parte grande es de compromisos reciprócales – y uno de los resultados de esto es que durante el sprint, solamente que sea absolutamente necesario, el equipo debe de ser DEJADO SOLO PARA COMPLETAR SU TRABAJO. Aun así, hay gente que como James Polk que se piensan tan importantes que no pueden confiar a el equipo para acabar el trabajo cometido, y no se dejaran afuera de el trabajo diario del equipo.
En esta nota, exploremos los peligros para un sprint. Yo personalmente he notado lo siguiente: Mucho cambio en dirección, muchos “tasks” (¿tareas?) trabajados en conjunto, falta de enfoque para terminar las tareas, falta de comunicación entre miembros del equipo, añadimiento de trabajo en medio del sprint, añadimiento de trabajo de soporte en medio del sprint, disrupciones por el management de IT, disrupciones por el Product Owner, y disrupciones por los ejecutivos. Como se puede ver, algunos de estas cosas están completamente entre el poder del equipo para resolver. Algunas estarán entre el poder de la organización de IT, y otras solo se pueden resolver en el circulo mas grande, con la organización entera necesitando un cambio de pensamiento. En mi experiencia, la mayoría de estos problemas nacen por un pobre entendimiento de lo que un “sprint” es y lo que ser “ágil” verdaderamente es.
En primer lugar, el Sprint. La palabra sí misma dibuja el debate entre el culto en Ágil y Scrum. Parece demasiada áspera, también tiempo dependiente, demasiada enfocada. Y esto es exactamente por qué es completamente adecuada para describir lo que un equipo de Scrum debe hacer. Esto es uno de muchos ejemplos de lo contra-intuitivo encontrado en el mundo Ágil. En el mundo de carreras, un sprint es una de las (si no la) carreras más cortas que pueden ser dirigidas. En una carrera más larga, un corredor puede ajustar y encontrar su paso. Si un error ocurre, ajustes pueden corregirlo. En un sprint – no hay ningún tiempo para esto. La manera que se comienza la carrera debe ser tan perfectamente posible, porque dentro de un ratito la carrera se termina. Un corredor debe concentrarse, solamente en una cosa – corriendo tan perfectamente como él posiblemente puede, de modo que él o ella puedan terminar en el mejor tiempo que ellos pueden conseguir. En cierto modo, la carrera es dirigida en contra de uno mismo. De esta manera, un equipo de Scrum debe tratar su compromiso. El Dueño de Producto (P.O.) consiente en permitir que el tiempo necesario para que el equipo pueda entregar a lo qué ellos se han comprometido en la sesión de planificación. Como un corredor, el equipo debe concentrarse exclusivamente en el objetivo enfrente de ellos. Cualquier influencia exterior quebrantara el enfoque del equipo y pondrá en peligro el éxito del sprint. Justo como un corredor en un sprint sufriendo un calambre, o perdiendo un zapato – cualquier pequeña cosa puede tener resultados catastróficos. Esto puede parecer muy académico a algunos practicantes, pero el hecho es que si las excepciones son hechas ellos tienden a crecer como hábitos. ¡Y los hábitos son muy difíciles de romperse, y fácil a aprovechar!
Ahora a la definición de "Ágil". He oído muchas cosas sobre esto, y he visto varias aplicaciones. En términos generales, el modo apropiado de usar esto es para una organización que va a tratar de encontrar alguna metodología ligera que le ayuda a realizar sus necesidades de desarrollo de software. La manera más común es que las organizaciones modifiquen lo que es juzgado como una práctica de Scrum estricta en algo más cómodo – y menos confiable, casi siempre una forma de la Scrum But o otra. El error principal de este esfuerzo muy comúnmente es que devalúa el compromiso recíproco entre el equipo de IT y la comunidad de comercio. O esto permite que el equipo de IT utilice sus malos hábitos para suprimir lo que ellos juzgan innecesario (demostración, standups diarios, planificación, documentación) por lo general para “entregar más rápido”. El pensamiento ágil es disciplinado. El pensamiento ágil es de colaboración, confianza y transparencia. Cuando el control, o el rastreo, o resultado en tiempo conducido son deseados, es posible que usted no este pensando de un modo Ágil. Y la parte triste de esto es que he visto equipos IT y equipos Comerciales reforzar la ambigüedad en el término para satisfacer sus necesidades – a su daño combinado.
Para esta entrada, quiero concentrarme en el impedimento más fácil de prevenir – el compromiso recíproco. Cuando un equipo y un Dueño de Producto (P.O.) están en la misma página, y hay protección de accionistas por el PO y colaboración con el ScrumMaster y transparencia entre el equipo entero, las cosas tienden a salir bien y en un modelo para mejorar. Cuando hay desconfianza, y una falta de entendimiento del proceso muy a menudo el fracaso y movimiento sin avance son el resultado. Yo he tenido el privilegio de trabajar en una tal situación. El equipo era un equipo bueno, con deseo de aplacar y superarse. Era, sin embargo un equipo inmaduro, careciendo de disciplina y práctica del proceso de Scrum. El P.O. era inteligente e involucrado, interesado en darle al equipo todo que ellos necesitaban para trabajar. En la superficie era una situación muy ideal. Pero dentro del primer sprint, se hizo claro que había problemas de transparencia y confianza serios. EL P.O. creía en el equilibrio de carga del equipo, sin tener en cuenta el estado durante el standup. El equipo no quiso ser atado a longitudes de sprint fijas, sobre todo en release, y quería entregar código completamente perfecto solamente. Pareció que el asunto se calmo con el proceso de mejora (bootstrapping), pero cuando problemas serios se encontraron se deshizo el proceso. El PO sintió fuertemente que una mano más pesada seria necesaria para asegurar que las cosas salieran bien, e inmediatamente se pusieron a tomar una postura como Polk declaro al inicio. Esto exacerbó los problemas de confianza dentro del equipo, y causó la “obra sin resultado” aumentada y disminuyó la calidad. El sprint nunca fue respetado, y extraordinariamente, aunque la entrega de la mayor parte de historias fue conseguida, los managers se enfocaron sólo en los fracasos principales y en el castigo a los miembros de equipo responsables (otra indicación que el pensamiento Ágil no está en el uso). La realización de Scrum falló – aunque el equipo estuviera al borde del éxito. Los socios de negocio no tuvieron la paciencia, y el equipo fue abandonado para tratar de entender cosas entre ellos. Y todo esto fue explicado y se derivó bajo el paraguas “de ser ágil”
¿Imagine qué hubiera pasado si el PO decide confiar en el equipo? ¿Si el equipo se hubiese mirado a si mismo y hubiera insistido en mejorar con retrospectivas sólidas? ¿Si en vez de mirar un instrumento de rastreo y descubrir "disponibilidad" el PO hubiera escuchado y hubiera hecho preguntas durante el standup? Muchos problemas habrían sido prevenidas, y el éxito habría sido el resultado. Pero cada uno implicó ser ágil, y no tomo su responsabilidad. Si usted no entiende la naturaleza del compromiso recíproco o la santidad del sprint, usted no puede tener un entendimiento sólido del proceso de Scrum. ¿Si usted tiene la colaboración, pero no la confianza o la transparencia, usted puede tener que dar un paso atrás y preguntarse – cuál es mi objetivo? ¿Ser ágil, o tener éxito? Un grande hombre una vez dijo “The Respect for the rights of others is Peace”. Si el equipo se respeta, no hay nada que no se puede conseguir.
Now in English...
"I prefer to supervise the whole operations of the government myself rather than entrust the public business to subordinates, and this makes my duties very great.”
This quote is a little more obscure – from James K. Polk, the eleventh president of the United States. In his time the US barely reached across the Mississippi river, and the newly bought Louisiana Purchase was the western frontier. He was about to unleash a great disservice to mankind, with many of the thought leaders in opposition to him crystallizing their views (Henry Thoreau and Frederick Douglass amongst them) and with the nation left with the seeds of the looming civil war.
This is an interesting start! SO what do we discuss that is at least mildly related to such a statement and a grave result? Well, one of the most counterintuitive of the Scrum nomenclatures, the sprint itself. The Sprint is challenging because most of Scrum is about balance, self-organization and collaboration, where a sprint denotes competition, focus and speed. So why use such a word for what we want to describe? Precisely because of the nature of Scrum itself and the importance of the iteration. The sprint is the allotted time the team has to perform it’s work, it occurs after planning and commitment and ends with a demonstration. The standup meeting is the daily touch point for all interested parties to see what the team is doing, but even at this, the pigs are the only to speak. Scrum to a large degree is about reciprocal commitments – and one of the results of this is that during the sprint, unless absolutely necessary, the team should be LEFT ALONE TO DO IT’S WORK. Yet, there are many like James Polk who think themselves so important that they do not trust the team to perform to it’s commitment, and will not be left out of the daily work.
On that note, let’s review the dangers to the sprint. I have personally witnessed the following: Too much shift in focus, too many tasks being worked at once, not enough focus on completing tasks, no communication between team members, addition of work for stories mid sprint, addition of production support efforts to team, influence from IT management, influence from other teams, influence from PO, and influence from executives. As you can see, some of these things are well within the team’s influence to resolve. Some are within the IT organization and some are at the outermost circle, with the whole organization requiring a change. In my experience, most of these issues stemmed from lack of understanding of what a “sprint” is about and what being “agile” means.
First, the sprint. The word itself draws debate amongst the learned in Agile and Scrum. It seems too harsh, too time driven, too focused. And this is precisely why it is completely adequate for describing what a scrum team must do. This is one of the many examples of counter intuitiveness found in the Agile world. In the world of racing, a sprint is one of the (if not the) shortest races that can be run. In a longer race, a runner can adjust and find his pace. If a mistake is made, adjustments can correct it. In a sprint – there is no time for this. The way you start the race must be as perfect as possible, for in a short time span it is all but over. A racer must focus, on one thing only – running as perfectly as he possibly can, so that he or she can finish in the best time that they can achieve. In a sense, the race is run against oneself. In this way, a Scrum team is to treat their commitment. The Product Owner agrees to allow the time needed for the team to deliver what they have committed to at the planning session. Like a runner, the team must focus exclusively on the goal before it. Any outside influence will throw the team off focus and will endanger the sprint’s success. Just like a runner in a sprint suffering a cramp, or loosing a shoe – any small issue can have devastating results. This may seem very academic to some practitioners, but the fact is that if exceptions are made they tend to become habits. And habits are very hard to break, and easy to take advantage of!
Now to the definition of “Agile”. I have heard many things on this, and seen a few applications. Generally speaking, the proper way to use this is for an organization to try to find some lightweight methodology to fit its software development needs. The most common way is for organizations to modify what is deemed as a strict scrum practice into something more palatable – and less reliable, almost always one form of Scrum But or another. The main fallacy of this very common approach is that it devalues the reciprocal commitment between the team and the business partnership. Or it enables the IT team to utilize it’s bad habits to do away with what they deem unnecessary (demos, daily standups, planning, documentation) usually to “deliver faster”. Agile thought is disciplined. Agile thinking is collaborative, it is trusting and transparent. When a controlling or tracking or time driven outcome is desired, you may not be thinking in an Agile way. And the sad part of this is that I have seen the IT and the Business teams leverage ambiguity in the term to suit their needs – to their combined harm.
For this entry, I want to focus on the easiest impediment to prevent – the reciprocal commitment. When a team and a Product Owner are on the same page, and there is protection from stakeholders from the PO and collaboration with the ScrumMaster and transparency between the entire team, things tend to proceed well and in an improvement pattern. When there is distrust, and a lack of understanding of the process very often failure and churn are the result. I have the privilege of working in one such situation. The team was a good team, with a willingness to please and perform. It was, however an immature team, lacking discipline and practice of the Scrum process. The PO was intelligent and engaged, and interested in giving the team all it needed to succeed. On the surface it was a very ideal situation. But within the first sprint, it became clear that there were serious trust and transparency issues. The PO believed in load balancing the team, regardless of the standup status. The team did not want to be bound to fixed sprint lengths, especially on releases, and wanted to deliver completely perfect code. The matter seemed to settle with the bootstrapping process, but when serious issues were encountered things fell apart. The PO felt strongly that a heavier hand was needed to ensure things went well, and immediately proceeded to take a Polk stance as stated above. This exacerbated the trust issues within the team, and resulted in increased churn and decreased quality. The sprint was never respected, and amazingly, although delivery of most stories was achieved, management focused only on the main failures and on punishment to the team members responsible (another flag that Agile thinking is not in use). The scrum implementation failed – although the team was on the verge of success. The business partners ran out of patience, and the team was left to try to figure things out amongst themselves. And all of this was explained and derived under the umbrella of “being agile”
Imagine what would have happened if the PO decided to trust the team? If the team had looked at itself and insisted on improving through solid retrospectives? If instead of looking at a tracking tool and finding “availability” the PO would have listened and asked questions during the standup? A lot of issues would have been prevented, and success would have been the result. But everyone involved wanted to be agile, and not take responsibility. If you do not understand the nature of the reciprocal commitment or the sanctity of the sprint, you may not have a solid understanding of the scrum process. If you have collaboration, but not trust or transparency, you may need to take a step back and ask yourself – what is my goal? To be agile, or to be successful? A great man once said “El respeto al derecho ajeno es la paz”. If the team respects itself, there is nothing it cannot achieve.
Estoy usando una nueva herramineta para traduccion (spelling y grammar). Por favor indiquenme si salio algo mal o no tan claro..
Ahora para el posting...
“Prefiero supervisar las operaciones enteras del gobierno yo mismo, más bien que confiar el negocio público a subordinados, y esto hace mis deberes muy grandes.”
Esta quotacion es un poco mas obscura – es de James K. Polk, el onceavo presidente de los Estados Unidos. En el tiempo que dijo esto, EEUU apenas llegaba al rio Mississippi, y la frontera del Oeste era la nueva acquicision de Louisiana. Aqui estaba a punto de poner un gran desservicio a la humanidad, con muchos de los lideres de pensamiento civil opuestos contra el cristalizando sus pensamientos (entre ellos Henry Thoreaou y Frederick Douglass) y dejando a la nacion de EEUU con las semillas de la impendiente guerra civil.
Que interesante comienzo! Que podríamos discutir que cuando menos se relate un poco a tan pesado propósito y sus graves resultados? Una de las mas contra intuitivas de las nomenclatures de Scrum es el Sprint mismo. El Sprint es dificultoso como concepto porque mucho de Scrum se propone el balance, la organización a si misma y la colaboración, donde el Sprint connota competición, enfoque y velocidad. Así que como es que una palabra tan cargada se usa para lo que queremos describir? Precisamente por la naturaleza de Scrum mismo y la importancia de la iteración de trabajo. La Sprint es el tiempo alocado para que el equipo termine su trabajo comprometido, ocurre después de el planeo y el compromiso del equipo, y acaba con la demostración. La junta diaria (standup) es el punto de toque diario para que el equipo mantenga informadas a todas la gentes que tengan interés del progreso; pero aun aquí, solo los marranitos (pigs) pueden hablar. Scrum, a parte grande es de compromisos reciprócales – y uno de los resultados de esto es que durante el sprint, solamente que sea absolutamente necesario, el equipo debe de ser DEJADO SOLO PARA COMPLETAR SU TRABAJO. Aun así, hay gente que como James Polk que se piensan tan importantes que no pueden confiar a el equipo para acabar el trabajo cometido, y no se dejaran afuera de el trabajo diario del equipo.
En esta nota, exploremos los peligros para un sprint. Yo personalmente he notado lo siguiente: Mucho cambio en dirección, muchos “tasks” (¿tareas?) trabajados en conjunto, falta de enfoque para terminar las tareas, falta de comunicación entre miembros del equipo, añadimiento de trabajo en medio del sprint, añadimiento de trabajo de soporte en medio del sprint, disrupciones por el management de IT, disrupciones por el Product Owner, y disrupciones por los ejecutivos. Como se puede ver, algunos de estas cosas están completamente entre el poder del equipo para resolver. Algunas estarán entre el poder de la organización de IT, y otras solo se pueden resolver en el circulo mas grande, con la organización entera necesitando un cambio de pensamiento. En mi experiencia, la mayoría de estos problemas nacen por un pobre entendimiento de lo que un “sprint” es y lo que ser “ágil” verdaderamente es.
En primer lugar, el Sprint. La palabra sí misma dibuja el debate entre el culto en Ágil y Scrum. Parece demasiada áspera, también tiempo dependiente, demasiada enfocada. Y esto es exactamente por qué es completamente adecuada para describir lo que un equipo de Scrum debe hacer. Esto es uno de muchos ejemplos de lo contra-intuitivo encontrado en el mundo Ágil. En el mundo de carreras, un sprint es una de las (si no la) carreras más cortas que pueden ser dirigidas. En una carrera más larga, un corredor puede ajustar y encontrar su paso. Si un error ocurre, ajustes pueden corregirlo. En un sprint – no hay ningún tiempo para esto. La manera que se comienza la carrera debe ser tan perfectamente posible, porque dentro de un ratito la carrera se termina. Un corredor debe concentrarse, solamente en una cosa – corriendo tan perfectamente como él posiblemente puede, de modo que él o ella puedan terminar en el mejor tiempo que ellos pueden conseguir. En cierto modo, la carrera es dirigida en contra de uno mismo. De esta manera, un equipo de Scrum debe tratar su compromiso. El Dueño de Producto (P.O.) consiente en permitir que el tiempo necesario para que el equipo pueda entregar a lo qué ellos se han comprometido en la sesión de planificación. Como un corredor, el equipo debe concentrarse exclusivamente en el objetivo enfrente de ellos. Cualquier influencia exterior quebrantara el enfoque del equipo y pondrá en peligro el éxito del sprint. Justo como un corredor en un sprint sufriendo un calambre, o perdiendo un zapato – cualquier pequeña cosa puede tener resultados catastróficos. Esto puede parecer muy académico a algunos practicantes, pero el hecho es que si las excepciones son hechas ellos tienden a crecer como hábitos. ¡Y los hábitos son muy difíciles de romperse, y fácil a aprovechar!
Ahora a la definición de "Ágil". He oído muchas cosas sobre esto, y he visto varias aplicaciones. En términos generales, el modo apropiado de usar esto es para una organización que va a tratar de encontrar alguna metodología ligera que le ayuda a realizar sus necesidades de desarrollo de software. La manera más común es que las organizaciones modifiquen lo que es juzgado como una práctica de Scrum estricta en algo más cómodo – y menos confiable, casi siempre una forma de la Scrum But o otra. El error principal de este esfuerzo muy comúnmente es que devalúa el compromiso recíproco entre el equipo de IT y la comunidad de comercio. O esto permite que el equipo de IT utilice sus malos hábitos para suprimir lo que ellos juzgan innecesario (demostración, standups diarios, planificación, documentación) por lo general para “entregar más rápido”. El pensamiento ágil es disciplinado. El pensamiento ágil es de colaboración, confianza y transparencia. Cuando el control, o el rastreo, o resultado en tiempo conducido son deseados, es posible que usted no este pensando de un modo Ágil. Y la parte triste de esto es que he visto equipos IT y equipos Comerciales reforzar la ambigüedad en el término para satisfacer sus necesidades – a su daño combinado.
Para esta entrada, quiero concentrarme en el impedimento más fácil de prevenir – el compromiso recíproco. Cuando un equipo y un Dueño de Producto (P.O.) están en la misma página, y hay protección de accionistas por el PO y colaboración con el ScrumMaster y transparencia entre el equipo entero, las cosas tienden a salir bien y en un modelo para mejorar. Cuando hay desconfianza, y una falta de entendimiento del proceso muy a menudo el fracaso y movimiento sin avance son el resultado. Yo he tenido el privilegio de trabajar en una tal situación. El equipo era un equipo bueno, con deseo de aplacar y superarse. Era, sin embargo un equipo inmaduro, careciendo de disciplina y práctica del proceso de Scrum. El P.O. era inteligente e involucrado, interesado en darle al equipo todo que ellos necesitaban para trabajar. En la superficie era una situación muy ideal. Pero dentro del primer sprint, se hizo claro que había problemas de transparencia y confianza serios. EL P.O. creía en el equilibrio de carga del equipo, sin tener en cuenta el estado durante el standup. El equipo no quiso ser atado a longitudes de sprint fijas, sobre todo en release, y quería entregar código completamente perfecto solamente. Pareció que el asunto se calmo con el proceso de mejora (bootstrapping), pero cuando problemas serios se encontraron se deshizo el proceso. El PO sintió fuertemente que una mano más pesada seria necesaria para asegurar que las cosas salieran bien, e inmediatamente se pusieron a tomar una postura como Polk declaro al inicio. Esto exacerbó los problemas de confianza dentro del equipo, y causó la “obra sin resultado” aumentada y disminuyó la calidad. El sprint nunca fue respetado, y extraordinariamente, aunque la entrega de la mayor parte de historias fue conseguida, los managers se enfocaron sólo en los fracasos principales y en el castigo a los miembros de equipo responsables (otra indicación que el pensamiento Ágil no está en el uso). La realización de Scrum falló – aunque el equipo estuviera al borde del éxito. Los socios de negocio no tuvieron la paciencia, y el equipo fue abandonado para tratar de entender cosas entre ellos. Y todo esto fue explicado y se derivó bajo el paraguas “de ser ágil”
¿Imagine qué hubiera pasado si el PO decide confiar en el equipo? ¿Si el equipo se hubiese mirado a si mismo y hubiera insistido en mejorar con retrospectivas sólidas? ¿Si en vez de mirar un instrumento de rastreo y descubrir "disponibilidad" el PO hubiera escuchado y hubiera hecho preguntas durante el standup? Muchos problemas habrían sido prevenidas, y el éxito habría sido el resultado. Pero cada uno implicó ser ágil, y no tomo su responsabilidad. Si usted no entiende la naturaleza del compromiso recíproco o la santidad del sprint, usted no puede tener un entendimiento sólido del proceso de Scrum. ¿Si usted tiene la colaboración, pero no la confianza o la transparencia, usted puede tener que dar un paso atrás y preguntarse – cuál es mi objetivo? ¿Ser ágil, o tener éxito? Un grande hombre una vez dijo “The Respect for the rights of others is Peace”. Si el equipo se respeta, no hay nada que no se puede conseguir.
Now in English...
"I prefer to supervise the whole operations of the government myself rather than entrust the public business to subordinates, and this makes my duties very great.”
This quote is a little more obscure – from James K. Polk, the eleventh president of the United States. In his time the US barely reached across the Mississippi river, and the newly bought Louisiana Purchase was the western frontier. He was about to unleash a great disservice to mankind, with many of the thought leaders in opposition to him crystallizing their views (Henry Thoreau and Frederick Douglass amongst them) and with the nation left with the seeds of the looming civil war.
This is an interesting start! SO what do we discuss that is at least mildly related to such a statement and a grave result? Well, one of the most counterintuitive of the Scrum nomenclatures, the sprint itself. The Sprint is challenging because most of Scrum is about balance, self-organization and collaboration, where a sprint denotes competition, focus and speed. So why use such a word for what we want to describe? Precisely because of the nature of Scrum itself and the importance of the iteration. The sprint is the allotted time the team has to perform it’s work, it occurs after planning and commitment and ends with a demonstration. The standup meeting is the daily touch point for all interested parties to see what the team is doing, but even at this, the pigs are the only to speak. Scrum to a large degree is about reciprocal commitments – and one of the results of this is that during the sprint, unless absolutely necessary, the team should be LEFT ALONE TO DO IT’S WORK. Yet, there are many like James Polk who think themselves so important that they do not trust the team to perform to it’s commitment, and will not be left out of the daily work.
On that note, let’s review the dangers to the sprint. I have personally witnessed the following: Too much shift in focus, too many tasks being worked at once, not enough focus on completing tasks, no communication between team members, addition of work for stories mid sprint, addition of production support efforts to team, influence from IT management, influence from other teams, influence from PO, and influence from executives. As you can see, some of these things are well within the team’s influence to resolve. Some are within the IT organization and some are at the outermost circle, with the whole organization requiring a change. In my experience, most of these issues stemmed from lack of understanding of what a “sprint” is about and what being “agile” means.
First, the sprint. The word itself draws debate amongst the learned in Agile and Scrum. It seems too harsh, too time driven, too focused. And this is precisely why it is completely adequate for describing what a scrum team must do. This is one of the many examples of counter intuitiveness found in the Agile world. In the world of racing, a sprint is one of the (if not the) shortest races that can be run. In a longer race, a runner can adjust and find his pace. If a mistake is made, adjustments can correct it. In a sprint – there is no time for this. The way you start the race must be as perfect as possible, for in a short time span it is all but over. A racer must focus, on one thing only – running as perfectly as he possibly can, so that he or she can finish in the best time that they can achieve. In a sense, the race is run against oneself. In this way, a Scrum team is to treat their commitment. The Product Owner agrees to allow the time needed for the team to deliver what they have committed to at the planning session. Like a runner, the team must focus exclusively on the goal before it. Any outside influence will throw the team off focus and will endanger the sprint’s success. Just like a runner in a sprint suffering a cramp, or loosing a shoe – any small issue can have devastating results. This may seem very academic to some practitioners, but the fact is that if exceptions are made they tend to become habits. And habits are very hard to break, and easy to take advantage of!
Now to the definition of “Agile”. I have heard many things on this, and seen a few applications. Generally speaking, the proper way to use this is for an organization to try to find some lightweight methodology to fit its software development needs. The most common way is for organizations to modify what is deemed as a strict scrum practice into something more palatable – and less reliable, almost always one form of Scrum But or another. The main fallacy of this very common approach is that it devalues the reciprocal commitment between the team and the business partnership. Or it enables the IT team to utilize it’s bad habits to do away with what they deem unnecessary (demos, daily standups, planning, documentation) usually to “deliver faster”. Agile thought is disciplined. Agile thinking is collaborative, it is trusting and transparent. When a controlling or tracking or time driven outcome is desired, you may not be thinking in an Agile way. And the sad part of this is that I have seen the IT and the Business teams leverage ambiguity in the term to suit their needs – to their combined harm.
For this entry, I want to focus on the easiest impediment to prevent – the reciprocal commitment. When a team and a Product Owner are on the same page, and there is protection from stakeholders from the PO and collaboration with the ScrumMaster and transparency between the entire team, things tend to proceed well and in an improvement pattern. When there is distrust, and a lack of understanding of the process very often failure and churn are the result. I have the privilege of working in one such situation. The team was a good team, with a willingness to please and perform. It was, however an immature team, lacking discipline and practice of the Scrum process. The PO was intelligent and engaged, and interested in giving the team all it needed to succeed. On the surface it was a very ideal situation. But within the first sprint, it became clear that there were serious trust and transparency issues. The PO believed in load balancing the team, regardless of the standup status. The team did not want to be bound to fixed sprint lengths, especially on releases, and wanted to deliver completely perfect code. The matter seemed to settle with the bootstrapping process, but when serious issues were encountered things fell apart. The PO felt strongly that a heavier hand was needed to ensure things went well, and immediately proceeded to take a Polk stance as stated above. This exacerbated the trust issues within the team, and resulted in increased churn and decreased quality. The sprint was never respected, and amazingly, although delivery of most stories was achieved, management focused only on the main failures and on punishment to the team members responsible (another flag that Agile thinking is not in use). The scrum implementation failed – although the team was on the verge of success. The business partners ran out of patience, and the team was left to try to figure things out amongst themselves. And all of this was explained and derived under the umbrella of “being agile”
Imagine what would have happened if the PO decided to trust the team? If the team had looked at itself and insisted on improving through solid retrospectives? If instead of looking at a tracking tool and finding “availability” the PO would have listened and asked questions during the standup? A lot of issues would have been prevented, and success would have been the result. But everyone involved wanted to be agile, and not take responsibility. If you do not understand the nature of the reciprocal commitment or the sanctity of the sprint, you may not have a solid understanding of the scrum process. If you have collaboration, but not trust or transparency, you may need to take a step back and ask yourself – what is my goal? To be agile, or to be successful? A great man once said “El respeto al derecho ajeno es la paz”. If the team respects itself, there is nothing it cannot achieve.
Saturday, August 1, 2009
Defendiendo los indefensibles vs. Defendiendo los indefensos
"Mejor morir a pie que vivir de rodillas"
La mayoría de nosotros somos familiares con las palabras de Zapata. Cien anos anteriores (cuando menos) en EEUU, el mismo sentimiento fue expresado por Patrick Henry, cuando dijo "Give me liberty or give me death". Para tener una revolución se requiere el ímpetus del cambio, algo nos hace reaccionar y el individuo invoca sus derechos humanos y se levanta para enfocarse y forzar el cambio. Después de el cerrillo inicial, la revolución quema fuertemente, pero al pasar de el tiempo, la gente se cansa y se empieza a tratar de normalizar la situación. Se pregunta uno, porque estoy peleando? Con cuanto cambio se puede vivir? Por que se requiere el cambio?
En la guerra de independencia de EEUU, se piensa que el 90% de la populación era loyalista - soportaba a el Rey de Inglaterra y NO a los revolucionarios. La revolución estadounidense no tardo mucho, y la estructura del liderazgo se mantuvo intacta - dándole la única posibilidad de el resultado que hoy se ve. En Latinoamérica, por lo mucho no se vio este resultado, y las guerras de independencia y cambio duraron muchísimo mas.
Siendo ScrumMaster, se ve que el cambio que se requiere de la organización es un cambio gigante. Se sabe que el "paradigm shift" requerido para poder pensar ágilmente involucra no solo IT, sino que casi todos los departamentos de la organización. IT casi siempre es el grupo que comienza el cambio, aunque yo he visto que a veces el grupo de negocios lo ha empezado. Todos los demás grupos no tienen necesidad del cambio, ya que ellos tienen su estructura y manera de trabajar. Para poder tener un cambio completo (para poder emular a Toyota y a Google) requiere MUCHISIMO esfuerzo, tiempo y sacrificio. La mayoría de las empresas (imagínense las compañías!) no tienen lo necesario para poder pagar por este cambio, ni en manera monetaria, ni emocional, ni en tiempo. Pero si como ScrumMaster les puedes dirigir, y si se empeñan a tratar de cambiar - entonces vale la pena el esfuerzo! Para el ScrumMaster, esto debe ser clarísimo, ya que el primero que cae en los frentes de la revolución es el General de campo (Washington, Gandhi, Hidalgo y Bolívar son ejemplos buenísimos de este hecho). Si se puede efectuar el cambio, el General es un héroe y merece la adulación y gracias de la organización o pueblo. Si no se puede efectuar el cambio, pues ya la historia nos da el resultado.
Entonces, con el conocimiento de arriba, como se reacciona un buen ScrumMaster (al estilo de Ron Jeffries) cuando el mismo equipo de Scrum se niega a cambiar? Cuando el equipo de IT actualmente hace excusas por el resto de una organización para NO efectuar el cambio? Cuando los "lideres" de IT se enfocan a sacudir la educación y la implementación de Scrum o Agil en la compañía? El riesgo que uno toma al enfocar el cambio es casi insurmentable, y como ScrumMaster se encuentran individuales que aman y entienden la metodología. Pero también se encuentra el sabotaje, se encuentran los miembros nefarios, y los que no quieren el cambio. Para muchos de nuestros compañeros, esto es incomprensible. Yo lo he encontrado de cinco equipos cuando menos dos veces. Una fue traición abierta, y se pudo identificar tempranamente y proteger al equipo. La otra fue presión personal de un individuo del equipo, pero sus decisiones internas afectaron al equipo negativamente. De ambos casos escribiré después, por ahora quiero enfocar - cuando se defiende al que quiere y cuando se defiende a los que no quieren, con tanto riesgo al cuello del ScrumMaster?
Se comprende bien cuando la resistencia al cambio se enfoca fuera de los equipos. La mejor defensa para esta resistencia es el desarrollo de los equipos a una mas alta nivel de producción y comunicación, conjuntada con un nivel mas alto de educación para el grupo resistente (comunicando expectativas propias). Es fácil ganar este argumento cuando se ve el resultado de el equipo (dado en working software, delivered value, y aceleración del tiempo de desarrollo). Pero cuando la resistencia es interior de IT, y específicamente cuando se encuentra uno con un equipo dividido, la reacción para mi es mas difícil. Claro, en el mismo cambio y tempranamente se encontraran con los individuos que no quieren ser parte de un equipo. Esto es fácil de remediar. Pero después, cuando empezamos a implementar ScrumBut, quien tiene el derecho de requerir el cambio? Cuanto compromiso es suficiente? Y como se maneja el grupo que dice querer cambiar pero que no se empeña en hacer ningún sacrificio para el cambio? Últimamente, y con un equipo entero he llegado a una simple solución - se deja el equipo en el nivel de la mediocridad que se le hace cómodo. He llegado a que NO se defienden los que no quieren ser defendidos.
Con el grupo mixto, cuando se ve que la mitad o mas de el grupo quiere efectuar los cambios, pero el PO no quiere cambiar; o el Lead Developer no deja que los desorraldores hagan lo que necesitan - como se abandona el grupo? Como se pregunta el cambio de las "golden calves" de la organización, cuando esto mismo es rogar por el termino? Claro, muchas veces en la organización se llega a la observación "Mira, esos ScrumMasters no hacen nada!! Que valor nos dan? Y nos cuestan tanto..." Estas organizaciones no entienden el rol del liderazgo. Y no deben de ser defendidas! Pero el equipo, los que si quieren...
Hay un dicho cuando uno empieza la certificación de ScrumMaster "a dead ScrumMaster can help no one". Acordando con las organizaciones, he visto dos muertes de Scrum. He educado a mis equipos, y muchas implementaciones han nacido de mis esfuerzos. Pero si no se puede tener una implementación debido a la organización misma, la muerte es inevitable. Quizás es mejor identificar esto tempranamente, pedir los cambios inmutables y tener el cesamiento del esfuerzo en este tiempo mas temprano para el beneficio de los que quieren hacer lo que es necesario - que seguir tratando de defender lo indefensible, y morir en emboscada por un equipo inmaduro o no cometido. Con el único resultado de ver a el resto del equipo a sufrir el regreso a una marcha de muerte...
Now in English -
“It's better to die upon your feet than to live upon your knees!”
Most of us are familiar with the words of Emiliano Zapata. One hundred years before him (at least) in the United States, the same thought was expressed by Patrick Henry, when he said “Give me liberty or give me death”. In order to start a revolution we need to have the necessity for change, something that makes us react and the individual will invoke his human rights and takes a stand in order to focus and force the needed change. After the initial spark, the revolution burns strongly, but as time passes, people get tired and they inevitably try to normalize their surroundings. They ask themselves, why am I fighting? With how much change can we live? Why do we even need this change?
In the war of Independence of the United States, it is thought that 90% of the colonists were loyalists – supporters of the King of England and NOT of the revolutionaries. The American Revolution was relatively short lived, and the leadership structure was left intact – giving it the only possibility for the result that we now see. In Latin America, for the most part this was not the case, and the wars of independence lasted a lot longer.
Being a ScrumMaster, you see that the change that an organization needs to undertake is a gigantic endeavor. You know the kind of “paradigm shift” required for an Agile mindset to occur involves not only IT, but almost all the departments within the organization. IT usually is the department that is leading the change, although I have seen at least one case in which the business has started the implementation. All the other departments may not need to change, given that they probably have their way of doing things. To have a complete change of mindset (to emulate Toyota or Google) requires an INMENSE effort, time and sacrifice. Most industries (not to mention companies) do not have what it takes to be able to undertake this change, neither monetarily, nor emotionally, nor in terms of time. But if as a ScrumMaster you can guide them, and they are willing to try to change – then it is worth the effort in undertaking! For the ScrumMaster, it should be very clear that the first leader that falls in the front of the revolution is the Field General (Washington, Gandhi, Hidalgo and Bolivar are great examples of this fact). If you can get the change in place, the General is a hero and deserves the adulation and thanks of the organization or people he helped. If the leader cannot affect the change, well history tells us what happens in these cases.
With the above being known, how should a good ScrumMaster (a Ron Jeffries emulator) react when the Scrum team itself refuses to change? When the IT team actually makes excuses for the rest of the organization in order to NOT affect change? When the IT “leaders” focus on placing Scrum education and implementation on a shaky basis for the company? The risk that one takes in helping to get a focus for change is almost insurmountable, and as a ScrumMaster you will find individuals that understand and love the Agile methodologies. But you also will find saboteurs, nefarious users and those that are threatened by change. Many in the Agile movement find this incomprehensible. In the five teams I have helped lead, I have discovered these types of scenarios twice. Once, it was a sabotage issue, and I was able to identify it and try to protect the team. The other was due to an individual team member’s pressure, but his own decisions affected the team badly. I will write about both of these cases in detail later, but for now I want to focus on this point – when do you defend those who want to be protected and when do you defend those who do not want protection, with so much risk riding on the ScrumMaster’s neck?
It is easy to understand when you meet resistance to change from outside IT groups. The best defense against this type of resistance is the development of the teams to a higher level of performance and communication, in conjunction with an educational push for the resisting team (setting appropriate expectations). It is easy to win this argument when the team’s results are easy to see (especially in terms of working software, delivered value, and time to market acceleration). But when the resistance is from within the IT organization, and specifically when you are dealing with a divided team, it is more difficult to have an appropriate reaction. Of course, you will see the individuals who resist change and teamwork very early on just due to the changes that are needed. This is relatively easy to remedy. But after a while, when the organization begins to adopt ScrumBut, who has the right to request change? What compromise level is enough? And how do you handle a team that says it is interested in change but that will refuse to make any sacrifice needed for change to take place? Ultimately, with one team I have come to a simple solution – you leave the team at the level of mediocrity it finds comfortable. I have reached the point of NOT defending those who do not want to be protected.
With a mixed team, when you see that half or more of the members want to commit to the changes, but the PO is not interested; or the Lead Developer does not let the Developers do what they need – how can you abandon this team? How do you ask the organization to change the “golden calves”, when this is at best dangerous or possibly career ending? Of course, some organizations reach a point where they observe ”These ScrumMasters don’t do much!! What value do they really bring? And they are a bit expensive…” These organizations do not understand the role of leadership. And they should not be helped! But the team, those that really want it…
There is an adage you may hear when you get your ScrumMaster certification “A dead ScumMaster can help no one”. I have seen two failed Scrum implementations in the organizations I have tried to help. I have educated my teams, and many other implementations have come as a direct result of these efforts. But if the implementation is not organizationally possible, the death of the effort is inevitable. Perhaps it may be easier to identify this possibility early on, asking for those immutable changes at this early stage and have the effort cease at the earlier time frame for the benefit of those that want to implement the needed changes – rather than continuing to try to defend the indefensible, and suffering sabotage at the hands of an immature or uncommitted team or organization. With the only reward being for you to see the teams slip back into a return to a death march…
La mayoría de nosotros somos familiares con las palabras de Zapata. Cien anos anteriores (cuando menos) en EEUU, el mismo sentimiento fue expresado por Patrick Henry, cuando dijo "Give me liberty or give me death". Para tener una revolución se requiere el ímpetus del cambio, algo nos hace reaccionar y el individuo invoca sus derechos humanos y se levanta para enfocarse y forzar el cambio. Después de el cerrillo inicial, la revolución quema fuertemente, pero al pasar de el tiempo, la gente se cansa y se empieza a tratar de normalizar la situación. Se pregunta uno, porque estoy peleando? Con cuanto cambio se puede vivir? Por que se requiere el cambio?
En la guerra de independencia de EEUU, se piensa que el 90% de la populación era loyalista - soportaba a el Rey de Inglaterra y NO a los revolucionarios. La revolución estadounidense no tardo mucho, y la estructura del liderazgo se mantuvo intacta - dándole la única posibilidad de el resultado que hoy se ve. En Latinoamérica, por lo mucho no se vio este resultado, y las guerras de independencia y cambio duraron muchísimo mas.
Siendo ScrumMaster, se ve que el cambio que se requiere de la organización es un cambio gigante. Se sabe que el "paradigm shift" requerido para poder pensar ágilmente involucra no solo IT, sino que casi todos los departamentos de la organización. IT casi siempre es el grupo que comienza el cambio, aunque yo he visto que a veces el grupo de negocios lo ha empezado. Todos los demás grupos no tienen necesidad del cambio, ya que ellos tienen su estructura y manera de trabajar. Para poder tener un cambio completo (para poder emular a Toyota y a Google) requiere MUCHISIMO esfuerzo, tiempo y sacrificio. La mayoría de las empresas (imagínense las compañías!) no tienen lo necesario para poder pagar por este cambio, ni en manera monetaria, ni emocional, ni en tiempo. Pero si como ScrumMaster les puedes dirigir, y si se empeñan a tratar de cambiar - entonces vale la pena el esfuerzo! Para el ScrumMaster, esto debe ser clarísimo, ya que el primero que cae en los frentes de la revolución es el General de campo (Washington, Gandhi, Hidalgo y Bolívar son ejemplos buenísimos de este hecho). Si se puede efectuar el cambio, el General es un héroe y merece la adulación y gracias de la organización o pueblo. Si no se puede efectuar el cambio, pues ya la historia nos da el resultado.
Entonces, con el conocimiento de arriba, como se reacciona un buen ScrumMaster (al estilo de Ron Jeffries) cuando el mismo equipo de Scrum se niega a cambiar? Cuando el equipo de IT actualmente hace excusas por el resto de una organización para NO efectuar el cambio? Cuando los "lideres" de IT se enfocan a sacudir la educación y la implementación de Scrum o Agil en la compañía? El riesgo que uno toma al enfocar el cambio es casi insurmentable, y como ScrumMaster se encuentran individuales que aman y entienden la metodología. Pero también se encuentra el sabotaje, se encuentran los miembros nefarios, y los que no quieren el cambio. Para muchos de nuestros compañeros, esto es incomprensible. Yo lo he encontrado de cinco equipos cuando menos dos veces. Una fue traición abierta, y se pudo identificar tempranamente y proteger al equipo. La otra fue presión personal de un individuo del equipo, pero sus decisiones internas afectaron al equipo negativamente. De ambos casos escribiré después, por ahora quiero enfocar - cuando se defiende al que quiere y cuando se defiende a los que no quieren, con tanto riesgo al cuello del ScrumMaster?
Se comprende bien cuando la resistencia al cambio se enfoca fuera de los equipos. La mejor defensa para esta resistencia es el desarrollo de los equipos a una mas alta nivel de producción y comunicación, conjuntada con un nivel mas alto de educación para el grupo resistente (comunicando expectativas propias). Es fácil ganar este argumento cuando se ve el resultado de el equipo (dado en working software, delivered value, y aceleración del tiempo de desarrollo). Pero cuando la resistencia es interior de IT, y específicamente cuando se encuentra uno con un equipo dividido, la reacción para mi es mas difícil. Claro, en el mismo cambio y tempranamente se encontraran con los individuos que no quieren ser parte de un equipo. Esto es fácil de remediar. Pero después, cuando empezamos a implementar ScrumBut, quien tiene el derecho de requerir el cambio? Cuanto compromiso es suficiente? Y como se maneja el grupo que dice querer cambiar pero que no se empeña en hacer ningún sacrificio para el cambio? Últimamente, y con un equipo entero he llegado a una simple solución - se deja el equipo en el nivel de la mediocridad que se le hace cómodo. He llegado a que NO se defienden los que no quieren ser defendidos.
Con el grupo mixto, cuando se ve que la mitad o mas de el grupo quiere efectuar los cambios, pero el PO no quiere cambiar; o el Lead Developer no deja que los desorraldores hagan lo que necesitan - como se abandona el grupo? Como se pregunta el cambio de las "golden calves" de la organización, cuando esto mismo es rogar por el termino? Claro, muchas veces en la organización se llega a la observación "Mira, esos ScrumMasters no hacen nada!! Que valor nos dan? Y nos cuestan tanto..." Estas organizaciones no entienden el rol del liderazgo. Y no deben de ser defendidas! Pero el equipo, los que si quieren...
Hay un dicho cuando uno empieza la certificación de ScrumMaster "a dead ScrumMaster can help no one". Acordando con las organizaciones, he visto dos muertes de Scrum. He educado a mis equipos, y muchas implementaciones han nacido de mis esfuerzos. Pero si no se puede tener una implementación debido a la organización misma, la muerte es inevitable. Quizás es mejor identificar esto tempranamente, pedir los cambios inmutables y tener el cesamiento del esfuerzo en este tiempo mas temprano para el beneficio de los que quieren hacer lo que es necesario - que seguir tratando de defender lo indefensible, y morir en emboscada por un equipo inmaduro o no cometido. Con el único resultado de ver a el resto del equipo a sufrir el regreso a una marcha de muerte...
Now in English -
“It's better to die upon your feet than to live upon your knees!”
Most of us are familiar with the words of Emiliano Zapata. One hundred years before him (at least) in the United States, the same thought was expressed by Patrick Henry, when he said “Give me liberty or give me death”. In order to start a revolution we need to have the necessity for change, something that makes us react and the individual will invoke his human rights and takes a stand in order to focus and force the needed change. After the initial spark, the revolution burns strongly, but as time passes, people get tired and they inevitably try to normalize their surroundings. They ask themselves, why am I fighting? With how much change can we live? Why do we even need this change?
In the war of Independence of the United States, it is thought that 90% of the colonists were loyalists – supporters of the King of England and NOT of the revolutionaries. The American Revolution was relatively short lived, and the leadership structure was left intact – giving it the only possibility for the result that we now see. In Latin America, for the most part this was not the case, and the wars of independence lasted a lot longer.
Being a ScrumMaster, you see that the change that an organization needs to undertake is a gigantic endeavor. You know the kind of “paradigm shift” required for an Agile mindset to occur involves not only IT, but almost all the departments within the organization. IT usually is the department that is leading the change, although I have seen at least one case in which the business has started the implementation. All the other departments may not need to change, given that they probably have their way of doing things. To have a complete change of mindset (to emulate Toyota or Google) requires an INMENSE effort, time and sacrifice. Most industries (not to mention companies) do not have what it takes to be able to undertake this change, neither monetarily, nor emotionally, nor in terms of time. But if as a ScrumMaster you can guide them, and they are willing to try to change – then it is worth the effort in undertaking! For the ScrumMaster, it should be very clear that the first leader that falls in the front of the revolution is the Field General (Washington, Gandhi, Hidalgo and Bolivar are great examples of this fact). If you can get the change in place, the General is a hero and deserves the adulation and thanks of the organization or people he helped. If the leader cannot affect the change, well history tells us what happens in these cases.
With the above being known, how should a good ScrumMaster (a Ron Jeffries emulator) react when the Scrum team itself refuses to change? When the IT team actually makes excuses for the rest of the organization in order to NOT affect change? When the IT “leaders” focus on placing Scrum education and implementation on a shaky basis for the company? The risk that one takes in helping to get a focus for change is almost insurmountable, and as a ScrumMaster you will find individuals that understand and love the Agile methodologies. But you also will find saboteurs, nefarious users and those that are threatened by change. Many in the Agile movement find this incomprehensible. In the five teams I have helped lead, I have discovered these types of scenarios twice. Once, it was a sabotage issue, and I was able to identify it and try to protect the team. The other was due to an individual team member’s pressure, but his own decisions affected the team badly. I will write about both of these cases in detail later, but for now I want to focus on this point – when do you defend those who want to be protected and when do you defend those who do not want protection, with so much risk riding on the ScrumMaster’s neck?
It is easy to understand when you meet resistance to change from outside IT groups. The best defense against this type of resistance is the development of the teams to a higher level of performance and communication, in conjunction with an educational push for the resisting team (setting appropriate expectations). It is easy to win this argument when the team’s results are easy to see (especially in terms of working software, delivered value, and time to market acceleration). But when the resistance is from within the IT organization, and specifically when you are dealing with a divided team, it is more difficult to have an appropriate reaction. Of course, you will see the individuals who resist change and teamwork very early on just due to the changes that are needed. This is relatively easy to remedy. But after a while, when the organization begins to adopt ScrumBut, who has the right to request change? What compromise level is enough? And how do you handle a team that says it is interested in change but that will refuse to make any sacrifice needed for change to take place? Ultimately, with one team I have come to a simple solution – you leave the team at the level of mediocrity it finds comfortable. I have reached the point of NOT defending those who do not want to be protected.
With a mixed team, when you see that half or more of the members want to commit to the changes, but the PO is not interested; or the Lead Developer does not let the Developers do what they need – how can you abandon this team? How do you ask the organization to change the “golden calves”, when this is at best dangerous or possibly career ending? Of course, some organizations reach a point where they observe ”These ScrumMasters don’t do much!! What value do they really bring? And they are a bit expensive…” These organizations do not understand the role of leadership. And they should not be helped! But the team, those that really want it…
There is an adage you may hear when you get your ScrumMaster certification “A dead ScumMaster can help no one”. I have seen two failed Scrum implementations in the organizations I have tried to help. I have educated my teams, and many other implementations have come as a direct result of these efforts. But if the implementation is not organizationally possible, the death of the effort is inevitable. Perhaps it may be easier to identify this possibility early on, asking for those immutable changes at this early stage and have the effort cease at the earlier time frame for the benefit of those that want to implement the needed changes – rather than continuing to try to defend the indefensible, and suffering sabotage at the hands of an immature or uncommitted team or organization. With the only reward being for you to see the teams slip back into a return to a death march…
Wednesday, July 22, 2009
De pensamientos revolucionarios avanza la civilizacion
Este es mi primer blog. Hola Mundo Lindo!!
Por ahora, escribo de mis observaciones laborales - en mi trabajo como ScrumMaster. Escribo en Espanol (y malamente ya que mi equipo es destacado a Ingles) para mantener anonimidad y un seguro de separacion de la opinion a mi empleo. Claro, si quisiera alguien saber, seria facilicimo traducir.
Para mi, desde muy pequeno mis heroes siempre han sido los revolucionarios. El cambio que ellos traen a la humanidad requiere una respuesta, ya sea silenciar el progreso o adaptar a la nueva realidad. Entre mis heroes personales se encuentran Benjamin Franklin, Pancho Villa y Emiliano Zapata, Alexander Hamilton, Miguel Hidalgo, George Washington, Benito Juarez y Abraham Lincolin, Mahatma Ghandi, Jesu Cristo, Tesla y Edison, los hermanos Wright, Dumont y hasta Napoleon Bonaparte.
Para mi, estos hombres cambiaron la realidad de las circumstancias en su tiempo, y requirieron que el mundo cambiese con ellos. Ahora nos encontramos en los momentos criticos de un cambio menor, pero de mucha improtancia. La industria cambia ahora en EEUU. Se muere la economia a base de la manufactura, y emerge la industria de el intelecto y la informacion. Entonces, a el mismo tiempo se esta desarrollando una nueva y diferente manera de manejar a esta misma industria. Los proyectos de Software se manejan tradicionalmente con las herramientas desarrolladas para proyectos de ingenieria civil utilizada en EEUU desde los medios 1800's. No que sea una herramienta mala, pero es un systema muy viejo - y mal adaptado a la realidad de la velocidad del desarrollo (aun en la arean Civil!).
Por esto mismo me embarque en mi direccion al tratar de ayudar a mis companeros en IT (y especificamente en Software Development) como un Project Manager. Trabajaba collaborativamente, con muy buenos resultados - pero mis amigos Project Managers no entendian porque me involucraba tanto. Y despues aprendi de Scrum y el movimiento Agil.
Yo ya habia practicado Lean y Kan Ban - y empezando con mi trabajo en Dell, use "lightweight processes". Pero la formalizacion de Scrum y la facilidad que encontre al adaptarla y al ayudar a mis equipos a trabajar mucho mejor mente me encanto absolutamente.
Desde entonces, no puedo ver a el movimiento como nada menos que una revolucion - y una que requiere el animo y el valor de los hombres previamente mencionados para implementar y defender.
Asi entonces - Hola.
Y ARIIBA LA SCRUMVOLUCION!!
Por ahora, escribo de mis observaciones laborales - en mi trabajo como ScrumMaster. Escribo en Espanol (y malamente ya que mi equipo es destacado a Ingles) para mantener anonimidad y un seguro de separacion de la opinion a mi empleo. Claro, si quisiera alguien saber, seria facilicimo traducir.
Para mi, desde muy pequeno mis heroes siempre han sido los revolucionarios. El cambio que ellos traen a la humanidad requiere una respuesta, ya sea silenciar el progreso o adaptar a la nueva realidad. Entre mis heroes personales se encuentran Benjamin Franklin, Pancho Villa y Emiliano Zapata, Alexander Hamilton, Miguel Hidalgo, George Washington, Benito Juarez y Abraham Lincolin, Mahatma Ghandi, Jesu Cristo, Tesla y Edison, los hermanos Wright, Dumont y hasta Napoleon Bonaparte.
Para mi, estos hombres cambiaron la realidad de las circumstancias en su tiempo, y requirieron que el mundo cambiese con ellos. Ahora nos encontramos en los momentos criticos de un cambio menor, pero de mucha improtancia. La industria cambia ahora en EEUU. Se muere la economia a base de la manufactura, y emerge la industria de el intelecto y la informacion. Entonces, a el mismo tiempo se esta desarrollando una nueva y diferente manera de manejar a esta misma industria. Los proyectos de Software se manejan tradicionalmente con las herramientas desarrolladas para proyectos de ingenieria civil utilizada en EEUU desde los medios 1800's. No que sea una herramienta mala, pero es un systema muy viejo - y mal adaptado a la realidad de la velocidad del desarrollo (aun en la arean Civil!).
Por esto mismo me embarque en mi direccion al tratar de ayudar a mis companeros en IT (y especificamente en Software Development) como un Project Manager. Trabajaba collaborativamente, con muy buenos resultados - pero mis amigos Project Managers no entendian porque me involucraba tanto. Y despues aprendi de Scrum y el movimiento Agil.
Yo ya habia practicado Lean y Kan Ban - y empezando con mi trabajo en Dell, use "lightweight processes". Pero la formalizacion de Scrum y la facilidad que encontre al adaptarla y al ayudar a mis equipos a trabajar mucho mejor mente me encanto absolutamente.
Desde entonces, no puedo ver a el movimiento como nada menos que una revolucion - y una que requiere el animo y el valor de los hombres previamente mencionados para implementar y defender.
Asi entonces - Hola.
Y ARIIBA LA SCRUMVOLUCION!!
Subscribe to:
Posts (Atom)