Certificaciones ¿Cómo puedo obtenerlas?: Scrum

Una certificación no es una garantía de profesionalidad, sin embargo, el hecho de tenerla mejora tu perfil y lo destaca dentro del mercado laboral. Se trata de una acreditación de terceros sobre unos conocimientos en un área específica. El esfuerzo invertido para obtenerla es algo muy valorable, sin embargo, si quieres certificarte debes saber que hay dos cosas que marcaran realmente la diferencia: el reconocimiento de la industria de dicha certificación y tu experiencia real.

yoda2

Como norma general, no recomiendo obtener ninguna certificación sin una experiencia previa mínima en la materia que te certificas. Tu experiencia y conocimiento más allá de la certificación es lo que realmente dará valor a tu perfil. La certificación no debe ser nunca el objetivo sino un medio para tener mejores oportunidades y poder seguir desarrollándote como profesional.

La certificación debe respaldar una experiencia y no suplir una carencia.

Las certificaciones de  Scrum Alliance o scrum.org, son posiblemente las más valoradas y reconocidas debido a que ambas fueron fundadas por uno de los creadores originales del framework. Existen otras que, al margen del conocimiento que puedas adquirir, no tienen el mismo reconocimiento de la industria y, en algunos casos, se quedaron en versiones antiguas del framework. No las enumeraré ni valoraré, pero si queréis saber más podéis visitar este interesante post de Jerónimo Palacios que hace una comparativa muy interesante.

Volviendo a Scrum Alliance y Scrum.org, aunque el reconocimiento de la industria de ambas es similar, en mi caso soy más partidario de scrum.org. Los motivos son históricos, económicos y prácticos.

Ken Schwaber funda Scrum Alliance en 2004 pero en 2008 deja la marca por desacuerdo con respecto a como se estaban realizando las evaluaciones de la certificaciones. En ese momento funda scrum.org, dando un enfoque distinto. Si las comparamos, scrum.org tiene exámenes más rigurosos que valoran tu capacidad de entender y aplicar Scrum. Además, la certificación tiene la ventaja de que no te obliga a realizar un curso oficial si no lo necesitas y no tiene fecha de caducidad.

Existen cuatro certificaciones pero las más habituales son: Professional Scrum master (PSM) y Professional Product Owner (PSPO). Ambas tienen varios niveles donde un nivel más alto indica una mayor maestría. Por norma general para demostrar conocimiento el nivel 1 es suficiente. El resto de niveles suelen obtenerlo personas que siguen el proceso de trainer oficial o que desean demostrar un mayor nivel de maestría en su conocimiento de Scrum por otros motivos.

Para ser trainer oficial, a parte de seguir el proceso de selección, necesitas una puntuación de un 95% en todas las certificaciones y en todos los niveles.

Certificacionesscrum

Aunque puedes presentarte a la certificación sin realizar ningún curso, recomiendo hacer un curso de preparación con un experto en la materia, sobre todo si no tienes una experiencia extensa en el framework. Esta libertad que proporciona scrum.org para presentarte directamente, optar por los cursos oficiales o contratar un curso con un consultor experimentado para que te oriente de cara al examen permite que puedas ajustar la preparación de la certificación a tus gustos y necesidades.

Si buscas un curso y no te convence el precio del oficial, que sea totalmente orientado a la certificación de scrum.org. Existen cursos que sirven para varias certificaciones, pero no los recomiendo en absoluto. Si tienes dudas, pregúntame o lee este post de Jerónimo Palacios .

