An Interview with Karen Greaves, Co-Author of Collaboration Games and other Growing Agile Books

Karen Greaves is the co-author of a number of Leanpub books, including the popular Collaboration Games. In this interview, Leanpub co-founder Len Epp talks with Karen about her career, moving from Cape Town to Seattle and back, the startup scene in South Africa, her books, and at the end as usual they talk a little bit about her experience self-publishing as an author on Leanpub.

This interview was recorded on February 9, 2017.

The full audio for the interview is here. You can subscribe to this podcast in iTunes or add the following podcast URL directly: http://leanpub.com/podcast.xml.

This interview has been edited for conciseness and clarity.

Len: Hi, I’m Len Epp from Leanpub, and in this Leanpub podcast, I’ll be interviewing Karen Greaves. Karen is a coach and agile software development trainer based in Cape Town, South Africa. Along with her colleague Samantha Laing at their company Growing Agile, she provides training, support, and coaching to both companies and individuals, with the goal of helping them to be agile. They provide their services in person and around the world in structured calls and through online courses. You can learn more about what they do at growingagile.co.za.

Along with Sam, Karen is the co-author of a number of Leanpub books, including six Growing Agile books in the Coach’s Guide series. Karen and Sam’s books are focused on what I described that they do with their business: helping people be agile, and helping people learn new skills.

You can follow Karen on Twitter @karen_greaves, and learn more about growing agile by following the Twitter account @growingagile, and you can also get in touch by emailing info@growingagile.co.za with questions.

In this interview, we’re going to talk about Karen’s professional interests, her books, and at the end, we’ll talk a little bit about her experience using Leanpub.

So, thank you Karen for being on the Leanpub Podcast.

Karen: Cool. It’s an honor to be here.

Len: I always like to start these interviews by asking people for their origin story, so I was wondering if you could talk a little bit on how you first became interested in programming and how you made your way into the role you’re in now?

Karen: I never know how far back to go to with this, but since you said since I first became interested in programming, I guess I’ll go back to university days.

I went to university and I studied physics and astrophysics, because I wanted to become an astrophysicist — you know, as you do. I think at somewhere around my second year of university, when I realized that I probably would have to get a job when I was done — and there really weren’t a lot of young women doing that, all the astrophysicists I’d met had been very, very old white men — so I thought that perhaps I might need another career, and I’d done computer science as a first year filler course, because I was like, “Oh what’s this computer science thing? Let me pick that up.” And it was like, “Well that was kind of fun, and not that difficult, so let me do that, because I hear you can get a job in that.”

So I finished my degree, and ended up doing an honors degree in computer science. During that time, we had a bunch of recruiters from Microsoft come out to Cape Town, South Africa, and they interviewed literally our entire honors class, and three of us actually got job offers.

It’s the first time Microsoft had come to South Africa. It was in, we’re talking ’97. So a big IT boom, and they were looking for more people than they could hire in the States, so they were hiring them from all sorts of exotic locations like South Africa. So, I got my first job offer to go work as a software tester for Microsoft in Seattle. I was like, “Well I can’t really turn that down.” So off I went to do that.

And I guess with it being my first job, I didn’t really know what anything else was like. So I was like, “Okay, so this is how you build software, and this is how you release a product.” Because you build it every day, and we have daily builds and stuff like that. And there’s 3,000 people building a piece of software. I worked on the Windows team.

And so I learned a bunch of things there, that I just thought were the way people do software, and eventually got kind of sick of the rain in Seattle. I love the sun, living in in South Africa. So after two and a half years, I was like, “Yeah, I can’t live here anymore,” and moved back to South Africa, and went into software more as a programmer. But I suddenly realized, “Wow, I really learned a lot of stuff about how to build software at scale at Microsoft, without really even realizing it.” And this is way pre-agile days, or any of that stuff.

So I did some work as a developer for a while, and then I was always kind of looking for a different opportunity. I worked in an organization — well I went for an interview as a developer at a London-based company, and they were starting an office in Cape Town.

The company was called Workshare. In their London office, they did extreme programming, and they wanted to start up the Cape Town office with hiring everyone, with the understanding that we do extreme programming. This is like early 2000, 2001.

So I was like, “I think I heard about that once. I have no idea what it is. But sure, I’ll come do that. Sounds like fun.” And when I went for the interview, apparently I was dressed really neatly. So I don’t think I was that neat, but the other guys who went for the interview, one of them, he was a surfer, he had like food stains on his shirt, so -

But the manager phoned me back, and he’s like, “Well, I know you interviewed for a developer position, but we’re looking for someone to fill this role that’s called the Onsite Customer In Extreme Programming. It’s kind of like a product owner role.” I didn’t know that then, but that’s kind of what it is. “I was told to look for someone really organized. And given that you dressed really smart for the interview, I get the impression you’re organized. So how about you do that job?” And I was like, “Uh, okay. I’ll give that a try.”

