It’s no secret a lot of what people call “Agile” is anything but. It’s faux, like the fake stitching on fake leather. Orgs bring in some consultants, check some boxes, and hope to see the old top-down Waterfall sped up, all while ignoring that there is really nothing Agile about imposing Agile practices. As a result, Agile experts spend a lot of time talking about “Dark Agile,” their name for all the things posing as Agile that simply aren’t.
Take SAFe. It has very successfully monetized the notion of “Agile transformation” while simultaneously being considered “Dark” by Agile experts. As Marty Cagan recently put it, if you’re flirting with SAFe, then you don’t have Agile product teams, you have “delivery teams” (think “pizza delivery teams”), and you don’t have Product Owners, you have command-and-control “backlog admins” (Cagan, 2019). (Or consider Snowden’s quip that SAFe actually has more to do with Six Sigma than Agile!)
Dark Agile is very real and is 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 forever protect the movement from the damage being done in its name? (Can you imagine if people went around saying, “Well, that’s not UX, that’s DUX. You know, Dark User Experience.” Would anyone care? I somehow doubt it.) I was in an interesting thread recently that all started when “Ray Frankenstein” shared this:
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. But what, really, is Agile? And what makes so much of it Dark?
As discussed here, “Light” Agile is anything in line with the Manifesto; i.e., Agile is just the four values and 12 principles. “Dark” Agile is claimed Agile not actually in line with the Vs and Ps. That’s it. Agile is not a framework. It’s not a methodology. (As I once heard someone joke, if you’re in an interview and the interviewer keeps saying they “Do Agile,” you should just hang up. They don’t know what they’re talking about.) Anyway, something had to fill the “how-to” void left by the non-prescriptive AM.
That something was Scrum and, frankly, Scrum is a big part of the problem (er, sorry, I mean “Dark Scrum.”) Yes, we all know 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. There might be a few trucks out there, a few horse-drawn buggies, but let’s face it, it’s mostly just 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 on output, on speed of building. This has largely been the legacy of concepts like points and velocity. Ironically, story points aren’t technically part of Scrum (in fact they aren’t even mentioned in the Scrum Guide). 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 I refer to as “Scrum jumping the shark.”
Speed of learning, not building, is what matters. But but but, Scrum defenders rally (pun intended), building is a means of learning! Well, 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’re really shipping coded product to test all your hypotheses, then you’re building faster than you can learn — that’s waste. You’re wasting money and adding a lot of 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 also an important difference between testing your solution idea and testing its underlying assumptions (see Torres, 2017). 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.
Yes, Agile doesn’t say you shouldn’t be doing design research. It doesn’t explicitly say teams should only be building stuff. It doesn’t say focus on speed, speed, speed!…but Agile as so frequently misused does, because Agile transformation is typically 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.” If that’s how you’re treating value, then vagueness and waste is what you’re gonna get. So start with research — stakeholder research, user research. You’ve got to explore the problem space, your problem frames, as well as define “value” for your endeavor. Gilb says this 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 Torres’ (2016) concept of an “opportunity tree,” it’s by chunking up from output 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.
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 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.
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.
Cagan, M. (2019). Product vs. feature teams. Silicon Valley Product Group. Retrieved on September 9, 2019 from: https://svpg.com/product-vs-feature-teams/.
Disabato, N. (2018). Value-Based Design. Draft.
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.
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.
Torres, T. (2017). How to improve your experiment design (and build trust in your product experiments). Product Talk. Retrieved on September 9, 2019 from: https://www.producttalk.org/2017/08/experiment-design/?utm_source=Twitter&utm_medium=tweet-this&utm_campaign=Monthly+Post.
Torres, T. (2016). Why this opportunity solution tree is changing the way product teams work. Product Talk. Retrieved on September 9, 2019 from: https://www.producttalk.org/2016/08/opportunity-solution-tree/.