Para poder aprobar es esencial que conozcas muy bien la guía de Scrum. El examen consta de 80 preguntas multiselección que debes contestar en 1 hora.  Se trata de un examen para el que necesitarás estudiar y prepararte. No es difícil, pero si que requiere cierta preparación y algo de estudio: “La certificación no te la van a regalar”. Con el material que te enumero a continuación, sería suficiente para superar el examen:

  • Manifiesto ágil. Es esencial que conozcas los principios y valores de agile. Siempre debes tenerlos en mente a la hora de contestar las preguntas.
  • La guía de scrum. Es la base de todo el examen, es lo más importante, debes conocerla y tenerla en mente en la contestación de cada pregunta.
  • Simuladores de examen. Los simuladores te servirán para habituarte al formato del examen, controlar tiempos, autoevaluarteestudiar y meditar sobre las preguntas. Te recomiendo usar varios en tu preparación:
    • Simuladores abiertos ofrecidos por scrum.org. Este es gratuito y básico. Tienes opciones para todas las certificaciones.
    • Simulador gratuito de Mikhail Lapshin. Tiene un examen por cada certificación. Siempre es el mismo examen pero es recomendable hacerlo varias veces. Las preguntas son bastante próximas a lo que te vas a encontrar en el examen real.
    • Simulador de pago. Busca uno alineado con las preguntas que te harán. Debes tener cuidado, ya que por experiencia no es fácil encontrar simuladores realmente buenos. Yo te recomiendo unos que recomiendan mucho en los foros y que a mi me dieron buen resultado: scrum master/product owner.

Para el caso concreto del examen de product owner debes tener en cuenta que entrarán las mismas preguntas que en el de scrum master más aquellas específicas de product owner. Por ese motivo, es muy recomendable que en los simuladores gratuitos que te he recomendado también realices los tests para el PSM I.

En general para cualquier certificación, el método de estudio es muy importante. El proceso que te recomiendo es el siguiente:

  • Lee el post y los libros recomendados, con tranquilidad, entendiendo los conceptos. Aplícalos si tienes oportunidad en tu día a día. Deberías interiorizarlos.
  • Ten en mente el manifiesto ágil. Memoriza y entiende los valores del manifiesto (son 4) y entiende sus principios (no los memorices, sólo entiende los 12 principios).
  • Estudia a conciencia la guía de Scrum y el manifiesto. Estudia a conciencia la guía, entiende las diferencias y matices entre Scrum y las prácticas añadidas que recomiendan en los libros y posts.
  • En el caso del examen de product owner, irán un poco más allá de la guía en las preguntas. En este caso, es esencial un curso preparatorio o leer los libros recomendados, sobre todo, todo lo relacionado con el rol de product owner: la visión, alcance, planning de producto y también los tipos de contratos agile
  • Usa los simuladores de examen, revisa las preguntas que has fallado y entiende los motivos. Apunta tus fallos, crea tus propios apuntes. Repite los tests, toma notas, lee todas las notas, repite los tests, toma notas, lee todas las notas… es un ciclo de aprendizaje continuo (y de mejora continua).
  • Participa en los foros de scrum.org o en cualquier foro donde puedas discutir sobre estos conceptos y llegar a un mayor entendimiento.
  • Practica lo aprendido y experimenta. Como te he comentado al principio, las certificaciones no tienen sentido sin experiencia.

Si sigues este método, poco a poco irás consiguiendo más puntuación en los simuladores e irás entendiendo mucho más la guía de scrum, que a priori parece muy simple, pero cada frase tiene mucho valor de fondo, mucho más de lo que puede aparentar en un principio.

Para saber si estás preparado para realizar el examen la recomendación es la siguiente:

  • Has sacado un 100% de aciertos en los simuladores gratuitos de una forma habitual. Esas preguntas deben salirte casi de forma automática porque durante el examen pueden aparecer (aunque no siempre), y el no tener que pensarlas mucho te dará tiempo extra para otras preguntas más complicadas.
  • Has sacado más de un 95% de aciertos en el simulador de pago de forma habitual.
  • Eres capaz de razonar de acuerdo a la guía de scrum las preguntas, tanto los aciertos como los fallos. Sabértelas de memoria no te garantizará aprobar el examen, ya que las preguntas del examen podría ser muy distintas.

Para presentarte al examen, simplemente tienes que realizar el pago en la propia página de scrum.org por lo que necesitarás crearte una cuenta. Te darán un código con el cual podrás acceder y examinarte en el momento que desees, desde casa.

