CategoriasAgileKanbanScrum

Cómo superar el examen PSK-I – Parte 2

Ahora que ya te has leído la parte 1 vamos a profundizar en la estructura del examen.

El examen tiene tres bloques principales:

  • Teoría de Scrum
  • Prácticas de Kanban
  • Métricas de Kanban

Así que si vienes del mundo Scrum, ya ves que tienes mucho ganado.

Recuerda la regla principal de la parte I de este artículo:

La guía de Kanban para equipos Scrum va de Scrum, no de Kanban. Esto es vital de cara al examen y a entender conceptos:

Regla fundamental: La guía Scrum no se cambia. No se alteran roles, no se alteran artefactos y no se alteran ceremonias*

* en lo esencial

CategoriasAgileScrum

Cómo superar el examen PSK-I (Professional Scrum with Kanban) – Parte 1

Esto viene de una historia en Linkedin, De un fallo de mi ego y de ser idiota.

Me empeñé en que sería un examen fácil de superar, al fin y al cabo he estudiado Kanban y estoy certificado en Scrum, ¿Qué podía ir mal? La respuesta es que fallé mi primer intento por poco y la aventura de certificarme acabó costándome el doble.

Así que te voy a evitar el dolor de pagar 400$ por dos intentos, ayudándote un poco con el estudio.

CategoriasScrum

Te cuento lo que hice para aprobar el examen de Professional Scrum Product Owner II

Hará unos dos meses me planteé superar el PSPO-II, aprovechando mi permiso de paternindad. El requisito era claro: lo tenía que hacer en poco tiempo.

Aquí te cuento cómo ha sido mi experiencia con el PSPO-II.

¿Hace falta hacer un training obligatorio?

  • No, pero seguramente sea recomendable si no tienes experiencia/conocimientos sobre el tema.
  • Al contrario que otras certificadoras, Scrum.org no tiene training obligatorio.

¿Hace falta pasar el PSPO-I para hacerlo?

  • No, pero seguramente ayude. Yo tenía la equivalente de Scrum Alliance.

¿Cuanto tiempo te llevó?

  • Unas 30 horas de lecturas y pruebas
  • Toda mi mochila de experiencias
CategoriasAgileScrum

Scrum y la teoría de Tuckman

Imagen de: https://www.flickr.com/photos/luigimengato/ original aquí.

La teoría de Tuckman lleva entre nosotros desde 1965, viene a decir que todos los equipos pasan inevitablemente por una serie de etapas de rendimiento cíclicas:

  • Formación (forming): ese periodo de ilusión en el que el equipo se forma, el rendimiento es superior a la suma de los rendimientos individuales, se descrube el proyecto…
  • Tormenta (storming): conforme el equipo se conoce y trabaja de forma conjunta surgen roces de diferentes tipos, conflictos.
  • Normalización (norming): se resuelven los problemas, se establecen normas de convivencia, se supera el conflicto (esperemos que sí)
  • Rendimiento (performing): una vez superado el conflicto el equipo rinde y alcanza su plenitud, sin embargo se puede volver a la fase de tormenta.

¿Y qué pinta Scrum en todo esto?

CategoriasScrum

El reto de crear: ¿Puedes enseñar Scrum?

Hace ya algún tiempo un amigo me picó, sabiendo que me gustan los métodos ágiles me propuso colaborar en la creación de contenido para enseñar Scrum Online.

He dedicado un mes completo a ello, a descubrir cosas que no sabía (pese a tener los certificados) a profundizar más, a confrontar ideas, contrastar fuentes, documentar y citar…

CategoriasAgile

Upstream scrum, ¿Qué hay antes del backlog?

Recientemente he concluido un programa de training como product owner de la Scrum Alliance. No difiere mucho del programa de Scrum máster y me deja más dudas que respuestas.

Sí, la figura del Product Owner está clara (no lo está) su responsabilidad ordenando el backlog, hablando con diferentes stakeholders…

Pero Scrum se centra en el equipo de desarrollo, en sus interacciones, habla de la entrega de valor por parte del equipo, pero se deja cosas importantes.

Si consideramos Scrum parte de un todo tendría dos interfaces claramente definidas, entrada y salida. La entrada es el backlog (y desde aquí tendríamos el upstream) y en la salida tendriamos el «Potentially shippable product increment» o increment directamente. El increment sería el downstream, la entrega, le seguiría el despliegue y la explotación (downstream).

CategoriasAgile

Scrum en operaciones, es cool pero no funciona

Scrum tiene un factor cool, a riesgo de elevar el número de haters, diré que hasta tiene un toque «populista». Me explico: es fácil de entender, las ideas que expone parecen resolver muchos problemas de forma sencilla.

Lo anterior es una idea que se aleja de la realidad, por mucho que Scrum sea un framework fácil de asimilar es muy complejo ponerlo en práctica.

Y aquí viene mi historia: es imposible aplicarlo en un entorno de operaciones de TI.