A Leanpub Frontmatter Podcast Interview with Samantha Laing, Author of Growing Agile: A Coach's Guide to Agile Testing

Len: Hi, I'm Len Epp from Leanpub, and in this podcast, I'll be interviewing Samantha Laing.

Sam is an Agile software development coach and speaker who works, along with her colleague Karen, at their company Growing Agile, based in Cape Town.

Along with Karen, Sam is the co-author of a number of Leanpub books, including, I think it's still six books in the Coach's Guide series [It's seven books now - eds.].

You can follow Sam on Twitter @samlaing, and learn more about Growing Agile by following the Twitter account @growingagile, and you can also get in touch by emailing them at info@growingagile.co.za with questions.

In this interview, we're going to talk a little bit about Sam's career and professional interests, her books, and at the end we'll talk a little bit about her experience self-publishing.

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

Sam: Pleasure, I'm excited to be here.

Len: I always like to start these interviews by asking people for their origin story. In our interview with your colleague Karen, she talked a little bit about her experience going to college and then heading off to Seattle in the late 90s, and I was wondering if you could talk a little bit about how you became interested in the world that you're in?

Sam: My story was a little less glamorous. I actually wanted to study medicine, and I wasn't accepted into the medical facility at university. We have an equivalent called the Bachelor of Science, where I could study all the same subjects, and probably get in in second year. So I did that, and one of the subjects I picked up as an extra was Computer Science. At the end of the first year, I realised actually I preferred computers and maths to anything else.

So I got my degree in Bachelor of Science, and in Computer Science and Maths, and I went off and became a software developer, which I loved. I absolutely loved software development. I started out in Delphi. I did some Pascal. I did some .NET, C#, some Java, a whole bunch. I kind of wormed my way around into a team lead position, and it was at this stage that I realised, no matter what we did or how well we did it, deadlines were always forced on us - and I hated it.

I had to make a choice in my career, whether I wanted to become an architect, and further my way in the development side, or if I wanted to become a manager. So I thought, "I might be able to help the team more with deadlines, if I became a manager." It turns out managers also have no say about deadlines.

It was around there somewhere that I discovered Agile and Scrum, and everything just opened up to me. There was light at the end of the passage. I thought, "I can finally do something about this." So I resigned, and didn't have a job and went in search of becoming a Scrum Master at some company. That's when Karen hired me as a Scrum Master, and that's how we met. Three years later we started our own business.

Len: What was that transition like from being a programmer, to being a manager?

Sam: It was very difficult initially, because I couldn't just solve the problem by myself. I had to help other people solve their own problems. Whereas as a team lead - if something was wrong, I could just jump in and fix it. That wasn't necessarily the case as a manager. It was also frustrating, because in my mind, I had expected to have a lot more say and a lot more, I don't know, power, maybe? I realised that I'm just another cog in the wheel, and there's always someone else above me that's actually pulling all the strings.

Len: I've interviewed quite a few people who are involved in Agile software development for this podcast, and frustration is part of the origin story of Agile. It's a common element, that people are part of organizations that are trying to achieve often pretty concrete goals, and yet the management structure and the management conventions seem to get in the way of achieving those goals. Do you think things have changed in the last, let's say, 15 years or so?

Sam: In some organizations, I see a lot of change. I am sometimes blown away by how forward-thinking they are. In other organizations, it might as well be the 1950s that I'm walking into. I see HR getting involved and talking to people, and there's no such thing as performance appraisals. There's even some organizations where all their salaries are completely open and transparent to everyone. That's just an amazing level of transparency.

Len: Why is that important? Why is it important to be transparent about salary levels?

Sam: I think salaries lead to a lot of underlying issues. Traditionally in organizations - I don't know if this is the same all over the world, or specific to South Africa - but salaries are kept a secret. Everyone has to not speak about their salary, or at least that's what's expected from you. But what management doesn't know is everyone actually talks about their salary, or most people do. And then they compare themselves to other people, they get really upset when they find out they're not being paid as much as someone else, who they think's doing less work or anything like that. It tends to lead to a lot of upset, unhappy people.

This actually happened to me at one organization where I was a team lead. I used to get into work first in the morning. I was there at about half past six in the morning. The first thing I'd do is print out all the bugs for our team. And I went to the printer, and someone had left a sheet with all our team members' names and their salaries.

Len: Wow.

Sam: Yes. It was very "wow," because me and the team lead for the other team - we were the two least paid on the whole team. So I just put that sheet on my boss's desk with a Post-it note on it saying, "We need to talk. Sam."

Len: One question I like to ask people who've gotten into software development is, if you were starting over now, or if we were talking to your younger self, who was just entering into a new career now, would you recommend studying computer science in university?

Sam: No. No, I wouldn't even recommend going to university. I think it is a huge waste of money. I mean, I did get value out of university; I don't think it was worth the price tag that was put on it. Particularly software development. We were taught such theoretical stuff, that when I got to the real world, I had learned so much of specific languages that - the only thing university taught me, was that I can switch languages quite easily. But that said, if I was given three years to learn to switch languages outside of university, I would probably also be able to do that.

Len: I'm curious - what's the situation with university tuition in South Africa? Obviously you said it cost money, so it's not paid for by the state. Is it a similar system to what one might find in the United States where there are private universities that are very expensive, and then public ones that might be slightly less expensive, or have a lot of scholarships?

Sam: So we have - I don't know if they're public or private actually, but we have a bunch of universities, and they are expensive. I don't think they're private. They cost a lot of money. Most people can't afford to go to university. Most people who do go to university are paying it off, which I think is very similar to the States.

Len: I'm speaking from the province of British Columbia in Canada. Obviously the student debt issue is a problem in most places, but we don't have quite the same problem with it in Canada. I don't think there are any universities in Canada where it costs $60,000 a year in tuition, like it does in some universities in the United States.

But one interesting thing, and I'm curious about your opinion about this, is that I've heard from people, if you want to work for a big company, like a Google or an Apple or something like that, then a Computer Science university degree is kind of a necessary requirement. Is that true in your experience, working with big companies, today?

Sam: Sadly, yes. Specifically, it has to be a Computer Science degree, an IT-related degree. For example, my wife used to be an HR manager. She's got a social sciences degree, she switched careers in her mid-30s, and she's now a software developer.

Everyone asks her, "Do you have a degree in IT?" And she's like, "Well no, but I do have a degree." It's kind of a barrier for her as well. She has to really prove herself, even though she's been employed as a software developer for five years.

Len: When you're brought into an organization as a coach, do you go into the backgrounds of the people that you're going to be working with? With their educational backgrounds?

Sam: Not necessarily. We don't really work with organizations long-term. We're usually only there for a month or two months, and we'll then maybe go back after a year. So we don't really talk about the education, unless it's something that's holding them back. Then we'll talk about what they could do.

Len: What drives an organization to invite you and Karen in to help them? What are the typical problems that lead them to go looking for solutions?

Sam: There's two types of people that contact us. One is companies that want to have Agile. They want to have this magic thing called Agile, and they want to do Scrum training.

And then there's the others, that have been doing the Scrum thing for a while, and they don't feel they're actually getting the benefit that it's supposed to bring to them. Those are the ones we truly love. Those are our favourite playing grounds. Because they've tried some things, and they either worked or didn't work. But for us, that's exciting, because we get to explore new areas with them, and help them - really dig deep into what they've been doing, and how they've been doing it and why they've been doing it.

Len: What are some of the obstacles that teams that adopted an Agile or Scrum approach then confront later on, after they've tried and not necessarily succeeded to the degree they wanted to? What are the typical problems that you then have to help people overcome?

Sam: On the surface, the problems that they mention are things like: "We commit to a certain amount of points every sprint, but we never deliver those points. A lot of our work is interrupted the whole time. When we start working on things in the sprint, they explode and snowball, and they are much larger than we thought they were".

I would say that's probably 80% of the problems. And those for us are awesome, because there's such nice ways to deal with that. Usually it touches on quite an itchy-scratchy topic, which is, "Do you all work on your own individual stories?" That is usually the case here, and when we suggest all working together on a story, that's impossible, because they can't see how they might even do that. So, showing teams what is possible, and how they could work together and help each other - after one month seeing how much their team has bonded, and how they love working together now, is amazing.

Len: And if you encounter say a sceptical programmer, do you have some techniques for overcoming that? I'm not a programmer myself, but I do write. And if someone came in and told me to collaborate with someone on writing, I'd do it, but I'd get grumpy.

What are the ways you have of trying to convince people that working together, in the ways that you get people to work together, is superior to the comfort zone that they're already in?

Sam: It doesn't work for everyone. What we try and do - and there are sceptics, there are always sceptics, they're usually senior developers who are very opinionated, and have the loudest voices in the room as well, so you can't ignore those sceptics - we usually try and speak to them one-on-one; we understand their frustrations. They generally have quite a bit of frustration.

Recently at an organization, the senior devs, there are three of them, and they actually wanted to leave. They told their manager they were going to leave, because they're so tired of not being able to get anything done, because they keep helping the junior developers, and no one has enough experience on the system, because the company is trying to scale, and they've also almost doubled in size in the last few months. So the drain on them is even more.

What we said to them was, "We just want you to try something for one meeting." That was a backlog grooming or backlog refinement session. "And then for sprint planning, part two - we want you to just tweak it and do it slightly differently, and then tell us at the end of the sprint if that helped you or not." The change in their team, and how much the juniors were able to do more things by themselves, instead of requiring their assistance every couple of hours, was awesome. They were amazed. They didn't think it would make such a difference.

Len: So if someone's sceptical about something, presenting them with defined parameters - "We're going to try this once, it's going to be like this" - can help put them at ease with what they're getting into, rather than an open-ended or undefined situation. I've heard that from a couple of other people before, I think - that sounds really good.

I wanted to ask you - I asked Karen this question as well, when I interviewed her - in one of your books, you talk about - both you and Karen have done your share over time on death march projects. I was wondering if you could maybe talk a little bit about one memorable death march project that you worked on, and what made it a death march rather than a parade?

Sam: Sure. It was a very dark time in my life. This was the company where I used to get in at half past six in the morning, and I used to leave at about 6 pm, drive 30-odd kilometres home, feed my dogs, turn around, drive back to the office, stay at the office until one in the morning, and then drive back home and sleep. We did that for - I don't even know how long. Probably six or so months.

The company - they were lovely. They supplied us with dinner every night, in the form of pizza. After about a month, everyone just was ordering salads from the pizza place, because I think our nutrition levels were so depleted, that's all we wanted.

Evening sessions were disastrous, because no one can focus for that long. We did get into trouble once with the security guards, because we had a paper airplane competition across the entrance hallway, to see whose plane could fly the farthest, and we created a lot of litter. People can only focus for so long, and making them stay in the office and pretending that they're being productive is just - I don't know who it's fooling. Certainly it didn't fool anyone on our team. The later we stayed, the more bugs we created, the more issues we created, the stupider we became.

This project - I think the end date was delayed something like eight times, the go live date. Eventually it went live, and I think it was in production for two years before they actually pulled the plug, because no one used it. So all this effort, all this energy, all this craziness - and for nothing.

Len: If you go into a company now, for example, and you see something like that happening, what can you say to managers about that? Like if they're under pressure to show that they're squeezing people for effort, what can you do to try and convince them that just keeping bums in seats longer, doesn't necessarily mean greater productivity?

Sam: One of the most effective techniques we have is to play games with them. We play the airplane game. Have you heard of that?

Len: No, I don't think so.

Sam: Basically, you fold paper airplanes. I'm seeing a theme here - I have clearly spent too much of my life folding paper airplanes! You set up a factory scenario, where one person folds the paper in half, the next person folds the nose, the next person folds the wings and draws a star on them, and then the next person puts another flap in the wings, and flys it. But the person who has the fourth stage, fold the wings and draw the star - is a bottleneck that you're creating in the system.

You put a whole bunch of papers in, and the tenth paper is a coloured paper. Then you time how long it takes for the coloured paper to get through the system. You tell people to work as fast as possible, and as soon as they get to that coloured paper, you stop the timer. So it takes about - four, five minutes, three to five minutes for the first round. People work like crazy. They create so many paper airplanes, they build up all over the show.

In the second round, you tell people they can't start folding the next airplane, until the person downstream from them has taken from them the one they've just folded. So, they can't build up an inventory. So only one airplane is at one person at a time. There's nothing waiting. So, if there's a bottleneck in the system, you all wait for the bottleneck to move; you're actually moving as slow as your bottleneck. And the time for the yellow piece to flow through the system, is almost half the time.

And then we ask them what they noticed. Which of those two rounds did they feel more productive? It's always the first round, because they were busy like headless chickens. And we ask, "But it took you twice as long in the first round to get to the yellow piece of paper than it did in the second round. So you were actually more productive in the second round, when you were calm and waiting. Not busy, busy, busy, busy." And then we asked them, "Which of these two scenarios is more relevant to how you work in your workplace, and how could you become calmer and thus more productive?"

Len: That's really interesting. I can say, personally, my mood is soured when I feel blocked. I'm the kind of person who kind of prefers to take an alternative route rather than sit in the traffic jam, even if I know it's going to take longer to go the other way. But what you just described is really convincing and very straightforward as a demonstration of why simply doing what maybe makes you feel better in the moment, isn't necessarily what's better for the team.

Sam: Yes. But it does take someone outside of the system to look at everything from an overall perspective to see that, because when you're in the system folding airplanes, that's all you see - that you have to fold airplanes. You don't see what's happening or that there's a bottleneck downstream, and it doesn't actually matter how fast you go.

Len: I wanted to ask you about something that I saw you tweet about. You might not remember it, but it was a blog post by Ron Jeffries, called Twice the Effort All the Time. I'll quote from it - I don't expect you to remember everything you tweet about, but I just wanted to use it as an example to get your opinions about Agile and the Agile community, where - people who are unfamiliar with it might not know, but there can be kind of big debates and heated opinion.

He says, "So, I guess, Agile has moved beyond being applied by people who understood it and liked what it gave them, or who liked what they saw and worked hard to learn to get it, into a world where "decision makers”, who don’t even know what it is, decide that those guys down there need some of that Agile Stuff and impose it – impose something – on their organization."

Is that something that you experience sometimes? Where people bring you into an organization and they don't really know even what it is that you're bringing - they just know that there's this Agile thing out there, and that they need a little bit of the special sauce or something like that?

Sam: Yes, 100%. We have been brought into organizations and been told, "Our mandate is that we will have 100 teams Agile by the end of the year, and we need 500 Scrum Masters." And we're like, "Well that's nice. There aren't 500 Scrum Masters in South Africa, but that's a lovely goal. Why do you want to be Agile?" "No, because we've been told that's in our company goals. It's our strategy for the year." It's so sad, because right there, our strategy for the year is to be Agile. It's like, "Well that's not really why Agile's here." That kind of goes against being Agile a bit.

Len: Ron Jeffries also writes about how often power holders have little or no idea how to program. I wanted to ask you a little bit about that. Is there something about managing software development that's maybe different from other types of labour? Do you need domain-specific expertise in order to successfully manage any software development project?

Sam: That's such a nice itchy-scratchy topic. I don't believe you need software knowledge to manage a team of software developers. I think it actually gets in the way. I think what managers need are people skills, and sadly most people, especially in software, become software development managers or managers of software teams, because they were the senior software developer. And they have very few people skills. They've never been trained in talking to people and leading people and managing people. They kind of fumble their way through it.

I think that's really, really sad. Because if you've ever had an awesome, amazing boss, it was because of his people skills, not because he was a excellent developer.

Len: That's a really interesting way to put it. I think you're the first person to put it quite that way. I've interviewed people before who've pointed out the importance of people skills. I was interviewing someone just recently who talked about how it's all people skills, in a way. But I think you're the first person to say that you actually don't really need to know how to program in order to manage a team of developers.

What would you suggest to say someone who's managing developers for the first time? What can they do to get their head in the right space for managing people who are doing that type of knowledge work?

Sam: The best advice I could give is for them to get themselves a business coach, someone who can ask them questions to show them how to ask questions, instead of order people around. Someone who can help them see that there are other ways to manage. That would be my advice.

Len: That's really interesting, walking into a situation and trying to figure out how to ask the right questions, rather than, first, how to give the right commands. How can you know how to issue the right commands, without actually knowing what the problems people have are, and whether or not they're even capable of articulating what their problems are?

Sam: Karen and I actually had this conversation in the car today about managers. We'd specifically noticed that mostly male managers in technical fields seemed so concerned about technology, and they want to drive the architecture and ensure people are going to the tech conferences. Female managers are more concerned about having one-on-ones with the people, ensuring that the teams are working together well, and making sure that everything is harmonious and happy.

When I think of a manager, I want someone who's looking after my well-being, because I have the technical expertise. I don't need them to have the technical expertise. I don't think I'd want them to be illiterate technically. I suppose there is a balance somewhere.

Len: I wanted to ask you - I think you're the third South African programmer that I've interviewed, and two of you are female. What's the gender divide like in software development in South Africa? Is it as one might expect it would be based on precedents in other places, or is it maybe a little bit different there?

Sam: For as long as I can remember, I was the only female developer on my teams. My wife has just joined a new company. She's the only female developer on a team of eight guys. It's majority male, very few females. That's just how it is.

Len: You brought up Karen. One thing I neglected to ask her in my interview with her, which I regretted not asking was: You work together in Growing Agile, the company, but you've also written a lot of books together. Do you have a particular process for collaboration? Does it just come out naturally? We already spoke a little bit about how some people like to work alone, and it takes some convincing to work with other people. But obviously you and Karen are very productive together. Do you have a process for writing together?

Sam: We do. I think Karen and I are quite unique, in that we only pair work. We haven't done any work separately since probably after the first three months of starting our company six years ago. So we are very used to pair working.

When it comes to writing a book, we have a Kanban board that we share. That's between us, flat on the table, and we roughly plan, what are all the chapters that we want in the book, and how do we want to make up those chapters? Are there images, is there a story, is there an exercise? What do we want in that chapter? And we break it down, and then we each grab a chapter, and we do what we call "vomit onto the page." That's our term for: don't filter, just type whatever comes to mind, and it doesn't matter if it's absolute crap. That's fine, just type.

And then when you're done, you put it into the review column on the Kanban board, and the other one will review it. But once someone has put all this junk on a page, it's so much easier to make it pretty and to ad lib and finish sentences and all of that. That's what we do.

Len: That sounds like a really good system, giving one license to just write. I've heard that from other writers before, and I've experienced this myself, where the biggest impediment to actually writing anything can be this fear of not writing a perfect thing with the first keystrokes. That's often the worst way to try and get anything done. Just letting yourself go is a really good way, not just to get started, but to write well in the end.

Is reader feedback important to you, I'm curious to know? For your books, have you solicited reader feedback - is that important to you?

Sam: It is important to us. We often encounter people have bought a book and then immediately we will ask them, "What did you think?" Most of our books have exercises in them. They're for coaches to use when they coach other people. We want to know how they used our books, and if it was helpful. We get some feedback about spelling mistakes. Mostly we get requests for new books.

Len: Do you have any new books that you're working on at the moment?

Sam: No, not at the moment. We've decided to only do smaller books. Most of our books recently have been a lot shorter. The reason for that is, we have what we call a "creation week," and we have to come up with the idea for the book, and write the book, and publish the book in that week. That's how we motivate ourselves and stimulate ourselves. But we haven't had another book creation week yet.

Len: That sounds like a really fun idea, and probably something to look forward to. I definitely look forward to your next creation week, and the next book that you guys write.

My last question for you is: you've used Leanpub to write and publish quite a few books. Is there anything missing that you can think of? Even if there isn't necessarily a weakness - if there was some magical, "world peace" button that we could create for you, that would really help you in what you do, or satisfy requests that your readers have had - is there anything like that that you can think of?

Sam: I will say the whole, pay what you want, if you want to pay more thing, I love that so much. I often find myself on other platforms going, "I wish they had that, because I wish I could decide what to pay for something." I really love that about Leanpub.

I think Karen and I have unique issues, because we have so many books. For example, if someone asks for a refund, we literally have to go through every single book - and about four button-clicks inside every book, to try and figure out which one was refunded, and was it a bundle, and was there a reason. I think that's the hardest thing for us, because we have so many books. To try and figure out which one's made money and which one's had refunds is hard for us.

Len: Thanks for that. I remember it was either with you or with Karen, I believe I was corresponding recently about coupons for multiple books.

Sam: Yes, coupons is also difficult.

Len: The way Leanpub works, authors can offer coupon links to people, where they click on the link and then they go to a page where they get a lower minimum price than they might normally see. But Sam and Karen have so many books, that when they want to do coupons for a number of books, they have to go into each individual book and then set a discount price. The idea of being able to set a global discount price for all the books, or something like that, is something that would be really useful.

I hadn't quite thought about drilling down into the issues around say refunds and feedback for multiple books as a collective issue. That's really interesting, and something that we'll definitely think about, because obviously we'd love to see more authors with more books, and we want to be able to meet those needs.

I wanted to say thanks very much, Sam, for staying up late in Cape Town, and doing this interview. We really appreciate it. I just wanted to thank you for being on the Leanpub Podcast, and for being a Leanpub author.

Sam: Thank you, it was really nice to see the face behind Leanpub. It was fun.

Len: Thank you.