My Year of Success and Failure using Scrum

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, other things failed miserably. This blog post contains a mixture my failures and successes using the Scrum Framework as a starting point. The first part of every paragraph briefly describes the most common failures I've experienced; the latter the successes I've already achieved this year or hope to achieve in 2017.

Wouldn't it be great if in 2017...

• The Scrum Team isn't a group without any synergy at all but 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 daily basis.

• The Scrum Master isn't a clerk, puppet master or project manager in disguise but someone who becomes acknowledged for its 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 customers voice, truly understanding its intentions and goals and is able to outstrip its expectations. Customer delight as the ultimate goal!

• The Development Team isn't bunch of reluctant individuals without a common goal but is a strong team pursuing technical excellence, is in direct contact with the customer, acting cross-functional, updating the Scrum board themselves, managing their own team composition, having time for innovation, fixing dependencies with other teams themselves and delivering 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, behaviour and endeavours

• 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 visualising all the work necessary to meet the Sprint Goal.

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

The Scrum Events are not considered as mandatory meetings but as 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 actual achieved results but an energising 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 optimise value.

• The Sprint Retrospective isn't cancelled 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 realise 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 common understanding about "quality" and 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, but for example Product Owners without any mandate or Scrum Masters considered the team's clerk did cause me some headaches. Luckily it 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?