Ultimamente escucho mucho sobre que Scrum fue concebido en foco al desarrollo de productos de software, pero para poder generar mas revenu, se tuvo que ampliar a otras industrias, por lo que esto provoco un daño colateral a la industria de TI propiamente.
Razones:
Lo que se evidencia es que si bien existe el potenciamiento a SoftwareCraftmanship, roles tan importantes como Scrum Master, no tienen el foco en el codigo que se escribe, por tanto la calidad y tiempo del producto se ve afectado.
Incluso escuche en algunas charlas de la comunidad agil que no deberiamos de desperdiciar el tiempo precioso de nuestros Product Owners en la escritura de las Historias de Usuario, ya que esto podria cubrirse perfectamente con las practicas de TDD y BDD, teniendo al equipo de desarrollo enfocado en escribir codigo de calidad y este solo validarlo de la mano con el Product Owner.
Otra justificación que escuche, fue que Scrum no incluye el concepto escritura de Historias de Usuario, con el formato que popularmente conocemos, COMO "Rol", NECESITO "Requisito", PARA "Beneficio", Criterios de Aceptación, etc. Esto solamente es una intención de una necesidad del cliente transmitida al equipo de desarrollo. Siendo que empresas grandes coorporaciones de plataformas de tracking de tareas fueron incluyendo para vender sus servicios. Nosotros solamente como Scrum Masters deberiamos de asegurar que el Product Owner transmita en lenguaje natural de ususario final estas intenciones a los equipos en un formato plano en documentos tan sencillos como Excel.
Estimasion no necesaria: Otra observacion que vi es que la estimación de esfuerzo a las Historias de Usuario tambien no son justificadas, ya que el equipo por lo menos al principio cuando estan en un estado de Forming no tienen idea de cuanto les tomaria desarrollar una caracteristica del producto, por lo que estarian solamente adivinando el esfuerzo requerido.
El Scrum Master debe poder hablar el lenguaje del equipo: Se habla muchas veces entre los desarrolladores que el SM debe tener conocimiento profundo de los frameworks, codigo y tecnologia que se utiliza para la construcción del producto, basicamente ellos piden que sea un Arquitecto de TI, esto para que pueda aportar al equipo e identificar cuando existen desvios o inflación en los tiempos estimados de entrega de cada miembro del equipo. Cabe mencionar que en mi experiencia si conoci varias empresas de desarrollo de Software que piden este requisito a la hora de evaluar a un Scrum Master.
Conclusión: En lo personal pienso que si se debe de realizar un balance entre las habilidades duras y las blandas que todo lider servicial debe poseer, sin embargo no veo como una condicional el ser experto en las habilidades tecnicas para poder liderar a equipos agiles, si habria que reforzar el hecho de dar mas foco en la escritura de codigo en el caso de empresas de desarrollo de Software, para poder mejorar la calidad de los productos.
Al mismo tiempo soy un creyente que Scrum si bien fue concebido para empresas de software, si se puede ampliar a otras industrias de forma satisfactoria. Se puede evidenciar muchos casos en la actualidad de empresas muy grandes que aplican Scrum o Less (marcos escalados) con mucho exito.
