English Spanish

sábado, 28 de marzo de 2015

Quién puede ser Product Owner o Scrum Master?

Al momento de adoptar la metodología ágil Scrum en una organización que está acostumbrada a trabajar usando el enfoque en cascada para sus proyectos de Desarrollo de Software, nos encontramos con ciertas preguntas de cara a los roles que generalmente existen en la gestión en cascada y cuáles son los mejores candidatos para ocupar los nuevos roles que propone Scrum.

Los roles que generalmente encontramos en la gestión en cascada o “Plan Driven” son el Product Manager, Business Analyst, Project Manager, Software Developer, DataBase Admin, Tester, UI Designer, Functional Director, etc. En Scrum solo son tres, el Product Owner, el Scrum Master y el Development Team.  Como decidimos quien va a ocupar que rol de Product Owner? Y quien puede ser el Scrum Master?  Hablemos un poco de eso.

En Scrum, el rol de Product Owner es el que se encarga de administrar el repositorio de requerimientos (el Product Backlog), priorizar los elementos de este repositorio basado en el valor que tienen para el negocio, agregar detalles a dichos elementos y además debe estar disponible para que el equipo de desarrollo pueda aclarar sus dudas y obtener respuesta a las posibles preguntas relacionadas con el trabajo que estarán haciendo.  Estas responsabilidades del Product Owner pueden ser cubiertas por varios de los roles que existen en la gestión tradicional o en cascada, sin embargo, hay que tomar en cuenta algunos elementos importantes antes de decidir quien será el que ocupara este rol de Product Owner.   Dentro de los elementos a tomar en cuenta están:
  • El candidato (o candidata) debe tener un buen conocimiento (yo diría que un perfecto dominio) del negocio, del producto que se espera construir o del servicio que va a crear.
  • Debe tener alto nivel de credibilidad en la organización, esto para que sus decisiones sean respetadas.
  • Debe ser un buen comunicador, es decir, debe saber transmitir una idea de manera clara (generalmente lo tendrá que hacer usando el lenguaje del negocio).

Todo aquel que cumpla con estos tres elementos es un candidato a ser Product Owner.  No es casualidad que generalmente las personas que pertenecen al área de negocios, áreas de gestión de productos, gestión de proyectos, áreas de mercadeo, operaciones, etc., son los que generalmente son seleccionados para cubrir este rol, esto es así debido a que esas personas conocen bien el producto o el negocio (a veces no saben exactamente lo que quieren pero tienen bien claro cual es la necesidad que se desea cubrir), gozan de alta credibilidad en la organización por sus hazañas pasadas en esas posiciones y como trabajan generalmente con muchas personas a su alrededor (o bajo su cargo) tienden a ser buenos comunicadores.

Por otro lado tenemos al Scrum Master, este rol debe tener un excelente dominio y conocimiento de la metodología Scrum y debe saber moverse dentro de la empresa, es decir, debe conocer los procesos, procedimientos, políticas de la empresa, la cultura organizacional e incluso es deseable que conozca algunos “atajos” para solucionar situaciones (conoce exactamente quien puede resolver un problema en particular cuando se presenta).  Esta persona debería de poder entender el lenguaje que use el Product Owner, me refiero al lenguaje del negocio y también debe poder comunicarse sin inconvenientes usando el lenguaje del equipo de desarrollo (siendo este el último el equipo de personas que creara el producto, servicio o resultado esperado), con esto del lenguaje me refiero a palabras y jergas propias del producto que se esta construyendo, si es de software debería poder entender una conversación técnica, si es un producto basado en maderas preciosa debería poder entender la terminología usada por los constructores de artículos en madera o ebanistas.  Debe tener capacidades de facilitador, poder solucionar conflictos (que seguro va a tener algunos que solucionar, tanto a lo interno del equipo de desarrollo como entre el Product Owner, el equipo, los stakeholders y demás involucrados).  

Los candidatos a Scrum Master son generalmente personas que salen del equipo de desarrollo, que presentan buenas capacidades de comunicación, solucionan conflictos, cuentan con alto nivel de empatía, conocen la empresa y saben como moverse dentro de ella.  También un Project Manager puede ser un buen Scrum Master, siempre y cuando cumpla con los elementos que ya hemos citado (si tiene un conocimiento básico o moderado sobre el producto o servicio a construir y las técnicas y herramientas que usara el equipo de desarrollo para crear dicho producto o servicio seria excelente).

