Scrum está en todas partes en el desarrollo de software, tanto que muchos lo consideran la forma predeterminada de trabajar de los equipos. Mi experiencia ha confirmado esto. En todos mis muchos años de desarrollo de software, todos menos dos de mis papeles utilizado Scrum. Es más, a menudo los equipos ni siquiera utilizaban el término "Scrum", simplemente asumían que la gente sabía lo que era. Así es como domina.
Sin embargo, también me di cuenta de que cada equipo hizo Scrum un poco diferente. Esto hizo que me interesara por la versión ideal de Scrum. Así que decidí aprender más inscribiéndome en el curso de Certificación Professional Scrum Master (PSM I) de Scrum.org. No se trataba sólo de curiosidad; aprendiendo más, podría ser más eficaz y ayudar a guiar a los equipos a utilizar Scrum de manera más eficaz.
Este fue un curso de dos días, y fue revelador. Nuestro instructor era genial; tenía un don para lograr el equilibrio perfecto entre presentaciones atractivas y aprendizaje interactivo. A través de una mezcla de actividades de grupo y estudios de casos, nos mantuvo inmersos en el material y nos permitió practicar lo que aprendimos. Me gustó mucho cómo equilibró todo esto con una presentación rigurosa que mostró Scrum como el resultado lógico de las observaciones clave sobre el desarrollo de software. Todo esto nos dio una apreciación más profunda de sus principios, y nos ayudó a entender lo que los elementos de Scrum - que muchos de nosotros dábamos por sentado - estaban destinados a lograr.
Si tuviera que citar una de las conclusiones favoritas, sería el concepto de un incremento. Así es como la Guía Scrum define un Incremento:
"Un incremento es un paso concreto hacia el objetivo del producto. Cada incremento es aditivo a todos los incrementos anteriores y verificado a fondo, asegurando que todos los incrementos trabajan juntos. Para aportar valor, el Incremento debe ser utilizable".
Nuestro instructor dio vida a esta definición haciendo hincapié en que los incrementos tienen que aportar valor a los usuarios finales. En pocas palabras, si los usuarios no notan un cambio en el producto al final de un sprint, entonces el equipo no ha entregado un incremento.
Por ejemplo, imaginemos que un equipo quiere añadir una nueva función a su aplicación. Esta función necesita una interfaz de usuario y una API. Mientras que la API es esencial para la función, es invisible para los usuarios. Supongamos que esta función tardará dos sprints en completarse y que la API y la interfaz de usuario requerirán el mismo tiempo. Si el equipo trabaja en la API en el primer sprint y en la interfaz de usuario en el segundo, entonces no están trabajando en incrementos. ¿Por qué? Porque al final del primer sprint, no han entregado nada que los usuarios puedan utilizar. En cambio, para trabajar en incrementos, el equipo debe dividir el trabajo para que puedan entregar una parte útil de extremo a extremo de la función (interfaz de usuario y API) en el primer sprint, y luego la parte restante de extremo a extremo de la función en el segundo.
Esto proporciona a los usuarios algo valioso que pueden utilizar en cada sprint. También significa que el equipo podría recibir comentarios sobre la función al final del primer sprint, en lugar de tener que esperar al final del segundo. Esto a su vez significa que los equipos podrían pivotar antes si lo necesitan. Scrum se nutre de la retroalimentación, por lo que la capacidad de pivotar rápidamente es esencial. Acortar el ciclo de retroalimentación y aumentar la eficacia de su equipo y el valor que ofrecen a los usuarios.
Saltando adelante, tuve la oportunidad de poner esto en práctica poco después del curso. Me dieron un elemento de trabajo y autonomía para decidir cómo abordarlo. El elemento de trabajo era demasiado grande para hacerlo en un solo sprint. Así que lo dividí en incrementos, cada uno de los cuales tenía valor para el usuario. Entonces trabajé y entregué un incremento. Al final del sprint, teníamos un software notablemente diferente que ofrecía un beneficio tangible a los usuarios finales. Pero también hubo otro beneficio inesperado.
Me dijeron que me trasladarían a otro cliente. Ahora bien, en otros equipos en los que los miembros cambiaban de puesto mientras había trabajo en curso, esto significaba tener reuniones de Transferencia de Conocimientos para asegurarse de que la gente entendía lo que hacía el trabajo parcialmente completado y el contexto completo de lo que se pretendía conseguir. Sin embargo, como yo trabajaba por incrementos, la parte del trabajo entregada estaba completa en sí misma, y el resto del trabajo se entendía fácilmente sin necesidad de contexto. El traspaso fue indoloro.
Volviendo al curso. El curso de formación incluía dos oportunidades para realizar el examen de certificación. La aprobación de este examen me haría un Scrum Master certificado. Si bien el examen era de libro abierto, era lo suficientemente largo como para que yo tuviera que ser capaz de responder a muchas preguntas basadas en mis conocimientos. Afortunadamente, nuestro instructor nos enseñó bien, y pasé el examen en mi primer intento. Poco después, recibí mi certificación. Ahora era un Scrum Master certificado.
Estoy muy contento de haber tomado el curso. Tengo una comprensión más profunda (y apreciación) de Scrum, y tengo una certificación que permite a otros saber que puedo ayudar en su viaje Scrum. Conozco los retos que Scrum está destinado a resolver, y las condiciones en las que prospera. Para aquellos que están considerando tomar el curso, les digo que lo hagan. No sólo le hará un miembro del equipo más eficaz, la certificación también mejorará su comerciabilidad. No está mal para un curso de dos días y un examen de una hora.
