The Elephant in the Agile Room
One of my favorite business books of recent years is Mark Schwartz’s (2016) phenomenal The Art of Business Value. (His follow-up, A Seat at the Table, is also fantastic.) The Art of Business Value deftly calls out Agile on basically dodging all matters of strategy. This enabled Scrum, which is how most organizations approach “Agile,” to enshrine the Fast Food Model of product work, with IT Agile teams being expected to fill orders the Business places at the proverbial drive thru. The result was, well, Waterfall. To mix metaphors, there’s an elephant in the room, and it’s an emperor with no clothes. Schwartz’s main argument is that while Agile made some improvement over Waterfall, it didn’t go far enough. As a result, to confuse Agile with the best of modern product work is to be left behind.
Waterfall took a point-in-time snapshot of information and based a long-term plan on it. Agile realized that specifying solution requirements prior to project work is a fool’s errand. Unfortunately, it stopped there. In Schwartz’s words,
…the critical assumption that was not challenged was that the business is responsible for determining the business needs — in other words, for making decisions on what would add business value. Even as the team and the business worked together iteratively and incrementally, it was solely the business that owned the business need. The IT team received frequent feedback from the business on whether it was “meeting the need” and adjusted course accordingly. The essence of the model was still that IT was not part of the business, but again an order taker.
In this view, the business communicates needs, and IT is just supposed to fill orders placed. Here, “success” is measured in terms of business customer satisfaction. As a former CIO, he says he knows firsthand that IT’s job is not to “deliver on business requirements,” as evidenced by the fact that whenever business outcomes are not achieved, the CIO cannot simply say, “So what? We delivered on the requirements you gave us.” It’s still somehow IT’s fault.
In their 2009 book, The Real Business of IT, Hunter and Westermen call this out as a “value trap.” Treating the business as IT’s customer — and assuming the customer is always right — limits value. It negates one of the most valuable things IT can do, which is help business managers learn how the business should be changed, as well as help them play their roles as they implement those changes.
Agile assumed that business value is something known by the business but not the Agile teams. This is simply not true, Schwartz says. Business value is not some secret formula known only by “the business.” There is no MBA secret magic. To escape the value trap, the business needs to partner with IT Agile teams to discover what will be of value as the teams do their work. We already know most features don’t create value, Schwartz emphasizes, so we need to move away from a model that pretends that if we just deliver more features, business value will magically pop out.
It’s telling that when Agile literature does discuss business value, it seldom amounts to more than some esoteric reference to “ROI,” which is, Schwartz argues, not a helpful thing to focus on. For example, Ken Schwaber (2004), as well as Craig Larman and Bas Vodde (2009), state that the Product Owner is responsible for “maximizing ROI.” (Huh?) Larman and Vodde state that when the product in question won’t be purchased by external customers, the Product Owner is still responsible for ROI by choosing “the highest-business-value, lowest-cost items each sprint.” As Schwartz points out, this is circular reasoning.
Though it can technically be anything, the “R” in ROI is generally revenue. One of the fathers of Scrum, Jeff Sutherland, has stated that the Product Owner is responsible for “maximizing revenue per story point” (see Sutherland, 2013). Schwartz rightly says it’s time to call BS on this notion. The fact is no Product Owner actually estimates the ROI of a story, nor should they. Even if a Product Owner somehow figured out how to apply a projected average increase divided by a projected average cost to individual backlog items, this doesn’t always maximize business value. There are a variety of problems with both ROI and NPV which Schwartz discusses, summarized in the following table.
ROI and NPV are basically Finance’s take on Waterfall. But we’re not supposed to be making all the decisions upfront anymore — decisions should be made at the “last responsible moment,” right? If so, why are we basing decisions on static figures derived from upfront decisions? As Schwartz notes,
Part of the business value that software development can give us is the ability to respond to unknown future needs. We can build things in a way that gives us more options in the future or in a way that gives us validated learning about the environment we are in. In economic terms, we can say that software development efforts can give us “real options” — that is, options to invest more or to not invest in the future, depending on which way the market goes.
Most interestingly, Schwartz further points out that Scrum is at odds with Lean Startup, and that DevOps firmly sides with Lean Startup. Here, the team is not a unidirectional recipient of “business needs.” Instead, it experiments and feeds information back to the business, helping to derisk the business’s own understanding of value as discoveries are made. The business then is not IT’s “customer;” rather, both bring their unique perspectives to an iterative, collaborative relationship that seeks to let the right ideas emerge as work progresses. As Schwartz puts it, Agile introduced a dynamic view of requirements — now it’s time to introduce a dynamic view of value. Our understanding of value, just like our assumptions about “requirements,” should evolve over time based on new information.
This brings up another issue. In Scrum, the Product Owner is the OPYCLT — the Only Person You Can Listen To. The Agile team is not supposed to take orders from anyone else. That, Schwartz observes, sounds suspiciously like command and control, another concept DevOps does away with. This leaves Scrum in an odd predicament: In DevOps, managers no longer dictate work to product teams, so why do Product Owners? Well, some say, the Product Owner can tell the team what to do but not how to do it…but that’s precisely what good managers did anyway, Schwartz notes. Well, maybe the advantage is that someone must have final say when it comes to prioritization and features…. Yes, Schwartz says, and that was the manager. So again, what’s the difference?
Decision making should be decentralized down to the Agile teams themselves, something Scrum prevents. In Scrum, teams are tasked with building features they neither chose nor can oversee the adoption of. This is just wrong, Schwartz argues. Product work is a team sport and Agile teams should own value delivery. The team must be able to interact with the organization and help determine and harvest value. The Product Owner should not be a go-between. The Agile team must continually provoke and observe, sense and respond, and venture out beyond its retrospectives, which keep the team focused on its own internal processes.
The Product Owner, Schwartz argues, is a leadership position in a Complex Adaptive System (CAS). The Product Owner can help teams frame measures around their output to show the value they have added. But how, Schwartz asks, does leadership know the right indicators of business value to follow in order to achieve the right outcomes? It can’t, he says. Leaders, just like Agile teams, can only posit a hypothesis, observe results, and alter their course accordingly. And this brings us to Schwartz’s definition of business value: It’s a hypothesis held by leadership about what will achieve its goals. That’s it. It should be whatever combination of indicators leaders hypothesize will lead to the strongest outcomes. In the end, it’s all about experimentation. In the next post we’ll take a close look at Schwartz’s specific recommendations.
Hunter, R. & Westerman, G. (2009). The real business of IT: How CIOs create and communicate business value. Boston: Harvard Business Press.
Larman, C. & Vodde, B. (2009). Scaling Lean and Agile development: thinking and organizational tools for large-scale Scrum. Upper Saddle River, NJ: Addison-Wesley.
Schwaber, K. (2004). Agile project management with Scrum. Redmond, WA: Microsoft Press.
Schwartz, M. (2016). The Art of Business Value. Portland, OR: IT Revolution.
Sutherland, J. (2013). Know the Scrum basics: Get your velocity right. Scruminc. Retrieved on December 7, 2017 from: https://www.scruminc.com/know-scrum-basics-get-your-velocity-2/.