That’s when I left development, and got into agile. My first job in agile was really being a product owner for a product that we built from the first line of code using TDD and all the XP practices. It was fantastic and beautiful and awesome. And because we kind of didn’t know what we had, I think it slowly slipped away over the years.

When I’d been there two and a half years, we had things like failing tests that we didn’t bother to fix, because it was more important to get features out. And all these things that now, I’m like, “Wow, we had it so good. How did we let that happen?”

So I left there a little bit disillusioned, and went into project management. Traditional waterfall, Gantt charts, all of that stuff. I did that for many years. I was — I am kind of a control freak. So I did all of the “I will come in and rescue your project. And if I’m the project manager, I will fix stuff and it’ll be awesome.”

During that time I worked insane hours. I think I worked at least 60 hours a week for about five years. Completely burned myself out. I ended up getting booked off, like a shrink saying to me, “You need to go home and sleep and do nothing else for a month.” And I was like, “That can’t possibly happen. The world will end.”

Fortunately, I had a really good colleague at the time, who said to me, “Just go. I will take care of everything. Just go. Don’t worry about anything.” That was really, really helpful. And then after that, I was like, “There must be a better way. This is just crazy. Maybe the better way is that I should just stop working in the software industry, because it’s broken. And it fundamentally doesn’t work.”

Through that journey, and leaving that company, and going through a couple of things, I ended up at a company where they got a new R&D director, and was like project manager in the project office or something. And she’s like, “I want to do Scrum.” I went, “Okay, what’s the Scrum thing?”

I went home and I read Henrik Kniberg’s book, Scrum and XP from the Trenches, and I read it over the weekend, and I came back to work on the Monday. I said, “I know the Scrum stuff. It’s like that XP stuff I did two and a half years ago. Sure I can roll this out to our team of 100 developers. That’ll be awesome, because they’ll all understand very easily how fantastic it is, because I had a fantastic experience with it.”

That’s when I learnt a lot about change management and coaching, and that you don’t roll out agile in a week to 100 people, by giving them a two hour PowerPoint presentation and expecting them to understand it. Funny enough, recently I’ve gone back to that company, and they really like me now. But I thought they would never want me to walk through the door. I made some really horrendous mistakes there. Upset a lot of people. Turned a lot of people against agile, because of the way I did it. But I learned a lot.

And then from there, I wanted to do more and more of this. I think I realized that I’d perhaps burned every bridge I had in that company. So I moved on to another place, where I was working as the dev manager, but with like four teams doing Scrum, and doing agile. They’d been doing it a while, so it was all about them improving. I really had a lot of fun there.

And then, actually at the company where I burnt all the bridges is where I met Sam. I hired her as a Scrum Master, and six months after I hired her, I left. But it was really good, because we met at that company, and we stayed friends. We hit it off immediately. I do like to remind everyone that I was her boss first, so I’m the one in charge.

Len: Noted.

Karen: Noted. She will disagree with that. We stayed friends, and after the next job, we were just talking. We’d both gone to the agile conference. And at the conference we were talking about what we wanted to do. The company I was working for had just been bought by a large American corporate, and I was like, “I’m not working for another large American corporate. I’m going to go on my own, and figure out what I want to do. But I want to help people with this agile stuff. That’s all I know.”

And Sam was like, “Yeah, maybe we could do something together?” And on that trip to [the agile conference] is when we decided, “You know what? We’re going to try this thing. We’re going to start our own business.” We’ve never done anything like that before. At the end of last year, that would’ve been five years ago.

So we kind of started Growing Agile from there. We went out on our own. We knew zero about running a business. We knew that we loved agile and wanted to help people. It’s been a fun ride since then.

Len: Thanks for that, that’s a great story.

I have some professional questions for you. But before we do that, I’d like to ask what it was like to move from the west coast of South Africa to the north-west of the United States — just what was that like, moving from Cape Town to Seattle? I know how it ended.

Karen: It was interesting, and a lot of things happened for me at that time. It was my very first job. I’d just finished university. I’d been dating someone for three years, and we were like, “Should we do the long distance relationship? Should we get married? What shall we do?”

The only way Microsoft would pay for your visa and for him to come with us, was if we got married. And actually we were both anti-marriage. But we were like, “Okay, well let’s get married.” So I was in a new country. I was in my very first job, and I was brand new, just married. So let’s go with — it was a very strange time. I am still married, to the same person.

Len: Oh wow, fantastic.

Karen: I like to say Bill Gates made us get married. I think it was a really difficult time, and a time that I didn’t know what was expected. So you’re in a place where everything is just different. You kind of go with what you see happening. A lot of my friends ended up being other immigrants. And there were three people from our class, we all went together. And we stayed friends.

So we found it really interesting that Americans are super, super friendly. But yet, having really deep — it was really difficult to make deep friends. It was very easy to be friendly to anyone, but the people that we counted on were actually people who were immigrants themselves.

Lots of people on my team were from like Eastern Europe and India and South Africa. So it was kind of weird, because we kind of had this little community within there. And I think Seattle at the time had massive influx of foreigners, just because of the jobs.

