Build unstoppable Scrum teams with the DOD GAME

Scrum teams need to focus on continuous improvement; this includes the following 3 main areas:

1. Software Quality (reducing code complexity, time to detect a bug, technical debt, etc.)

2. Way in which members communicate and information flows within and outside the team

3. Way in which obstacles are removed

These three points plus size and order of the requirements can directly impact the user experience and final cost of your software product. While I will focus on the first area only, you would be able to find more about the the second and third one in here.

When an organisation starts using Scrum, they often have concerns about the initial Acceptance Criteria list to be added into the new Definition of Done. Some companies choose to use an existing and comprehensive DOD list, while others select a basic list and allow the team to improve it, and the remaining ones prefer to create a DOD from scratch. Every alternative has advantages and disadvantages, and each case should be carefully analysed to chose the right option.

dodgamepicture

Whatever the desired option is, the organisation should understand that an Acceptance Criteria list is a proprietary set of rules and, therefore, local knowledge that must be learned and improved over time. That is why, in my experience, it is always advisable to start with a small DOD and, once the team is able to master it, allow them to make improvements.

A process which is run on regular basis to upgrade the DOD is highly desirable; that will assist the team to gain certain cadence and evolve the list over time.

Keep in mind that there will be no continuous improvement if the team in charge of building the software product does not control their own Definition of Done. That will cause a drop in quality, increase in complexity, technical debt and cost per requirements as well as frustration of its members. As a result of the company taking this shortcut, the Scrum Team will be unable to evolve their processes and the DOD will become larger.

Automating as much as possible and taking solid steps towards learning is essential as it allows people to spend more time at focusing on improving the other two areas.

I know by experience that many organisations have no idea how to help their Scrum teams to improve their Definitions Of Done without invading their spaces or pushing items into their lists. They also feel that they don´t have an efficient and consistent framework to support members in taking the right amount of time to learn and think of the coming acceptance criteria items.

The DOD game is a consistent solution which offers a powerful tool to allow teams to improve their DOD’s on regular basis, give visibility to the rest of the company about progress and help the organisation to understand more about software quality.

Instructions and details of the DOD game can be downloaded here

Have fun and send me your feedback!

Thanks for listening,
Erich.

Creando equipos de Scrum imparables con el juego de DOD

Los equipos Scrum necesitan centrar su mejora continua en las siguientes 3 áreas:

  1. Calidad del software producido (disminucion de complejidad de código, tiempo en detectar un error, deuda técnica, etc.)
  2. Forma en la que se comunican los integrantes y fluye la información dentro y fuera del equipo
  3. Vía en que los obstáculos son removidos

Estos tres pilares, sumados al tamaño y orden de los requerimientos, afecta directamente el coste final del producto de software y la experiencia de usuario. Si bien me centraré en el primer punto, podrás encontrar más sobre el segundo y tercero aquí.

Cuando una organización comienza a utilizar Scrum, suelen plantearse dudas referentes a que pruebas de aceptación compondrán la definición de hecho (Definition of Done) de un nuevo equipo. Algunas empresas eligen que se utilice una DOD ya existente que sea completa a nivel de criterios de aceptación, otras que se emplee una lista básica y que posteriormente se vaya perfeccionando, y los restantes que se comience desde cero y se deje al nuevo equipo que elabore su lista de criterios de aceptación inicial.
Cada alternativa tiene ventajas y desventajas, y deberá analizarse cautelosamente cada caso para conocer que opción elegir.

dodgamepicture

Cualquiera sea la opción seleccionada, la organización deberá comprender que los criterios de aceptación pertenecen a reglas puntuales de la compañía y, por lo tanto, es conocimiento específico que tendrá que ser aprendido y mejorado con el pasar del tiempo. Es por ello que en mi experiencia, siempre es recomendable empezar con un conjunto reducido de criterios de aceptación, y una vez que los mismos son entendidos por todos los miembros con facilidad, ir adicionando o eliminando elementos a la lista cada intervalos razonables.

Se necesita entonces que el proceso de evolución de la lista DOD pueda realizarse entre períodos de tiempo regulares y que el equipo pueda adueñarse del proceso.
Si no existe una revisión continua de la DOD por los equipos que producen software, la calidad del producto bajará, lo que aumentará la complejidad, deuda técnica y coste de los requisitos, así como la frustración de sus miembros. A su vez, si es la empresa quien se encarga de empujar este proceso, los equipos no podrán evolucionar, lo que producirá con el tiempo un aumento de la lista.

Automatizar lo mayor posible y dar pasos solidos es imprescindible ya que permitirá al equipo disponer de más tiempo para centrarse en mejorar los demás pilares.

Es por ello que la incógnita se centra en como ayudar a los equipos Scrum a mejorar su Definition Of Done de forma no invasiva y a su vez brindar un marco de trabajo consistente y tiempo adecuado para que sus miembros puedan comprender y mejorar la lista de criterios de aceptación.

El juego de la DOD es entonces una solución que ofrece una herramienta poderosa, que ha sido probado con un elevado número de equipos Scrum, y que permite a estos ponerse objetivos regulares de mejora continua, así como ofrecer visibilidad al resto de la empresa sobre el avance y comprensión sobre la calidad del software.

Las instrucciones y detalles del juego pueden ser bajadas aquí
¡Que los disfrutes y envíanos tu retro-alimentación!

Si necesitas conocer más sobre como potenciar equipos Scrum, visita nuestro sitio Web.

Gracias por escucharme,
Erich.