Similarly simple advice can be found in the Scrum Guide. I review it, as well as the guidelines for Extreme Programming, often, and especially before each new consulting gig. The combination of these two concepts is what most people consider Agile these days and it helps to have them fresh in my head when I start a new project. Every time I read through the Scrum Guide I am struck by how obvious and straightforward it all seems, much like that *sagely advice from my old track coach. I am similarly struck by how readily we trade the simple Scrum guidelines for the convoluted as we go through our day to day operations. And how surprised we are when it bites us in the rump.
Being a realist, I know asking for a commitment to Scrum done by the letter on most teams is going to be a tough sell. So, for this week's post I have picked exactly two pieces of the Scrum Guide I would like tattooed on the synapses of every team who considers themselves practitioners of Scrum. I see these simple bits of guidance from Scrum violated constantly and they are among the most empowering if followed.
Thing One - The Sprint
'The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created.'
Taken on it's face this means every Sprint produces working software that can be demonstrated by a user. It does not mean the creation of some technical component that will only ever be known to work properly after several months of other giant architectural dreams are realized. Put something in the hands of the product owner that is usable. Do so every sprint. It may be embarrassingly light on features, but something that works end to end and could be shipped if required. Product owners and paying customers don't care one single bit about how shiny your data access layer and back end services are polished. Until I can charge customers or enable business functionality for a partner, the software is useless. Unfortunately, yes, I mean yours too.
Thing Two - The Product Owner
'The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:
- Clearly expressing Product Backlog items;
- Ordering the items in the Product Backlog to best achieve goals and missions;
- Optimizing the value of the work the Development Team performs;
- Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
- Ensuring the Development Team understands items in the Product Backlog to the level needed.
The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.
The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.
For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says.'That's a mouthful by anyone's standards. An entire organization respecting a single person's decisions is also something I have rarely witnessed. Empowering a Product Owner and fighting to keep that Product Owner focused and present in the team space is genuinely tough. Having recognized that, it is still absolutely worth the effort. Letting one person focus on the product evolution and trusting them to checkpoint and refine as they iterate takes away a non-trivial amount of thrash that slows development teams down. I suppose one interpretation of empowering a product owner is really embracing the empiricism at the heart of Scrum. It means always moving forward, potentially imperfectly, so that the team can keep learning and producing value.
In Closing
If your team is not currently doing these things, please don' take this post as a condemnation of your professional ability. Scrum is difficult. Software can be difficult. We all need constant reminders of how this is supposed to work and why it is important to be making continuous improvements toward a model we know produces the best results.The quotes in this post were taken from the Scrum Guide, which can be found here.