So the other thing is, you think of something like Seattle as this big city, and then actually there’s more people in Cape Town as a city than there is in Washington State as a whole state. And that surprised me, because you think of these cities as these massive cities. And actually we’re like, “Wow, it’s quite small compared to being back home.” So yeah, kind of a culture shift.

Len: That’s really interesting. Did you — I have to ask, I live just a couple of hours’ boat ride north of Seattle now — did you become a Seahawks fan?

Karen: No, I don’t understand it at all. But to be fair, I’m a South African who doesn’t watch rugby. So sport and me, no idea.

Len: I just remember visiting there one time with some friends to see a Seahawks game. I’m not a big NFL fan. It was the first game I’d ever seen. But the whole city just poured out of their houses, it seemed — and walked and drove, and took public transportation to the game.

So you were there in the late 90’s, right?

Karen: Yeah, I was there ’98 to 2000. Very late 90’s. Just the time to start to see the boom, the Microsoft stock price go through the toilet, just before I left. That was about it.

Len: I was going to ask, so were you there for the crash?

Karen: I was. It’s really interesting, because when they offered us jobs, we all took what sounded like an impressive salary in South African terms. But actually in terms of companies, the salaries weren’t that great, because you got these stock options. And everyone was like, “Well your stock options are going to be worth millions, so don’t really worry about it.”

And the first set of my stock options that vested, I made quite a bit of money on them. And then the second set — because I think you have to be there like 18 months before the set vests, and then the second set vested just before we left. And I literally made like $1 a share. Because my strike price, and what I sold them for was so, so — yeah. So in the time I was there, the last year I was there, it crashed.

Len: And what’s the scene like in South Africa for software engineering and startups? Is there a lot of activity?

Karen: There is a huge amount of activity. In fact, there’s an initiative — they kind of call it Silicon Cape, here. So it’s like Silicon Valley, but we have Silicon Cape. There’s a big hub for startups, entrepreneurs. We have a huge benefit, because we’re in the same time zone as Europe, but a hell of a lot cheaper. And our English tends to be better than, say, India. So we’re better understood by Europeans. We have a lot of cultural things that are similar as well. Because there’s a lot of European heritage, like Dutch and stuff here.

So a lot of European companies outsource their work to South Africa. I think we’re known fairly well — particularly if I think of friends who work in London. We’re known as fairly hard workers, South Africans. So people do think that they can come here and get a product built and get good work.

But we see a lot of companies — I mean, we’re approaching a company now, where the owner or the funders of the business are based in San Francisco, but all the build happens here, because dev skills are just so much cheaper. So I mean, a huge opportunity. We don’t have enough skills for the amount of work we have for software dev.

Len: That’s really interesting. You reminded me of a story I have from my first job in London. I moved there with a friend and his girlfriend. And the girlfriend had an interview for a job, and when she had her interview, the very, very British boss asked her, “And do you know anyone else from Saskatoon, Saskatchewan who’s recently moved to London?” And she said, “Yes.” And so I got an interview.

This guy had this concept of people from Saskatoon, Saskatchewan being hard workers. And so they were — in this random office in London, there were like half a dozen people from the place I came from.

Karen: From the one place?

Len: Yeah.

Karen: The same thing happened at Microsoft. So the year I went there, they’d brought a whole team from all sorts of different departments. And it’s the three of us that went back, went into different departments all within Windows, but different places. And I went into the printing and imaging team.

And the next year, they were going to do another run to South Africa for their recruiting thing at the end of kind of the university year. And the printing and imaging team are like, “We’re going. We’ll take a whole bunch of them.” And so the next year, there must have been about four or five South Africans who joined our team. Because they were like, “Yeah, we want more of those, please.”

Len: And when you moved back, did you miss the expat community that you’d been a part of in Seattle? Being around people from other countries, who are in other countries?

Karen: Actually the two other friends of mine that moved there at the same time, they were from South Africa. They actually left within a couple of months of us. So we kind of all moved there together, and then left. Yeah, I have to say — no, I don’t really miss it.

Len: Fair enough.

Karen: It felt so much like an us and them environment. Like, “I’m a foreigner in this place, and so I’m making myself feel comfortable with these other foreigners. But I don’t really feel part of the place.” And I think in Cape Town in South Africa, I feel part of the place. And so no, I don’t actually miss it.

Len: One of the themes of this podcast is me asking people who either did or did not take computer science in university back in the day, and whether or not they would recommend [what they did] to someone thinking about becoming a developer now?

Karen: Oh no.

Len: So what would you recommend that someone do?

Karen: I don’t think I learned anything at university that I use today. A couple of years ago, I saw a paper that was written by one of my professors from university, about agile game development. And I was like, “Oh my gosh, this is terrible. You really have no idea what agile’s about.”