Al empezar el examen te recomiendo tener abierta la guía de scrum por si te surge alguna duda. Controla el tiempo, podrás marcar las preguntas para volver a ellas al final de test, con lo cual es preferible que contestes siempre y si tienes dudas pongas la que crees más probable y marques la pregunta . Así al final del examen, si te queda tiempo, podrás volver a repasar las más dudosas.

Según acabes te darán la nota. Un resultado mayor o igual a un 85% significa que has aprobado. No se tratan de una certificaciones complicadas, al menos el nivel 1, pero como comentaba al principio, no te lo van a regalar.

Recuerda que el hecho de tener una certificación no va a demostrar que eres experto en la materia. Te abrirá puertas y, si acudes a los cursos, harás networking. Tómalo como un medio para tener nuevas oportunidades y seguir formándote.

Estos dos libros los recomiendan orientados al examen, aunque francamente, yo no los he utilizado, ya me contaréis que os parecen:

Por otro lado, aunque para el examen siempre te tienes que ceñir a la guía de scrum,  la lectura adicional puede enriquecer tu conocimiento:

Y para que vayas más allá de la certificación no puedes olvidar estas autenticas joyas:

Y tú, ¿qué opinas sobre las certificaciones?

Anuncios

Scrum II: ¿Haciendo Scrum soy ágil?

En el post anterior Scrum I: Nadar a través del cambio más que tratar de andar sobre las aguas hicimos un pequeño repaso de la guía de Scrum, rompiendo con algunos mitos y dando algunos consejos respecto a por qué utilizar un enfoque incremental e iterativo en el desarrollo software.

quarterback-73614_960_720

Este post pretende ayudar a aquellos equipos que comienzan a arrancar con Scrum y que suelen tener confusión debido a que tienen la idea equivocada de que Scrum, como pasaba con Waterfall, les ofrece una receta que se debe seguir al pié de la letra para llegar al éxito en el desarrollo de su producto software.

Adaptar Scrum vs Cherry-picking

Existen tantas formas de implementar Scrum como proyectos o productos. La idea principal es adaptar el framework a un contexto determinado.  Llamamos Cherry-picking a coger del framework algunas ideas y descartar otras.  Todo lo que se indica en la guía de Scrum es Scrum, y el resultado de hacer Cherry-picking es otra cosa que, aunque funcione en tu contexto, no es Scrum, y por tanto no debería ser llamado Scrum. Esto con otras palabras viene descrito en la nota final de la guía de Scrum.

Adaptar a Scrum a mi contexto

Cuando haces una adaptación de Scrum a tu contexto no debes perder de vista los artefactos, eventos, valores y principios de Scrum. Y sobre todo, es aplicado a todo el ciclo de desarrollo de producto, no a una etapa del mismo.

Bien estés tratando de adaptar a tu contexto Scrum o utilizando algunos elementos para crear un modelo híbrido, hay que tener mucho cuidado con incumplir los valores del manifiesto de desarrollo ágil, Esto es algo, que en los modelos híbridos con base en Waterfall, es bastante complicado de cumplir por su naturaleza. Os los resumo:

  • Colaboración con cliente vs negociación contractual.
  • Respuesta al cambio vs seguir un plan.
  • Documentación exhaustiva vs software funcionando.
  • Individuos e iteraciones vs procesos y herramientas.

El no cumplir con estos valores o con los propios de valores de Scrum suele ser la causa más habitual de “fracaso de Scrum” y esto suele llevar a la falsa percepción de que “Scrum es una metodología de juguete”.

Decidir si Scrum se puede adaptar a mi contexto

Existen algunas recomendaciones que no están para nada grabadas en piedra que tratan de ayudar en la toma de decisión de utilizar Scrum u otro framework. En este caso, una recomendación que he escuchado bastante es que “si tienes el scope bastante claro a priori , encaja muy bien, sobre todo, si tienes hitos concretos con entregas”.

Esta recomendación tomada al pie de la letra es bastante discutible. Primero porque suele confundirse de forma habitual “tener una visión y roadmap inicial acordado entre cliente y el equipo” con “tener un scope cerrado con cliente por contrato”. Y segundo porque se confunde el término “cherry-picking de Scrum” con “adaptar Scrum”.

