DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Scrum Successes and Failures in 2017

Scrum Successes and Failures in 2017

My use of Scrum in 2017 involved a lot of lessons learned. As always, some things turned out to be a success, and other things failed miserably.

Barry Overeem user avatar by
Barry Overeem
·
Jan. 07, 17 · Opinion
Like (8)
Save
Tweet
Share
8.78K Views

Join the DZone community and get the full member experience.

Join For Free

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?

scrum Sprint (software development)

Published at DZone with permission of Barry Overeem, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • ChatGPT: The Unexpected API Test Automation Help
  • AWS Cloud Migration: Best Practices and Pitfalls to Avoid
  • Real-Time Stream Processing With Hazelcast and StreamNative
  • Key Considerations When Implementing Virtual Kubernetes Clusters

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: