Checklist de un Scrum Master Un adecuado Scrum Master puedo manejar 2 o 3 equipos al mismo tiempo.

Si tu trabajo se limita a organizar reuniones, hacer respetar los timeboxing y responder a los impedimentos que la gente reporta explcitamente, vas a poder manejar parttime estos equipos. El equipo probablemente tendr un rendimiento superior comparado al estado pre-Scrum de la organizacin, y probablemente nada catastrfico va a suceder. Pero si quieren imaginar un equipo que tiene un gran rendimiento, logrando objetivos que antes eran imposibles, dentro de una organizacin transformada, consideren tener un Gran Scrum Master. Un gran ScrumMaster puede manejar un equipo a la vez. Se recomienda un ScrumMaster dedicado full-time a un equipo de unas 7 personas, sobre todo cuando se inicia. Si no has pensado o considerado todo el trabajo que hay que hacer: sintonizar con el Dueo del producto, el equipo, las prcticas de ingeniera del equipo, y la organizacin fuera del equipo. Si bien no hay una receta nica, a continuacin un listado de tareas que muchas veces un Scrum Master pasa por alto. Cmo va trabajando mi Dueo de Producto? Puedes ayudar a incrementar la efectividad de tu Dueo de Producto, ayudndolo a mantener la Pila de Producto (Product Backlog) y el Plan de Entrega (Release Plan). (Nota: Solo el Dueo de Producto prioriza la Pila de Producto) __Est la Pila de Producto priorizada de acuerdo a su ltima idea? __El Backlog captura (representa) todos los requerimientos y deseos del producto de todos los stakeholders? Recuerda que el backlog es emergente. __ Es la Pila de Producto de un tamao manejable? Para mantener un nmero manejable de elementos, mantener las cosas ms granular hacia la parte superior, y las historias picas generales en la parte inferior. Es contraproducente analizar demasiado ms all de la parte superior de la Pila de Producto. Sus requisitos cambiarn en la constante conversacin entre el desarrollo del producto y stakeholders/clientes. __Podra cualquier requerimiento (especialmente aquellos cercanos a la parte superior de la Pila de Productoo) ser mejor expresado como historia de usuario independiente, negociable, valuable, estimable, pequeo y testeable? __Has instruido a tu Dueo de Producto sobre las technical debts y como evitarlas? Una pieza del puzzle podra agregar prueba automtica y refactoring a la definicin de done de cada tem del backlog. __es el Backlog un information radiator, claramente visible para todos los stakeholders? __Si estas usando una herramienta automtica para la gestin del Backlog, te est en realidad funcionando? Las herramientas de gestin automticas implican el riesgo de convertirse en information Refrigerators sin una radiacin activa del Scrum Master. __Puedes ayudar a irradiar mostrando a todos impresiones?

__Puedes ayudar a irradiar creando Big Visible Charts? __Has ayudado a tu Dueo de Producto a organizar los tems del Backlog en Release apropiados? __Todos los stakeholders (incluido el equipo de desarrollo) estn al tanto de si el Release Plan aun coincide con la realidad, basado en la velocidad actual (ejemplo: story points por sprint)? __Tu Dueo de Producto ajust el Release Plan luego de la ltima Sprint Review? La minora de los Dueos de Producto que entregan a tiempo sus productos testeados, replanifican el Release cada Sprint, por lo general postergando algunos trabajos para futuros Releases, a medida que se descubren trabajos mas importantes. Puede tratar de mostrar a todos los Producto / Release Burndown Charts, despus de que los items han sido reconocidos como "done" en cada reunin Sprint Review. Esto permite la deteccin temprana de alcance / cambios de cronogramas. Cmo va trabajando mi equipo? __los miembros del equipo estn pasando la mayora de su tiempo en estado de flujo? Algunas caractersticas de este estado (de Flow: La Psicologa de la experiencia ptima, de Mihaly Cskiszentmihalyi): metas claras (las expectativas y reglas son discernibles, y las metas son alcanzables y alineadas apropiadamente con el set de habilidades y actitudes de cada uno); Concentracin y Foco, con alto grado de concentracin en un campo limitado de atencin; Una prdida del sentido de auto-conciencia, la fusin de la accin y la conciencia; el sentido distorsionado del tiempo - la experiencia subjetiva propia del tiempo es alterado; Feedback directo e inmediato (xitos y fracasos en el curso de la actividad son evidentes, por lo que el comportamiento se puede ajustar segn sea necesario); Equilibrio entre el nivel de habilidad y el desafo (la actividad no es ni demasiado fcil ni demasiado difcil); un sentido de control personal sobre la situacin o actividad; la actividad es intrnsecamente gratificante, as que hay un sentido de accin fcil o cmoda. __Los miembros del equipo se llevan bien, se divierten juntos, y celebran el xito del otro? __ Los miembros del equipo mantienen un nivel alto de responsabilidad unos con otros, y se desafan para seguir creciendo? __ Existen problemas / oportunidades que el equipo no est discutiendo porque se sienten demasiado incmodos? Ver Crucial Conversations: tools for talking when stakes are high. O considere buscar un facilitador profesional que pueda transformar las conversaciones incmodas en ms cmodas. __Ha probado diferentes formatos y lugares para llevar a cabo la Retrospectiva? Ver Agile Retrospectives: making good teams great, de Esther Derby y Diana Larsen. __ El equipo se mantuvo enfocado en los criterios de aceptacin? Tal vez usted debera llevar a cabo un chequeo a mitad del Sprint para volver a revisar los criterios de aceptacin de los tems del Product backlog comprometidos para este Sprint. __ El Sprint Backlog refleja lo que el equipo est haciendo? Las interrupciones y distracciones que no contribuyen a los objetivos de Sprint son impedimentos.

