When I work with customers, the ones who have the biggest troubles are the ones who are obsessed with ”doing scrum right”. I get that Type A personality desire to do something correctly and follow the rules but the problem is that they end up focusing on the wrong thing. Scrum is not the point.
Let me clarify. If I’m working with a company on their agile transformation or their implementation of Scrum or doing a Scrum training for their team, they’re not wrong in thinking that Scrum is important. It’s that Scrum isn’t the point. Following all the rules, regulations, and guidelines of Scrum doesn’t guarantee success.
If your focus is on the process, you’ll get good at the process. If your focus is on delivery, then you’ll get good at delivery.
You’re being paid to deliver features or business value, or done software. Whatever it is that you’re working on, it’s delivering that really matters. (You can use Scrum for non-software things but I’m going to assume that the reader is from the software world.)
Scrum is a Tool and ’Agile’ is a Mindset
If you want to get good at delivering done, working software (or whatever you’re working on), Scrum is an excellent tool. It helps the humans to wrap their heads around the complexity of delivering stuff. The complexity isn’t just about writing the code and testing the application. Scrum tries to help you with the tricky human stuff, too.
Computers are easy. If you can spell out exactly what you want them to do, the computer will do it the same way every time. Humans on the other hand are way more difficult. There’s vagueness all over the place in human interactions, language, and motivations. Scrum’s events, roles, and artifacts give you a framework for how to wrangle the humans — herd the cats, if you will — in order to deliver done, working software.
A piano or a saxophone are tools for making music. Getting really good at just pressing the keys does not guarantee that you make great music. Technical prowess on the instrument does not necessarily lead to musicality. You can have amazing technique and still make terrible music if you don’t pay attention to the end goal.
It’s All About Done, Working Software
In software development, the goal is done, working software. I’d probably toss in ‘maintainable’ and ’testable’, too. But overall, it’s got to be done and it has to work properly.
So Scrum is not the point. Done, working software is the point. But Scrum is a great tool for delivering done, working software.
If you’re using Scrum, your goal — your *mission* — is to remember how the role, events, and artifacts of Scrum help you to deliver done, working software. When I’m teaching Scrum or helping teams, I want everyone to remember how each piece of the Scrum Framework gets you closer to done, working software.
Each Thing in Scrum Relates to Delivery
Scrum is made up of roles, events, and artifacts.
The roles: Product Owner, Development Team, Scrum Master
The events: Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective
The artifacts: Product Backlog, Sprint Backlog, the Increment
If your organization is new to Scrum, you'll want to try to remember what each of those things has to do with done, working software. If you're an organization that's been using Scrum for a while and you want to (perhaps) tighten up your use of Scrum or to see if there are things you could do to improve your delivery process, once again, a great place to start is to think about how all those items related to done, working software.
There's lots that can be said about how they relate and what the motivations are for each...but I'm going to try to write a quick version for each item.
How Scrum Roles Relate to Done, Working Software
Product Owner. This person decides which features should get added to the product (aka. turned into done, working software) and in which order. The list of features is the Product Backlog. The items in the Product Backlog are called Product Backlog Items (PBIs). This person also is responsible for the priorities of the PBIs on the backlog. The PBIs at the top of the Product Backlog should be turned into done, working software first because they're the highest priority.
Development Team. These are the people who create and deliver the done, working software. They take the goals and features requested by the Product Owner and turn them into done, working software that's delivered in the product.
Scrum Master. This person helps everyone to be productive and to focus on delivering done, working software. For example, the Scrum Master might help the Product Owner to ensure that the contents and the priorities in the Product Backlog are clear and understandable. Another example, the Scrum Master might help the Development Team to stay focused on delivering features to 'Done' even if things get chaotic and stressful.
How Scrum Events Relate to Done, Working Software
The Sprint. This is the container for everything that happens in Scrum. It starts with Sprint Planning and ends with the Sprint Retrospective. The idea is that you'll deliver done, working software in 30 days or less.
Sprint Planning. This meeting is where everyone decides what features they're going to work on. Typically this meeting answers two questions for the Sprint: 1) what PBIs will we attempt to turn into done, working software and 2) how will we turn those PBIs into done, working software.
Daily Scrum. This meeting is for the Development Team to review their progress towards delivering done, working software in the Sprint. Essentially, they're looking at how much progress they've made and then making sure that their plan for delivery is still valid.
Sprint Review. This meeting brings everyone together as well as any Stakeholders who might care to attend. Let's show off that done, working software (aka. the Increment) and get feedback on it. Let's get feedback on the product. Is it in good shape? Are we missing anything? Let's also get feedback on the Product Backlog to make sure that we're thinking of developing the right features for future sprints -- basically, verify that we're planning to build the right done, working software.
Sprint Retrospective. This meeting brings everyone together to discuss how the delivery of done, working software went in this Sprint. The idea is to identify ways to improve the delivery process and ideally limit any mistakes to a single sprint.
How Scrum Artifacts Relate to Done, Working Software
Product Backlog. This is the list of features that might possibly be added to the product -- aka. the list of PBIs that might get turned into done, working software. The highest priority items should be at the top of this list.
Sprint Backlog. This is the 'what', 'why', and 'how' for the Sprint. The sprint goal describes why are we building this done, working software. The list of PBIs represents the features the team intends to deliver as done, working software in this sprint. The team's plan (often a list of tasks) describes how they intend to create the done, working software.
The Increment. This is the done, working software delivered as part of this Sprint.
Summary
If you want to be successful, focus on delivering done, working software. Deliver business value. Deliver features that bring delight to your customers and stakeholders. Get good at that delivery process. Remember that Scrum is there to help you and your team(s) to deliver done, working software. But getting good at Scrum by itself is NOT the goal.
And if your use of Scrum feels heavy, pointless, or just isn't working, try to remember how the roles, events, and artifacts each try to help you towards delivering that done, working software.
I hope this helps.
-Ben
-- Looking for help with Scrum? Not sure what 'done' even means? Having trouble getting done, working software from your teams? Do you have a pile of requirements and they're all #1 priorities? Feeling overwhelmed? We can help. Drop us a line at info@benday.com.
