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.