Scrum y el arte de hacer las cosas
Kent Beck dijo alguna vez, que invento la programación extrema para hacer un mundo más seguro para los programadores, pero el mundo aún no es seguro para ellos. En el 2001 reunió a 16 personas, entre las cuales estaban Robert C. Martin, Martin Fowler, Dave Thomas entre otros más, aquí nació el termino 'Metodologías ágiles' y con ello el manifiesto ágil, un tratado basado en 4 pilares que dan paso a los doce principios del llamado 'Software ágil'.
Pero esto lo puedes ver en la wikipedia.
Hoy en día y casi dos décadas después, su exponente más famoso del manifiesto ágil es scrum, un modelo que apareció en los años 80's y que surgió del análisis de como se desarrollaban nuevos productos en algunas de las principales empresas de la época. Para 1995 vio su versión para el desarrollo de software de la mano de Ken Schwaber y significo un hito que unía las gerencias altas y medias, y por primera vez, voz al cliente dentro de la empres. Ya no se pensaba en una entrega final y única, si no en varias con el fin de que el cliente pudiera empezar a operar. Los riesgos reducirían y la calidad del software se vería beneficiada.
Estamos hablando de que el movimiento ágil vino a romper con la forma en que se hacía software en la industriaría. Pero la realidad es otra, por que sobre el papel es maravillo, pero ahora mismo resulta ser bastante obscuro y a palabras de Schwaber: "Eso me pone triste".
¿Qué falla en Scrum?
Algo que llama la atención a primera vista es que muchas veces son personas con buenas intenciones, pero que lo están haciendo mal. Otra cosa a destacar, es la cultura laboral en las empresas y como las figuras de autoridad pueden llegar a abusar de la metodología generando lo que Ron Jeffries llama "Dark Scrum". Ahora que lo pienso, adoptar Scrum requiere un cambio de mentalidad a varios niveles de una organización, por lo cual, si una empresa no esta dispuesta a aceptar los cambios que una metodología como esta requiere, entonces es cuando podemos asegurar el fracaso de su implementación. Entonces el problema no es saber hacia donde ir, si no como poner en marcha todo aquello que deberíamos. Y es que la clave esta precisamente en esta última frase.
Déjenme explicarme y de paso preguntar, usted ¿Cuántas veces ha visto un puesto estratégico ocupado por una persona que no tiene los skill para el mismo? ¿Cuántos tienen nombramientos cuyas responsabilidades no entienden y no ejercen? Esto es un problema común en las empresas, promover a un buen empleado que desempeña bien su trabajo, a otro, donde muchas veces lo desconoce y termina tratando de hacer lo mejor que puede, pero dando pésimos resultados.
En el libro "El arte de la ejecución en los negocios" de Bossidy y Charan, se profundiza sobre este problema, aunque ellos lo hacen desde el punto de vista de un nivel ejecutivo y no operativo. Y te preguntaras ¿Esto que tiene que ver con scrum? Recuerdas que mencione que esto era un cambio en la cultura organizacional, verdad. Pues resulta que Charan identifica el problema entre el objetivo estratégico y la ejecución de acciones que pongan en marcha dicha estrategia, siendo la implementación (ejecución) una disciplina a considerar en la estrategia y un punto fundamental en la cultura de trabajo.
Muchas empresas llegan a perder buenos técnicos y ganan un pésimo líder, todo esto falla por tener a las personas equivocadas en puestos estratégicos.
Pero no siempre pasa esto, también existe otro factor.
Hace muchos me años leí un articulo llamado "Prohibidos monos y lagartos", en el cual Alejandro Pérez e Iván Zaera trataron de dar una explicación al fracaso de los proyectos, entre esta charla llegaron tan abajo como pudieron, encontrando dos mentalidades tóxicas para cualquier empresa, la del mono y la del lagarto. Resulta que la mentalidad de un mono, es aquella donde un individuo aprende a usar una herramienta de una forma espectacular pero que no la entiende, por lo que si varia algo de esa herramienta, le resultara muy difícil entender lo que esta pasando. Por otra parte, la mentalidad de lagartija, es aquella que solo busca sobrevivir al día, que piensa en lo que podría hacer fuera de horario laboral y que le preocupa mas el día de pago que ser un profesionista.
Con este contexto, podemos empezar a darnos una idea del por que falla Scrum en su mayoría de casos, y en este punto me podrás decir que es mas un tema de que no conocen la metodología que cualquier otra cosa. Y es verdad en algunos casos, pero recordemos que scrum establece un vinculo entre la alta gerencia y operaciones. Y para ello deben de dejar la microadministración.
Pero todo esto ¿En realidad impide que Scrum se lleve a cabo? ¿Esto hace inseguro al mundo para un desarrollador? La respuesta es: Hace que el mundo laboral sera peligroso para todos los involucrados.
Scrum tiene bases muy solidas en el estudio del desarrollo de un producto, por lo que siempre se dará una mayor prioridad a aquello que aporte valor al producto sobre lo que no, los equipos no son menores a 3 o mayores a 9, se basan en el logro de objetivos y el equipo debe ser auto gestionado. Es por esto que he preferido hablarte de lo anterior, de la importancia de conocer los objetivos de la empresa a corto, mediano y largo plazo, de ser la voz conciente del cliente, y no solo hacer lo que el cliente quiera, aun si sabemos que poco o nada le ayudara al producto, vamos, que para eso nos contrato como expertos y no solo como maquiladora.
El problema de la administración de proyectos.
Seamos claros, scrum te da pautas para desarrollar el proyecto bajo una visión de entrega de producto lo antes posible, de poder brindar al cliente un producto minimo viable bajo entregas continuas, pero olvidamos algo importante en el camino, ¿Cómo vamos administrar el proyecto?
Por desgracia he de decir que muchas empresas tienen project Managers que no cuentan con los skills suficientes. Muchas veces el project manager es un vendedor, un ejecutivo de cuenta o tristemente, una edecan que se encarga de dar fechas de entrega, y no aquel que use las bases de la ingeniería del software para poder gestionar los diferentes puntos a lo largo de un proyecto, ago que incluso los cursos de Scrum no te lo dan.
Ian Sommerville describe dos enfoques en su libro "Ingeniería de Software", el método predictivo, el cual abarca metodologías como cascada o espiral, y por otro lado el método adaptativo, el cual planteaba originalmente un ciclo de vida para el software completo por cada integración, pero para usos prácticos y por eso suena mucho hoy en día al desarrollo iterativo propuesto por Scrum, entonces nos tomaremos una pequeña licencia al englobar todo método clásico dentro del método predictivo, y a todo método ágil dentro del método adaptativo.
¿Se puede hacer Scrum bajo la ingeniería de software?
La respuesta es si, que si quieres un enfoque puro o basado en el Project Manager Profecional, en el Project Manager Institute, bajo las reglas de PRINCE2, la respuesta es, si, por que todas ellas definen cosas en común, entre ellas siempre veras un análisis de riesgos, de costos, una linea base independientemente de que te decidas por un desarrollo predictivo o adaptativo, documentos de requerimientos etc.
Conclusión
La administración de proyectos requiere de que todos podamos saber las reglas del juego, y si aplicamos una capa de metodología ágil, debemos ser conscientes del cambio de cultura organizacional necesario para ello. Como PM, debes estar preparado para interactuar entre los diferentes niveles de gerencias y el cliente, pero también con la parte operativa, como desarrollador, saber e involucrarte con los objetivos de tu empresa y querer aportar tu parte para el cumplimiento de las mismas. Y como organización, tienes que comprender que tener personas capacitadas en puestos claves te permitirá alcanzar tus objetivos estratégicos.
Saludos cordiales.
Pero esto lo puedes ver en la wikipedia.
Hoy en día y casi dos décadas después, su exponente más famoso del manifiesto ágil es scrum, un modelo que apareció en los años 80's y que surgió del análisis de como se desarrollaban nuevos productos en algunas de las principales empresas de la época. Para 1995 vio su versión para el desarrollo de software de la mano de Ken Schwaber y significo un hito que unía las gerencias altas y medias, y por primera vez, voz al cliente dentro de la empres. Ya no se pensaba en una entrega final y única, si no en varias con el fin de que el cliente pudiera empezar a operar. Los riesgos reducirían y la calidad del software se vería beneficiada.
Estamos hablando de que el movimiento ágil vino a romper con la forma en que se hacía software en la industriaría. Pero la realidad es otra, por que sobre el papel es maravillo, pero ahora mismo resulta ser bastante obscuro y a palabras de Schwaber: "Eso me pone triste".
¿Qué falla en Scrum?
Algo que llama la atención a primera vista es que muchas veces son personas con buenas intenciones, pero que lo están haciendo mal. Otra cosa a destacar, es la cultura laboral en las empresas y como las figuras de autoridad pueden llegar a abusar de la metodología generando lo que Ron Jeffries llama "Dark Scrum". Ahora que lo pienso, adoptar Scrum requiere un cambio de mentalidad a varios niveles de una organización, por lo cual, si una empresa no esta dispuesta a aceptar los cambios que una metodología como esta requiere, entonces es cuando podemos asegurar el fracaso de su implementación. Entonces el problema no es saber hacia donde ir, si no como poner en marcha todo aquello que deberíamos. Y es que la clave esta precisamente en esta última frase.
Déjenme explicarme y de paso preguntar, usted ¿Cuántas veces ha visto un puesto estratégico ocupado por una persona que no tiene los skill para el mismo? ¿Cuántos tienen nombramientos cuyas responsabilidades no entienden y no ejercen? Esto es un problema común en las empresas, promover a un buen empleado que desempeña bien su trabajo, a otro, donde muchas veces lo desconoce y termina tratando de hacer lo mejor que puede, pero dando pésimos resultados.
En el libro "El arte de la ejecución en los negocios" de Bossidy y Charan, se profundiza sobre este problema, aunque ellos lo hacen desde el punto de vista de un nivel ejecutivo y no operativo. Y te preguntaras ¿Esto que tiene que ver con scrum? Recuerdas que mencione que esto era un cambio en la cultura organizacional, verdad. Pues resulta que Charan identifica el problema entre el objetivo estratégico y la ejecución de acciones que pongan en marcha dicha estrategia, siendo la implementación (ejecución) una disciplina a considerar en la estrategia y un punto fundamental en la cultura de trabajo.
Muchas empresas llegan a perder buenos técnicos y ganan un pésimo líder, todo esto falla por tener a las personas equivocadas en puestos estratégicos.
Pero no siempre pasa esto, también existe otro factor.
Hace muchos me años leí un articulo llamado "Prohibidos monos y lagartos", en el cual Alejandro Pérez e Iván Zaera trataron de dar una explicación al fracaso de los proyectos, entre esta charla llegaron tan abajo como pudieron, encontrando dos mentalidades tóxicas para cualquier empresa, la del mono y la del lagarto. Resulta que la mentalidad de un mono, es aquella donde un individuo aprende a usar una herramienta de una forma espectacular pero que no la entiende, por lo que si varia algo de esa herramienta, le resultara muy difícil entender lo que esta pasando. Por otra parte, la mentalidad de lagartija, es aquella que solo busca sobrevivir al día, que piensa en lo que podría hacer fuera de horario laboral y que le preocupa mas el día de pago que ser un profesionista.
Con este contexto, podemos empezar a darnos una idea del por que falla Scrum en su mayoría de casos, y en este punto me podrás decir que es mas un tema de que no conocen la metodología que cualquier otra cosa. Y es verdad en algunos casos, pero recordemos que scrum establece un vinculo entre la alta gerencia y operaciones. Y para ello deben de dejar la microadministración.
Pero todo esto ¿En realidad impide que Scrum se lleve a cabo? ¿Esto hace inseguro al mundo para un desarrollador? La respuesta es: Hace que el mundo laboral sera peligroso para todos los involucrados.
Scrum tiene bases muy solidas en el estudio del desarrollo de un producto, por lo que siempre se dará una mayor prioridad a aquello que aporte valor al producto sobre lo que no, los equipos no son menores a 3 o mayores a 9, se basan en el logro de objetivos y el equipo debe ser auto gestionado. Es por esto que he preferido hablarte de lo anterior, de la importancia de conocer los objetivos de la empresa a corto, mediano y largo plazo, de ser la voz conciente del cliente, y no solo hacer lo que el cliente quiera, aun si sabemos que poco o nada le ayudara al producto, vamos, que para eso nos contrato como expertos y no solo como maquiladora.
El problema de la administración de proyectos.
Seamos claros, scrum te da pautas para desarrollar el proyecto bajo una visión de entrega de producto lo antes posible, de poder brindar al cliente un producto minimo viable bajo entregas continuas, pero olvidamos algo importante en el camino, ¿Cómo vamos administrar el proyecto?
Por desgracia he de decir que muchas empresas tienen project Managers que no cuentan con los skills suficientes. Muchas veces el project manager es un vendedor, un ejecutivo de cuenta o tristemente, una edecan que se encarga de dar fechas de entrega, y no aquel que use las bases de la ingeniería del software para poder gestionar los diferentes puntos a lo largo de un proyecto, ago que incluso los cursos de Scrum no te lo dan.
Ian Sommerville describe dos enfoques en su libro "Ingeniería de Software", el método predictivo, el cual abarca metodologías como cascada o espiral, y por otro lado el método adaptativo, el cual planteaba originalmente un ciclo de vida para el software completo por cada integración, pero para usos prácticos y por eso suena mucho hoy en día al desarrollo iterativo propuesto por Scrum, entonces nos tomaremos una pequeña licencia al englobar todo método clásico dentro del método predictivo, y a todo método ágil dentro del método adaptativo.
¿Se puede hacer Scrum bajo la ingeniería de software?
La respuesta es si, que si quieres un enfoque puro o basado en el Project Manager Profecional, en el Project Manager Institute, bajo las reglas de PRINCE2, la respuesta es, si, por que todas ellas definen cosas en común, entre ellas siempre veras un análisis de riesgos, de costos, una linea base independientemente de que te decidas por un desarrollo predictivo o adaptativo, documentos de requerimientos etc.
Conclusión
La administración de proyectos requiere de que todos podamos saber las reglas del juego, y si aplicamos una capa de metodología ágil, debemos ser conscientes del cambio de cultura organizacional necesario para ello. Como PM, debes estar preparado para interactuar entre los diferentes niveles de gerencias y el cliente, pero también con la parte operativa, como desarrollador, saber e involucrarte con los objetivos de tu empresa y querer aportar tu parte para el cumplimiento de las mismas. Y como organización, tienes que comprender que tener personas capacitadas en puestos claves te permitirá alcanzar tus objetivos estratégicos.
Saludos cordiales.
Comentarios
Publicar un comentario