__ Las tareas del equipo estn estimadas y/o actualizadas en el taskboard? __ Los artefactos (herramientas) de autogestin del equipo (taskboard, Sprint Burndown chart, etc) estn visibles para el equipo y son conveniente para ser utilizados por ell equipo? __ Los artefactos (herramientas) de autogestin del equipo estn adecuadamente protegidos de los micro-gerentes? __ Los miembros del equipo se ofrecen voluntariamente para las tareas? __ Los technical debt repayment tems (para tratar temas que estn minando la velocidad del equipo) estn capturados en el backlog, o comunicados con el Dueo del producto? __ Los miembros del equipo dejan de lado sus ttulos de trabajo cuando trabajan en la sala del equipo? __ El equipo entero se considera responsables colectivamente de la documentacin de usuario, pruebas, etc? Cmo van funcionando las prcticas ingenieriles? __El sistema en desarrollo tiene un botn push to test para que cualquiera (del mismo equipo u otro equipo) puede detectar convenientemente cuando estn broken?. Generalmente esto se alcanza a travs del xUnit framework (JUnit, NUnit, etc). __Tienen un balance apropiado entre pruebas funcionales y pruebas unitarias? __El equipo esta escribiendo tanto las pruebas funcionales como las pruebas unitarias en el mismo lenguaje que el sistema que estn desarrollando? __El equipo descubri la til zona gris que existe entre pruebas funcionales y pruebas unitarias? __el server de integracin continua suena automticamente su alarma dentro de la hora (o minutos) que alguien causa una falla de regresin? __Todas las pruebas roll up en el resultado de integracin continua del server? __Los miembros del equipo descubrieron el placer del diseo continuo y el refactoring continuo, como una alternativa al Big Design Up Front?. El refactoring tiene una definicin estricta: cambiar la estructura interna de un sistema sin cambiar su comportamiento externo. El refactoring debera ocurrir varias veces por hora, cada vez que haya un cdigo duplicado, lgica condicional compleja, identificadores mal nombrados, acoplamiento excesivo entre objetos, excesiva responsabilidad en un objeto, etc. El Refactoring con confianza es prctico con cobertura de pruebas automatizadas. Los baches en las coberturas de pruebas y los refactoring diferidos son cancers llamados technical debt. __Tu definicin de done para cada tem funcional del Product Backlog incluye refactoring y cobertura total de pruebas automatizadas? Es poco probable que en cada Sprint desarrolles productos potencialmente entregables (Potentiallyshippable products) sin aprender prcticas de eXtreme Programming. __Los miembros del equipo hacen pair programming la mayora del tiempo? Pair programming puede mejorar de manera significativa el mantenimiento del cdigo y reducir el ndice de bugs. Pero es una prctica que desafa los lmites de la gente y a veces parece tomar mucho tiempo (si es que priorizamos la cantidad sobre la calidad). En vez de forzar a la gente a hacer esto, incialos con el ejemplo, estableciendo paired workday con los miembros del equipo.

Cmo esta trabajando la organizacin? __Existe la cantidad apropiada de tiempo en coordinacin inter-equipos? Scrum de Scrum es solo una forma de alcanzar esto. Considere tambin enviar embajadores a los daily meetings de otros equipos. __La coordinacin inter-equipos la realizan gente comprometidas? (dirty hands= subirse las mangas de la camisa para trabajar). __Tus reuniones de Scrum Masters (con otros Scrum Masters) est trabajando la lista de impedimentos de la organizacin? __Cuando es apropiado, los impedimentos de la organizacin son pegados en el muro de la oficina del director de desarrollo (o produccin)? Puede cuantificarse el costo en dlares, en prdidas del mercado, en prdida de calidad, en prdidas de oportunidades de clientes? __Es su organizacin una de las pocas con carreras profesional compatible con los objetivos colectivos de sus equipos? Responda "no" si no hay un incentivo de carrera para hacer el trabajo de programacin o arquitectura, a expensas de las pruebas, automatizacin de pruebas o documentacin del usuario. __ Est ayudando a crear una organizacin de aprendizaje? __Su organizacin ha sido reconocida por la prensa especializada u otras fuentes independientes como uno de los mejores lugares para trabajar o un lder en su industria? Fuente: http://scrumalliance.org/articles/194-an-example-scrummasters-checklist