Aunque esto que les describo en esta ocasión aplica para la generalidad de los proyectos que son llevados con Scrum, recuerden que existen escenarios puntuales donde el caso particular del Product Owner puede necesitar características especiales, este es el caso de múltiples equipos de Scrum que desarrollan componentes de un producto mayor, en ese caso los Product Owners requieren de un conocimiento “técnico” importante para poder pasar los requerimientos (historias de usuario) de manera que cumplan con los requisitos de la integración que en un momento futuro habrá que realizar, pero esa es otra historia :P.

Bueno eso es todo en cuanto los quien puede ocupar los roles de Product Owner y Scrum Master en Scrum, espero verlos pronto por acá en otro post de Agile Zone.





martes, 20 de enero de 2015

About zero (0) story points

The Fibonacci series was slightly modified for agile planning purposes. This modification includes adding the values 0 and 0.5 and rounding up the values that exceed 13 (20, 40 and 100). The question is: can we assign zero story points to an issue? Is this correct? Does this have any impact in velocity measurements or indicators or any other charts or reports?

We assign zero story points to an issue that requires the least effort of the team to be completed. Issues that take a few hours to be resolved and accepted, or issues that only need to be verified by a team member in order to be considered as “solved”. Those issues don’t have impact in a velocity report or velocity chart of the team, for that reason we need to be careful to assign zero story points to an issue. Imagine a sprint with 30 issues in it (bugs, improvements, spikes and stories) and 15 of them with zero story points, that situation changes the measurement of velocity of the team because if we put the 15 issues together in a bag, we can assign 3 or 5 story points to that bag, but we don’t see these story points in any place.

You can handle this situation with multiple approaches. The first approach is take one issue with zero story point for each team member or less. If you have 7 team members, you can take into the sprint up to 7 issues with zero story points and no more. The second approach is to create a new issue with multiples things to do (various issues interrelated with zero story points each one) and assign 0.5, 1 or 2 story points to that new issue.

In conclusion, you can assign zero story point to an issue under specific conditions (the issue take the least effort of the team to be completed), but be careful including those issues in a single sprint can impact your velocity measurement.

La serie Fibonacci fue ligeramente modificada para ser usada en la planeación ágil, específicamente en el Planning Poker. Esta modificación incluye los valores cero (0) y 0.5 y redondea algunos valores superiores al 13 (20, 40 y 100). La pregunta aquí es: puedo asignar cero (0) story points a un issue (error, historia de usuario, mejora, spike, etc.)? Esto estaría correcto? Tendría esto algún impacto en la medición de la velocidad, en los indicadores de velocidad o gráficas y reportes relacionados?, hablemos de eso.

Asignamos cero (0) story points a un Issue que requiere el mínimo esfuerzo del equipo para ser completado. Issues que toman solo algunas horas para ser resueltos y aceptados, o issues que solo necesitan ser verificados por algún miembro del equipo para ser considerado como “resuelto” o “terminado”. Esos issues que pesan cero (0) no tienen impacto en los reportes de velocidad o graficas de medición de velocidad del equipo, por esa razón tenemos que tener mucho cuidado al asignar cero (0) story points a un issue. Imagine que usted tiene 30 issues en un sprint (errores, mejoras, spikes e historias de usuario) y que 15 de esos issues pesan cero (0) story points, esto puede cambiar la velocidad de su equipo de manera interesante. Imagine que usted pueda colocar esos 15 issues todos en una bolsa y darle un peso a dicha bolsa, esto seguro pesaría unos 3 o 5 story points, sin embargo, usted nunca va a ver esos story points en ningún lugar si los deja sueltos.

Se puede manejar esta situación de varias maneras. La primera es tomando como máximo un issue que pesa cero (0) por cada miembro del equipo dentro de un mismo sprint. Si usted tiene 7 miembros en su equipo, solo podrá tomar 7 issues con peso cero (0) en un mismo sprint y no más. Otra forma es agrupar los issues relacionados y que pesan cero (0) y crear un nuevo issue que los incluya a todos y a este nuevo issue si darle un peso, que podría ser 0.5, 1 o 2 story points.

En conclusión, usted puede asignar cero (0) story points a un issue bajo ciertas condiciones muy específicas (el issue tomaría el mínimo esfuerzo del equipo para ser completado), pero tenga mucho cuidado con incluir varios de estos issues en un mismo sprint ya que esto puede impactar su medición de la velocidad del equipo.