TL;DR: Use Burn-Down Charts to Discover Scrum Anti-Patterns
A burn-down chart tracks the progress of a team toward a goal by visualizing the remaining work in comparison to the available time. So far, so good. More interesting than reporting a status, however, is the fact that burn-down charts also visualize scrum anti-patterns of a team or its organization.
Learn more about discovering these anti-patterns that can range from systemic issues like queues outside a team’s sphere of influence and other organizational debt to a team’s fluency in agile practices.
On February 3rd, 2018, 20-plus people will join a hackathon to build an agility assessment framework based on this taxonomy. The goal of the workshop is to provide the first version of a tool that empowers agile practitioners to measure agility, be it an organization’s suitability for agile practices or a team’s progress on its path to becoming agile.
After rebuilding an existing application on a new tech stack within time and under budget our team had an overall retrospective with stakeholders this week to identify systemic issues. We found more than 20 problems in total and derived eight detailed recommendation the organization will need to address when moving forward to the next level of agile product creation.
Read on and learn how we achieved this result in under two hours with an overall retrospective attended by 16 people.
The following 70 scrum master theses describe the role of the scrum master from a holistic product creation perspective.
The scrum master theses cover the role of the scrum master from product discovery to product delivery in hands-on practical manner. On the one side, they address typical scrum ceremonies such as sprint planning, sprint review, and the retrospective. On the other hand, the scrum master theses also cover, for example, the relationship with the product owner, they deal with agile metrics, and how to kick-off an agile transition, thus moving beyond the original scrum guide.
Learn more about agile management anti-patterns the aspiring agile manager should avoid during the organization’s transition. From stage-gate through the back door to the ‘where is my report’ attitude.
Do you remember the good old days when the organization started with its first Scrum team? And the new engineering kid on the block was “merely” supposed to deliver a potentially shippable product increment at the end of a sprint?
The first team was to sound the bell for the upcoming change towards a learning organization. Little did we know back then about the challenges along that route. When teams 2, 3 and 4 joined, shipping a product increment at the end of a sprint became first complicated, and then complex.
It turns out that becoming agile does not only required to create (Scrum) teams. Reaping the full benefits of becoming agile, of becoming a learning organization built around software also requires changing engineering practices. Nowadays, it is all about continuous value delivery.