I drew a picture for someone the other day and I have mapped three decades - the nineties, 2000 and 2010, and I sort of feel like the nineties were the year of project, “We know it all” and “That doesn’t work”, 2000’s were the years of process, all the stuff blossomed, and I think it’s now interesting for us to think of the era of product. And the other thing I drew in the continuum and made me happy, is I felt that in the nineties we were overly certain and then the Agile movement challenged our certainty and made us learn faster, accelerated learning has been interesting to me, I wish we could switch the name of it to “The Uncertainty Movement”. I think that would get people thinking more about less product arrogance that they surely that they know what people need.
Scaling is really interesting because I think we are often making this mistake of conflating scaling and spreading so people will say to me “We have forty thousand people” and I thought forty thousand people don’t do much interesting other than a stadium wave, forty thousand people rarely build a thing and if you want to talk about scale I think it’s a large group of people trying to produce something. And then the delivery piece, it still matters, it’s still a big deal in a lot of companies, DevOps is really neat and bright and shiny but a lot of companies still haven’t really mastered continuous integration across teams so I sort of worry sometimes that the scale discussion is distracting us from some of the fundamentals. But I don’t want to be like the crabby old guy that’s like “It’s not like their first album man” but talking to a few people here and one of the things that is interesting is where are the engineering tracks, where are the people talking about what Fred Brooks once called accidental complexity.
I once wrote a book for the Pragmatic Programmers, which turned into a video series, because I think I am probably just better at waving my hands and ranting.
Yes, “Cutting an Agile Groove”. So I started thinking what do I want to say because those are starting to feel kind of old to me and I started writing something and the first version was called “How to build the wrong thing faster and learn from it”. And it’s gone through a few titles but the working title right now is this idea from progress to product, which doesn’t trivialize progress but I think that’s maybe the inflection point we are at right now, and I hope we don’t go from progress back to process. Process is sort of part of the picture, it’s not the whole thing. But there’s a lot of people that struggle when you say “Let’s think in product”, large organizations that have big systems that I think inherently deliver a service, and there is not a product like a big retailer with a .com, they don’t necessarily think that way but there’s more people struggling to come up with a platform product model, that’s neat to see.
Craig: And I guess the other thing that I heard you talk about before is this whole idea of that product development role, I guess what you call a product developer and how we move people to be thinking more in that type of space? Tell us about your thinking around that.
A big portion of it has been coming from working with some game development groups which is really neat. What game developers do is on Wednesdays is they all stop and play the game. And that doesn’t happen in banks enough, if you ask a product developer at a game company it’s “Yes, I’m building this Star Wars game” and you ask a dude at a bank and they say “I’m a Java guy” and one person is bonded to the game and the other person is bonded to the language, It’s about as interesting as me saying “Hi I’m Dave, an English speaker”. I wonder if in many ways some of the process stuff learning when it gets a little bit too in the forefront, we lose sight of the idea is to figure out what we don’t know sooner, that my idea of product arrogance is about the one from Nassim Taleb where he talked about epistemic arrogance being the difference between what you know and what you think you know, product arrogance is the difference I think between what people need and what you think they need, and I hope more ecosystems become about really skilled software engineers, who make the leap to product developers, sort of like being a guitar player is important but being in a great band is what most guitar players want to do unless they are a solo act but none of us are rarely are solo acts.
Craig: Yes I mean software doesn’t get developed by individuals, it needs teams and teams of people to do that.
Most often, there are still some solo acts out there, some of the analytics groups I work with, there’s one person coming up with a brilliant algorithm, they don’t really need to pair or be on a team or anything, that one person can make substantial change. The other thing I see is I love talking about collaboration but I don’t think we should mistake crowds for collaboration, a group of people that don’t have a common goal don’t spontaneously do anything really interesting.
Craig: That’s a mob right?
You’re right, and they do scary things.
It’s like a series of wacky things like Dude’s Law and stuff, I am trying to inject humour into ecosystems and I was chatting with a friend from Mumbai and I was kind of getting frustrated again with this more process instead of more product, and I asked him, I was thinking naan is such a funny term because it has so many meanings and I said: “Would you ever serve a meal that’s only naan bread?” And he says “No”, and I said “By in large, would you ever serve a meal that has no naan bread?” and he said “No” and I thought “That’s it! Naan is only part of the meal” so I created a process called NonBan and you can’t go to the website because it’s the leanest process ever, there is no website.
Craig: It’s an image.
It’s too Lean. But it’s kind of funny, some of those little memes have caught on in organizations and I think just like anything you can do to laugh at yourself, a build server that used to play a funny sound orshoot nerf rockets, that kind of stuff just keeps us grounded that we are wrong a lot and wrong is being ok, science is mostly about being wrong.
Craig: And Dude’s Law I guess is the other one that did the rounds, tell us about Dude’s Law. 435
Dude’s Law, I mean the weirdest part for me of Dude’s Law is that someone sent me a proof on this SAS internal website where a guy wrote a proof of Dude’s Law but it came because I discovered my oldest daughter’s friends were calling me “The Big Lebowsky” behind my back, sort of a dubious honor. At the same time I went to this physics conference with these Nobel speakers, it was the hundreth year of Einstein’s publications, hundreth anniversary, and I just thought “Scientists get together and they are so courageous”, all scientists know that gravity is a theory but it’s a well tested theory so I just ripped a page out of their book and took Ohm’s Law which shows that current is equal to the voltage of a resistance, when voltage goes down, resistance stays constant, and then current goes through the roof, but the average person calls it a short circuit. So I created my goofy law which is value equals why over how. Because I hear all these people saying: “How do you do story points?” and Jeff Patton and I became fast friends because everybody was asking us “How do you write a story? Show me a story” like Jeff and I had the secret story like the world’s funniest joke from Monty Python or something. And I think it’s just starting to intrude, sort of like when you get frustrated go to mechanics instead of thinking about of why you are doing that. I talked for a long time about programing and music and when people are learning they do need to focus on the mechanics, but for instance at this conference here I was suggesting that maybe people throw out the idea of Scrum teams and just start talking about teams. The Rolling Stones probably wouldn’t identify themselves primarily as a rock and roll band because that’s so obvious, they are the Stones, and it sort of feel like that’s what I was trying to get at, and there is some talk out now where some guy is talking about why over how, and I was like “He stole my thunder, he’s getting more press”.
A handful of years ago Jeff and I were both trying to do a visual organization of index cards and post its and Jeff coined this really nice term “Story Map” which for me lit up because a map kind of takes you on a take people somewhere, on a journey so we also both learnt we were writing something to try and help people in distributed ecosystems have a similar experience that they do when they are sitting together at a table, pushing cards around, because that’s so powerful. Just like you and I, there is so much power in the words like this and that, you and I start pointing at things. And so we joined forces a few years ago and started building this thing called Cardboard, its had a bunch of different names, but we try to keep it like it’s cards on a board and our joke for a while was if Google Docs and post-it notes had a kid it would look like Cardboard, so that is sort of all it is. But now we have software teams using it, and nurses and hospitals using it and teachers, there’s a whole grade school that was using it, it was really neat kind of that whole product discovery thing. We kept it really simple, all it does is put post it like card things on a grid and you can flip them over but you can invite someone. So if you and I are jamming away and we think “Oh, we should call Hans” and then we can bang invite him, because I think that’s what is missing in distributed ecosystems.
People walk up and they go “Oh, you have a board too” and they think that what we have is a Kanban board. But I was at a client about six months ago and they had a Kanban board and I thought “Why are we all using this representation which is kind of progress left to right and variation top to bottom?”, and story maps and Cardboard by enlarge what you see is people are representing interactions on this dimension and complexity on this dimension, so I took this group’s Kanban board and I said “You guys want to be able to see progress right? How about things that haven’t been started we just leave them alone, things that are in progress we put a yellow sticker on and things that are done we put a green sticker on” and then we just took their board and rearranged it from this left to right of progress to use. And then what happens all the time when do that is people see “Wow, we almost have something really neat done” or “We are really far from having anything that is usable, testable, validatable done”. And it’s been interesting watching people here just assume because it’s cards on a board then it’s a Kanban board. And so what we did is we riffed off a Google Maps so out here in DC when I am driving, I hate driving here, I’ll flip on maps and I will look at the distance, the time it takes but I would also look at the traffic because I’d rather spend ten more minutes driving on a sweet back road than stuck in traffic. And I sort of feel like that’s the horizon of card boards, to not replicate what’s in those tools, like teams, times and things, but instead answer the questions of “When have we hit NVP”, “What are the hidden complexities?” We were talking with a big company here about in large systems being able to see use against complexity, sort of like a heat map that would compare like a story map just systemic complexity like Sonar does - that got me going. Because that’s another thing when people talk about scale here I don’t think they are talking about complexity and systems, and that’s not going away, it’s just getting worse the more complex things get the faster we move.
Probably the best way is just go to Devjam.com, this is a funny short, people look at it in airports all the time, I think they all think it says death jam, and then they see the AC/DC lightning bolt and it’s like “Dude if I were Rick Rubin, I would get my own plane”, but Devjam I post most of my stuff there, @DavidHussman.
Craig: Excellent, well you are the rock star, the dude of our Agile community, thanks for talking to us today.
4 Thanks very much, thank you.
Community comments