author and publisher.
The End of Agile
Published in PragPub Magazine
A few years ago I was giving one of my
“The theater I did in college has helped me more in my programming career than half of my engineering courses.”—Grant Gainey, Senior Architect Developer
There are many reasons that a theater course would come in handy, not the least of which is learning how to work well with others under sometimes trying and unexpected circumstances. But there’s one aspect in particular that’s worth looking at in more detail.
In her autobiography, comedian Tina Fey (
Rule 1: Agree
Rule 2: Add
First, you have to agree with whatever is going on. If another character has already established that your characters are on the moon, or in a coal mine, or in the catacombs under Paris, you have to go along with that. It’s bad form to say, “No, wait, that’s no moon, it’s a space station!” So the first rule is to agree with what’s been set out.
Next, you have to add something of your own. You can’t advance the plot if you simply agree and stop there: “Yup, this sure is the moon all right.” That kills the dialog dead on the spot.
So you add your own little bit of advancement, which we’ll refer to in shorthand as “yes, and...” In this example, where your characters are on the moon, perhaps you’d add a line such as, “yes, and I think I saw something move over there near the rim of that crater.” Now the other actors have something to go with; they’ll add their own bits, and the act moves forward.
And that’s the important part: moving forward.
To me, this short idea of “yes, and...” is something we’ve lost track of in agile projects. As I mentioned in the previous column, what we call “agile” is supposed to be ever-changing and constantly adapting. This is one way to keep things moving: follow the rules of improv theater.
Rule one, agree. Don’t reject current agile practices, but don’t accept them as written in stone either. What constitutes your current set of agile practices isn’t “done”: it’s not finished, it’s not established as canon, and it never will be.
Rule two, add your piece. It’s up to you and the rest of your team to evolve your agile practice, to keep it alive and keep it moving.
That was always the intention with what we call “agile.” It was never intended to be a static, fixed set of anything. Remember the very first words of the the Agile Manifesto, that we wrote ten years ago:
“We are uncovering better ways of developing software...”—agilemanifesto.org
We’re still uncovering, still discovering. And you should be, too. What works well for me won’t necessarily work well for you; what works well for you now won’t necessarily work well for you next time.
“Yes,” we’ve got some great stuff, as an industry, we’re adopting better practices than were in common use previously.
“And...” the world is changing.
Windows and the desktop PC is dying. Microsoft’s share of internet-connected devices went from 95% to under 50% in the last three years (Roger McNamee, Elevation Partners). HTML5 isn’t the HTML you grew up with. Social interaction is no longer a pedestrian app to find lost classmates, it’s a required feature. There are new capabilities, new interaction paradigms, different development styles that demand even faster time to market.
As of 2011, the codification of the principles that comprise “agile” is now ten years old. Do you think it should survive unchanged another ten? Is this the end of agile?
Maybe it is the end of agile as you knew it, and that’s a good thing. Because with an agile approach, there is no end. There’s only “yes, and...”
Something to think about.
(If you are at the Agile 2011 Conference in Salt Lake City next week, find me and let me know what your thoughts are on agile and where your practice is headed.)
What’s a guru meditation? It’s an in-house joke from the early days of the Amiga computer and refers to an error message from the Amiga OS, baffling to ordinary users and meaningful only to the technically adept.
The Pragmatic Programmer, 20th Anniversary Edition
May 7, 2019
New Album, "far flung thoughts"
February 28, 2019
The Four Keys To Rapid Response Software Development
January 14, 2019
- List All News...
Bailing Out Your Company
September 12, 2018
Fixing the Stress of Designing, Forecasting, or Planning
July 9, 2017
Stop Practicing and Start Growing
July 11, 2016
- List All Articles...