So I don’t know — if you didn’t know how to code, I might do a short coding course. But I would just start working, I think. I thought that maybe I wanted to do a master’s degree or a PhD one day, and once I started working, I was like, “That is really not interesting to me.” Because the problems that I care about are how people work in the workplace, and the challenges that they have and the struggles. And I want to help them solve that. I don’t really want to do theory for theory’s sake.

There is another university in Cape Town. It’s called The University of Stellenbosch. And they have a Computer Science department where they partner very closely with businesses. It’s very, I guess, startup-y business-focused: how do you use computer science to help you launch a business in the software industry? That’s the impression I get. I didn’t go there, so I can’t tell.

And so I think if you did want to do it — to me, something like that is better. But I find some universities are so caught up in the academic, and they’re literally 20 years behind. I think in computer science, you can’t be 20 years behind. It’s archaic, literally if you’re that far behind.

Len: That’s a very clear answer. Thanks for that.

Karen: Sam may have had something to do with that.

Len: People are not always quite so direct.

I was wondering, one thing you mentioned in the introduction to one of your books, is that both you and Sam have done your share of overtime on death march projects. I was wondering if you wouldn’t mind telling the story about maybe, let’s say the worst death march project that you ever worked on?

Karen: Well I’ll tell you edited highlights, because it went on for a very long time — about two years, I think. And I remember at one point — actually it was the first time I thought about writing a book, but this is way before I discovered Leanpub.

It was a Saturday night, or, I think it was a Friday night, and I was sleeping in the spare room, so I didn’t have to wake my husband up, because I had to wake up every hour to check that the script that was loading data on the production servers hadn’t fallen over. Because if it did, I’d need to restart it, so that by the end of the weekend, the data would’ve loaded.

I was the project manager. I’m not really sure why I was checking the script. I mean, I didn’t know anything about loading data and scripts. But I knew enough to make that happen. And at some point — I think it was about three o’clock in the morning, I woke up and I was like, “I should write a book called The Project from Hell, and I should just write it about my life for the last year. And it’ll be riveting.” And maybe one day I’ll do that. But it’ll probably be quite sad.

It was a project that literally — we didn’t have enough capacity in the company to write the proposal, because it would’ve taken too much effort from people who were overworked on other things to write the proposal. So we got an external person who knew nothing about our clients and our environment or the skills we had or anything to write the proposal.

And then when we won it, we decided to deliver it against the proposal that they’d put in, which — as soon as I took a look at the proposal — when they were like, “Okay, now you’re going to manage this project,” I was like, “There is no way this is going to happen.” It’s day one of the project, and we’re about two years behind, because they’ve got one day for going into production — and in my experience, that takes a minimum of three months.

The project actually took us a year to get into production. I remember writing the contract, and there was a date that was a deliverable milestone date that was in December. And because of the swap over of the years, I actually got the date wrong in the contract — and the client signed the wrong date. So the date in the contract was a year later than it was supposed to be — and we still didn’t deliver on time.

Len: Oh my.

Karen: But it was actually a big breakthrough for me, because it was in that project — we were working all hours, trying to get these things doing, trying to come up with miracles. And I had this really difficult client. They were — they were Danish actually. I’ve since met really nice Danish people, but I thought Danish people were evil at this time in my life.

And he was like, “Well it’s just not acceptable that the date’s going to slip, you have to ship on the date.” And I was like, “I’m not sure how many more ways to tell you that — I know that this is terrible for you, but it is not going to happen.” And every week he would yell at me for about six months.

And then the day came when the deadline happened. And I sat in the meeting, and I was like, “So as I’ve been saying for the last six months, we haven’t delivered yet — and this is where we are.” And suddenly it felt like all this power that he had over me — the threat that he was holding of like, “Something bad’s going to happen if you don’t ship,” just disappeared, because it was like, “Well, and here we are, and nothing’s changed really. You can yell at me some more.” And he did. But actually, not facing the reality was not helping him either. So yeah, that’s kind of the worst project ever.

Len: That’s really interesting. It reminds me of something I often reflect on. Which is — people often think that just demanding the impossible is the same thing as being a hard ass. And it’s not. It’s being an imaginary fantasy person. There’s nothing hard ass whatsoever about refusing to face reality, and about conflating negativity with realism.

Karen: My favorite is — I watch these TV shows, and they’ll have like someone — I just started watching the new season of 24. 24 was a great one back in the day. Jack Bauer’s running around saving the world, gun shot — whatever, and then the President phones and goes, “You have to get him.” And I’m like, “Yes, because it’s not like he was trying before you said that.” Now he’s going to try 110%, because of your statement. Thanks Mr. President, that was really helpful. It kind of feels like that, when those people are just like, “No, you really — “ Yes, we were all sitting here with our feet on the desk, until you said something.”

Len: On that note I wanted to ask: one of the things that people who aren’t in software development, one of their main contacts with it, other than their daily use of things that are related to programming, which happens in all kinds of visible and invisible ways, is with catastrophic project failures that they hear about. Particularly big software development programs. And the ones that people often hear about are, for a number of reasons, software projects run by government departments. That’s probably because everybody feels they have a stake in it, not only because the funding comes from their taxes, but also because they’re building a public service that was supposed to be enjoyed by everyone.

