A lot of what people call “Agile” is anything but. It’s faux, like fake stitching on fake leather. It’s skeuomorphic empowerment. Orgs bring in some consultants, check some boxes, and hope to see the old top-down Waterfall sped up. As a result, Agile experts spend a lot of time talking about “Dark Agile.”
Take SAFe, which has successfully monetized the notion of “Agile transformation” while simultaneously being considered “Dark” by Agile experts. Yes, Dark Agile is real and widespread; and yet, for those whose jobs have been made worse by it, it can feel dismissive when their frustrations are waved aside with a blasé, “Well, that’s not REAL Agile.”
Even if technically true, can pointing it out protect the movement from the damage being done in its name? I was in an interesting thread recently that all started when “Ray Frankenstein” tweeted about a party he was at. Now, I don’t know if Agile kills kittens, but this reminded me of Drift CEO David Cancel announcing at Mind the Product that he “hates Agile,” which resulted in 1.4k PMs breaking out in applause.
If you’re going to try and salvage Agile by calling dismissing the damage done as “Dark,” then what really is Agile? “Light Agile,” it seems, is anything in line with the Manifesto, the four values and 12 principles. “Dark Agile” is anything that doesn’t line up with the Vs and Ps. That’s it in a nutshell. Agile is not a concrete framework. It’s not a methodology.
Now something had to fill the “how-to” void left by the non-prescriptive and intentionally vague Manifesto. Like the ideas in the Manifesto itself, that something also predated it. It was Scrum, which is a big part of the problem (er, sorry, I mean “Dark Scrum.”) Yes, Agile != Scrum. But let’s be honest here, it’s not quite like equating cars with Ford Pintos. It’s more like equating four-wheeled vehicles with, well, cars.
In the wild, after all, most instantiations of Agile are in fact Scrum, and Scrum leaves a LOT to be desired. It tends to keep the focus strictly on output, on speed of building. This has largely been the legacy of concepts like points and velocity. Ironically, story points aren’t technically even part of Scrum (in fact they aren’t mentioned in the Scrum Guide at all).
They were likely invented by Jeffries, which he’s apologized for multiple times. Still, today’s focus on points is largely due to Scrum as commonly taught by consultants (whether “Dark” or not). Scrum cofounder Jeff Sutherland made this worse with his popular notion of “twice the work in half the time,” which should be remembered as, “Scrum jumping the shark.”
So…what’s wrong with output? Well, speed of LEARNING is what matters. But but but, Scrum defenders rally (pun intended), building is a means of learning! Yes, but it’s only one tool from what should be a bigger toolbox, and the tool you use should be determined by the types of questions asked. Really you should focus on maximizing value per MINIMAL output, and you can’t do that if speed of building is coin of the realm.
If you test all your assumptions with coded product, then you’re building faster than you can learn…and that’s waste. You’re wasting money and adding unnecessary complexity to the environment. (In other words, you’re over-betting on your ideas.) Thankfully, more and more product strategy thought leaders seem to get this.
There is an important difference between testing solution ideas and exploring your problem frame (Dorst, 2015). Scrum tends to encourage the former; and, given negative feedback, typically only “pivots” by way of changing what is added to what’s ALREADY BUILT. That’s a far cry from validating assumptions about the problem space and discovering the most value-adding ways to frame the situation.
In fact, it’s very late-game, low-level, and TACTICAL. It’s what Designers call “premature convergence.” It assumes most of the important questions have already been answered. Sure, Agile doesn’t explicitly say you shouldn’t be doing design research. It doesn’t explicitly say teams should ONLY be building stuff. But Agile as practiced so typically does, because Agile transformation is a bait-and-switch.
It’s not actually about increasing team agility, autonomy, nimbleness, decision authority, user collaboration, or self-organization at all. It’s about squeezing more blood from the proverbial stone—and it is Dark indeed. So, when you hear about “velocity” or, even worse, “billable points,” you should just think, “waste.” As Mark Schwartz (2016) has pointed out, whether by design or not, Agile largely passed the buck on the concept of “value.”
The expectation was that others can just tell you what will be of value, that you can simply ask and be told, “Uh yeah, that was value.” Unfortunately, that’s not good enough, as Tom Gilb has been pointing out for years. Not defining value creates a void that gets filled by speed of building. Treating speed as a proxy for value is a chimera. It causes Darkness. To paraphrase the bad ad campaign, “What happens in vagueness, stays in vagueness.”
Starting with research and exploring the problem space, your problem frames, as well as how you define “value,” Gilb says should cause a fundamental paradigm shift. As he puts it, the focus can no longer be, “We build code.” It should be, “We deliver value even if we don’t build any code” (Gilb, 2015; 2010). The focus should be how you operationalize value in the form of aligning stakeholders on prioritized measurable success criteria.
You can then explore alternative ways to achieve these goals, which may or may not involve coded product. Similar to Fisher and Ury’s (1981) concept of upleveling from positions to interests, it’s by “chunking up” from output to target value that you create the space needed for real agility, the ability to explore and switch between multiple possible options, avoiding the trap of one-plan-at-a-time solution thinking (Finkelstein, Whitehead, & Campbell, 2008).
This, by the way, is what some people mean when they talk about “requirements” (see, for instance, Hall, 2013). This is reflected in Gilb’s call to become “value-focused” (see also Disabato, 2018). As Gilb points out, this shift should change how you see the 12 Agile principles. Let’s take a quick look at each, channeling some Gilb.
The Agile Principles Seen Through a Value-Based Design Lens
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Your priority should be to discover and meet user needs, achieving measurable goals stakeholders agree as the operational definition of value. Ignoring this is how you end up in a situation where most of what’s built has zero ROI (see Kohavi et al., 2009). Acceptance criteria are often unhelpful as well, as they tend to more be Agile’s version of specs.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
This again depends on how you define “requirements.” If you mean a design, then yes. If you mean your success criteria, then that’s another story. These might change as you learn, but you actually don’t want constantly changing goals. As Gilb notes, if you’re still confusing requirements with designs or solutions, then your real requirements—what those design ideas are meant to achieve—are still hidden from you. You’re flying blind.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Sure, but learning your way to agreed goals as fast as possible—while also building as little as possible—will create more value and less waste.
4. Business people and developers must work together daily throughout the project.
No, not really, but product teams should be collaborating daily with real users, and without a go-between (sorry POs).
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
What job? What’s “done?” What is the “job to be done?” Focus on framing it and vetting assumptions with stakeholder and user research. Remember, what happens in vagueness stays in vagueness.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Is it? Rally data (discussed by Larry Maccherone) suggests F2F teams are actually not the most productive, so probably you should just do what works best in your context.
7. Working software is the primary measure of progress.
Progress toward what? Again, how would you know? Moving your value metrics in the right direction is the best measure of progress. Stop focusing on output altogether. It’s a red herring.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Good, but the aim is to meet needs and solve problems whether you build anything or NOT. The goal is not to build stuff indefinitely. The real currency is decisions made that change the environment, not shipped code. You can change all kinds of other things to achieve target outcomes.
9. Continuous attention to technical excellence and good design enhances agility.
Yes, and more importantly, focusing on interests and not positions (outcomes over output) increases your agility by enabling you to generate and explore more options while learning your way forward. Up-level to value and avoid one-plan-at-a-time solution thinking.
10. Simplicity—the art of maximizing the amount of work not done—is essential.
Easily the best of the Agile principles. 100% agree.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
Again, what is meant by “requirements?” Requirements shouldn’t have anything to do with the work you end up doing to achieve them. If instead you mean the agreed success criteria, that’s more negotiated with stakeholders than anything.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Sure, but if you can add value quicker than your interval, then lose the intervals. They’re just decreasing your speed of learning. (Continuous everything.)
As you start going down the path of becoming more value-driven, it fundamentally changes how you think about your work.
This approach emphasizes things like problem-space research, interviewing stakeholders, frame and scenario exploration, and negotiation skills. As in any negotiation, you need to know what your walkaway point is, your “Ulysses pact” or “non-negotiables.”
For me, I’m starting to see being value-driven itself as my non-negotiable.
I’ll talk more about this in upcoming posts. Until next time.
References
Disabato, N. (2018). Value-Based Design. Draft.
Dorst, K. (2015). Frame innovation: Create new thinking by design. MIT Press.
Finkelstein, S., Whitehead, J., & Campbell, A. (2008). Think again: Why good leaders make bad decisions and how to keep it from happening to you. Boston: Harvard Business School Publishing.
Fisher, R. & Ury, W. (1981). Getting to yes: Negotiating agreement without giving in. Boston: Houghton Mifflin Company.
Gilb, T. (2015). Agility is the TOOL, not the master: Practical Agile Systems Engineering tools. Presented at AgileEE: Kyiv, Ukraine.
Gilb, T. (2010). Value-driven development principles and values—agility is the tool, not the master. Agile Record, Issue 3, 18–25.
Hall, E. (2013). Just enough research. NY: A Book Apart.
Kohavi, R., Crook, T., Longbotham, R., Grasca, B., Henne, R., Ferres, J. L. & Melamed, T. (2009). Online experimentation at Microsoft. Retrieved on October 18, 2016 from: http://ai.stanford.edu/~ronnyk/ExPThinkWeek2009Public.pdf.
Schwartz, M. (2016). The Art of Business Value. Portland, OR: IT Revolution.
Charles Lambdin 
One thought on “Agile Light and Dark, and Becoming Value-Driven”