Saron: Welcome to Ruby Rogues episode number 277. Today on our Panel, we have Jessica Kerr.
Jessica: Good morning!
Saron: Sam Livingston-Gray
Sam: The pen is only mightier than the sword at distances greater than five feet.
Saron: That was longer than me actually saying your name. I’m your host, Saron Yitbarek. Today, we have a special guest, Andy Hunt. Andy, you want to introduce yourself?
Andy: My name’s Andy Hunt, I started off my work in life as a programmer, worked for big companies, small ones, became a consultant, author, publisher, was one of the 17 authors of The Agile Manifesto and have quite a bit to say on the subject.
Saron: That’s quite a resume. After 17 years, you’re not tired of talking about Agile yet?
Andy: Completely tired of talking about Agile. It was boring after the first two years but everyday we find that people literally still just don’t get it. They look at Agile–lots of little tiny waterfalls. This is literally a quote from a client who said, “I love the benefits you can get from test-driven design. We’d like those benefits but we don’t want to have to do any testing.” Okay, there you have it.
There’s a lot of resistance still in some pockets, there’s a lot of misunderstandings, there’s a lot of misinformation. Yeah, it’s been 15 years since the Manifesto in 2001 and we’re still bloody talking about it because folks still don’t have as good of a handle on it as I think they could. Frustration with that and frustration with these sort of the relatively poor adoption of mainstream Agile methods, I figured, “Well fine, I’ll just start my own. I’ll make my own method.” You know how the rest of that quote goes. I’ll make my own.
I started the GROWS Method which is online as is everything else at GROWSmethod.com and the idea is several fold, to get people back to basics, to start off by saying okay. One of the issues with Agile is you painted this picture of this utopian, here’s how it works, here’s how all the pieces fit together, it’s great, we’re all going to do this tomorrow start. Of course, it doesn’t work that way and you get a lot of project teams that fail from trying to do all of that all at once. One thing we’ve found is there’s not a lot of information or a good sense of where do you start What practice do you do first, how do you proceed from there, how do you grow from starting from nowhere and growing into becoming an Agile practitioner.
It’s vitally important if you’re in any modern software engineering enterprise that you can very reliably and consistently build your product and build it and test it and ship it and get it out the door and yet all these teams that claim to be Agile, claim to be doing scrum, claim to be doing XP, some combination, many of them still don’t have continuous integration, they don’t have continuous bills, they don’t have any kind of automated testing in place.
My theory is if you don’t have that very basic level of infrastructure and support then it doesn’t matter if you’re talking to customers, it doesn’t matter if you’ve got the best stories in the world, it doesn’t matter, nothing else matters if you can’t get the bloody thing out the door. One thing that we really try to focus on is to start at that very basic and still undone mechanical level, make sure that you’ve got automation, make sure you’ve got continuous bills, continuous testing that this is all set up and working smoothly and then you can move on and talk about what it is you’re going to build and so on.
Sam: You said something early on there about people who wanted to do Agile but didn’t want to do all the testing. That reminds me of some of the criticism I’ve seen about programming over the years which were that XP is this great set of interlocking practices that each of the practices supports one or three of the other ones. If you take one of those pieces out, it’s significantly weakening the feedback mechanisms that you’ve got. Is that something that you tried to address in GROWS? In XP you are allowed to adopt, people wanted to adopt XP would take bits of pieces but leave out important parts. Is that something you’ve tried to address with GROWS?
Andy: The basic idea behind GROWS is that people perceive along a path when they’re learning something, a growth path. We took inspiration from the Dreyfus model of skill acquisition that these folks made up back in the 70s where you go through five stages from novice to expert. The idea that we’re putting forth is when you first start off, you’re a novice because as a novice, you don’t have experience. That’s sort of the definition, you’re just starting with this.
At the novice level in GROWS, the focus is on safety and hygiene, make sure everything is in version control, make sure the builds are clean and automated, that sort of mechanical level. That’s the novice level. Frankly, a lot of folks stumble on that even if they’ve been doing this for a while but we start with that.
The second level, once you’ve sort of gotten those basics out of the way, is kind of checklist driven because again, as a beginner, you don’t have a lot of experience to guide you so we provide a checklist of do this, make sure that works, make sure you’re getting this feedback, make sure you’re getting that feedback.
From there, you can move on to sort of a more recipe based approach where there’s more judgment calls and up to a more smooth adoption where it’s become unconscious to you you’re doing it and you’re beginning to innovate and add new things to the practices which is also something we haven’t had sort of at all.
And then finally get to the expert layer where you’re able to replicate what you’ve learned and your teachings and help teach others to get there as well.
We’ve got this growth path in place starting off with make sure this works and make sure you get feedback. On the question of feedback, leaving out some practice or another, we’re not particularly bent that you do things a certain way as long as they get done. For instance, one of the ideas is you have to have two pairs of eyes on any bit of code. You can implement that idea in any number of ways, you can do the XP pair programming thing. If that doesn’t work for you for whatever reasons, then there’s various levels of code reviews you can do from the informal, “Hey, take a look at this,” to the sort of Spanish inquisition under the bare lightbulb. If that’s your thing, it’s not my place to call it one way or the other if it works for you.
The focus is always on getting feedback at every level. Whether it’s from the code, whether it’s from the users, whether it’s your own performance in a meeting, whatever it is. You want to basically run this continuous loop of do something, do some experiment, do something and get feedback from it, make small adjustments and continue and go around and around. That’s the engine that drives it making it okay for people to experiment with code, to experiment with the methodology itself because I think it’s the height of arrogance to say, “Here, do this thing, this will work for everyone. Trust me.”
Sam: What could possibly go wrong?
Andy: What could possibly go wrong? It does go wrong. People do need some permission to say, “Well, let’s try this to see if this works any better.” Now, there’s danger there of course. You’ve got one very big risk that what they want to try is just backsliding into more plan-based sort of waterfall-ish behaviors and we know that doesn’t work. There are people who are like, “Oh, waterfall’s fine.” Waterfall can work in a very small number of domains. If there’s literally no unknowns and it’s all laid out and nothing’s going to change. It’s a very static environment, not dynamic at all, there’s no unknowns, it’s all laid out, sure, knock your socks off.
Sam: The clip that I remember for that one is that waterfall essentially amounts to an agreement by all parties and not to learn anything for the entire duration of the project.
Andy: I haven’t heard that but yeah, I think that’s pretty fair. There are places where that can happen. It’s a big world out there. That’s one of the issues that comes up–I’m talking about any methodology is there’s just a huge unimaginable variety of software projects. Unfortunately, most of the literature sort of assumes it’s a brand new greenfield project in popular language of your choice. Whether it’s Java, Ruby on Rails, or Elixir and Phoneix, whatever the hot new thing is. Yeah, there’s some of that but there’s folks still out there writing in Cobalt, there’s folks doing copy and paste websites in PHP, there’s folks doing cutting edge make your uber car driver list kind of nifty stuff and everything in between.
Saron: My understanding of Agile and the Manifesto is that it wasn’t supposed to be so productized and commercialized. It was the way of thinking, it was the philosophy. Seeing how things have turned out, is it fair to say that that GROWS is what Agile should have been or you wished it was if you could have controlled the process productization of it?
Andy: To a degree. It’s not entirely fair to say that, “Well, this is what it should have been in the first place,” because the Manifesto was 15 years ago and Scrum and XP and Crystal and whatever else, none of that popped into existence the year before. They all had rich histories of 5, 10 years whatever before that. I think it’s probably better to say, “Yes, this is partially my view of what Agile should have been at the time tempered with and these are the things we’ve learned over the last 10, 15 years that we thought were good ideas but now we’ve seen more of how they can be misapplied and what the downsides are.”
Saron: Can you give an example of that?
Andy: I guess, probably. One thing, human memory is really crappy. It’s something we don’t like to talk about but you know–in my book on Pragmatic Thinking and Learning, I make the big point that you get this really awesome ideas all the time that if you pursued and followed up, you really develop something very cool. It’s like, “Oh, I got this great idea in the shower. I got this great idea while driving. I’ll remember that.” And you don’t. You walk through the doorway, your buffer clears and you say, “What was I thinking about?” and it’s gone.
Saron: That’s okay. You can’t follow up on all of them anyway. We don’t have time.
Sam: Yeah, I’d like some choice about which one stick because I probably didn’t need that third computer.
Andy: The question was for examples of things that we sort of know better now. Scrum’s daily standup is a very popular Agile practice. It’s possibly the most widely practiced, widely adopted Agile thing and it makes sort of sense. You put everyone together, all the team members in a room and get them to sort of sync up and be aware of what they’re doing. I’ve been in multiple, multiple companies where the first time they do that, it’s a real big surprise to find out that your neighbor’s working on the same thing that you’re working on or that there was a misunderstanding or whatever might be. It’s a very useful practice. Scrum has promoted this, it’s widely done. Wonderful, right? Well, no. There are some very major potential drawbacks with implementing that. Some of the things we’ve seen is I’ve had people say this with a straight face, we do our daily stand-ups on Friday.
Saron: That’s amazing. That’s impressive.
Sam: How do words work?
Andy: I’m not making this up. The only time that the team actually talks to each other is during the daily stand-up
Andy: You can have stakeholders come in and monopolize or dominate the conversation, you can have a manager or executive leadership come in and dominate the conversation or worse, begin to micro-manage and demand to know, “Okay, how are you going to fix that problem with the database and want to see your 12 point plan for what you’re going to implement it all during this meeting which now instead of being 10 or 15 minute quick synchronization for the team has become an hour and a half slog fest death march sort of event.” There’s some very, very potential risks to doing a daily stand-up.
For GROWS, we do a couple of things. First of all, some of the practices that are popular and well-known, we renamed solely to try to get away from some of the baggage. It’s the same thing but hopefully with less baggage associated with it. In this case, we explicitly call it the team sync. The idea is that this is a practice for the team, it’s not for the executive leadership, it’s not for the sponsors, it’s not for stakeholders, it is for the team as like a code synchronization point. An informal chance to make sure that everyone knows what everyone else is doing, what problems they’re facing, and what value there is in what they’re doing.
Now, as Scrum says, the manager’s job is to listen and take note of what’s in their way and help clear obstacles. That’s what it’s supposed to be. On the GROWS side, what we do is we list out for any practice, we list out what the pain points are, why should you be doing this in the first place, what the benefits are. There’s an adoption experiment that says, “Okay, if you want to do this, here’s what you try, and here’s the feedback you should expect from it.
But the most important part, I think for any practice, is enumerating the warning signs. For the stand-up meeting, people come in and say, “Okay, I’m still working on XYZ.” I don’t care, That’s not useful. Tell me what is working, tell me what you’re stuck on, “I’m still working on X,” is a huge warning sign. It’s not doing the practice correctly. People start sitting down, meetings are starting to get longer. Again, if you’re violating the spirit of the thing, if there’s more that needs to be discussed, then there always is, the idea is to schedule other get togethers as needed not to impact this synchronization event.
The best part I think from all the practices we’ve started to put up on the GROWS site is a section called How To Fail Spectacularly. When we first did this, I actually named it Spectacularly Stupid Ideas, which I thought was kind of tongue and cheek but kind of funny. Some of our early beta readers came and looked and this one guy is like, “Guys, I love what you’re doing. This is wonderful information, this is really helpful, this clarifies a lot of things for me. However, I want to show this to my management and I can’t show them your site because you’ve got this section called Spectacularly Stupid Ideas which basically outline our business plan.”
Andy: I renamed it, How To Fail Spectacularly.
Sam: That made them feel better, right?
Andy: It’s what takes the stupid word out of it and I’m hoping it’s more cautionary it’s how to fail so a reason a person will look at this he’ll be like, “Oh, so these things here that we’re doing, probably we ought not be doing this.”
Jessica: Failures trendy now. Failure’s cool. Everybody wants to fail.
Andy: We’ve got that ironed out. We’ve got that nailed.
Sam: I have a sticker on one of my devices, it says, “Move slow and make things.”
Andy: Honestly, that’s all there is to it but there’s so much that gets in our way of doing that. Some of it is fairly far out of our hands and out of our control. A lot of reasons that it looks like executives act weird or don’t do the right thing for software or try to screw us has nothing to do with them but they’re forced to do that because of accounting principles and accounting rules or legal requirements or these things that are so far removed from our day to day experience but that’s the world you have to deal with.
One of the things that struck me, it’s an interesting trade-off, all of engineering is trade-off. Everything is you can do this or that, you can’t have both. You do this at that expense, however it goes.
When XP first started getting popular, they made the very conscious decision I think that it should be a bottom-up kind of a movement. It should be adopted by developers, be grass roots, and work its way up into the organization. I think that was probably the correct decision at that time but as with all trade-offs, you got a situation now where you’ve got a lot of developer on board with it and not nearly as many executives or managers who are on board with it or understand it. We run into very frequent problems where the developers know the right thing to do and can’t, they’re not allowed.
One of the things that we’re trying to do to change that is to make it very explicit that the rest of the organization is part of the methodology. We have practices for executives, we have practices for users. We keep saying, well, we want user involvement, we want them to sit in and watch our demos and give us feedback dynamite. Have we told them how? Have we taught them? Have we laid out our expectations of what sort of criticism, what kind of critique that we want to accept for them sitting in and watching our product? No! We plop it in front of them and say, “What do you think?” They’re like, “It looks great.” Or, “Can you make it pink or mauve or whatever?”
We have this expectation that the rest of the organization will follow along with us but we haven’t really done anything serious to kind of get their involvement. One of the big things behind GROWS is that it is all inclusive. We’ve got practices for the users, we’ve got practices for the executives. The executive angle I think is particularly important because as an executive, and one of my many hats, I’m a publisher at Pragmatic bookshelf and I am running that company and I full well what it’s like to sit on the other side of the chair from a developer and have that end of the argument and not be in the developer’s chair. I’ve been in both and it’s fascinating to see how your vision changes from the other side of the table.
As an executive, I want to know what’s going on to a point, I sure as hell don’t want the details. I would like some vague comfort level of, “Are you going to make it on time? And if you’re not, when are you going to make it by?” That’s kind of all I care about. I’d like to know that as an executive.
We have practices in place that let executives get the level of information that’s appropriate to them, get the transparency through to the team without encouraging micromanagement or over-involvement or panic but to get them the information they want and the expectation that we’ll get from the executive leadership something like a coherent vision so we know what in the hell it is we’re building and more importantly why. What’s it supposed to do, what are we trying to accomplish here.
That’s where an awful lot of folks fall down trying to communicate the organization’s purpose. They get bogged down, “Well we’ve got a mission statement here, we’re a customer-focused blah blah.” It just start spewing Google AdWords at you and there’s no actual meaning there. That’s something we really try hard to avoid is this sort of meaningless mission statement and actually get them something useful, something we can work with.
There’s a great example on the site of bad mission statement where it says, “If you’ve got a content-free unactionable vision such as ‘We’re a customer-centric organization focused on actualizing best of breed cross platform enterprise FaceTime ideation.” Rocking, alright. Does that mean it should be real time or batch or should it be how many servers are we going to need? There’s nothing. You see a lot of these things with we want better quality or faster delivery, yeah I’d like to win the lottery so what? That’s not useful. We try to emphasize useful vision and goals from the executives and in return, they get the feedback they need and with everyone included in the process, hopefully everyone will be happier.
Sam: I have one thing to toss in the scenario as just a momentary amusement. The Ruby faker gem contains some code to generate some of those lovely mission statements. It’s fakercompany.bsmodel.
Sam: The documentation that has it returning something like empower one to one web readiness. This reminds me actually of some of the critiques that Sara May has had of the solid principles which are that they’re great at describing what code should look like that is easy to change but they don’t really say very much about how to get there. It sounds like that same angle of how to get there, something that you put a lot of thought into with GROWS. Is that accurate?
Andy: I think that’s fair. It’s interesting you put a lot of thought into is sort of relative. This started as off the cuff kind of thing it’s like what actually happened is I had this one person I was talking to who was really trying to do the right thing, really trying to be Agile, really trying to experiment with what they had and find their way through and wasn’t allowed to because it wasn’t Scrum, it wasn’t XP, it wasn’t a recognized method. It’s like, “Fine, now you’ve got to recognize method. Look, there’s a website, there’s going to be a book. It’s real, knock your socks off.”
The idea of how to get through it is you’ve got to try it first. A prototype is worth a thousand meetings, right? That’s how we do stuff. We play with code to learn how it works. We have to try it. We have to see it. We want to put our code in front of users to see if that’s what they were thinking. Our written and oral communications skills are pretty poor as such things go, you just really need to see it.
Architecturally, one of the big things that we push is the idea of traceable development which has been called thin skeleton, thin red line, these very southern names. We put these forth back in the Pragmatic Programmer book Dave Thomas and I wrote back at the turn of the century. The idea that your very first version of your code is ‘Hello World’. It’s a thin slice but it goes all the way through the application, web front end, through the database, through whatever middle-way you’ve got in the middle, all of that. You start with that very thin slice and add to it with the notion that you’re doing this because you want constant feedback. It’s all about feedback.
Back to the original question, I pitched out my very first earliest ideas of GROWS to start getting feedback on it. At a certain point after starting very early on, my friend Gerald Richardson joined me. He’s got a lot of clients in the area and he’s seen a lot of really interesting things that we’ve been able to capture on how people do things wrong so we started working on it together and again with this idea of we don’t know where this is headed. I didn’t wake up one morning and have this grand vision of this shall be the method to end all methods. The whole idea of the method is we don’t know but we can try and figure it out.
You put something out there, you get some feedback, you make a small adjustment, rinse and repeat. That’s what we preach with GROWS and that’s how we’re developing GROWS. We put stuff out there, we get feedback from people, we tweak it.
Saron: One of the things that I really liked when I was looking at the website and just learning more about this is that there are lots of tools. You mentioned the tracer bullet development, there’s practices by SAGE, there’s all these diagrams and stages and just very clearly laid out structures on how to do this sort of thing. It made me wonder, how much of this is research? You mentioned getting feedback from people and saying, “How well does this work in incorporating that?” But how empirical is this really and can something like this be very empirical?
Andy: It’s a good question. Much of what we have here is information or ideas or approaches that have been born out from experience. Somebody had an idea once and said, “Hey, this might work. Let’s try it.” Over the years, it’s either worked or it’s been modified or it’s been forgotten. We see things where all that would’ve worked but here’s a the tweak that makes it actually work better.
Much of this is born from our personal experience, experience from our friends in the community, people that we know, people that we follow and for the most part is what’s happening out in the world. But interestingly, one of the problems with the mainstream Agile methods is they’ve been fairly stagnant. If you look at Scrum or XP, they themselves are actually not very Agile. They haven’t changed, they haven’t adapted. Some tweaks here and there and some better discussions and descriptions but the fun little practice haven’t changed, they’re the same.
That strikes me as probably not a healthy thing. We’re supposed to inspect and adapt and they haven’t adapted. One of the things we put on each of the practices is its application and there’s three categories at present. Practice that we recommend can be critical, it could be helpful or it could be experimental. If it’s critical, that’s something like version control. You have to have it. I don’t care if you use Git, I don’t care if you use Subversion or Mercurial or anything that’s not Outlook. We know people who wants to use Microsoft Outlook at version control and they mailed the code to each other at the end of the day.
Andy: I can’t make these things up. Something at that level, it’s marked as critical, it’s like literally just do it, this is really not up for discussion. You have to do this.
Helpful is something like setting like setting team interruption protocols. Where do you strike the balance between having the team getting pinged and interrupted with bugs and crisis all the time versus walling them off where they don’t talk to anybody. There’s advantage and you have to have a team that’s responsive but you also have to have quiet time so you can think and get things done. How do you draw the balance?
Some teams will say, “Well, Tuesdays, we can’t be interrupted. We won’t respond to email, we won’t respond to phone calls, Tuesdays and Thursday, or everyday from one to four or whatever it might be.” That’s a helpful level practice. It’s not mandatory but it’s something that’s going to come up and it’s something you need to address. I don’t really care how you address it, you can have a floater or a bug catcher as Sam notices here. You can pick half days during the week or a whole day. I don’t care as long as everyone agrees to it. That’s why it’s described as a protocol. It’s like, “Alright, here’s the rules of engagement. This is what we’re going to do.” That’s the helpful level.
Then, the third category is the experimental level. That’s the, “Well, this is a nifty idea. Maybe we’ve done some research on it, maybe a few folks who tried it but it’s not really proven out in the world yet. It’s an interesting idea. Somebody should try it. We should see what happens.”
One of the goals behind this is to try to get folks to come up with new ways of doing things, to try to innovate, to try to get new and different practices into the Agile world. That’s one of the things back at the 10 year anniversary of the Manifesto, one of the popular interviewer questions was, “What do you see that’s different or that didn’t turn out the way you expected from when you all wrote Manifesto in the first place?” Back when the Manifesto was written, the common thought going around the table was really everyone and their dog was going to come out with their own Agile method. Here’s the principles sort of behind it, everyone’s going to come up with different practices, every consultant, every group’s going to come up with new practices that honor these principles but have their own sort of unique take on it.
That never really happened. It became Scrum and a little bit of XP. If you look at the some of the vendor polls and surveys that go out there, some astonishing percentage, 70% or 80% of the world, if you ask them what is Agile, they’ll say it’s Scrum and that’s really all they know sort of at the end of the question. We missed out on the opportunities to innovate and to add new practices to find out new and better ways of doing things which are out there. The technology that we work with on a day to day basis is vastly different from 15 years ago, 20 years ago, 25 years ago. We don’t really take advantage of that as much as we could or should. I think there’s plenty of room for innovation there and I’d like to see it. Hopefully, we’ll have mechanisms in place to begin to foster that.
Jessica: Andy, it sounds like you’re not prescribing practices we know that will work for everyone but you are enumerating things that you know don’t work.
Andy: That’s true, and we certainly know things that don’t work, we know ways that popular practices can go sideways and cause trouble for you. When we’re prescriptive, we try to prescribe what it is you need to accomplish and not be, “And you have to do it this way.” Two eyes on code I think is a good example. You got to have more than one person look at a piece of code before it gets into the pipeline whether you do that by code reviews, by pair programming, by whatever else, okay that’s your call and here’s the trade-offs for those but the choice is yours.
Jessica: So you’re giving people the what and the why but not micromanaging their how?
Andy: We try not to. We certainly give suggestions. It’s like, well, Scrum says do this or whatever and this is popular and these are the drawbacks and benefits of that but it’s more important that people realize that the whole point of the game is feedback. You mentioned earlier in this podcast some resistance to unit testing or resistance to automated testing and we try to combat that by pointing out that that is your code feedback. That’s the level of feedback that says that this code actually does something akin to what you thought it did which often could be a surprise. Obviously.
Sam: It’s also damage control in case of regressions, right?
Andy: Exactly, absolutely. We used to call it the safety net. It’s like you have to have that level of safety net for the feedback that it generates. The overall, the sort of baked in corporate idea that you only get feedback at the end is disastrous.
This is not even just our industry, look at the movies, motion picture industry I think is a really interesting sort of example. As a motion picture exec, I would love to say, “I want a guaranteed method to produce a great script.” The same way we say, “Well, I want a guaranteed method to produce great software.” It’s the same question and it’s not that easy.
You look at the recent Spade of DC superhero movies where they fell on their face largely according to reviews and according to box office and you have to wonder. There were stories about Suicide Squad that just came out this summer of 2016 where the tale says that they had to film almost in the can, finally decided to check with users, show it to test audiences and they didn’t like it. They wanted it to be more like the trailer that they’d seen and they didn’t like how the movie turned out. It was a frantic and expensive effort at the end to re-cut it, re-shoot scenes, try to get it to what the users said they wanted and the results apparently was kind of Frankenstein-esque vivisected nightmare where it just lacks cohesion at that point, it just had these bits and pieces spliced in and didn’t really satisfy anyone.
You’ve got people here gambling what $200 million, $300 million for a blockbuster movies these days and they’re running into the exact same problems you run into in software. It’s a creative, intellectual endeavor and there’s no way to know upfront that, “Yes, that’s the right script, that’s going to resonate with audiences, people will like it.” Versus, “Yes, these are the right projects, these are the right features, this is the right architecture, these are the right design decisions.” We don’t know.
Really, the only way forward is to check, to have feedback. To check with the users, check your unit tests, check, check, check, tweak a little, check again. It’s really the only way through for this sort of complex and chaotic domains.
Jessica: Sometimes I think that companies or people in companies don’t want those sort of, “How do we know this is working,” checks because then they would know that it isn’t and their actual check if this is working is, “Am I still getting my paycheck?”
Andy: That is absolutely true. In fact, there’s a popular thing about burnout versus burn down charts. We recommend a burndown chart because it shows you across the top what your scope is. When scope increases, the top line of the chart goes up.
Jessica: I thought that was at burn up chart?
Andy: Left and rights whatever. The one that goes that way, you want to show scope creep and show that line on the top rising as it goes. It makes it harder to hit, no kidding, but we’ve had people say, “Oh, we can’t do that because that will make the developers depressed seeing that we keep moving target.
Jessica: Like they don’t know.
Andy: It’s like, “What are you going to do when they do find out?
Jessica: For the listeners, a burndown chart shows how much work you have left to do and you hope that that goes down. A burn up chart shows how much work has been done and also the target, how much work we expect to get done before we’re finished. You can see both lines going up that we are getting stuff done and the goal is moving farther away from us all the time.
Andy: The irony is that is the sort of thing when you show that to executives and show it, “Okay, by adding these things, you’re going to now miss your date by this far.” It’s like, “Oh.” Suddenly, they have enlightenment.
Sam: Assuming that there’s a sort of executive that will take that feedback.
Andy: Which happens. I think one of the biggest problems with computer science, with software development, is that we seem to run into a lot of human limitations a lot faster than a lot of industries might. That’s probably reasonable considering that as we move out of the industrial age into the information age, we’re running into more basic cognitive limitations of the species.
One of the big ones that comes up is this need for closure. It is a hardwired cognitive bias that most people, many people would much rather have the wrong number in the box than to leave it open and not know the answer. “I need to know when this is going to ship.” “June 1st. I made that up, it’s not going to happen. That’s a complete BS number.” “Wonderful, but I needed a number. I have to have a number.” “But it’s wrong.” “That’s okay, I have to have it.” That’s a very real cognitive bias that a lot of people are suspect to. Unfortunately, that’s the biggest hindrance to an Agile approach is you got to get over that. You have to be comfortable with uncertainty.
Jessica: You have to know what you don’t know because the emptiness of that box is information.
Sam: You have to trust the people that you work with.
Andy: Absolutely. You have to be comfortable with the unsolved problem. It has to be, “Well, how are you going to do this? How are you going to fix this?” “We don’t know yet. We’re researching, we’re looking into it, we’re running experiments, we’re getting data. We’ll figure it out but we don’t know.” Unfortunately, in many environments, that’s really just not acceptable. There’s a lot of places where you simply are not allowed to say I don’t know. I think that’s one of the big hindrances to Agile adoption in general is that sort of culture of demanding sort of perfect knowledge upfront. I mean it’s a fantasy, it’s unrealistic but it’s a very popular fantasy.
Jessica: I’ve heard that in academia part of the culture is that at least in history that if you’re asked a question, you need to know the answer. That affects your reputation. You should know things. Whereas in at least where I work, being able to say, “Oh gosh, I don’t know. Let’s find out,” increases your status a lot more than, “It’s blah blah blah.”
Andy: Right. That’s exactly it and unfortunately there’s a very prevalent corporate culture that tends toward the first and not the second. It absolutely should be, “Let’s find out.” Or, “Here’s what we’re going to find out.” As opposed to, “Oh, it’s X.”
Unfortunately, not to get into politics, but you absolutely see this with politicians as well. It’s not politically popular to say, “Well, we don’t know. We need to study that. We need to get some data on that.” It’s much more popular to say, “Shoot them all. Lock them all up.” Whatever the issue might be to come up with something that sounds decisive even if it’s the wrong answer.
Saron: Why is it called GROWS, in all caps?
Sam: With a TM, let’s not forget the TM.
Saron: The TM, it’s been bothering me for a long time. Why is it called that?
Andy: Two questions in there. GROWS was initially going to be an acronym because I wanted the idea of growth as a simple metaphor because code GROWS, you grow code. You start with a thin tracer bullet approach, you grow code as you go along, you don’t build, it’s a much more organic process.
Similarly, you cannot ignore the fact that you’ve got to grow team skills as well. You’ve got to grow the team skill at working with each other, you’ve got to grow individuals technical acumen as they go along. These are very important things that regular methodology sort of leave out but assume, well of course this is something you would do in a reasonable company and that’s a dangerous assumption.
I want to emphasize the aspect of growth. We came up with a couple of different acronyms for it, Growing Real World Oriented Software kind of things but I didn’t actually really like any of those so we abandoned that and it’s just GROWS. It doesn’t stand for anything.
The trademark on the other hand was very deliberate seeing how other methods and other ideas have been used and abused, we want to try to avoid that same fate. Claiming GROWS as a trademark gives us some measure of protection from at least companies misusing the name and saying, “Oh, this is GROWS method and it turns out it’s just waterfall or some other non-Agile, non-viable approach.” It’s mostly just to try to prevent delusion or confusion and try to keep the name at least to represent what we want it to represent. You’re perfectly free. Everything on the website is free, you’re perfectly welcome to take these ideas, do something else with them and call it something else, that’s fine but if you’re going to call it this, then you need to play it by our rules, our philosophies.
Sam: What was that, just again?
Jessica: So we don’t get GROWS-terfall? I love the name waterfall because it just fits so well because at the end, you’ll get a big crash.
Andy: I love it. There was some conference a couple of years ago, I’ve got the t-shirt somewhere where it has the cartoon of the person in the kayak or the canoe halfway down the waterfall saying, “So far, so good.” Exactly that.
Just like the big blockbusters that don’t find out until they burned through $300 million. I’d like to know, especially as a business owner, I want to know in the first couple of days, in the first week, if this is viable or not. I want to keep knowing that we’re on target or we’re hitting the rails, we’re not going to make it. I would almost say that it’s professional incompetence or something legally damaging to do waterfall in this day and age.
Jessica: Well, we’re on the topic of the name. I like the name GROWS because it really sounds like it has scaling built right in.
Sam: Oh, no.
Andy: It does. It absolutely does. Scaling is built right in. You want to know the secret to scaling? The secret to scaling is to not scale up the mess. That is really what it comes down to. Again, this is where folks trip up, they’re like, “We’re enterprise.”
First of all, as soon as somebody uses the word enterprise you know you’re in kind of a lot of trouble. It’s probably not going to work. Whether it’s a methodology or technology, as soon as it gets all enterprisey, that’s kind of red flag. What happens is you’ve got a company that has tons of bugs maybe, terrible releases, terrible release history, they can’t quite finish what they’re doing, teams don’t like each other, they’re toxic, they don’t have solid technical practices, they don’t have any kind of steady rhythm or cadence, the vision is unclear, and now they want to scale. Great.
Now, you get that, you multiply it a thousand times. What were annoyances for just a few teams are now impediments. What were impediments are now problems. What were problems are now full-scale disasters because you scaled up gunk that didn’t work well.
Jessica: How do you know when you’re good enough to start scaling up?
Andy: Well, that’s a good question. I’m literally working on that material as we speak, this call interrupted the chapter I was writing. The idea is simple enough that you have to have it working in the small first. You have to have individual teams that ship on a reliable cadence, on time, you know their speed. There’s an interesting thing there too. We really try to push the idea that team velocity is a constant. Any given team is as fast as they are and that’s how fast they go. If you want to know when they’re going to be done, you plot how many features they’ve completed over a few buckets of time and you draw a line, linear interpolation, that’s how long it’s going to take. It’s like, “Well, we want to be faster.” Well, I’d like to win the lottery too but wishing doesn’t make itself.
Sam: It doesn’t go up into the right.
Andy: It is what it is. You know the relative speed of your many teams, you know that they either ship reliably or don’t, you know that they ship crap or don’t, and from there it’s really then just a matter of, “Okay, what’s the best way to synchronize communication among N teams? Do you do a hierarchal kind of reduction thing like Scrum of Scrums, do you do like a network model, do you do this, do you do that? That’s a separate question, that’s just a matter of how do you do coordinate visibility and transparency amongst these teams through to the executive layer with a large number of teams. That’s a simpler and less emotional problem to, “Nothing works and we can’t get stuff out to work.”
Sam: Speaking of scaling, as I was reading through the GROWS website, I was struck by some parallels with Jim Shore and Diana Larsen’s Agile Fluency Model which is another way of sort of putting stages onto things and say so at first, maybe you’re not going to deliver much very well and as you get, as you master that, then you can start working on this next thing. I was wondering if that had informed GROWS at all or vice versa or what.
Andy: I don’t think so. I mean, I know those folks, I am not intimate with their works. I don’t think I’ve actually read it. Diana’s one of our authors. I met Shore a few times. Nice folks. I’m sure what they’re doing is spot on but I’m not particularly familiar with it. I like the idea of starting simply and working your way up because I think that’s one of the big mistakes that gets made so often is, “Here’s this thing where we’re Agile tomorrow.” And bang, bang and crash I suppose is more accurate.
Sam: Big bang integration.
Andy: I’m not playing with it but it sounds like a right idea in the right direction. I would like to see more of that. In a perfect world, I don’t want to have to be writing this GROWS stuff or talking about it, or speaking about it, or giving workshops, all of which I do, I’d rather not be doing any of that. There’s far more interesting stuff out there but there’s such wide spread misunderstanding and misapplication, I really felt compelled. It’s like, “This is not a solved problem yet. Yes, we know the answers, within the community we know the answers, we know the right way to do things but that hasn’t really gotten out into the world as well as it needs to.” Sam just typed in, “Someone on the internet is wrong.” Absolutely.
Sam: Well, cool. Thank you. For our listeners, I did drop a couple of links about Agile Fluency into the show notes. If you’re curious about that–
Andy: Some interesting stuff.
Jessica: I’m a little skeptical. Andy said, “We have the answers, we know how to do this.”
Andy: We have some answers.
Jessica: We at least know some things not to do.
Andy: That’s a better way.
Jessica: That’s how it definitely hasn’t made it out into the community yet.
Sam: I’d really like to believe that. I’ve seen an hour of visual programming models that have tried to solve that same vision and it comes down to, the problem is programming.
Andy: Yeah, exactly. That’s why the only way I think that scenario works is if you get that sort of breakthrough in generalized AI where it is actually learning from you and knows the peculiarities of when you say, “I want this over there. I want this to work this way,” what that actually means.
Saron: What do you see as the future of GROWS? What do you hope it accomplishes? Where do you see it going?
Andy: My fondest hope for it, once we get sort of the first version kind of out there and it’s maybe three quarters complete currently, maybe 60%, somewhere in there. Once we kind of get the first full idea sketched out, we’re going to open it up for much more community involvement. I want to see people out there trying things. I want to see them trying new approaches. I want them writing them up and sending them in. We’ve got a couple of folks doing this already saying, “Hey, this is cool. We’ve done this thing and it worked really well.” I want to hear about that. I want to publicize that. I want other people to try it. I want to get their feedback. Ultimately, I want to move the industry forward because we’ve got far more interesting problems ahead of us, this ain’t one of them.
Saron: I like that. I like that a lot. With that, shall we move on to some picks?
Sam: Works for me.
Saron: I’m going to take that as a yes. Okay. Jessica you want to go first?
Jessica: I’m going to pick camping in the front yard because my eight year old did that last night in a tent and it was really cute.
Saron: Is that safe? Is that safe or are there bugs and stuff?
Jessica: There are indeed bugs. She killed at least one bloody mosquito.
Andy: How did you get the bed out on the front lawn?
Jessica: She dragged the sleeping bag out there all by herself with great enthusiasm.
Saron: Wow, wait did she sleep–I’m sorry I’m very interested in this. I don’t really know how children work so this is a fascinating topic. Did she do it by herself? Did she just slept outside on her own?
Jessica: Well, actually we have a house guest at that moment. So she slept out there with an adult.
Saron: Okay, wow. That’s a great pick. Thank you Jessica! Sam, you want to go next?
Sam: Sure. Speaking of children and how they work. A couple of weeks ago, we went on vacation and as part of the vacation, one day, we went in San Francisco to the California Academy of Sciences. Then the very next day, we went to the Exploratorium. I’m going to pick both of those, they are both excellent museums.
The Cali Academy of Sciences is more an illustration of like what you can do when you put a lot of money into a few exhibits. They’ve got some just absolutely stunning aquariums and this big, giant dome inside their building. It’s got a sort of warm rain forest thing with butterflies flying around in there, that’s really cool.
And then sort of at the other of the scale the Exploratorium is what happens when you take all of your money and you turn it into a bunch of little interactive experiments and then spread them all throughout a large building. It’s just like, you can’t walk five feet without going, “Ooh, what’s that? I got to play with that.” They are both absolutely wonderful. Personally, if it were me with one day, I’d go to the Exploratorium but they’re both worth checking out. Those are my picks.
Saron: Nice. I have a bunch of picks. This is my first show back so I’m very excited. Number one is this book called Shoe Dog which is a memoir by Phil Knight, the creator of Nike. I read a bunch of business-y books and profiles and that kind of thing. This book by Phil Knight is this awesome story of how he created Nike and what I loved about it is usually when I read business books, it’s all, “Ugh, everything is terrible and then now, I’m the greatest person ever,” which is fine if you’ve made a big empire, good for you.
This story is basically Phil kind of talking through all the hurdles and the struggles and the down points at each level and every time he tells the story, I think to myself, “If this happened to me, I would just quit. I would quit right now and there just wouldn’t be a Nike.” It’s just really motivational, inspirational, and just a good reminder as we struggle with our own software problems and product problems that Phil Knight has probably been through way worse than anything I’ve experienced. That’s one.
The second is this thing that someone gave me called Espresso Pillows which are just as magical as they sound. They’re from Trader Joe’s. They are these little Espresso bits that are covered in toffee and chocolate and they are so freaking good. They’re just absolutely delicious. I basically finished the can in two days which is probably not safe but they’re really good and I highly recommend them.
Next is a talk that I saw at Jingle Con which I thought was absolutely incredible. It’s called It’s Darkest Before The Dawn. It was a talk by Tim Allen. He’s a developer and basically going through his struggles with alcoholism. It was incredibly vulnerable and powerful and deeply personal but also just made everyone in the audience really think about our culture and how we approach alcohol and habits, a bit part of tech culture for better and for worse. It’s just really, really insightful, touching story so I highly recommend that you all watch that. It’s on YouTube now.
My very last pick is our own Ruby Book Club podcast that I’m doing with Nadia Odunayo who was actually a guest, I think, a few weeks back. We’re doing a podcast we’ve been doing four months now and we read an hour of Ruby book each week and then talk about it together. It’s an awesome way to just kind of focus on learning in small steps and we recently started 99 Bottles of OOP which is by Sandi Metz and Katrina Owen. If you’re interested in reading that book and getting through it and being consistent about it, we’d love for you to join us in our meeting journey.
Andy: Alright. My pick for the readers is you, the reader. Invest in yourself. I love that Mark Twain quote, something about, “Those who don’t read good books have no advantage over those who can’t.” Which I think is a very powerful idea. It’s so easy to kind of get caught up in work, in our development, in families, everything else, and not invest in reading any of the fine books you just mentioned, in reading tech books, in reading business books, psychology, history, whatever it might be. Yeah, you need all of that.
Read, read constantly. I say that in part as a publisher because I want you to read our books at pragprog.com but really just read anything, not the net, read actual books that people put care and time into.
In terms of URLs and places to pitch, for books to read, come to pragprog.com. For more information on the GROWS method, go to GROWSmethod.com. I’m on Twitter @PragmaticAndy. My personal website is toolshed.com has more information on me and other links, articles, other things to read. That’s all I’ve got for today, thank you all so much for having me.
Sam: Thanks, Andy. This was fun.
Saron: I was going to ask you where we can follow you and how we can learn about you but you did all that too. Thank you.
Jessica: Thanks, Andy.
Andy: No problem.
Saron: Sam, did you want to throw in an extra pick?
Sam: Not a pick but I did want to let the listeners know since you mentioned 99 Bottles of OOP, we have scheduled our next Book Club episode which we’re going to record on late October and it will come out in November. It’s going to be about 99 Bottles of OOP. I’m really looking forward to that. If anybody wants to buy the book and get ahead, you’ve got two chances. One is listening to Saron and Nadia and the other is procrastinating and listening to us.
Saron: Awesome. Well, thanks so much Andy for being on the show. That’s all we got.
Andy: Alright, thank you all for having me.