The opportunities and consequences of being responsive to change have never been higher. Organizations that once had many years to respond to competitive, environmental or socio/political pressures now have to respond within months or weeks. Organizations have to transition from thoughtful, careful collectives to ones that can react at breakneck speeds. And respond in a way that does not introduce a massive amount of risk or reduce customer perceived quality and value.
Scrum was built to better manage risk and deliver value by focusing on inspection and encouraging adaptation. It uses an empirical approach combined with self organizing, empowered teams to effectively work on complex problems. And after reading Jeff Gothelf’s and Josh Seiden’s book “Sense and Respond: How Successful Organizations Listen to Customers and Create New Products Continuously”, I realized that the world is full of complex problems. This got me thinking about the relationship between Scrum and modern organizations as they pivot toward becoming able to ‘sense and respond’. So, I decided to ask Jeff Gothelf… Here is a condensed version of our conversation.
Dave: Hey Jeff, you are famous for Lean UX and Design, so what made you write a book on how organizations can sense and respond?
Jeff: In the nearly 5 years since Lean UX came out, we’ve received a ton of feedback. If I had to sum it up, it would be this: nearly everyone who has read the book agrees with the principles and tactics it advocates. However, almost all of those people react the same way, “I’d love to work this way but my company/boss won’t let me.” This seemed like an opportunity. If teams are eager to improve the way they’re working but the environment around them - culture, incentives, managers - aren’t supporting that change, can we convince them to reconsider?
Sense & Respond was exactly this attempt to change the hearts and minds of managers, executives and aspiring managers. It makes the case that first and foremost, any business of scale or that seeks to scale is in the software business. We share a series of compelling case studies to illustrate how this is true across nearly every industry. We then move on to the second half of the book where we discuss how managing a software-based business is different. We cover culture, process, staffing, planning, budgeting and incentives. Change has to be holistic.
Dave: As you know, Scrum is all about inspection and adaptation through transparency coupled with self-organized, empowered teams. That sounds like the perfect model for a sense and respond organization. What are the challenges of Scrum and building a responsive organization ?
Jeff: In my experience, many organizations are building and expanding their capacity to sense. They’re investing in DevOps, analytics, qualitative research and other learning activities. Where they’re struggling is to use that insight in a real-time capacity and respond to what they’re learning. This is where the conflict of leveraging Scrum to build a responsive organization arise. While Scrum provides the cadences and opportunities to respond in a timely fashion to new insights, most organizations don’t reward this behavior. In fact, it’s often seen as a career-limiting move. This is because “responding” is an explicit admission by the team, the team lead or an executive that they were wrong about something. Being wrong is not something organizations celebrate. It’s something they work toward minimizing. However, particularly in software based businesses, we’re going to be wrong quite often. The sooner we can find that out and, even more importantly, respond to what we’re learning the sooner we can course-correct.
Dave: WOW, that is a big point. What you are describing is rewarding teams on learning and, ultimately, delivering more value to customers. But you are not saying that teams should aim to fail, but instead they need to break down their work into small chunks of ‘stuff’ that provides ultimate learning with minimum risk. For example you would not want to test a new pacemaker in someone's chest, but you want to incrementally build your knowledge of the pacemaker by delivering something to stakeholders and getting feedback.
What you are describing is the challenge of ownership. Product Owner (PO) is the role in the Scrum Framework empowered to make decisions about what and when things are in the product. But disempowerment is a real problem in most organizations, with their POs not having the power to make decisions. Is this something you see when introducing the ideas of Sense and Respond?
Jeff: There’s a famous, 20 year old piece from Brad Horowitz where he calls product managers the “CEO of their products.” This couldn’t be further from the truth. CEO’s have a capacity to make final decisions, hiring/firing choices and ultimately shape the strategy and vision of an organization or offering. Product managers (owners) don’t have this. What they can hope for, in ideal situations, is the ability to steer a product toward a strategically relevant and tactically successful deployment. As soon as you introduce sensing into an organization you provide teams, and their product owners, with information that may contradict the rationale for the work they’re doing. Responding to that insight puts the PO in a challenging position often having to justify course corrections in the face of organizational commitment that conflict with the findings their teams have sensed. Good PO’s can take the insight they’re sensing and translate it into compelling stories written in the language of the people they’re trying to convince in the hopes of ultimately delivering the most customer value.
Dave: OK - You talked about the team, and who is involved. Scrum calls for the team to include everyone necessary to delivery the outcome required. How would you staff one of these teams? For more complex situations, how do you get all the necessary skills?
Jeff: Cross-functional collaboration is the key to success in any Sense & Respond team. At the very basic level, the core team is made up of product, design and engineering. We augment that team with subject matter experts, technical specialists or other skillsets needed to deliver the product. However, that’s not enough. No product goes live without legal approving it, finance budgeting for it and ops agreeing to deploy and maintain it broadly. These folks don’t belong on the core team. It’s not a good use of their time. However, they still need to be involved in the process more often than once every three months. In this situation, consider using the “orbital model” for rethinking the core team’s interaction with these supporting disciplines. This model asks each team to form a specific service level agreement with legal, finance et al that asks for a small amount of regularly scheduled support. For example, the core team gets 2 hours of a lawyer’s time every 2 weeks. This allows both sides to discuss the current project, debate any legal concerns and move forward in the most compliant way based on current knowledge. This hedges any concerns about running into a series of regulatory, financial or other roadblocks as the team gets closer to full deployment.
Dave: That sounds perfect, it is essentially making these areas “services” to the team. Overall however don’t you find that the act of releasing software is really hard for many organizations?
Jeff: Maybe at one point, but these days almost all organizations I work with are releasing some software relatively quickly. At worst, I’m seeing quarterly releases.
Dave: For example large banks have such complex systems it is almost impossible for one team to understand these systems enough to release customer value alone. Are there some legacy environments where Sense and Respond doesn’t work? Do you have to have an environment that allows small-ish teams of people to be able to release software rapidly?
Jeff: The continuous nature of software allows us to sense as quickly as you can get something into users’ hands. Organizations need to work toward driving up their speed of learning. The faster they can ship, the faster they can learn. Small teams move faster, therefore they learn faster. If there are dependencies on other teams they can be mitigated through a better sense of what “customer value” is across these dependent teams. If we can focus dependent teams toward the same measure of customer value, they start to work more effectively together -- through collaboration, knowledge sharing, proactive problem solving et al-- allowing the organization to sense more quickly and, equally as important, respond.
Dave: Ok, assuming you can do this, what does planning for executives looks like in this new world? Many executives challenge Scrum because we empower the Scrum Team to make decisions within the guardrails of the vision. They say ‘Scrum allows teams to do whatever they want without any governance.’ Of course we counter with the fact that you still need to provide direction, measures and attend the Sprint Reviews to see what is happening and provide crucial feedback. Scrum provides more control than waterfall, but they still do not like it.. People tend to love detailed project plans that they can measure the activity, not the output. What does planning look like for Sense and Respond ?
Jeff: Planning is the key activity to building a successful Sense & Respond practice. The challenge with managing to outcomes is that it shifts the teams’ focus away from features -- easily plotted on a timeline or roadmap -- to changes in customer behaviors. The teams, armed with the insight collected via sensing activities, need to adjust course (to “be agile”) as they learn these new things. These shifts in direction conflict with linear roadmapping practices. To support this, managers need to ask teams to be transparent about what they’re learning and how it’s affecting their work. They should ask to see how teams are tracking toward delivering customer value and jump in when teams start to veer off strategic course or if something significant has changed in the company priorities.
Dave: This all makes perfect sense for ‘new’ products, but many people building software are actually maintaining it. Adding little features and fixing bugs. Maybe they are doing a set of changes driven by legal or regulatory. Does this approach apply to them? Is this approach only relevant for innovation?
Jeff: I hear this argument quite a bit. I believe that teams working on existing systems are actually in a *better* position to work this way than teams working on brand new initiatives. Existing systems already have users. They have usage patterns. They have analytics. They have feedback. All of this existing insight gives teams a much more informed point of view of where to optimize. They can hone in much faster than “new initiative” teams on the work of greatest customer value. They can also start assessing the impact of their work much sooner because, again, they already have users.
There will always be situations where things simply have to get built. Legal and compliance are two great examples of this. In these, low risk, low uncertainty situations a more straightforward execution is usually warranted. That said, just because a feature has to be included for compliance reasons doesn’t mean there is only one way to implement it. What teams will often find is that there is actual flexibility in how these (actual) requirements can be implemented with some being more successful and less distracting to the overall user experience than others. The level of discovery that you would expend on these features is admittedly smaller but it shouldn’t be thrown out altogether as these features still need to figure into a holistic workflow.
Dave: Scrum and Sense and Respond seem to fit together perfectly. Sense and Respond would encourage Scrum Teams to focus on re-framing and building backlogs that ask questions of the outcomes rather than describing solutions and activities. This would not only encourage everyone to think about what they are trying to do, but also how to measure it. Time to add measurement to your Definition of Done :-)