Scrum is about shipping fast(er). But it is also about building what the customer needs. These are two sides of the same coin. Although the former is often at the forefront of attention (also thanks to DevOps), the latter is frequently forgotten. Think about it; how often do you have real customers or real users present during Sprint Reviews? How often do developers talk with real customers and users? Although I understand why, this is not helped by the the official Scrum Guide. It has exactly zero references to ‘customers’ or ‘users’, and abstracts them away behind the business jargon of ‘stakeholders’. Contrast this with the Agile Manifesto which references ‘customer collaboration’ purposefully as part of its third principle.
It's all about your customers, or why common sense is not common practice
Let’s not beat around the bush; your organization exists because it offers something valuable to people outside your organization. What this means is different for organizations operating in the private or the public sector. If you work for a company in the private sector (like Google, BMW or Walmart) it will be offering products or services that distinguish themselves from competitors in aspects that are important to your customers (e.g. convenience, cost, quality). Products or services that fail to draw in sufficient customers will eventually wither and disappear in the marketplace of competing services and products. If your organization is a non-profit (like the Red Cross or the Rotary) or if it operates in the public sector (e.g. the police, the army or the city council), it offers a unique or otherwise valuable service to its members, citizens or customers. Although the dynamics are different, an organization can continue to exist only if it offers something valuable to people outside the organization. And with the onset of social media, fewer and fewer organizations can survive the wrath of unhappy customers, citizens or members (for brevity, I will refer to these groups as ‘customers’ from hereon). Organizations need to be acutely aware of how important their customers are to their continued existence.
Every organization has external customers. Others also have ‘internal’ customers. These are the users or departments that need some service or product from other teams or departments within the same organization. Although the dynamics are different, the principle is the same. You can only continue to exist if you offer something valuable to your customers.
This seems so obvious. But somehow we often forget what this means in our day-to-day work. Why is that in many organizations - large or small - the people that are actually working on a product (designers, developers, managers, testers, etc) rarely talk to customers and users. Hidden behind layers of ‘organizational fat’ (sales, marketing, account managers, project managers), the customer has become an abstraction.
Product Development requires collaborative discovery
Why should we care about this? It has everything to do with the inherent complexity of product development. While customers initially seem to know what they need, and developers seem to know how to implement this, the reality is that customers figure out what they need along the way and developers figure out how to build this along the way. This process of ‘collaborative discovery’ necessarily requires frequent feedback and communication between the people using the product and the people building it. It requires a lot of it.
This is where the Scrum Framework comes in. It lays down the bare essentials for a process that promotes collaborative discovery. By frequently delivering incremental versions of a product, developers and customers can have important conversations about what is needed and how to build it. “Does the feature, implemented this way, help you solve the problem?”, “Do you understand how to use this feature?”, “What can we do to make this feature more useful to you?” and “What new, valuable ideas pop up when you see this?” are the kind of things you want developers and customers to be talking about.
A lot of Scrum Teams often forget about the ‘collaborative’ part, making the ‘discovery’ part more like a lifeless trudge down a one-way road. Without meaningful feedback and input from customers, what else is there to do but continue to plow through the Product Backlog until the product is done? Teams rarely see customers or users, or are even afraid of them (‘they are always unhappy!’). Being very abstract and distant, what customers want and need becomes something that development teams only know through layers of organizational filtering.
You shouldn't ship fast without involving the customer
This is why ‘building what the customer needs’ and ‘shipping fast’ are two sides of the same coin. It's wonderful to ship fast. But it is nothing more than a technical exercise if the customers are not also deeply involved in this process. How can developers build good products if they never talk or see customers and users? This means that we need to draw the people that use the product - our customers and users - deeply into the process of building that product. Not hidden behind a Product Owner, but in a more direct sense. Only then can we create the kind of collaborative environment where valuable, amazing products are created. Scrum will help you do both, but it requires careful attention to both sides of the coin in equal measure.
This post is a selection from the upcoming book on (Zombie) Scrum that I'm authoring with Johannes Schartau. Check out www.zombiescrum.org for more posts. We'd love to hear your ideas, feedback and input! We aim to publish the full book early next year, so consider this our way to 'ship fast and involve the customer' :) I would also like to credit Dave West from Scrum.org for the inspiration to write this post. He made a similar case during the Scrum Day Europe 2017.