Algo que si es cierto es que, en el caso de aquellos proyectos que tienen el scope cerrado por contrato, la organización del equipo de desarrollo mediante Scrum y prácticas XP mejora el desarrollo de producto comparándolo con seguir el proceso requerido en Waterfall o V-Model.

Pero mejorar no es sinónimo de éxito. Bajo mi experiencia, en proyectos de scope cerrado, los pocos proyectos que son entregados a tiempo satisfaciendo las necesidades de cliente (algo que en Waterfall es considerado éxito, y esto,  es muy discutible) han utilizado algún tipo de enfoque incremental y adaptativo.

Esto no es una adaptación de Scrum a un contexto sino que es un modelo híbrido donde hemos hecho cherry-picking en una de las etapas del ciclo en cascada: el desarrollo por norma general.

Otra recomendación es que Scrum suele ser un buen punto de partida para comenzar a aplicar Agile en nuestros proyectos. Sobre todo para equipos que no tienen ninguna experiencia con Agile. Con esto, en ningún caso quiero afirmar que si un proyecto quiere adoptar agile tenga que hacer Scrum, pero el framework maneja conceptos que son relativamente fáciles de entender y seguir (aunque difíciles de dominar) y eso favorece a asimilación de cambio de paradigma.

Definir agilidad, no es algo sencillo

Uno de los conceptos más vagos es el concepto de agilidad. Echa un vistazo a este artículo de Javier Garzas, que habla justo de este tema. De ahí que mucha gente lo confunda ser ágil con “hacer las cosas más rápido” o “hacer las cosas de forma incremental y con equipos pequeños”.

El concepto de que Agile “es una cultura y unos valores” también es en cierto modo polémico. Esto es debido a que, independientemente de estos principios y valores propicien un mentalidad ágil, para serlo realmente debe haber algo más, y esto es, una serie de prácticas concretas.

En el caso de Scrum, seguir la guía de Scrum no es suficiente. De hecho, las implementaciones de Scrum, suelen estar apoyadas por algunas o todas las prácticas XP y otras muchas buenas prácticas que rodean al desarrollo software (Principios SOLID, DRY , YAGNI, entre otros). No tienen por qué ser sólo prácticas técnicas. También deberíamos incluir equipos pequeños, auto-organizados, cross-funcionales, con poder de decisión local al proyecto y altamente motivados. Quizás si tienes más interés puedes echar un vistazo a algunos posts anteriores como:

Mi humilde opinión

Si te centras en seguir Scrum sin tener en cuenta el resto de buenas prácticas, valores y principios, probablemente no serás ágil, aunque estoy seguro de que este tema podría ser un nido de polémica.

Entiendo agilidad como una cultura, principios y valores resaltados en el manifiesto ágil unidos a su vez a los los principios y valores framework que utilicemos, más un conjunto de buenas prácticas en desarrollo software que mejoran la calidad de nuestro producto, eliminan barreras y fomentan la colaboración y comunicación en el equipo.

Por este motivo, si te consideras agilista y estás desarrollando software mediante Scrum, pero desconoces o no aplicas un conjunto de prácticas mínimas que damos muchas veces por obvias como es usar un sistema de control de versiones (en serio, esto pasa), integración continua y test unitarios, muy probablemente no estés siendo todo lo ágil que puedes llegar a ser.

Si además para ti el cliente es un ser mitológico y tu contrato es la ley, casi me atrevería a asegurar que ágil no eres, aunque, como no tengo contexto y siempre hay algo que aprender, no aseguraré nada y diré que hay una alta probabilidad de que ágil no seas.

Creo también que se puede ser ágil sin ser agilista. Me he encontrado equipos, sobre todo pequeñas empresas, que aun sin haber oído hablar jamás de Scrum o los principios y valores del manifiesto (en serio, esto ocurre) aceptaban el cambio de forma natural y su forma de trabajo era muy similar a la de un equipo ágil.

Mi conclusión es que hacer Scrum no es necesariamente ser ágil del mismo modo que hay equipos que son ágiles sin haber escuchado jamás sobre Scrum.

Y tú, ¿qué opinas?