Welcome to the Home of Scrum!

Every Sprint starts with a Sprint Planning event. It is very crucial to ensure that the Scrum Team comes to a shared understanding of what and how are they going to deliver a “Done” increment that creates maximum business impact. Although, like other events Sprint Planning also is often marred with few dysfunctions. In this post I will bring forth 5 common dysfunctions that I have observed associated with this event. Unavailable Product Owner: Product Owners often tend to think that their job is to pass on the requirements to the Development Team and that is good enough to get the work done. They spend too much time with the end-customers, stakeholders or just writing detailed requirements for the team. On the other hand they spend too little time with the team and are mostly unavailable to the team when they are needed the most. This leads to the most common dysfunction – unavailable Product Owner which percolates to other dysfunctions. Lack of Refinement: Since Product Owner is often unavailable, the development team skips the Product Backlog Refinement sessions. As we are aware, Product Backlog Refinement is a collaborative session where the Product Backlog Items are refined and moved towards the ready state i.e. detailed enough, ordered and estimated. Ordering of Product Backlog Items is accountability of the Product Owner, as well as providing enough details around any Product Backlog Item is job of the PO. Now, since the PO is not available then the refinement doesn’t add any value. Ambiguous Requirements: As enough time is not spent in Product Backlog Refinement, the development team sees the requirements for the first time during the Sprint Planning. Since, refinement has not happened these requirements are often vague and ambiguous. The development often does not have clue how to move forward. They spend lot of time going over and over a single PBI and thus not making use of the Sprint Planning event to Inspect and Adapt for the Sprint. Erroneous Forecasts: Since the team sees the PBIs for the first time during the Sprint Planning, they often do not have any clarity of how to approach the requirement, or they often overlook scenarios/complexities that may arise as they start implementing the requirements. As a result, the estimates provided by the team are either overestimated or underestimated. This in-turn leads to erroneous forecasts of what can be done during the Sprint or thereafter. No Shared Commitment : All the above four dysfunctions lead to the final dysfunction which is No Shared Commitment within the Scrum team. As the requirements are vague, the forecasts over/under estimated and there is no shared commitment within the Scrum Team, a tiff starts between the business (Product Owner) and delivery (the Development Team). A game of pointing fingers and highlighting what other has not done or could have done begins. None of which is conducive for the team to work as a cohesive unit. Conclusion: There might be many more dysfunctions that might lead to not having a successful Sprint Planning event. These are few that I came across. As a Scrum Master it is always good to be vigilant about such dysfunctions, reveal them and help the team to overcome the dysfunctions.

While working remotely might feel good right now, we are up for trouble. Anxiety-invoked behavior and stress are likely to happen very soon. Let's discuss what is coming at us.

En la reunión del Manifiesto Ágil en 2001, se escribió un conjunto de 4 valores respaldados por una docena de principios. Esto era el inicio de lo que es Agile. Hubo 3 expertos en Scrum presentes y los 4 fundadores de eXtreme Programming. Estos fueron los únicos dos procesos ampliamente implementados en el mundo real. Están relacionados porque los fundadores de ambos procesos se comunicaban en los grupos de noticias de Internet a medida que se formaban y reutilizaban ideas el uno del otro ya en 1994. Los otros expertos en la reunión, habían escrito libros y documentos sobre procesos de desarrollo más adaptables y flexibles para reemplazar el Rational Unified Process de IBM que era dominante en ese momento en software, pero demasiado pesado. Entonces Scrum y XP son los padres de Agile, y Agile no es un marco o una implementación operativa. Es un concepto abstracto no operativo. La implementación operativa de Agile en más del 80% de los equipos de hoy es una variante de Scrum. Los equipos más hábiles implementan prácticas XP dentro del Scrum. Una práctica de XP extremadamente importante implementada en los primeros equipos Scrum es la integración continua varias veces al día y el despliegue a producción al menos una vez por sprint, si no varias veces al día. Además, el movimiento DevOps ha evolucionado para promover esta práctica que formaba parte de los equipos originales de Scrum y XP. Más del 50% de los equipos "ágiles" no pueden entregar al final de un sprint y llegan tarde, por encima del presupuesto del proyecto, con clientes insatisfechos según los datos del Standish Group en cientos de miles de proyectos. Así que ten cuidado con el falso Agile y los falsos mesías de la agilidad. Espero haberte explicado la diferencia entre Scrum y Agile.

In this third post of the Remote Agile series, we address the tool at the heart of working with a distributed team as a Scrum Master, Agile Coach, or Product Owner: Zoom.