Agile without the baggage
I enjoyed a recent post on Medium* on “agile for skeptics,” called “Agile without ‘agile.’” The author is James Plunkett, a Brit who works for Citizen Advice, an NGO that “provides free, confidential, and independent advice to help people overcome their problems.” (His tech writing seems to be a bit of a sideline; he notes on Medium that “posts here don't always relate to the day job,” but somehow he has over 8,000 Twitter followers.)
“One of the challenges of agile is the word ‘agile,’” the post began. “Even now, the word puts some people off. They get, understandably, skeptical about the jargon, dismissing otherwise helpful insights as yet another digital fad. Meanwhile, other people end up embracing nothing but the jargon, without the substance underneath. They start standing up for their meetings and think this will deliver better outcomes for their customers or user focus less on the word itself and more on two irreducible principles for how good products/services are designed.”
Plunkett’s advice: “[F]ocus less on the word itself and more on two irreducible principles for how good products/services are designed.”
Those two principles are:
- You should always build solutions quickly and simply at first — just get something workable finished.
“These rules capture many of the upsides of agile without the jargon,” Plunkett wrote. He argued that changes in the ecosystem surrounding software change the costs and benefits of software revision, and thus increase the advantages of agile. First, compared to before, revising software is much cheaper. With current data analytics, it is possible quickly to change small amounts of code and then test user reactions in real time by exposing samples of users to both unrevised and revised software, and see which version works better.
Second, real-world testing matters more than it used to. Early in industrialization, when the primary output was physical things, engineering ruled. “Who cared if your loom/steam engine/high-speed steel was a pleasure to use?” Plunkett noted. “The value of innovation lay mainly in whether it worked.” However, that has changed with time. Now knowledge about the user experience is as important as engineering knowledge. Today, he said, “you simply cannot get away with overlooking the design/user-testing side of things. The age in which you could occasionally get away with shoddy UX is dying, if it’s not dead already.” The reason is that “badly-designed digital services are literally worthless. They have no value whatsoever, in a way that isn’t quite true for a badly designed hammer or washing machine.”
I periodically hear the concern from govtech friends that agile in government risks becoming a ritual, where a few surface-level practices and phrases substitute for real behavioral changes. Skeptics worry that vendors’ embrace of agile often takes this character. Plunkett’s post reminds us that this danger is not unique to government, and that the best way to get back onto a productive path is to remember why we are embracing agile in the first place.
Above all, we need to translate agile rhetoric into agile action. That is a responsibility for both government folks and vendors, but government folks are in the best position to effectuate such a change because their signals and their behaviors will signal to the vendor community what is valued and frowned on.
* Medium is a site filled with lots of content, much but not all about tech. Many of my tech friends outside government, including civic tech people such as Jennifer Pahlka of Code for America and my Kennedy School colleague who teaches digital government, David Eaves, write for it regularly. I have occasionally in past blogs discussed Medium posts, but I’m not sure how common it is for government folks to follow it.
Posted by Steve Kelman on Jan 02, 2019 at 10:08 AM