Ten Years Of Agile: An Interview with Brian Marick
About ten years ago, a test consultant named Brian Marick took a trip to snowbird, Utah, to attend a gathering of software leaders that would end up creating the Agile Manifesto.
Since then, Brian has stayed involved with the Agile Movement, working as a volunteer (and occasionally keynoting) at the Agile Conference, serving on the Board of Directors for the Agile Alliance, and helping to create the Gordon Pask Award for contributions to the practice of Agile Software Development.
We caught up with Brian to take a look back, and ask: What's next?
InformIT: You were a co-author of the Agile Manifesto in 2001. What drew you to the gathering?
Brian: Martin Fowler knew of me (I'm not 100% certain we had ever met); I was part of a reading group that had commented on his books and manuscripts. So he knew me as a tester, and he knew a little bit about the branch of testing—the context driven movement—that I was heavily involved with. Martin thought that there should at least be one tester there, and he told I believe Bob Martin, who was organizing it, that there should believe at least one tester there. James Bach and I were the people the he had recommended, and James couldn't come, and I did.
Why I came was that I knew these people by reputation for a number of years, though I had probably not met them, and it seemed it would be a worthwhile workshop to go to.
InformIT: Ten years ago, what were your predictions and expectations for the Agile movement?
Brian: I honestly didn't have any. I didn't expect the manifesto to become a very big deal; Ward Cunningham had the clever idea of putting it up on its own page and allowing people sign on in agreement with it. A flood of people did, and that was the first indication that there was a serious untapped undercurrent of desire for this thing.
I'm not good enough at marketing or prognosticating to have made any predictions about what might have happened.
InformIT: Since the manifesto was signed in 2001, we've seen the agile movement spawn a dozen conferences, several associations, hundreds of books, and even new movements like Software Craft. How does this differ from your wishes and predictions from ten years ago? In hindsight, do you see any downside to the direction Agile has taken, or do you see more possible benefit had it taken a different direction?
Brian: I've drifted away from Agile consulting because the clever creation of the Scrum certification, and the nature of Scrum itself as basically a “management practice” without the icky programming stuff that XP had, caused it to be wildly successful among people who don't necessarily take it seriously. So you get these half versions of Scrum ("We do Scrum but ..." etc.), and the way that's taken over the enterprise is disheartening to me because there's a lot more potential there that I actually believe will never be realized simply because of the nature of large enterprises.
On the other hand the practices—the icky practices of programming as well as the social practices like face-to-face communication and no code ownership and standups and such—have taken hold quite well in small shops, especially small shops in the Ruby world. That's led to a lot of people who are doing Agile—may not self-identify as Agile, may even push against Agile as something that's been tainted with the Scrum-Management-Enterprise label—but those people are really doing Agile, and they are people I can work with, so I'm happy that I now have this much larger community of small companies that I feel comfortable working with.
InformIT: What do you find to be new and exciting in the world of agile software? Where do you predict the world of software development is heading next?
Brian: New and different—Kanban is taking off. Kanban has seemingly a division, somewhat similar that in Agile, with the big enterprise software people primarily interested in drawing lines on boards and organizing fungible units of work (AKA "people"). That's not a blanket condemnation of those people; it's just that there's both the people oriented thing and the abstract maximize-flow thing, and some people tend to gravitate more to one or the other. There are, however, several practices of Kanban, like the idea of single piece flow and minimal marketable unit, that have trickled down into the Agile world.
Now that those “other people” are using the micro-practices of Kanban—ideas like "if there is a bottleneck don't do anything until the bottleneck is fixed,"—you'll see more commonly now among Kanban influenced places that, rather than having the cards mark across the board and pile up into a huge pile on the testing column, programmers simply stop working on things and help the testers. That's a new style of working that is not managed and planned as much as implemented by the team for themselves.
InformIT: What advice would you give to yourself at that Agile meeting ten years ago?
Brian: Except for turning down the pre-IPO job at Google (I'd tell myself to take it), I'd tell myself to get much more heavily involved with Test Driven Development earlier on. Back then, it seemed obvious to many of us that Acceptance Test Driven Design (ATDD) made sense, and that ATDD would be a good first step. I still believe it makes sense, but that your best bet is to start a low level with the programmers, getting them test-inflected, because then they will be willing to make the changes to the architecture that are required to make ATDD really work. So we spent maybe a few years flailing around that we might have been able skip.
Other than that, let's see. It was apparent, early on, that a lot of what happened with Product Owners was that random people get told, "Congratulations! You're a product owner," then got dumped into an Agile team without any instructions, and, "Oh by the way, you still have all you other other responsibilities." We kind of just let that happen because we were focusing on issues on the technical side. We tended to treat the product owner as this nice person who would protect us from all the craziness of the business world and feed us a steady stream of stories to implement. Concentrating on that person's problems and needs earlier on would have been a good thing.
InformIT: What are you working on now?
Brian: I've drifted out of Agile Consultancy per se; the market has pretty much dried up for weirdo software consultants who live in the middle of nowhere and work alone. These days I'm trying to be mostly a Clojure and Ruby Programmer.
When it comes to Agile, the two things that I'm sort of pushing on and hoping other people pick up on is first the notion that an Agile team operates according to the rules of gift economies, which are poorly understood in the software development world—often misunderstood. A better understanding of how gift economies work, especially when they run into contact with money economies, I think would be a good thing to have. I think there are parallels we can learn if we study the anthropological literature.
I used to think that if you want physical metaphors for Agile, that fencing was a good metaphor, but I've come to realize that Tango is a good metaphor for Agile, because Tango is a dance that is somewhat unique. At any point in the dance, the leader has multiple possible next moves to make, so the job of the follower is very much to put yourself in a stance where you are ready to respond quickly and gracefully to lot of different possible things. That's very close to the Agile notion of trying to not anticipate too much.
There's a couple of other things I'm working on that aren't directly related to Agile, but might be of some interest. One is I'm developing a style of Test Driven Design for functional languages that is inspired by Freeman and Pryce's Growing Object Oriented Software Guided by Tests. I've started a series of free, two-day workshops where, in exchange for expenses, I will come in and help people learn how to do this type of TDD in Clojure. You can find details on my blog. The other thing I'm doing is based on an idea by Enrique Comba. He'll go visit your place, he'll work with you for some period of time, and, at the end of that, you pay what you think he was worth. I want to do more of that.