Of course, probably many people have heard about the scandal around the botched rollout of the Obamacare website in the United States that happened.

But in Canada, we’ve had a string of these in the past 20 years. I mean it’s kind of wrong to call it a string. But like, quite a few huge project failures. Where you hear on the street is like, “They spent 300 million dollars trying to build a database, and then just hit delete and started over.”

And I was wondering, with your expertise, if you could explain maybe to the lay person, what would you say about why those catastrophic — How is it possible that something like that can happen?

Karen: So I think it comes from the nature of people believing that you can plan something that massive in advance. And I think there’s probably a certain part of government stuff that — because we’ve got all these stakeholders, and we have to make everyone happy — it’s really difficult to get agreement on what we should do, how much it’s going to cost, how much budget we have.

And because that’s so painful, we should do it — as little as possible. And to do that as little as possible means we should have the biggest project possible. So let’s just try and put all into one project that’s going to cost three billion dollars and take three years. But at least we’ll only have to go through this painful process of figuring out — asking for a budget and asking for money and getting sign off on what people want — we’ll only have to do that once, so it’ll be great.

It’s really interesting, because everything that you think now about what you want in three years’ time is false. Even the people who are involved in the project now, aren’t going to be involved in three years’ time. And so if you think about it logically, it’s never a good idea to plan anything three years in advance in detail, and expect it to go according to plan. But because of the nature of the stuff being hard and time-consuming, people try to do less of that.

I’m trying to think of other places where this happens. I guess it’s a little bit also — because we call it “software engineering,” it must be related to the building of buildings. And I think the buildings do do that, but we plan it in advance. Although having done renovations and watched many shows, they are never on budget. So they have the same problems.

But yeah, I think the nature of the problem software is trying to solve, versus the problems buildings are trying to solve — the nature is that our requirements change in the software world so much more that a long project is inherently a bad idea. I don’t know? Am I answering your question?

Len: Yes, that’s a very great answer. That idea that — just because of the nature of all the interests involved, putting all sorts of things into one project, for kind of bureaucratic reasons — I haven’t heard that answer to that question before. That’s really interesting.

Karen: I think it’s worse, and I think that’s why it’s worse in the government things. Because the bureaucracy is higher, which drives a need to avoid it. And the way to avoid it is actually making your project more risky.

Len: It’s really interesting. One of the other answers I’ve heard to that question as well — and I was wondering if you would agree with this — is having people in charge of software projects who don’t know anything about software, is a problem in a way for that type of activity that it isn’t for other types of activity.

So for example, you could have someone who’s very good at just managing stuff generally, who might be able to manage non-software projects in a way that they just can’t for software. Because there’s something unique to that activity, where you require domain expertise, and can’t just apply abstract management principles successfully.

Karen: Yeah so I haven’t really thought about it, but I think it’s true. But I think it’s true in many spaces. I mean — so I love home improvement shows and building shows and things like that. I don’t know if you’ve ever seen the show, Grand Designs? I think it’s a British show. They go around, it’s people who are building ridiculous houses. And they have a plan.

And the number of times someone’s like, “Oh well, I’m just going to project manage it myself to save money. And I know nothing, because I’m usually a dentist. But I’m going to project manage building my own house.” And it’s a complete and utter mess up. I mean, I watch it for amusement’s sake, because my husband and I have this little gamble of, ‘Okay, it’s going to be double the budget and three times later than they think.” We have a little betting pool as to how late it’s going to be, and how over budget, over schedule it’s going to be. And it always is.

But it amazes me, that I think there’s this perception — perhaps because it’s so hard to see what project managers or people running that stuff do, that people think they can do it themselves. And maybe that’s happening here as well — people in government are like, “Well it’s just managing a project, I can do that. Who cares if it’s software?”

And so, I think if you’re not deep into the discipline yourself, you don’t actually see all of the things that the person who really knows what they’re doing is seeing. We see the same thing in agile, with Scrum masters. People are like, “Oh I don’t see what that Scrum master does. But the team that they’re with just really, really works. But I can’t see what they’re doing. And aren’t I doing the same things? Why does my team suck?” So I think it happens in anything, where you’re not deeply involved in the discipline. I don’t think you can do as well as someone who is.

Len: Switching over to the subject of agile, I was wondering if you wouldn’t mind explaining what that is, say to someone who doesn’t know what it is — and what your take on it is now, and maybe how it’s changed in the last two years? If it has.

Karen: Yes. It’s interesting that you ask that, because certainly my take on what it is has changed. And I think it’s changed in the industry. But I think it changes for groups of people. And so what I thought agile was 10 years ago — there’s probably still people who think it’s that. So I think it’s more of — it doesn’t change as a whole, it just changes as people’s understanding of it changes. Maybe the global understanding is a merge of all of that.

