Scrum Successes and Failures in 2017

This year, I was in the lucky circumstance to be part of some awesome (Scrum) teams. It certainly wasn’t all “Scrum by the book,” but I’ve learned a tremendous amount of lessons and generated lots of values insights. As always, some things turned out to be a success, and other things failed miserably. This blog post contains a mixture my failures and successes using the Scrum framework as a starting point. 

The following would be the most ideal scenarios for 2017.

The Scrum Team isn’t a group without any synergy at all. It forms a solid, stable, and reliable team moving forward as one, having fun with each other, and continuously challenging, supporting, and engaging one other to do improve on a daily basis.

The Scrum Master isn’t a clerk, puppet master, or project manager in disguise, but someone who becomes acknowledged for their diversity being a servant leader, facilitator, coach, manager, mentor, teacher, impediment remover, and powerful change agent.

The Product Owner isn’t a scribe or proxy without any mandate but someone acting as the entrepreneur for the product, proudly representing the customer's voice, truly understanding the product's intentions and goals. They are is able to outstrip expectations. Customer delight is the ultimate goal!

The Development Team isn’t bunch of reluctant individuals without a common goal but a strong team pursuing technical excellence who is in direct contact with the customer, acts cross-functionally, updates the Scrum board themselves, manages their own team composition, has time for innovation, fixes dependencies with other teams themselves, and delivers a potentially releasable, valuable product each Sprint.

The Scrum Values are not a dusty poster on the wall but the values commitment, respect, openness, focus, and courage give the Scrum Team a solid foundation and direction for their work, behavior, and endeavors.

The Product Backlog isn’t an endless incoherent list of work hidden in some digital tool but an ordered shared backlog taking priority, value, dependencies, risk and the amount of learning into account.

The Sprint Backlog isn’t the sum of all the unfinished work of the previous Sprints but a forecast visualizing all the work necessary to meet the Sprint Goal.

The Increment isn’t a functional or technical document lacking any business value but an increment of the product that generates feedback, insights, and learning, which helps build the right product.

The Scrum Events are not considered to be mandatory meetings but opportunities for conversations, discovery, and collaboration.

The Sprint isn’t an artificial time-box or everlasting “Sprint 0” without any business value but is considered a powerful instrument that offers focus, rhythm, and predictability by ensuring inspection and adaptation of progress toward a Sprint Goal.

The Sprint Planning isn’t a tedious full day session with a poorly refined Product Backlog but an opportunity to create an engaging Sprint plan with clear goals the entire Scrum team commits to.

The Daily Scrum isn’t a status-update towards the Scrum Master focusing on minor activities instead of achieved results but an energizing inspection of the progress made towards the Sprint Goal resulting in a fresh committed daily plan.

The Sprint Review isn’t considered as a “demo” in which the results are shown to the Product Owner but is used to gather feedback on the delivered product and evaluate the collaboration. It’s the ideal moment for a joint reflection and to decide how to proceed to optimize value.

The Sprint Retrospective isn’t canceled because “there’s nothing to improve” or “we don’t have time to discuss improvements,” but is an opportunity to inspect collaboration, engineering practices, and the Definition of Done, resulting in actionable and committed improvements or shared working agreements.

Backlog Refinement isn’t considered as a too expensive “meeting” but seen as a necessary ongoing process to improve the Product Backlog. It’s an activity to collaborate as a team with the goal of reviewing and revising Product Backlog Items ensuring a high-quality Product Backlog.

The Sprint Goal isn’t the usual “just realize the Sprint Backlog” but is used as an instrument to test assumptions, address risks, or deliver features.

The Definition of Done isn’t a document defined by the Quality Assurance department the Scrum Team must comply to but a practice for the Development Team to create a common understanding about quality that helps the team assess when work on the product increment is complete.

A Definition of Ready isn’t necessary because frequent refinement of the backlog already creates a flow of Product Backlog Item readiness.

Closing

This blog post contains my year of Scrum in a nutshell. Using the parts of the Scrum framework as a starting point, I’ve shared some of my failures and successes. Of course, “failure” might sound dramatic — however, Product Owners without any mandate or Scrum Masters who were considered the team’s clerk did cause me some headaches. Luckily, this did result in lots of learning and insights. Can’t wait to apply them in 2017!

What are your successes or failures using Scrum this year?