Co-developing Iterative AI Design Principles
With Elisabeth Hendrickson, one of the Agile Manifesto authors
“Agile Up to Here”
Elisabeth:
"What’s interesting is that one of the turning points happened to be a studio I had and decided to host at the time. It was a physical space, about a thousand square feet, wide open, flexible, think of an event space, but it could also be a shared team room. So I hosted an event called *Agile Up to Here*. We got Alan Cooper, Jeff Patton and some people who really understood Agile deeply. Here was our challenge: “Hey, this Agile stuff—a bunch of us in the room understand the software engineering side of it, but how do we fit design into this? How do we make this a genuinely cross-team effort with exploratory testing?”
John Bach came in and did some exploratory testing. We brought together an amazing group of people, and what happened in the room, from my point of view, was nothing short of magical. We built a little thing. We were working on Alan Cooper’s Homophones website. Jeff Patton ran story mapping, and I acted as a kind of Agile coach or Scrum master. We had developers pairing, John Bach doing paired exploratory testing, and we learned so much. Did everyone there understand Agile? Most of the people had some flavor of it, but we didn’t have widespread agreement on how to Agile.
And it turned out to be helpful. The only way to get oriented in an unfolding industry trend is to get curious people together and just start practicing it. I didn’t realize so many people were up to speed with some flavor of Agile. But with AI? That’s different. With AI, nobody’s really up to speed. People are still asking, ‘What’s AI?’ The best way to orient ourselves is to get together and start formulating principles that feel right. That pull request we just merged? Some of those principles started with discussions in conference rooms, on napkins. That feels like the only way to do it. It’s not like you can have an academic give you a full definition, and then everybody just follows it."
https://agilemanifesto.org/
You can get surprised by how short the Agile manifesto is!
“Was it ever longer?" you would ask. "Was there a process of ‘reduce phase,’ like in map-reduce?:)"
Elisabeth:
"This is hard to say. But those four simple lines? My understanding is that the summit brought together people who had been doing lightweight development. They were disenchanted with the heavyweight, command-and-control best practices that were harming the industry. They didn’t all agree on what they wanted, but they did agree on what they didn’t want. After much discussion, someone stood at a whiteboard and wrote out the principles. It wasn’t like a group of brilliant individuals perfectly aligned; it was more spontaneous. But the Agile manifesto came from that catalytic moment."
And that’s how AI feels right now. We’re just starting to get a sense of what should be true. Some people, like you two, see the future clearly. Others, like me, are looking at what’s happening and thinking, “There has to be a better way”. I can imagine some things that should be true, like iterative development of models, but I don’t know how to do them yet. When I talk to you, my brain explodes with ideas, and I think, “Yes, I want that”."
For the history books, the first version of the manifesto is right here in the corner. That’s our discussion and some sketches. So we know who went to the whiteboard.
However, the point is that the Agile community goal was to create a system you can control, share, update, trace, and collaboratively develop. The principles applied to different domains.
And, speaking of principles, let’s look, for example, at the Voltron’s composable codex. It’s amazing how it starts with *building composable data systems is hard, because it is hard*. It reminds me of AI—it's so young. But Voltron's hierarchy of needs—MICE, or Modular, Interoperable, Customizable, and Extensible—goes back to the pyramid of needs for AI that Monica Ragazzi created in 2017.
https://voltrondata.com/codex/a-new-frontier
The Agile Manifesto’s 12 principles distill down to delivering continuous value at a sustainable pace while adapting to changing needs. The same applies to AI models—they deliver value differently, but the goal is the same.
However, in AI, you can’t inspect or modify behavior directly like you do in traditional software. There’s no static analysis. AI is different. That’s why testing and validation need to evolve. We have to characterize model capabilities and limitations to understand whether we’re delivering value. Now, there’s too much emphasis on building systems and not enough on reasoning about them.
But at least we can start breaking these black boxes into smaller components. With transformers, we have layers. We can reason about each layer—what happens if we change one layer and not another? There are already tools to measure compute resources for different layers. It’s a step further, and we captured this in our principles.
And that ties back to composability. If the building blocks are composable, we can solve problems more efficiently. Composable, modular, customizable, interoperable… Stop, we have a source of inspiration here?
https://voltrondata.com/codex/accelerated-hardware#4-4-mice
Elisabeth:
"In the past, we had artisanal builds. Now, that’s a highly curated branch in Git.
The details change, but the principles stay the same.
So, what you need is the ability to build your artifact from scratch.
The trick is just being stubborn enough to learn the magic behind the technology. Anyone can do it—it’s not about being smart, it’s about persistence."
Stay persistent with us, contribute to our Iterative AI Design Principles on Github:
–-
AIFoundry.org Team