I used to think it was really a specific way of doing things. It was basically Scrum, and I used to be — Sam jokingly calls me, I used to be the Scrum Nazi. I was like, “You will do it this way, the only way. And otherwise you’re not doing Scrum and you’re a bad person.” And now I’m kind of like, “Agile’s really just — it’s not just the way I think.”

It’s just a way of not hassling too much about getting everything perfect, but figuring out what you’re trying to do and why, and doing a small piece of it to check for all of your assumptions; not to check that they were right, because they were all wrong. To figure out how you got all your assumptions wrong, so that you can improve on them, and do another version.

I mean that’s literally it. Stop trying to do the big plan everything upfront and think you can cater for everything. Because you can cater for nothing. So just start on a really small part of it, so that you can learn some stuff and then iterate. So I guess that’s what agile means to me.

Len: And for those who aren’t aware about what Scrum is, or a Scrum Master, if you could maybe explain a little bit about that.

Karen: Sure, so I’ll do the classic teach, we do this all the time. We even have a little umbrella diagram, that you could find in one of our books.

To me, agile is a philosophy. It’s based on a single document called the Manifesto, and it’s a philosophy which is — we want to iterate, inspect and adapt — and get better at what we do. There are other things about collaboration and delivering value for customers, but at its heart it’s this empirical process of — do some stuff, check how we did, change what we’re doing to improve. So that’s a philosophy.

Underneath the philosophy are a couple of frameworks. And a lot of people call them methodologies, but this is the Scrum Nazi in me — they are not methodologies, they’re frameworks, because they’re very lightweight. There are some things to help you be more agile, so they’re a little bit more prescriptive. Scrum is the most popular of those. And when I say it’s a little bit prescriptive — it has three roles, five meetings — and somewhere between one and five artifacts, depending on how they’ve upgraded the Scrum guide recently. Because they change it a lot.

[brief loss of audio] … guidelines — I guess it’s kind of like to give you training wheels to do agile before you really know what it means. And it’s a really good place for people to start when they’re doing it. Because it helps people understand the mechanics of doing stuff [brief loss of audio]….

And there’s lots of other frameworks. I Googled once, there were about 17 of them — including one called Puma, which I think sounds awesome. But Scrum and Kanban — I’m South African, that’s my accent. Kanban, if I want to be more specific — are the two most common frameworks.

And Scrum Master is really just a role, one of those three roles in Scrum. But it’s the most interesting role to me, because I think it’s a role that doesn’t exist in other frameworks. And that’s a role who’s job is — we always say it’s like the coach of a sports team. They’re not the person running on the field, kicking the goals. They’re not in charge of anyone necessarily. They’re just helping people get better at their game.

And so to me, the Scrum Master role is a dedicated role, to have someone in your organization who’s just there to help you do your jobs better, but not by doing any of the work for you. And so, I think that’s where people get confused. Because they think it’s a project manager who’s managing everything, and it’s not that role at all.

Len: And as a coach, can you give me an example of something that you might do — if you’re hired say to come into a company to coach a team. What’s an example of how that would play out?

Karen: Going on my coach journey, I’m learning that more and more what I do is less and less. But really, I think the role of a coach is to ask questions that help people really think for themselves about why they’re doing what they’re doing — and perhaps the answers they already know within themselves for how they can do it better. To kind of hold their hand as an accountability partner, so that they actually start doing those things that they know they should be doing to get better. But they haven’t actually made it into a concrete plan, “I’m going to do next week.”

So usually our engagements are — we ask a lot of questions like, “Well why is that important, and why do you do that? And what’s difficult about that? And what could you do instead?” And they come up with all the answers themselves. And then we go, “Okay, so let’s just recap. Next week you are going to do X, and you think it’s going to have this impact. So we’ll revisit then, and see if it did.” And that’s kind of my job. I ask questions and tell people back what they’ve just said.

Len: In one of your books, you talk about training from the back of the room. I was wondering if you could talk a little bit about what that is, because it sounds quite interesting.

Karen: Yeah. So it’s actually based on a book, and there’s training courses and stuff, by a woman called Sharon Bowman. I was lucky enough to attend one of her courses, probably back in like 2011, and I instantly loved it.

So what it is, is instead of the usual — most people who go on training, they expect they’re going to sit at a table and look at PowerPoint slides all day, and fall asleep and check their phone and stuff like that.

And so, what Sharon has done, is a lot of research into how the brain works, and particularly how adults learn. And with changes of things like technology and television and adverts — we have really, really short attention spans. So one of the big things about training from the back of the room, is that you should never really teach anything for more than like 10 minutes at a time, because people have just stopped listening.

So instead, you want to teach in really small chunks, and then you want to do exercises that help people digest what they’ve just learned. There’s a couple of techniques.

She talks about the 4C plans, which is — you’ll see lots of those in our books, but essentially, breaking every topic into four parts — one where you connect people to what they know about the topic, one where you teach them some new things, one where they immediately get to practice what they’ve just learned. And then the last part, which is, thinking about how they might apply what they’ve just learned to work.

