Daniel Vacanti, Author of Flow Metrics for Scrum Teams: Because story points were never a part of Scrum anyway

Len: Hi I’m Len Epp from Leanpub, and in this episode of the Frontmatter podcast I’ll be interviewing Daniel Vacanti.

Based in the Miami-Fort Lauderdale area, Daniel has two decades of experience working with, and writing and speaking about, Lean and Agile practices, including helping to develop the Kanban Method for knowledge work in 2007.

He is the co-founder of ActionableAgile and more recently of ProKanban.org, which helps teams and organizations improve their agile practices through training and courses.

You can follow him on Twitter @danvacanti and as I mentioned you can check out his website at prokanban.org.

Daniel is the author of a number of books that have been published on Leanpub and elsewhere, including Flow Metrics for Scrum Teams: Because story points were never a part of Scrum anyway, When Will It Be Done? Lean-Agile Forecasting To Answer Your Customers’ Most Important Question, and Actionable Agile Metrics for Predictability: An Introduction](https://leanpub.com/actionableagilemetrics).

In his books, Daniel covers a lot of ground on Lean and Agile methods and approaches, with a particular focus on subjects like probability mathematics, and in particular on freeing teams from approaches that don’t use data or math properly, and engage in wasteful guesstimation that we can so easily confuse for sound analysis.

In this interview, we’re going to talk about Daniel’s background and career, professional interests, his books, and at the end we’ll talk about his experience using Leanpub to self-publish his book.

So, thank you Daniel for being on the Leanpub Frontmatter Podcast.

Daniel: Thanks so much for the invitation, Len. I’m really, really excited to be here. Glad to have had the invitation, and can’t wait to get this conversation going.

Len: Thanks. We were really glad to see your great books appear over time on Leanpub, and it was really nice to see them find an audience as well.

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 about where you grew up, and how you found your way into a career working in lean and Agile methods?

Daniel: I was born and raised in D.C., actually in the city. Not too many people - I think I’ve only met one other person in my life who was actually born inside Washington D.C., so if you’re in D.C. and listening, I’m glad that you are.

As you suggested, my interest early on was in mathematics. I actually graduated with a math degree or “maths,” depending on where you are in the world. But I quickly found out that you really can’t get a job in mathematics. I mean, that’s just a really, really hard thing to do.

But what’s interesting is, if you could spell “C,” then you got hired as a programmer, right when I graduated. So that’s how I got into software development. I sent out a resume, and then they hired me.

I got into Agile methodologies just by pure dumb luck. A couple of the teams that I was working on were experimenting with them. I got sucked into the management side of things, because I kept looking around for better ways to do stuff.

I kept thinking my whole career, “There’s got to be a better way.” When you have dates dictated to you, and schedules and scope and everything dictated, it’s like, “There’s got to be something different.” So the opportunity came along, and there was nobody else who really volunteered to take up the management side of things, so I did, and that’s really how my Agile career took off.

Len: It’s really interesting actually. I didn’t know that you studied maths, and then took up programming, as a result of job applications. Did they do a lot of training for you? Was it a big company or a start-up? What was that experience like?

Daniel: It was a start-up-ish that had a contract with a big company. So essentially, even though the company that was paying my paycheck was a startup, it really had the feel of a huge corporation, and things like that. No, there wasn’t really much on-the-job training. It was really pushed in at the deep end, and learn.

As part of the maths degree that I got, they forced you essentially to get a Computer Science minor. That was because there was so much Computer Science in it, that you essentially graduated university with a Computer Science minor.

I kept thinking, I was sitting through all these Computer Science classes, I’m like, “When am I ever going to use this? This is a waste of my time. When am I actually going to use it?” I came to find out that there was some use.

But I will say this, and I’m guessing many people, many other people, I’m hoping many other people on your program have probably said this. Pretty much everything I learned about software, about work, about everything, I learned on the job. I did not really learn much of anything useful at university.

Len: That’s really interesting. Actually, that leads me to ask a version of a question, which is a way into the bigger topic, but a version of a question that often comes up, which is, if you were starting out now, or if you were giving advice to someone who were starting out now who was going to have a career in, let’s say computer programming and software development, maybe with an eye on becoming someone like you in the future, moving to the management and consulting side and things like that, would you recommend doing a full Computer Science degree?

Daniel: Wholeheartedly no, absolutely not. I would say, “Don’t waste your time, don’t waste your money.” So many good code camps are out there now, that you can go to, if really what you’re trying to do is get into programming, there are just so many really, really good resources out there, that we just never - I don’t know how old you are, but back when I was growing up, the interwebs was this very, very nascent thing, right? Still using text browsers, and stuff that like that. So we just didn’t have the resources that were available to us now.

I guess, I can only speak for American universities too, I don’t know about universities abroad, and in Canada, I’m sure they’re much better. But yeah, I would, not that I have an opinion on this, can you tell, Len?

Len: Yeah.

Daniel: I don’t have an opinion at all, but yeah. I don’t have many regrets in my life, but probably my biggest regret is going to university and paying for it.

Len: That’s really interesting that you’re so straightforward about that. Some people hedge it a little bit, but to be that straightforward about it. One question I have about that is, actually you mentioned, being born in D.C. and growing up in that area. I’ve done some client work in that area, and there are some big, big, very process-heavy organizations that do work down there. I do believe that, at least in the past, typically, having a college degree might actually have been an entry requirement, that HR departments had no way around. Has that changed, do you think? I mean, like let’s say, to be specific about it, like in say in the defense industry, or things like that?

Daniel: I honestly can’t speak to say like something specifically like the defense industry or something like that. But most of the companies that I work at now, that I work with nowadays, I don’t believe they do have that requirement. They would be hard-pressed, I think, if they did.

I mean, you’re absolutely right with your point. I think way back when, yeah, you had to actually have that degree to even get your foot in the door. That was table stakes type stuff.

But less and less - I don’t really come across that anymore, nor, like I said, nor would I think it’s beneficial existentially to have that requirement. Most of the best developers I’ve ever met don’t have that degree, or certainly don’t even have a Computer Science degree, but don’t even have a university degree. A couple of people come to mind that don’t even have even university degrees, are probably the best developers I’ve ever met.

Len: I’ve heard that from quite a few different people in the past. I have actually heard specifically, that in some of those typically more rigid industries like defense, that actually things are opening up on that front. There’s things like the notorious war for talent in software development, and stuff like that, that force your hand, right? Again, as you mentioned, the resources that are available to you, including learning resources.

Lots of people I interview for this podcast started with a magazine, and typing programs into something. So they began as self-taught anyway. But with code camps and just the incredible resources available today, and not just for learning, but for actually doing, right? Like, fork a repo on GitHub. You can just get going on something, with relatively little training, and just make a real product.

Daniel: That’s exactly it. Like I said, with everything that’s out there right now, just everything at your fingertips for free. All of this stuff’s just for free, you can get going. To me it seems, probably the nicest word I can think of is “superfluous.” To go through the quote unquote “rigor” of a university degree.

Len: My personal position on that is that, one of the really important things that comes from getting a university degree, and this is specifically in-person learning, is the range of acquaintance that you can develop there. So things like, doctors become a lot less intimidating, when you remember what it was like going to the bar on Friday nights with one, when you were 18 together.

Daniel: Right.

Len: It’s like a bit of a ticket to the middle classes. Like well, if you get in legal trouble, you can call your lawyer buddy and stuff like that. The cheesy word for it is “networking.” But lifetime, lifelong friendships, and stuff like that, are really important. But if you’re asking someone to spend four years of their youth, and go into hundreds of thousands of dollars of debt, so they can make some friends, I understand that that doesn’t necessarily sound like the best argument.

You mentioned different countries, it does vary as well, right? Like if you live in a country where tuition is low, that decision’s very different from when it’s like, you’re going to have to delay some important life choices probably, because of the debt that you accumulate.

It’s tough, especially when you’re young. But I think a lot of people actually will enjoy hearing the straightforwardness of your answer.

You mentioned you moved into the management side of things. I know you’ve told this story before, but I think people listening to this, would be quite interested to hear that you were there at the origins of Kanban, as a knowledge work process. So if you could just talk for a few minutes about what that story actually is?

Daniel: There was a company called Corbis, in Seattle. Owned by somebody that most people, hopefully you have heard of, a guy by the name of Bill Gates, that owned this company called Corbis in Seattle.

This team was tasked with changing the way that they work. They weren’t effective. It started off in the sustainment and maintenance group. How Corbis did sustainment and maintenance at the time, it was very waterfall-ish, and just very not effective. So the incoming CIO challenged them, and said, “Hey, we need to fix this. Because our customers are simply not happy.”

So, the team got together, led by a gentleman named Darren Davis, and dreamt this all up. I happened to be consulting there at the time, and it was my job to then scale up. I should say, help to scale the practices that the sustainment engineering group did, scale that to the rest of engineering.

We did all of software development for Corbis. We had a couple of big projects that we kicked off, and were in the process of ramping up a lot of the engineering effort.

So, I was there to help. How do we take some of these flow principles that we were playing around with on the sustainment team, and take them to the rest of engineering? So I just learned a lot, a lot, a lot from that. The lessons I learned from there, I’ve carried with me for the rest of my career. Again, more fundamental lessons than anything that I learned at university.

Len: I’m really interested to talk about those a little bit more in depth. So we’ve used, I used one technical term, “Kanban.” then you used one, “flow.”

Daniel: Yeah.

Len: You used another one, “waterfall.” We could probably talk about what those three things are, and then explain your positions on what you’ve learned about them. So I guess, if you could just give the quick introduction to what waterfall planning is in software development?

Daniel: Yeah. I keep meaning, because there was a paper, I think the original paper on waterfall was written, I want to say in the sixties. Do not quote me on this. People are probably going to send you hate mail now. I don’t know if they do that anymore, but I think it was in the sixties. I keep meaning to go back, I’ve read excepts of this paper. But my understanding, and when you read the original waterfall paper, it’s not as waterfall-ish as people make it out to be.

But anyway, the idea behind waterfall, generally speaking, and this might be a crude generalization, the idea of waterfall is that, you essentially have these gates, right? Say you’re kicking off a project. So you do a whole bunch of planning, and try to discover all of the scope upfront. It’s like, “This is the scope of this project. This is what it’s going to be.” Once all that’s decided, then you kick it over to analysis. Like, “Okay, now how do we take the scope, and how do we break it into work that we understand?” But then you do all of that analysis. Only when all of that analysis is done, you’re like, “Okay, now we understand this thing.”

Then you throw it over into development, and you do all of the development on all that analysis, all that scope that you just came up with. Only when you’re done with all the development for all of that scope, then you throw everything over the wall to test, and so on and so on. That’s the idea.

That’s why they call it “waterfall.” Because the stuff just, I was going to say “flows,” but that’s the wrong word. It’s more “dumps onto” the next, the whole thing just dumps on the next step downstream. It’s a very, very, very big batch, big upfront planning type of approach.

It was practiced for many, many years. But certainly with the advent of things like the internet and things like that, lifecycles of projects and things like that, became much - being able to get those things shortened became so important. Having things like waterfall, meant that you could respond to market changes as quickly as you needed to.

You can imagine, if you’re some poor tester, let’s say a project has been scoped to be 18 months. Well, almost certainly, the whole schedule will have been chewed up before anything ever gets to the testing.

So now you’re this poor tester, and you’ve got two weeks to test something that has been worked on for 18 months. Now you find all these bugs in test. But you’re like, “Well, but we said the project was going to be done in two weeks. We don’t have any time to fix this stuff.”

So it became very problematic. Which, I would argue, was the whole impetus behind the rise of Agile, right? That’s why Agile practices came to be prominent. Because waterfall just wasn’t working in the changing marketplace.

Len: Thanks for that really great answer. I’ll give my own, building on that. I love the word “dump.”, because it does actually capture something affective about the process, right? There’s something, I don’t really have a term for it. But that I think in my head of like a like self-defeating realism, or a romantic realism, which I encountered in the world of financial modeling myself.

Often people think that you’re not being rigorous, unless you have a really detailed plan. Then they have these ideas that there’s the people who are going to be in charge at the top. They are going to commission some people to make a detailed plan, right?

So they’re dumping off the planning onto those people. Those people write their 100-page Word document about how this program is going to be built. Then they dump that off to some project managers, who are like, “Okay, we’ve literally got 1,000 spelled out things that need to be done. We’re going to hire 100 people to do 10 each. Then we’re going to dump those tasks onto those people.”

Then all the way up the chain, you’re going to have people going, “What stage are we at? What stage are we at in the plan? What stage are we at in the plan?”

Then, as you said, at the end, it gets dumped onto some testers, who are often under incredible pressure to not find problems. Because the problems are not specified in the plan, and especially any specific ones you might find.

It’s not just that it disrupts the timing, it’s the whole mindset gets disrupted when you find a problem. That’s why Boeings fall out of the sky, to put it very crudely.

So, in response to these pressures, and it’s what you’re describing in your own story, is, people were starting to realize that in the gap between you making your plan and this product coming out, we might’ve learned something about the market, and we might want to change something. So then you get another technical term, of Agile being developed.

In that context, I was wondering if you could talk a little bit about exactly how the Kanban process, ignoring other details of the origin story, which I’ll link to, where you talk about that in a talk on YouTube. But what is the Kanban process? What physical form does it take? For people who, let’s say, don’t know anything about it at all?

Daniel: It’s maybe a bit abstract than what people might be expecting, or might even assume. In that it’s not common, there’s not a formal methodology. It’s not even, I would argue, a formal framework. The way that we like to characterize Kanban is more of a strategy.

It’s a strategy to achieve flow. The basic thanking is, whatever job that you, the global “you” out there, whatever job you are doing, that job exists probably to deliver value for a customer. There is a customer somewhere that’s waiting for your help or your input, or whatever. Waiting for you to at least contribute to delivery of value.

One of the best ways, what we’ve learned, and we’ll probably get into this - one of the best ways to optimize that delivery of value, is to focus on this thing called “flow.” We keep talking about flow. Hopefully we’ll talk some more about it. But you want to optimize customer value, you optimize for flow.

If you buy all that, and I am waving my hands, this is a podcast, so nobody can really see me waving my hands, or whatever. But I’m waving my hands quite a bit. If you buy that argument, then what Kanban is, is really it’s a strategy to achieve flow. A strategy. It’s not the only strategy, but it is a strategy to achieve flow. So if you use Kanban, you’ll achieve flow. If you achieve flow, the idea is, you’ll probably optimize delivery of customer value. In 25 words or less.

Len: I’ve got a quote here from your Actionable Agile Metrics book: “Simply stated, flow is the movement and delivery of customer value through a process.” Which is great. Because I think it represents it, A, in a sense it’s abstract, but it’s very grounded in a couple of constants - movement, delivery, customer value, and process.

But it’s a process, not the process, right? So, different companies and teams would presumably find their own - part of the activity of achieving flow, is thinking about how you do things, how you want to do things. But in particular, that customer value concept is very important.

I’m just gathering this from your writings, and other things I know about the industry, but, one item of customer value, that you can deliver, is answering their question, “When will it be done?” Which is the title of one of your books.

How do you wrap customers heads around the reality of what value you can give when you answer that question? Because people, on Twitter, like, the leading way to put it would be, “People want a deterministic prediction.” The only honesty you can give them is a probabilistic forecast. So if you could just talk, generally speaking, about your position on that, and how you go about explaining that to say a recalcitrant customer?

Daniel: If I can continue my brutal honesty, I don’t know that I have a good answer to that. If I did have a good answer to that, I’d probably be sitting on a beach somewhere counting all of my money. As much as I love you Len, I probably wouldn’t be talking to you, and be doing something else. I really don’t know. It’s one of the reasons that I wrote that book.

Because, if we can loop back to our original conversation about waterfall, to me, the fatal flaw in waterfall, if there is just one, is this idea of deterministic thinking. I love the fact that you used “determinism.” Most people believe that we can know with 100% certainty what our scope is going to be upfront. We know with 100% certainty what our schedule’s going to be upfront. What our finances are going to be upfront. The truth of the matter is, we don’t.

The future’s full of uncertainty. I always say this, “If you can predict the future,” if people are good at predicting the future, then, “I’ve got like tons of wonderful business ideas for you.” Because generally, the future is just full of uncertainty.

Once people recognize, once somebody recognizes that, “Hey, the future is full of uncertainty,” then the next step they need to take is, “Okay, well, ‘uncertainty’ means we need to drop deterministic thinking, and now start taking a more probabilistic approach, and embracing probability.” Because probability is literally, and I mean “literally, literally,” Is literally the science of uncertainty, right? That’s what we’re talking about.

But, to your original question, getting customers to understand that, “Hey, the best I can do is probably give you a range of possible outcomes. We can negotiate that range, based on whatever agreed confidence that we need. That’s really the best we can do.”

Another great thing, I love, that you said, is, “by the way, we will learn. As we develop this, and as we deliver, both of us will learn. You’ll learn that some of the stuff you thought you needed, you don’t need. Some of the stuff you had no idea you needed, you absolutely need. We’ll tweak and we’ll change as we go. Our probabilities of being able to deliver certain outcomes will change, based on that new information that we get.” So, I, I don’t know if I faked my way through that answer?

Len: I think you answered it very well. The very top of your answer was like, “It’s very difficult, and there’s no one answer for how you can convince someone of the truth of the claim that you’re making,” right?

I think there’s two sort of - and, again, I came across this in financial modelling, and things like that. There are people who, There’s a like positive thing, where they believe it’s achievable. There’s a negative thing, where they think you’re being evasive or weak if you can’t, if you refuse to give them that, right? They’re saying, “Oh, you’re just going to use this to take advantage of me. To like draw out the project.” Or, “You just haven’t thought about it hard enough.” Or, “Maybe you’re not smart enough, and don’t understand the situation well enough?” When you’ve pierced that veil yourself, it can be very frustrating.

Because you think, “You think that when I show you a chart, now,” of a projection going forward of something, whether it’s a stock or a cryptocurrency, or something like that, that, “That’s the reality, now we know.”

That’s crazy. That’s crazy. But knowing that, doesn’t make the person stop being crazy, right? To speak in a very self-interested way about this, you’re just stuck with matters of psychology and process, and what you can do.

But that’s why I really like the way you described focusing things on customer value. In addition, you have this great example that you use of hurricanes. How like, you go through, I think it was Sandy, in the particular example that you use, Hurricane Sandy, to show, like, “Things really can change on a dime, but it doesn’t mean you shouldn’t try. It means you need to understand what a probabilistic forecast really is.”

Daniel: Yeah, absolutely. This is why I love the work of say people like Annie Duke so much. I guess, she’s maybe the one you should ask that earlier question, she might have a much better answer than you. But, essentially you really need to think like a poker player. Her book is called [Thinking In Bets](https://www.amazon.com/Thinking-in-Bets-Annie-Duke-audiobook/dp/B078SBSBW3/ref=sr_1_4. One of her books. But that’s how you, when you get new information, not only can you not be afraid to change, it almost necessitates or requires a change, at least a consideration of change.

That’s why I like the hurricane stuff. Because if you go to The National Hurricane Center, they are not going to tell you that hurricane path with 100% certainty. They’re not. In fact, they’re very, very clear that, “This is a probabilistic model, and we’re looking at about a 70% chance. When you see those graphs, you’re looking at about a 70% chance.”

And, well, it’s fine for people to get angry with The National Hurricane Center, for, “Hey, why can’t you give me a 100% model?” That’s just not the way the world works. It’s just not the way the universe works.

Richard Feynman talked a lot about this. It’s one of the basics of nature, it’s one of the building blocks of nature. Probability is intrinsic to nature. It’s not a result of something. It’s intrinsic. When you go down to the quantum level or below, now we’re getting philosophical. But these types of things are intrinsic. So thinking that you can escape them, thinking that you’re smarter - because, like you said, “Oh I showed a graph, and now there’s uncertainty,” or, “Now there’s certainty,” that’s the wrong way to think about it.

I love, by the way, I love how you talk about insanity. Because, yeah, human psychology is a big part of this. Things like behavioral economics, big time.

Len: Well, and something I will confess to being bad at, which is probabilistic thinking. It doesn’t come naturally to everybody. In fact, it doesn’t come naturally to most of us. And, actually, maybe some of the listeners will have heard of this? But if you could explain a little bit the Monty Hall, “Let’s Make A Deal” classic example of how - I’ve read the answer to why it works the way it does, dozens of times, and still haven’t really - well not dozens, a few times, and I still can’t, I couldn’t reproduce the answer, if I were asked to do it on my own. But if you could talk a little bit about the three doors and what the sort of counterintuitive answer to what you should do in that scenario?

Daniel: I could try. That definitely works better with some visuals, but happy to give it a shot.

So the idea, is, on “Let’s Make A Deal,” a contestant is presented with three closed doors. Behind one of the closed doors is a brand new car, and behind the other two closed doors is a goat. The objective of the game’s really easy. If you pick the door that has the car, you win the car, right? So, what Monty Hall does, is say, “Okay, contestant, please pick your door.” The contestant will pick a door. Let’s say they pick number two, door number two.

What Monty Hall will do then, is, Once the contestant picks door number two, Monty Hall will open one of the other two doors, door number one, or door number three, revealing where one of the goats is. So let’s say he opens door number three, now we’ve got the contestant who chose door number two, we’ve got door number three that’s open, it shows a goat.

Monty Hall will go back to the contestants and say, “Okay, I’m going to give you a one time opportunity here to change your answer. If you want to, you can change your answer. Now that I’ve shown you there’s a goat behind door number three, do you want to stick with your original answer of door number two, or do you want to go to door number one?”

Most contestants, when given that opportunity to switch, will not. They will stick with their original choice. Because this gets into the psychology thing, I think? Because the pain of switching, I think this is how I would explain it? The pain of switching and failing is much higher, much greater than the pain of staying and failing. So that’s why most people will stay, even though, from a mathematics perspective, your odds are about double of being right, if you switch.

Len: Yeah. Sorry, go ahead. No, I was going to say, that’s the part that breaks my brain.

Daniel: Yeah.

Len: Maybe I’m too impassive. I don’t think I would be too much subject to the like, “Oh the pain of switching,” regretting my mistake if I switched, and it turned out my original choice was right. But it’s just that like, the way my brain goes through that, is, “No matter what, when I pick a door, there’s going to be one that can be picked that has a goat behind it. So how can it possibly make - that’s going to be the same. Every time I pick a door, there’s going to be one door that Monty Hall can pick, that does have a goat behind it. So how can it possibly make a difference, when I switch?”

Of course, there is an answer to that. I think it has something to do with the fact that you’ve got more information now. The fact that Monty Hall had more information then you did, when he made his choice. It’s something along those lines. But, again, like it just doesn’t come intuitively to me, to get the rigorous reason behind that.

Daniel: Yeah. I can take one more minute, maybe try to explain it, and you tell me if this helps you or not?

But for the listeners out there, when all three doors are closed, any door that you choose, you’ve got a 33% chance of being right, okay? So once you choose door number two, my example. Once you choose door number two, you have a 33% chance of being right. What that really means, the way you really need to think about it, is, you actually have a 66% chance of being wrong. Once you chose that door, you have a 66% chance of being wrong. So when Monty Hall opens door number three for you, he’s done you a huge favor. Because he’s just showed you, it’s not door number three anymore, right? So, remember, I now have a 66% chance of being wrong. That means that door that I just chose, that door number two, 66% chance of being wrong. So I should probably switch. If that makes sense, if that helps you at all?

Len: I could repeat the words back at you, but my, you know what I mean? I could write down the answer correctly. But I guess what I’m confessing to, is my intuition still doesn’t really change.

Daniel: And, yeah, that’s probability for you, right?

Len: Yeah.

Daniel: I don’t know that I have a good feel for probabilistic thinking either. I know that I should be doing it. But, I think, that’s just human nature, we’re just not good at it.

Len: Yeah, I know. It’s great, we were making fun of crazy people earlier, for just believing projections. But confessing to your own faults can also be helpful for understanding things, and explaining things as well.

When it comes to flow, so the concept of flow, I think I might have a fun way into asking you your thoughts on that. Which is, I believe you have a beef with Steve Tendon, about his concept of flow? I say that humorously, and with the knowledge that you’re friendly with each other.

Daniel: Yeah.

Len: Steve has been a guest on the podcast in the past, and has a couple of books on Leanpub. Is that actually a good framing? If it’s not, please just like give me your own concept of flow. I thought maybe a compare and contrast might help?

Daniel: Yeah. So Steve is a very good friend of mine. We talk all the time. In fact, we just talked yesterday. Steve Tendon talks a lot about the Theory of Constraints. I personally have not found much, what’s the word I’m looking for? I was going to say “value,” but I don’t know if that’s the right word. Whatever it is, whatever that word is, in applying the Theory of Constraints, I’ve gotten much more bang for the buck in applying Deming. Hopefully people have heard of Deming? But even Deming’s mentor, Walter Shewhart, and their theory of variation.

I may come across this way, I don’t mean to, and I’m not saying that Steve is wrong and I’m right. I’m saying, there are many, many competing theories out there around flow. All of which are probably valid to some degree.

I just tend to favor more looking at flow from a variation perspective. Steve just tends to look at it more from the Theory of Constraints perspective. If I’m being completely honest, depending on how many beers you get into me, at the end of the day, we’re probably both right.

Alot of times, we’re probably just arguing over semantics. He points this out to me all the time. He’s like, “Dan, you know you say you’re not doing Theory of Constraints, but you are doing Theory of Constraints.” I have a hard time arguing with him when he says that, but -

Len: Maybe we could go into a little bit more detail there, about what the variation perspective is, and what you mean by that. I think probably a lot of our listeners will be familiar with Deming, and like this kind of high-level thinking, and how it makes it’s way into Post-it notes on boards, or what have you. But, yeah, if you could talk a little bit about the variation perspective that you mention?

Daniel: Yeah, and it might help to, maybe to start with the Theory of Constraints perspective, too? And, again, I’ll caveat this with, “I am not an expert of Theory of Constraints.” So, again, if you get hate mail, this is all my fault, I might be saying it all wrong.

But the Theory of Constraints roughly says that, in a given process, there is only one, for lack of a better word, “governing constraint,” right? There’s a part of your process that is going to govern the operation of the rest of the process. That’s the constraint.

All decisions, all your decisions around how the process operates, should be subordinated to understanding of where that constraint is, and what’s commonly called is “exploiting that constraint.” I think “exploiting” is a terrible word, but whatever.

The big assumption with the Theory of Constraints, then, is that you can identify where that constraint is, right? That’s the big - even the people in the Theory of Constraints community, I think would say, “Hey, you know what? If you guess wrong and you’re applying the Theory of Constraints, and you guess wrong where that constraint is, you’re actually going to do more harm than good,” right?

That’s why I come in. Because forgetting for a second the whole debate around, “Is software development complex or chaotic or simple, or whatever?” Forgetting the whole Stacey or Cynefin model stuff. There is a lot of variability in what we do. There’s variability in item size. There’s variability in people’s ability to do work. There’s variability in how process is structured. There’s variability in global pandemics coming through. There’s all kinds of variability that we have to deal with, that I think make it very, very, very hard, a process to say, “Yes, without a doubt, that’s where the constraint is.”

Because that variability will change from day to day. It will change, and it will make it look, the variability and flow, will make it look like constraint. It’s here one day, and then here another day, and then here another day.

So, that’s why I think understanding and controlling for variability, I believe, is a little bit more effective approach. That’s not to say, just to be clear, that’s not to say you shouldn’t study Theory of Constraints, and read a little bit more about that. Because in your context, maybe it is very easy to see where that constraint is.

Len: Maybe, to give people an image, of what would an example of a constraint be, for example? If we’re actually applying this to a circumstance? Like, let’s say, for example, you’re managing a big software development project. You’re watching, let’s say you’ve got ten rows, where you’re watching things flow from left to right, so started to finished. You can see, I think there are apps you can use, that, you can also do this physically, but you can change the color to stay green as long as they’re good, and they’ll start dimming to red if they’re going bad.

So a Theory of Constraints person would probably want, I’m just making this up, but like, would they go there and look for a constraint? Like, “Not enough developers working on that,” would that be a constraint?

Daniel: So, similar to like that. Let’s maybe even, if I may?

Len: Please.

Daniel: Take that metaphor, and maybe simplify it a little bit.

Let’s look at a single team. Let’s say on this team we have analysts and developers and testers. Let’s say, again, I’m not saying you should do this. But let’s say that those people are very siloed. Analysts can only do analysis. Developers can only do development. Testers can only do testing. Again, just to make the example simple.

So let’s stay on that team. You’ve got ten analysts, one developer, and 22 testers, right? Just for example.

Well, it’s pretty obvious there that development’s probably your constraint. Because the developers are not going to be able to keep up with the work that the analysts are probably throwing over the wall at them.

Then your testers are probably going to be starved for work. Because the poor developer is overwhelmed, and nothing’s getting through the tests, and we’ve got 22 testers sitting around.

So that constraint, is, it’s called, because that’s where the - well, I was going to say, “The slowest flow is happening.” But it actually manifests itself as the longest amount of time, I think, to get through that queue.

I don’t know if that helps a little bit? Wherever that flow is constrained, we’re not getting the throughput that we expect.

Len: I think that’s a really great, very clear example. Especially with the numbers being put that way. It’s a very clear example, and it puts it in the context of, one team trying to develop some app or features, or something like that.

Just for people listening, it’s so interesting how much depth there is to this field, that one might not be - I’m just a dabbler myself. But, so for example, you might think, from that example, “Oh what we need to do is throw more people at the problem.” Then there’s this concept that people who’ve read about software development will know about, The Mythical Man-Month, for example. Where, What was the? I saw a joke when I was researching for this, that someone made, I don’t know if it was you, but it was like, “If you want someone to finish reading a book faster, just buy them another copy. Buy them a second copy,” or something like that?

Daniel: Yeah.

Len: But it captures the spirit of the The Mythical Man-Month, the idea of like managing what you do with that constraint, kind of, isn’t necessarily straightforward, even if you’ve identified it.

Daniel: Yeah, yeah. This is the fundamental problem of flow, is, we like to say, “It’s unintuitive to the point of being counterintuitive.” Because you’re right. Initial reaction might be, “Let’s throw a whole bunch of people at it. Let’s throw a whole bunch of money at it.” But in the short term, the absolute best thing that you can do when you’ve identified that constraint, or just in general, when you’ve identified a variation to your flow, is to work on less. Not to try and do more. It’s actually to work on less.

There’s a whole bunch of Queuing theory to support the fact that, when you see problems with flow like that, work on less. That’s the whole, I wouldn’t say, the whole underlying, organizing principle behind Kanban. That just freaks people out. Just like, “What? I’m going to get more stuff done faster by working on less?” “Yes.” Then once we have a good understanding of that, then we can talk about, “Should we be adding people? Should we be spending money?” Or whatever. But until you’ve got control of the number of things that we’re working on, any of those types of decisions, are premature. Not just a little premature, like very, very premature.

Len: That’s interesting. That reminded me of a metaphor that you used in, I think the introduction to one of your books, where you talk about how like, basically what you’ve done, if you start analyzing your process, you find that you’ve done a DDOS attack on yourself by - I’m laughing - or, Distributed Denial of Service attack, for those unfamiliar - where basically it’s, You’ve probably heard of it, “The website’s gone down, because some bad actor threw too many eyeballs at it at the same time, and it couldn’t handle the load.”

But we often do this thing to ourselves. Because it makes you feel productive to start new tasks, and start new tasks, and start new tasks. But if you’re not focusing on actually finishing the ones that you’ve started, now you’re working on unfinished things all the time, that never get done.

“…it feels more productive to start more stuff. But you’re actually more productive if you finish more stuff.”

Daniel: Yeah. I love that you phrased that, like, yeah, it feels more productive to start more stuff. But you’re actually more productive if you finish more stuff. That’s where you’re actually more productive. This is where I think, when, bringing in some of the metrics, and things like that to the conversation. Simultaneously make it easier and harder. Because of all the things that we’ve talked about. Because people need to understand probability. Then people need to accept that, hey, their intuition is letting them down.

Len: Yeah. That reminds me of something that I’ve thought about a fair amount. Which is, one thing that one can, when people are managing, are paying teams of people to do work, there is a strong psychological need to have everybody be busy all the time. Otherwise, you feel like you’re wasting money. And, so, for example, sometimes, if everybody’s busy all the time, that means you have no one available to handle something unexpected that needs to be done.

But another version of that problem, I live here every day in the city of Victoria, where, the city loves to operate - it has lots of people to operate machines to do work. Very clearly, the ethos is that, “Nobody should ever be idle.” So what that means, is there’s guys literally blowing leaf blowers at like a single leaf pasted to the sidewalk in the rain, because it’d be a waste to have that person not be working.

It’s like, “Well actually what it does, is it just means that we’re constantly assaulted throughout every day of our lives, with all this unnecessary disruption to our lives.” Because people don’t want to wait. They don’t want to just leave the equipment idle. So once you’ve got it, that means someone needs to be driving it around all the time, or whatever.

Do you have any like big answers for - if you were brought into an organization where you saw this problem, like you’re doing too much, but that doesn’t mean you should fire anybody.

Daniel: Right.

Len: How do you explain that?

Daniel: Well, there’s several good examples out there. An extreme example, if we talked about society at large, an extreme example of society that, we understand this, is, we literally pay firepersons and paramedics to sit around and do nothing, waiting for, like you were saying, “Waiting for that emergency.” Can you imagine if paramedics, let’s just say paramedics showed up for their job, and there was no call out or whatever, so we started forcing them to go pick up a leaf blower and start cleaning the sidewalks -

Len: Yeah. Keep busy.

Daniel: Then, they’re like three miles away from the hospital, when the call comes in. So that’s the extreme example, is, if you don’t build slack into the system, then very bad things are going to happen.

Companies like FedEx and UPS understand this very well. They’ve got tons of empty planes, tons of empty trucks, a lot of times either circling in the air or just driving. So whenever there is a problem, they can divert those empty resources.

Not that I’m necessarily calling people “resources,” that’s another conversation. To go help out with those problems of flow.

So, yeah, it’s funny how we think about waste. Most people think that idleness is waste, where this ought to be. This was the brilliance of Toyota. They realized it was like overburdening. That’s really what’s waste.

Len: That actually reminds me. I was just going to say, another example of like, the way we like feel waste, when we’re just not thinking it through properly, can be, for example, I was just thinking, like let’s say a paramedic, I’ve got a cousin who’s a firefighter. So, he’s done some self-defense training, right? There’s a certain way of thinking, where you can say, “What if he got to the end of his career and he never used it? Does he then relate to it, ‘Oh I wasted all that time doing self-defense training, because I never actually got attacked.’” It’s like, “No, it wasn’t a waste.”

But that’s where probability comes in, right? Because there is going to be some proportion of firefighters who, because they’re not just fighting fires - they do all kinds of other things as well. There’s going to be some proportion of them, that do encounter this. So someone somewhere has to be counting the beans, and going, “Well, actually everybody should be devoting this much of their time, their training time, to self-defense,” because, “Add actuarial analysis here.”

Daniel: Yeah. It’s the whole, not to get too overly technical, it’s the whole ex-post versus ex-ante analysis. What we were talking about way before, too.

People think that all the stuff should be knowable upfront. If you get an outcome, where, “Hey I never used self-defense,” I think is what you said? Once you know that sample path, and you say, “Oh well, then I should’ve never done it.” Well that’s the ex-ante, ex-post analysis. Just because a sample path is known, doesn’t necessarily mean there weren’t other possibilities. You could’ve just as equally been attacked 50 times in your career, whatever, so -

Len: To bring up another technical term, and your latest book, Flow Metrics For Scrum Teams, the word “Scrum” is in there. In the introduction of the book, it says, “The book is partly about things Dan disliked about Scrum.” I think there are probably people listening who are waiting to hear you talk about that. What’s your general position? What is Scrum, what’s your general position on it?

Daniel: My general position on it, it’s not that Scrum is necessarily a bad thing. I think Scrum had a place.

If we rewind 20 years ago, because we were talking about waterfall and the rise of Agile practices. 20 years ago, if I was starting out and I had to choose waterfall versus Scrum, well, of course, I would, at that time I would’ve chosen Scrum hands down, right? Every day of the week, and twice on Sunday. That’s the way I would’ve chosen it to work.

But, and maybe because I lived through it, I always think of scrum as a reaction to waterfall. To me, that’s the reason that Scrum existed, and that’s the reason why we were successful. It was because it was a good alternative, potentially a great alternative to waterfall.

But think about all the things that have happened specifically in software development. I would argue, maybe, potentially in knowledge work in general. But especially software development over the years, around the tooling and the practices that we’ve developed.

We build things like continuous integration. 20 years ago, how many companies did you know that were doing continuous integration, and now it’s table stakes. 20 years ago, how many people did you know, companies did you know, that were doing continuous deployment, continuous delivery? Hardly anybody. But now it’s table stakes.

So, the engineering practices have evolved to be more and more and more continuous. What I don’t understand is, why haven’t Agile practitioners caught up to that? If your engineering practices are continuous, your process has to be continuous too. Your process has to be continuous to support that. So, if I had a gripe with Scrum, it would be, it’s still anchored in that batchy thinking, where I think we need much more continuous processes to support the way that we work today.

Len: Just to drill in on what you mean when you’re talking about continuous processes for Agile management. You talk about aging work, the concept of aging work in progress. I think it’s the one you called, “The most important chart you’ll ever see,” or something like that. But the aging work in progress chart. So if you could talk a little bit about what aging work in progress is, and how, what a chart like that looks like, things like that?

Daniel: Yeah. The idea behind aging is, so, if we talk about flow being the way to optimize customer delivery. Well, the important part of that is that we deliver something to the customer. The problem with things like a definition of “done,” Scrum has an emphasis on the definition of “done,” and things like that. There are good things about that.

But the problem with that is, you have to actually be done before you know something’s wrong, right? But by that time, a lot of times, that’s too late of a signal. From a flow perspective, we want a signal as early as possible that something may be going wrong.

The best signal that I found, by far, is to focus on something called “aging.”

So in a process, you’ve always got, whether you know it or not, you’ve always got at least two defining points. A point at which something is considered started, and a point at which something is considered finished. What aging measures is, “How long has it been since this thing that we’re working on, this value item, or whatever it is, how long has it been since it’s crossed that start point?”

Because if we’re monitoring that, especially in relation to how long it’s taken us to complete stuff in the past, that’s going to give us a very early signal, even before the thing is done, that, “Hey, maybe something’s wrong here? It’s bigger than what we thought. Maybe we don’t have the right people on here. Maybe it needs to be broken up or better analysis needs to be done? It’s blocked.” Whatever it is, right? The aging is going to give us a wonderful signal that some action may need to be taken.

Len: Actually, you mentioned earlier, living through something, and knowledge work. I’m going to be asking a question about metrics. So I’ll start from over here, but I’ll end up over there.

We just went through a pandemic, it’s still going on, to some extent, although a lot of the lockdown and restrictions have been lifted. But this brought with it a huge shift towards “working from home,” as people call it, and/or working remotely. There’s areas like medicine, for example, where they say, “There’s ten years of progress in one year,” in terms of telemedicine, and things like that.

One challenge that remote work, for organizations that aren’t familiar with it, presents, is monitoring. The crude version of it is monitoring people. The more, I guess, using loaded language, refined version, is monitoring what you’re calling “processes.”

There was a genre of news article, about how bosses can’t monitor their workers anymore, and how this is a big problem for companies.

I was just wondering, just, since I’ve got you here, and this is your area, what have your thoughts been as you’ve been watching this happen? Are you even being a part of it, if you had any work that you had to do that was related to it?

Daniel: Well, I mean, so, first, a shameless plug here. It was one of the reasons why I love a Kanban-esque approach, is because, and you’ve probably heard this idiom or euphemism, or whatever you want to call it, but, “In Kanban, we focus on the work, not the worker.” What we really care about is getting those things done. I don’t care who’s working on it. I don’t care what they’re, I don’t care. It’s like, “Are we getting this stuff done? If we’re not getting this stuff done, how are we as a team or organization going to self-organize to solve those problems?”

So whatever answer I give is going to be colored by that perspective. I don’t necessarily see a problem with remote working, or being in the office, or hybrid. My guess is, I don’t really have a strong opinion on this, but my guess is, some hybrid is going to prevail. The genie’s out of the bottle, right? Pandora’s opened that box, we’re not going to close it again.

I don’t think that’s necessarily a bad thing, again, as long as we have an ability to, I think, like I said, I think it would be more about monitoring the work, and not necessarily who’s doing the work.

If we see a problem with how the work is getting done, then questions need to be asked. But it’s not - the question, from a Deming perspective, if we see teams are dropping in productivity, the question isn’t, “Why do you suck?” Right? That’s not the question. The question is, “What about how we’ve designed our process is failing us, and what are the changes in the process that we need to make, to enable people in this brave new world to be as effective as they can be?”

Len: That’s a really great answer. Thanks for that. My anecdotal, or vicarious experience of it, was the way that these changes were being represented was very grumpy. Because I think, one thing that was exposed - the story wasn’t told this way, generally speaking - but what was exposed was that a lot of organizations and a lot of managers didn’t exist to get the work done primarily. They existed for some ethic, right? An example would be, I read numerous examples of where it’s like, “How do I know if I send the analyst off to make a presentation on X and they come back seven hours later, that they really spent seven hours working on it?” It’s like, “No serious person thinks that way.”

A person who might be rich, they might be successful, they might be in a position of power, they might have just success after success and promotion after promotion their whole lives. But that is not a serious way to achieve anything, other than maintain the organization’s ethic. I think a lot of what was exposed was, again, it gets represented as, “Oh, workers just want to sit around in their sweatpants.” it’s like, “Actually what they really want to do is work. They really want to achieve the goals that they’re there to do, rather than be monitored all the time for keystrokes and what have you.”

One of the big lessons is, if you actually just trust people to have the self-respect that they mostly do have, you’re going to end up with a much more productive team. Whether you settle on a hybrid model or not, it’s making sure that you’re actually trying to get the thing done, is the most important thing that you can do, right?

Daniel: Yeah. Not to sound like a broken record, but certainly there is going to be a percentage of people out there that are going to take advantage of that system. That is going to happen.

But again, if we take a Deming approach, it’s like, yeah, maybe 5% of the people are taking advantage of the system, but 95% of the people are probably exactly like what you’re saying. They want to be empowered, and they want to be given the independence and autonomy, just to get their work done.

We have a tendency to focus on that 5%. Well, because there’s 5% over there that are doing bad, that means the whole process is broken. Well, actually no. It’s quite the opposite, it’s actually probably working much better than we want to acknowledge.

Len: Speaking just generally of the pandemic and the effects it’s had as well, you mentioned Kanban as a strategy. But all of the people who’ve heard about it will probably have a very specific image in their head, of like a whiteboard, or even a wall, with Post-it notes in rows and columns on it, and stuff like that. What have you seen? Have you seen people - obviously people had to shift more towards using apps, basically, to manage this stuff, even if they would favor having a physical wall. Do you think that there’s something important that’s lost by not having people gathering in one place to view the same physical thing?

Daniel: Probably, yeah. Before the pandemic, I always said my favorite Kanban tool was a physical board. That was by far and away my favorite tool. The thing is, now, having developed a tool of myself, for myself, the truth of the matter is that all tools work, and all tools don’t work. It really just comes down to how you use them. So people love to rail against Jira, people love to rail against Azure DevOps, whatever.

For Kanban, is Jira ideal? Well, for the expert user out there, it probably isn’t. But for most teams, it’s probably good enough. Same thing with Azure DevOps. There are things that drive me nuts about both of those things. But are they workable, are they usable? Absolutely.

Is there something that’s lost from people not being together and huddled around a physical board? Maybe, probably, but I don’t think any of that is fatal or not overcome-able, or any of that. I think, we’ve learned in the past couple of years, in fact, how to overcome some of those things. So I’m not that worried about it.

Len: On that optimistic note, maybe it’s time, and in the interest of time, to move onto the last part of the interview, where we talk about your experience as a writer.

As someone who thinks about process and stuff like that, I’m just curious if you could talk a little bit about what’s - that doesn’t necessarily mean you do, but do you have a process for writing? Do you self-monitor your progress, and things like that?

Daniel: So I used to be a big outliner. I’d have an idea, and I’d sit down and I’d write an outline of all the stuff that I want to say.

That has evolved dramatically over several years, to where I’m driven by - oh, this is going to sound bad, but I’m going to say it anyway - more, I’m driven by anger. Something will just piss me off, and I’ll just start writing it. I find that taking that more stream of consciousness type of approach, just have a blank piece of paper, and just start typing, is what works for me.

As a writer, that was probably the biggest thing for me to get over. You’ve got the tyranny of the blank page, and you feel like every sentence that you have to write has to be perfect, right? It has to be exactly what you want it to be.

This idea that, “Oh yeah, you can always edit it later and you can change and rearrange,” for me, it’s much more effective, just start typing, and it’s okay to throw stuff away. So that’s how my thinking has evolved over the past couple of years.

Len: That’s a really great answer. I say that partly, because I identify with it. Anger’s a form of passion, which is a good thing to have if you’re writing, usually. Anger is also distinct from rage. Rage is uncontrolled anger. You definitely want to avoid that. But anger is a fine motivation for doing things.

In particular, I was getting angry myself mentioning this genre of terrible article published in major publication after major publication, about the future of work and working from home, by people who didn’t, evidently, didn’t take ten minutes, to look into the fact that, there’s a lot of research, and whole areas of study that have existed for decades on this stuff. There’s companies like Hashicorp that have never had an office. Just to pick an example, the Globe and Mail in Canada, their expert on what’s going to happen to the future of work is a CEO of an office space leasing company in Toronto. Like yeah, right, that’s a good source for information.

But anger, not just in the blogosphere, where obviously anger plays a role, and like, I’m going to get a short post out. But it is important, I think, sometimes, to - you take that as a good motivation for, why are you angry, right? Well, you should think about it. Like you might actually have very good reason to be angry.

Then as a writer, you’re confronted with, keep in mind you probably have an opportunity to do a second draft, or to edit it later. So, you can shave off the parts that were maybe not so well controlled when you were writing.

But I think anger’s a great motivation, for, a great way to get started writing something.

Daniel: Well, and if I can give a plug for Leanpub, it’s the whole reason that I picked Leanpub as my first medium for publishing, was because I could get it wrong, and there was almost, there was zero cost. Essentially zero cost to me, to get something wrong. It’s like, “Oh, okay. I just fix it and push another button and hey, look, it’s published. I don’t quite like that.”

So Leanpub acted as a wonderful outlet for that anger. could write something, I could put it up and - I’m a very visual writer too. I like to see it.

Which is one thing we should talk about. I don’t know if I necessarily agree with separating out formatting from content. I don’t know if I necessarily agree with that. To me, format is content. But that’s a - maybe you can have me back, and we can have this whole philosophical debate about that. But anyway, I like to see it. With Leanpub, it’s just so easy for me to put something new out there, generate a PDF, and just see how it looks.

Len: You brought up formatting and content. So, I’ve got a doctorate in English Literature for my sins, so -

Daniel: Oh no, I stepped in it. I’m sorry.

Len: No, no. This is actually an argument I’ve had from your side. From what I imagine some version of what your position is, and borrowing, if you want to go all high philosophical - borrowing from Hegel about the unity of form and content in a very deep sense - that’s not just, he would make that claim not just about writing, if you know what I mean?

Daniel: Yeah.

Len: But about like history itself. But no, there are some projects where formatting and content are not distinct. To pick from the history of English literature, Tristram Shandy is an example of that. But there’s all kinds of other things where form and content, from a certain perspective of like hermeneutical analysis, there’s just no distinction for some projects, whether you know all the fancy words or whatever, it’s just obviously the form and the content are not distinct, for example, from an experiential perspective, and I certainly agree with that.

But, for those listening, what you’re bringing up, is the fact that, when people encounter formatting problems with Leanpub, or I should say “limitations,” our textbook answer is, “Formatting is procrastination while you’re writing.”

Daniel: Yeah.

Len: That qualification at the end there, leaves us a little bit of an out from the stronger claim that’s being made there. But it is true that that is something we do say, and I do, I’d say it myself. I believe that it is 95% of the time the right thing to tell a writer, “You shouldn’t be worrying.” Talking about myself there, where it’s like, “Oh, like let’s go off on the formatting.” You’re not writing anymore. You’re not writing anymore.

But every time I say it, I feel bad. Because I do believe that formatting is very important for most, for lots and lots of projects.

Daniel: I would, you know, just hopefully, I was just having a dig at your expense there.

Len: Oh, yeah.

Daniel: But the thing is, if we do take the the small batch, because Leanpub’s all about “Publish Early, Publish Often,” right? That’s really why I think it exists, which is wonderful.

But the “Publish Early, Publish Often,” to me, it’s like, when I’m looking at a revision of something I’ve written, I’m trying to look at it from the perspective of how my consumer is going to. If it’s just trash, it’s like, “If I can’t tell the difference between, is this a new heading or is this a new section of the book, and did I reference that, the figure right?”

Because you probably saw my books, I think my first book has 120 graphics in it, or something ridiculous like that. Which was painful in Leanpub’s original Markdown flavor. It was painful to get all of those images just right. But no, anyway -

Len: Yeah, no, I really appreciate the feedback, and that’s great.

On that note, one of the requests that we get over and over again, is like, “It would be great to see an instant rendering of my page.” Because the way Leanpub works, if you’re using one of our writing modes - we have an upload writing mode. So by the way, for anyone listening, if you don’t want to learn any of this stuff, if you’ve got an ebook file, you can upload it to Leanpub and be making 80% royalties in five minutes.

But if you want to use one our writing modes, we have a Word writing mode as well, it’s rather limited in terms of formatting.

But most Leanpub books are written in plain text. What that means is they have to go through a rendering. So that our book generators, as we call them, read the instructions that you’ve written. Because you don’t just write the paragraphs, you have to write the formatting instructions in there too, like, “This is a chapter heading.” It’s a pound sign.

But then there needs to be this rendering going on and what you have to do, is you just have to cross your fingers, and hope you got it right and click the button, and maybe go down to page 182 where you made your latest change, and see, did that actually work? It is an inherently painful process, and it is something we’ve had people ask for, like an instant rendering of the page. Write on the left, rendering on the right, stuff like that. It’s possible that someday we’ll have something along those lines, but definitely like we know that there’s these - especially when it comes to formatting, there is really just an inherent difficulty when it’s not WYSIWYG, or “What you see is what you get,” right?

Daniel: Yeah.

Len: There’s some difference between what you do, what you actually write, and what’s produced.

With that said, the last question I always like to ask on the podcast if the guest is a Leanpub author, is, if there was one magic feature we could build for you, or if there was one thing other than formatting that you were constantly like shaking your fist at the screen and shouting at Leanpub for that we could fix for you, is there anything that you can think of that you would ask us to do?

Daniel: So and I was just thinking about - even before you reached out to me for the podcast, writing the last book. The only thing that really makes me angry, I apologize, it’s a formatting thing.

Len: That’s fine.

Daniel: So if I have several headings, if I have like heading 1, heading 2, heading 3, heading 4, And - because I reached out to support and asked if I could do this, and they said, “No.” But I want to be able to give different styles or different fonts or different whatever for each of those subheadings. They said, “No, it’s impossible to do that.”

Len: Yeah, we created a story based on that feedback, and for discussion. It’s not something we’re going to do anytime soon, unfortunately, sorry about that. But yeah, what Daniel’s talking about, for anyone listening, is that we’ve got a heading, Level heading 1, level heading 2, level heading 3. We just do what we decide with that formatting instruction. You can’t tweak it, so to make it different font, choose a different font from the body font or, well, no, you can set the title font, but that’s basically, you can’t change it. Yeah, you, But it’s a global setting, you can’t do it on a per heading, or, and you can’t do it on a heading level thing either.

I can see how that’d be very frustrating. Especially if you use things like Microsoft Word, you can easily just select that text, and change the color or change the font or make it - well, you can make ours italics.

So I understand the request, and yeah, we did see it. Sorry the answer is that that’s not going to be happening anytime soon.

Daniel: That’s okay. I’m not telling you anything you don’t know. But where it really becomes a problem, is in editing. Because I’ll cut and paste whole sections to different parts, look at something, “Oh, I had this in chapter two, it’s really a chapter seven thing.” But if all the headings look the same, then I lose, I’m like, “Oh shit, was this really a subheading of this?” Or whatever, and it was just hard. I’m selfish, and I’m lazy, so you’ll just have to know that.

Len: Well, and you should be, and it’s our job to give authors what they need.

By the way, there’s lots of features that we do have that - they’re there because someone did exactly what you just did now, years ago, or last week, and we’ve responded with, by saying, “Okay.” So we really appreciate the feedback.

Daniel: No, sorry. I was just going to say, again, if I can end on a positive note. There is a reason I keep coming back to Leanpub. There’s a reason I just published the Flow Metrics for Scrum book, just published, I think two weeks ago, maybe three weeks ago, whatever?

Like the whole philosophy behind Leanpub, the fact that I can keep my copyright, the fact, the thing that, honestly, the original thing that sold me on Leanpub was, it’s so open. You’re like, “Here, we’ll even create the files. You can export this thing off to Amazon and then sell your stuff to Amazon.” Honestly that was the thing that hooked me. I was like, “That’s just a wonderful thing.” So I will keep coming back to Leanpub and publishing all my books because of the openness of the platform, I just love it.

Len: Thanks for mentioning that. I really appreciate that.

That actually gives me an opportunity to, I like, I almost buried the lede here, which is, we actually do have another out. When it comes to formatting, and it’s an export-based out, and we have InDesign export.

The idea there is that, you can write your book on Leanpub, and you could potentially like not care about, you could be like, “I’m a writer, I don’t do formatting. That’s for book designers.” So we actually have a thing where you can export the InDesign files. We have had people in the past who are like, “I’m familiar with the conventional publishing process. I’m the writer, I write the manuscript. Then I’m going to,” even if they’re self-publishing, they’re like, “I’m going to hand this off to a book designer that I’m going to pay,” and they can use that.

When it comes to the openness, yeah, I think one of the things that we sometimes have a hard time communicating, and that’s all our fault, is that, when you write a book on Leanpub, you don’t have to just publish it on Leanpub. You don’t have to publish it on Leanpub at all. We just want authors using our platform, and that thing - in the self-publishing world, I don’t know if you’re familiar with the term “going wide,” but that’s the settled-upon technical term for one approach to self-publishing, is, “Put it on all the platforms.”

That’s the position we’ve taken. We do say, “If you’re doing your own promoting, you’re probably making more money per sale on Leanpub.” So if you’re making a specific, personal recommendation, like you’re standing in front of a conference, probably point them to Leanpub, is the best idea. But obviously we don’t have nearly the eyeballs of Amazon. So if you want to get the eyeballs and the conventional recognition, please go put your book on Amazon and go wide.

The other version is “put your eggs in one basket,” is the very technical term that people use. Just put it in one place. The idea there is put all your marketing in one spot, not in multiple spots.

Daniel: Right.

Len: Well, thank you very much for taking the time out of, what I’m sure is a beautiful day in the Miami area, to talk to me and to talk to our audience, and thank you very much for being a Leanpub author, we really appreciate it.

Daniel: Thank you for the platform. Thanks for everything that you do, and thanks for the invitation. I was just looking at the clock, it’s almost an hour and a half we’ve been talking. It doesn’t feel like that at all, so hope the listeners feel the same the way when we get to the edited version of this. But, yeah, I can listen to myself talk all day. But anyway, thank you so much for the opportunity to come and talk to you today, I’ve thoroughly enjoyed it, and I look forward to hopefully some future conversations.

Len: Thanks.

And as always, thanks to all of you for listening to this episode of the Frontmatter podcast. If you like what you heard, please rate and review it wherever you found it, and if you’d like to be a Leanpub author, please visit our website at leanpub.com.