So you kind of do that for every single topic. And you make sure you mix up different learning styles. Some of it might be reading, some of it might be listening. Some of it might be talking. But you engage — everyone learns in a different way. You use different styles. And the reason for it is — A, you have more fun. B, you’re more engaged. And C, the chances are you’re going to learn — or you’re going to retain more of what you learned during the course. So that’s the quick summary of what it is.

Len: That reminds me, I think this might be related, but one of your more popular books is called, Collaboration Games and it’s really fun. It took me a moment when I started reading it, to figure out exactly what was going on, but it’s the description of a bunch of games to play. And my favorite one was collaborative origami.

As I understand it, a person is given a piece of paper, and another person is given a set of instructions. And one person just reads out the instructions and the other person, simply by listening to the verbal instructions, is supposed to construct the piece of origami. One of the reasons I like it, is because I think people really underestimate how many mistakes they’re making in their use of language, and it’s just kind of a permanent existential condition of human life that we’re constantly saying the wrong thing, communicating the wrong thing. And we don’t like facing the fact that our basic engagement with each other and the world is flawed.

I was wondering just what your favorite game is, and if you could explain what that might be?

Karen: I think I can. I think my favorite one, just because of the impact it has on people, is actually also in that book. It’s called “Broken Skype.” It’s really funny, because we’re on Skype right now. But you know the old game that you used play as a kid — Broken Telephone, where you whisper in someone’s ear, and then they pass it on, and it comes up all jumbled. It’s kind of a take on that. But instead of whispering, you do hand signals. And so we get people to stand in a row. And one person at the back, we show them a set of hand signals. And they pass it down the line. And then we get the person at the front to show the whole room what they got. And it’s usually hysterically funny, because it’s got nothing to do with the original sign. Usually it’s in some way a little bit disgusting. Because somehow that just comes in.

And so we do that first in the line, and then we do it again with a more complicated sign, and it gets worse. And people just lose it, and half of it is people shrugging, because they’re like, “I don’t remember the sign.” And that starts to become part of the sign. And then we do it again in a circle. And in the circle — although you can only do the sign and pass it on on your turn, you watch every single person. And so you can see where it falls down, and you can kind of correct on your turn.

And it’s amazing. Pretty much every time we play it in the circle, it eventually corrects and people actually get it right. Even people who have no idea what the sign was, will recognize it when someone does it right. They’re like, “Oh yes, that was it.” And we debrief it by saying, “This is the difference between handing off documents, and we’ll try and implement them and hand it to the next person. Or having the entire team involved in the discussion about what you need. Because each person’s going to remember a part of it. And together you’re much more likely to create something closer to the whole.

And when we teach that to people who are new to agile, and the benefit of having the whole team in sprint planning — they’re suddenly like, “Oh wow, that’s so obvious.” So I think that’s my favorite one, just because it’s such a big insight for people. And we almost don’t even have to be [brief loss of audio].

So, I really like games as a way to teach people the kind of experience they should be having when they’re doing agile. Because once they’ve experienced it in a game, if they experience it at work, they can be like, “Oh, we’re onto something here.”

Len: That’s a really great answer. I’m just struck by — I remember playing the game, “Telephone,” and I didn’t realize that I’d always assumed there was something about the auditory nature of it that made the communication fail. I’m surprised to hear that something that’s visual and tactile breaks down just as easily.

Karen: But it’s exactly what you said, right? It’s not just our inability to communicate with voice. I mean, have you ever had — I’m a really bad emailer, so I fight with people over email, because I misunderstand their tone. And I get really upset with people who are good friends of mine. And then I’ll be like, “Oh, it was just because the email — I didn’t understand the tone.” But anything that we do, we communicate really badly. And only with multiple people, can we hope to improve that communication.

Len: I really like that idea of people around the circle correcting things later on when they see things go bad.

Just moving on to the last part of the interview, I wanted to ask you why you and Sam decided to start publishing books on Leanpub?

Karen: So interestingly, the book Collaboration Games that you mentioned was our very first book. We decided somewhere in our first or second year of business — I’m not sure — that the problem with coaching is it’s very much tied to your time. And we wanted to explore creating some kind of products that could generate revenue that wasn’t linked to time — just as a different way of doing it.

And we’re like, “Okay, well what kind of products could we build?” And the first things that came to mind were books, because they seemed accessible and easy to do. And then we were like — well but the whole idea of the process that some people seem to go through to write a book, where they write them for years, and they have to look for a publisher. We’re like, “Well that’s really hard, that’s really not us…” We’re kind of instant gratification people.

And so we looked around for what we can do. And I think we both bought some books on Leanpub from other people, but through our research we stumbled across Leanpub, and we actually never tried any other platform — we kind of looked at a couple, and we went, “Well Leanpub looks easy enough, let’s try that for the first book. And then we can both evaluate writing a book. We can evaluate if we’re able to market and sell it. And we can evaluate if Leanpub works for us as a platform.”

And we made the first book free, because we were like, “Well we’re just kind of testing some stuff.” And it was hugely successful. Leanpub was really, really easy to use. So we loved that part of it. And the fact that there’s actually quite a big agile audience on Leanpub meant that people were discovering the book, without us actually advertising it ourselves. And so that was probably — we consider that a really successful experiment, which is when we decided to write the next book. And it’s just been going from there.

I mean, I think I looked the other day, we have about 14 [books] or something. They’re so easy to write. So yeah, I think it was because we picked it to evaluate. And then we couldn’t ask for anything better in a platform. So we’re like, “Well why fix something if it’s ain’t broken?” And now we love it. And we love the idea that we can — because when we work on a book, usually once a month, we set aside four days a month — because we only work four days a week — and we literally say, “Right, we’re writing a book this week.” And it’ll be done by the Friday.

And it might not be perfect, there might be some spelling errors. We might not have the final cover from our designer. But we can still publish it on Friday. And then as we get the little things, and someone’s like, “Oh you forgot this, there’s an error here,” and the designer’s like, “Here’s the final cover.” The great thing about Leanpub is we can just update it, and people get the latest version. So that’s really helpful to us, with the way we work, which is, “Let’s get something finished and out there as quickly as possible.”

Len: And have you ever published a book in progress, like not sort of finished, but 50% done, and hit the publish button?

Karen: We did actually. Our first after Collaboration Games, our first big book, The Coach’s Guide to Training Scrum, what it was is, we were doing a lot of training at the time. Which was the two-day CSM — the Certified Scrum Master training. And we’d made a decision to stop doing that training. But we had all this great training material that we knew was really good.

And so we’re like, “Well let’s put it into a book.” But it was going to take a long time to put the whole two days into a book. So we said, “Well what if we put [brief loss of audio]” … We often teach it as a one-day class. Not for the CSM, but just internally. “What if we do the one-day training as the first version, and then when we’ve got [brief loss of audio] … one when it was 50% done, when we had all of the day one materials in it. And people loved it, and we got really good feedback. So we’re like, “Okay, well now we’ll take the time.” And we did the second release which had all of the day two stuff.

And it was really great, because people who’d bought the first version were like, “Oh my gosh, I had no idea that the update would be so much more material.” They thought it would be like a minor update, but they got like a whole day’s worth of training. So yeah that’s the first time we used it, and it worked really well for us.

Len: Fantastic. Thanks for the kind words by the way, we appreciate that.

Karen: We love you guys.

Len: Thanks. Well we love you too. You’re some of our favorite Leanpub authors.

My last question is, as always on these interviews, if there was something we could build for you that doesn’t exist, can you think of anything that that might be?

Karen: Oh I’ve lost you for a bit.

Len: Oh sorry, yeah. I was asking — speaking of Broken Skype. I was -

Karen: Yes, exactly — Broken Skype, here we are.

Len: I was asking if there was one feature we could build for you that we haven’t built yet — can you think of anything?

Karen: I can actually. You shouldn’t have asked me that. So and some of your [brief loss of audio] … with 14 books. When we decide to do a special for, like, our birthday recently — five years of Growing agile — to create a coupon code on every single book — it’s really painful. So if we can have a way to say, “Apply this coupon code to all of our books,” and it just takes the same percentage off, that would be awesome.

Len: I was thinking about something similar just the other day, on our end, and the idea of providing like tick boxes and creating a sale for all of my books. That’s a really good idea. Thanks very much for that.

Karen: I was going to say — and the other one is creating multiple — I don’t know if this has changed actually, because we haven’t done it for a while. But the one year we went to agile, and we wanted to have our books at the book table, but because they’re ebooks, what they do is — we print out the front and something about the book, and then we give them coupon codes. And then they take cash, and then they give them the coupon code. Because this is how they want to do the books. We’re like, “Just give them the URL.”

And they were like, “Please can you create 30 coupon codes for us?” And we’re like, “Okay.” And we did them individually. I don’t think we sold a single one. Because all people did was like, “Oh, this is where we can get the book.” Well let’s just go to Leanpub and buy it. I actually don’t think we’d ever do it that way again, we’d just give them the URL. But I think the conference bookstore wants to do the — I don’t know, “We’ll take cash from people to give them a voucher.” It’s a bit odd.

We had to create a large number of unique coupon codes. That was a pain. But that is not as much of an issue for us anymore, wanting to create a coupon for many books. That’s much more important to us these days.

Len: Thanks for the feedback, that’s really interesting. I’ll talk to the team about that.

And on the subject of thanks, thank you very much for being on the Leanpub Podcast, and thanks for being a Leanpub author — we really appreciate it.

Karen: Yeah. Anyone who wants to write books, we tell them to come look at you guys. Because it really is simple. Thanks for supporting us.

Len: Thank you.

Karen: Cheers Len.

Len: Cheers.