An interview with Jimmy Janlén
00:00
00:00
  • August 9th, 2019

Jimmy Janlén, Author of Toolbox for the Agile Coach - Visualization Examples: How great teams visualize their work

00:00
00:00
1 H 13 MIN
In this Episode

Jimmy Janlén is the author of the Leanpub book Toolbox for the Agile Coach - Visualization Examples: How great teams visualize their work. In this interview, Leanpub co-founder Len Epp talks with Jimmy about his background, his first experiences coding, the legendary "Spotify model" of development, his book and the power of various types of physical visualization to create a shared reality, and at the end, they talk a little bit about his experience as a self-published author.

This interview was recorded on June 18, 2019.

The full audio for the interview is here: https://s3.amazonaws.com/leanpub_podcasts/FM123-Jmmy-Janlen-2019-06-18.mp3. You can subscribe to the Frontmatter podcast in iTunes here https://itunes.apple.com/ca/podcast/leanpub-podcast/id517117137 or add the podcast URL directly here: https://itunes.apple.com/ca/podcast/leanpub-podcast/id517117137.

This interview has been edited for conciseness and clarity.

Transcript

Toolbox for the Agile Coach - Visualization Examples: How great teams visualize their work by Jimmy Janlén

Len: Hi, I'm Len Epp Leanpub, and in this Frontmatter podcast, I'll be interviewing Jimmy Janlén.

Based in Stockholm, Jimmy is an agile coach and self-described bureaucracy therapist, cultural acupuncturist, and visualization magician, who helps teams and leaders in their adoption of agile practice and culture. You can follow him on Twitter @JimmyJanlen, and check out his website at visualizationexamples.com. He does videos on the YouTube channel, crispagileacademy, and you can read his blog at blog.crisp.se/author/jimmyjanlen.

He's the author of a number of Leanpub books, including Decision-Making Principles & Practices, Jimmy Cards, and his bestselling book Toolbox for the Agile Coach - Visualization examples: How great teams visualize their work.

In this interview we're going to talk about his background and career, professional interests, a little bit about his time working for Spotify, or times working for Spotify, and all his work on visualization; and we'll talk a little bit in the end about his work as a self-published author.

So, thank you very much for being on the Frontmatter Podcast.

Jimmy: Thank you so much.

Len: I always like to start these interviews by asking people for their origin story. So, I was wondering if you could talk a little bit about where you grew up, and how you first became interested in Computer Science and software?

Jimmy: I grew up in the middle of Sweden, in a small town called Kumla. At some point early on, I decided, "I want to be part of creating the amazing graphical effects for the future Star Wars movies." I decided, that's going to be digital, and hence I need to study Computer Science. However, I forgot about that dream somewhere along the journey. So ended up as an IT consultant - .NET, Microsoft. I was a developer for nine, eight years - I think? Until I stumbled upon Scrum for the first time, and that was in 2000 - 2006, maybe?

Len: And how did you come across Scrum?

Jimmy: I started working with Siemens, they do all things - tumblers, wind - electricity and gadgets, whatever. And they also develop software. At that point in time, they were building this huge administrative tool system for hospitals. And when I joined, they had just gone through a dramatic top-down, big bang, hardcore transformation to Agile - 2005. So they said, "We're doing Scrum here." I said, "Whatever. Don't talk process with me. I'm a developer, and just let me code." Processes had never helped me so far. But then I realized something else was going on.

This was actually an environment, a setting, a process - a way of working that helped me. So then I started to pay attention, and then I started to read up on it. There wasn't that much to read back then. But then I got blown away and realized the power of it. And a few years down the road, I had the opportunity to become a Scrum Master - and then I changed assignments. As a consultant, I've always been a consultant - all my life. And for the past 10-ish years, I've been primarily doing Agile coaching.

Len: And for those who might be unfamiliar with some of these terms - one way I always like to frame these kinds of discussions is, software is the foundation on which basically everything in the world is built and done nowadays.

Jimmy: Yes.

Len: And so the way that software is built is actually something that we're - I think people outside the profession are sort of indifferent to. But actually, if you're wondering why you run into security bugs here or privacy problems there - a lot of it has to do with the way software is built. And we're sort of - if you think in grand historical terms, we're still at the very beginning of figuring out how we're going to be doing this. And so in that context, I was wondering if you could talk a little bit about - let's talk first about what Scrum is.

Jimmy: Well, Scrum is a simple recipe for how to collaborate in teams of five to ten people. It's a set of simple ceremonies, routines, habits, you can have as a team, in order to collaborate, think together, plan together, execute together, and deliver together.

But the basis of Scrum is Agile. And for me, Agile is more a mindset. It's a way of viewing work. There's many different ways to approach work, and Agile - if you're doing Agile, you are subscribed to the belief that work is best done if we do it in teams, we put ownership of the work and the result to the team, and we give them the biggest possible room to own and make decisions for themselves. That's a belief, and it's still, according to some people at least, an unproven hypothesis. Even though Agile is taking the world by storm.

Scrum is a simple framework for a software development team to do Agile. For me, Agile is bigger. Agile is, in some sense, a cultural world revolution in the workspace. Because it flips upside down the management, leadership, teamwork. How we conduct and execute a work - and primarily how we learn how to improve. And it's rapidly expanding beyond IT and software as well.

Len: You've got a great video on YouTube where you actually have all sorts of great visualizations of like pyramids and things like that. And a great explanation of - it's a bit sort of literally cartoonish, but a kind of old-school way of doing things, where the workers are at the bottom of the pyramid, and they exist to serve the masters at the top. But this Agile revolution - one way of characterizing it is that the leaders should view themselves as servants of the people who are actually creating the stuff.

Jimmy: Yes.

Len: The final authority still is claimed by the be CEO at the end of the day, and the board and the C-suite generally.

But there is this view that, instead of seeing - I've got this image that I've used on this podcast before of - you can imagine, maybe from science fiction or whatevee, an old salt mine in ancient Rome. Where there's guys with whips at the bottom of the pit. And then there's guys with whips, for the guys with whips, further up the pit. At the very top is some guy in - I don't know, like in a toga - who's in charge of it all. And the idea was that you should - I use this image deliberately, because the idea is that a worker is someone who represents a problem that you need to prevent from escaping. You need to punish them in order to get them to work.

Jimmy: Yeah. They're a machine that you need to keep on motivating.

Len: Exactly, exactly. And negatively. And Agile represents this way of saying, "No, no, no. Work should be a place that you, as a leader of a business - you should make your business a place where people want to be.

And you should give them autonomy. I was wondering if you could just talk a little bit - I'm maybe getting it a little bit ahead of myself here, so I'll pause on this for a moment. But one thing I wanted to ask you, because it comes up on this podcast a lot - is, if you were starting out now in a career with the intention of maybe spending some time as a developer and then being a consultant - would you do a full Computer Science degree at university?

Jimmy: Oh, I think so. I'm not sure. I started developing myself, I started writing code. I wrote when I was 10. When I was 11, I wrote my first text-based RPG adventure. By the age of 12, I wrote my first text based RPG adventure editor. So I believe I was a really, really good developer, even before I started Computer Science at university.

But I did learn all the math and all the foundation of it. So for me, it was worth it. But then again, through my career as a consultant, because I have the luxury of meeting so many people from all the places I visit and the companies I work with - I've met so many brilliant people without a formal university degree. So yeah, I loved it myself and I learned a lot, and I believe it helped me. But then again, I’ve seen the opposite as well. Really brilliant developers who become technical leaders within their company, and even beyond - without it. So no. That was a fluffy answer.

Len: No, I thought that was a great answer. I particularly like that you sort of rooted it in your own experience. That happens a fair amount when I'm talking to people, that they talk about their first experience coding, and just for the record - could you let us know what your first computer was? Just so you know the answers to that question have ranged from Jerry Weinberg saying, "I was the first computer, I met" to a guy using like a calculator.

Jimmy: It was a Commodore 64. And I started out with just copying programs, and by the end of a four-hour long session when I kind of just copy the text from a magazine - and once I finally hashed out all the commas and numbers that was wrong, I was so rewarded with a balloon that bounced around them.

In the beginning, I actually thought that the text I copied was like a wizard's spell. The balloon was always in the computer - inside the Commodore 64. Or it was Mickey Mouse, or whatever - or the rocket. I just casted a spell to conjure that animation. But after a while, I figured out, "No, actually the thing I'm copying here is actually code that creates the balloon or whatever."

Len: Yeah that's really interesting. It's curious, one of the reasons I asked the question about getting a Computer Science degree is, so many of the people that I interview had that experience of learning the way you did, so from a magazine, or something like that. And literally - for those listening who might not know, like a print magazine, is what we're talking about. You'd have to get your parents to take you to a store maybe, and then you'd browse a stand and buy something that had a program typed out in it, in print, in ink.

And then you would reproduce it on your computer at home. But of course nowadays you can get all kinds of materials. I mean there's all kinds of books - of course, on Leanpub. There's all kinds of videos, and even one-on-one interactions, and Stack Overflow - the resources available are just incredible. And of course - not just the resources for doing it, like for learning, but the computers that we have now, are also just incredible. And it does make it a genuine conundrum. If you're starting out a career in this area, what should you do?

Jimmy: I guess you have been part of founding a startup, right? So follow your passion, that's my advice. Even if you do study, or - find a really passionate project to work on. Because when you're passionate, that's when you pour energy into something. And when you pour energy and time into something, that's when you become great.

Len: Just before we get back to talking about Agile, I'd like to talk to you about your time - you've done a couple of stints at Spotify.

Jimmy: Yes.

Len: I'm just looking at LinkedIn here. Did you also spend some time in New Zealand?

Jimmy: Yes, I did. I spent six months there. So it was kind of an MVP. Me and my ex-girlfriend, wife - were trying to figure out if we actually wanted to move to New Zealand. So we decided, "Let's try for six months."

I loved it. It's the single most beautiful country in the world. However, it's so freaking far away and isolated - but it was beautiful. And there I worked with a huge, ambitious large-scale Agile transformation - one of the banks of New Zealand, in Auckland. That was really exciting.

Len: Oh that's really interesting. I'd like to ask you about that. One of the challenges - we've already talked a little bit about Agile. And one of the things that happens if you're a consultant in this world, is Agile transformation, which is - there's a company that decides it wants to move from the, let's just say, the old top-down model, to a little bit more of a bottom-up model. And that's a very challenging thing.

Jimmy: Yes it is. I used to be super cynical about the success rate of an Agile transformation, especially if you're a huge company. I don't know? Five thousand, ten thousand, twenty or fifty thousand employees. But then again, there's more and more success stories to be found around the world.

But it's super hard. If you have a company that's been around for fifty or a hundred years, especially if you're a bank or a similar business, and you're trying to transform from this hierarchical, bureaucratical environment and way of working - which is slow, but it is very safe. And if you're a bank - slow is good, slow is a safe. If you've been around for too long as a company, all the structures, they get embedded in the walls, in the people. It becomes an entity unto itself.

So it takes an enormous amount of perseverance and commitment from all layers - especially the top, of course, to do this. I think for it to be successful, you can't review it like just another process framework you put on top of everything else.

I've heard so many scary stories about that. They have their own way working, and then they discovered ITIL and TM3 [?] and whatnot. And then they discover safe, and they just stack it all on top of each other. If you're doing that, nothing's going to change. So I think if you want true change, you need to tackle it on every level. Both organization, leadership, culture, behaviors, habits -

Len: One thing you've spoken about is how sometimes a new structure - which is basically people - can be created within a company in order to solve a problem. And then when that problem is solved, the structure remains behind.

Jimmy: Yes. I've seen that so many times.

Len: I'm very curious about that. Do people who are in positions like that know it? They know their value is derived from the work they do, right? So let's pretend we invented a bureaucratic process to ensure our self of this or that - and because that was a huge problem, and we needed, maybe, to hire someone, and we gave that person a title, and the company grew, and that person became a department. So now we have institutionalized - Jimmy: Institutionalized the solution into hierarchies with roles and so on. Now let's imagine me, I'm a head of, or a middle manager, in that hierarchy. Obviously I want to still have a job tomorrow. So I'm going to be opposed to any change that tries to get rid of the structure I'm living in. I want to be valuable. As a human person, I want to feel safe and I want to be appreciated. So I'm going to protect the structure, whatever it is. So in that sense, the structure gets a life of its own.

Len: One thing that can be very important as well, is how things can be kind of budget-driven. And so I've got this story I like to tell, it's kind of a sad story about a friend of mine whose career wasn't going so well. He took a job as a product manager for a big IT project that was government funded, at one of these companies where they have these giant sad buildings and nondescript company names. He realized very quickly that there was nothing for him to do, and the reason he'd been hired was there was a budget, which had a position for a product manager. And the person who was at the top of this budget wasn't going to give up a part of their budget. And the person who made the plan wasn't going to admit they made a mistake and they didn't need this person they budgeted for. And so they filled the spot with my friend.

Jimmy: I think that's another example of how these structures become a thing of their own. I guess somewhere along the line, they decided, "Dammit we're too big, we need to be in control of our money, and now we're going to split our money. Or the money we're going to spend this year by department or by manager -" And so, "Hello manager, here's your budget for the year. Here's your pile of money. And by the way, if you don't spend it - you're going to get less money next year." So it doesn't really matter what they spend it on, because their influence and power, in some sense, it's directly linked to their budget. So they need to spend it, or they need to sell ideas that are worth bigger budgets for next year. Nothing in this is aimed at employee happiness satisfaction, customer happiness - or anything like that.

Len: This this will sound maybe kind of silly, but I remembered - there's a company here in Canada called WestJet, and one of the things they became well-known for was they empowered their workers in airports. So the person who in the old days, would print out your ticket for you and stuff and check you in - those people had the power to do things like order pizza for customers if there was a flight delay. This might sound silly, but it was revolutionary, both from the perspective of the customer, and from the perspective of the idea that this guy could just choose to do something kind of risky and that costs money - on the fly, to help people make money. And everybody loved it. Because it was empowering the people at the point of contact with customers to make decisions.

Jimmy: And it sends another very strong message, "Hello, you're employed - and I trust you. I trust that you want to do a good job, and I trust that you make responsible decisions." If I have that freedom, I'm also feeling trusted to act responsibly - and trusted that I'm doing my best to do a good job. So there's some huge benefits of that approach. And I know you wanted to ask me a little bit about Spotify later on, or--?

Len: Yeah.

Jimmy: I have so many examples. I spent, together, four years all in all - in two different periods, with a one and half year gap in between, at Spotify. And there's so many stories. Because there's the room and it's not cost - they really live by this, the default to openness and transparency, that's one thing. They also default to trusting employees, and they have so many active acts of trust.

For example, default to openness is one. They share every single information with everyone at the company. They went public last year, right? That - or was it earlier this year? No it was last year.

Len: It feels like it wasn't that long ago. Just for a little bit of context - so, Spotify, for those who maybe don't know, is this very successful music streaming service. And it's based in Sweden, right?

Jimmy: Yes, the founder and headquarters are in Sweden.

Len: And it's this huge success story. It sort of started very small, and is well known in the software development world, for something called "the Spotify model," that is a beast of legend. I know you'll get a chance to talk about this, that there isn't really a sort of like hard and fast model. What there is, it was a bunch of principles. So anyway - with that context, you've had the fortune of being there a couple of times to see this huge company grow.

Jimmy: Yes. That was a luxury, to be part of their journey. I wasn't there from the beginning when they were really small in one tiny office. But I think I joined when there were three, four hundred people - and I ended my last engagement with them roughly a year ago. Then they were four thousand. So they've experienced hyper-growth for ten years in a row, more or less. 30%, 40% growth in number of employees each year. Which is just -

Len: It's crazy.

Jimmy: It's crazy, really crazy. But going back to the topic earlier on, about trust and transparency. I think one reason they are successful with this, is that they distribute ownership. They truly believe in autonomy, moving ownership and decision making to the teams that are working on the problem - or working on the feature, working on the platform. And that in itself is an act of trust, right?

So, the teams are hugely responsible for deciding what to do next and how to do it, and so on - which opportunities to pursue. Every single person has access to, or you used to - at least, when I ended my engagement there, had access to production from day one. So if you wanted to, you can screw things up. And that happened. But when it happened, it got celebrated, sort of having the courage to try something. And people helped out to fix it.

They have all these great acts of trust. Another act of trust is that - if you think you need a flight from Stockholm to New York to visit the team, you just book a ticket in their system. "Because if you think you need to travel, we believe you." If you need a new keyboard or you've lost your cable or charger or whatever, each office has a self-service desk. You just go there and grab it.

But in order for you to make a responsible decision, the price tag is next to it. So if you're thinking, "Oh I need a new keyboard, I'm just going to take this one." And then you actually see the price tag, and then you might realize that, "Hmm, this was expensive - I'm going to have a second look before I take a new one." There's so many examples of active acts of trust. And that makes people motivated. They feel trusted, they feel appreciated. It's a super powerful thing.

Len: And there's something they have called a failure wall, is that right?

Jimmy: Yes. It's a whiteboard type of failure wall. It pops up here and there, it's not a process or - someone started doing it, and it was fun, and then it spread. So it keeps popping up, and it lives for a few weeks or a few months, and then it kind of fades away. And then it pops up somewhere else.

The idea is simple. If you screw up - you accidentally send an email to everyone, or you - I don't know? You screw something up in production, as a leader, as a developer, as tester - whatnot. Then you write your failure or your mistake on a post-it. You explain it to the people that happen to be around, and you do a failure bow - and then you are received with an applause. And the symbolism of this is really, it's very important. Because it signals that making mistakes is okay - as long as you act responsible for them, and you learn from them, and you try to improve on it.

Len: It's very interesting the way this responsibility is kind of formalized - so, when you're working at Spotify, you're part of a squad, that's kind of the lowest level of organization - is that right?

Jimmy: That's right.

Len: And can you explain a little bit about what a squad is?

Jimmy: It's an Agile team. But they've decided to call it something special, so they decided to name it "squad." It clarifies even further, the properties of that team. So it's five to seven, maybe ten people, co-located. They sit together in one room, they have a clear mission. It can be develop Spotify for cars or speakers, or improve the search algorithm, or improve the log in experience. So they have a narrow mission, user-facing - if possible, a user-facing journey that they are responsible for improving over time.

They are end-to-end, so they should be able to deliver. They should be able to think, plan, execute, build - and deliver themself. And once they have delivered it to production, they are also responsible for maintaining it and fixing problems as they occur. So they don't hand the feature over to a maintenance team or anything. They are self-organizing, meaning that the people in the team, they are expected to figure out together how to collaborate, how to help out, who does what in which order - and so on.

Len: And the squad sits together, they're co-located.

Jimmy: Yes. That's a built-in design principle of their organization. So yes, the members of a squad, they have actually a big room together - whiteboard, chairs, a lounge chair - so on, a TV, there may be a small booth where they can talk undisturbed on the phone, or with a few people. Several squads are grouped into an organizational unit called a "tribe." And once again, the tribe is co-located. So when possible - there are exceptions of course, squads belonging to the same tribe - yes, kind of a department-ish thing. They're also co-located. So they sit down together on the same floor in the same building.

Len: And is there another level of organization that kind of cuts across? I'm forgetting the name. I think there's a name for it? But you can have people in different squads who are all part of the same group as well?

Jimmy: Yes. I think I know what you're getting at here. So all work is done in squads, right? We collaborate, we build - there's no work done anywhere outside a squad. However, the back-end developers, for example, in a tribe, or the QA or Java developers - they of course want to share knowledge, but between people of common interest or common skill base. So that's when they have a chapter. I do my work in a squad, I sit together and work with my squad. But I belong to a chapter. Maybe I'm a back-end engineer, then I would belong to a back-end chapter. And that back-end chapter also has a chapter lead, which is my hiring manager. That's how it plays out.

Len: That's really interesting. One of the reasons I gather it's sort of a joke to talk but "the Spotify model," is that they've changed - they're changing all the time, and they've gone down different paths. And I'm forgetting, like - there was this one path they went down, that you talk about in a video, where they had like quarterly targets or something like that?

Jimmy: Yes. And this failed dramatically as a model. The first time they did it, they struggled with it for a few years and then and they gave up. Because the whole company went into kind of a death rattle with itself every end of quarter.

But actually, they have since - two or three years now - they're doing OKRs again. It's a new twist. If you read the book on how OKRs should be used, they're not doing that. So they're doing a type of simplified Spotify adopted version of it. So when I start explaining how Spotify do OKRs to someone who is an OKR guru - t they get very upset.

Len: And this is objectives and key results, by the way.

Jimmy: Yes. So once every quarter, each - the squad, some people within each tribe, get together. Through various collaborative workshops, they agree upon, what ambition do we set for ourselves this quarter, and what specific smart measurable goal should we set for ourselves? That's the key results. And this has been working out really well for them actually for their - this is the first time they've got an alignment process that works for them.

But this isn't enough. They also have something we call, "Spotify rhythm," on top of this, which dictates what are the company's top ten most important priorities right now. So all the tribes need to align their work and ambitions towards those company bets, and those -

Len: That's a really interesting concept. Someone coming in from a sort of more conventional management or working background, might think it's like, "All this empowering of people at the level of product creation sounds great, but can it potentially lead to chaos?" And the answer is, "Yes." And so you talk very, very clearly about how there's a cost - all of this great stuff doesn't come for free. And the price you pay is communication.

Jimmy: Yes.

Len: And so having, say, ten very clear goals that everybody knows, is really important. And we'll get down to the level of visualization. When I say "down," I mean that's getting to where things really matter. But at the top - Spotify's CEO Daniel Ek - he talks directly to the whole company routinely.

Jimmy: Yes, that's another great thing they're doing. I'm amazed that they - not just him, but the whole C-suite. So roughly every sixth week, two or three times every quarter, they have an all-hands meeting, awesome, big gatherings - where every single employee is invited. They talk on stage about the big news, about maybe new company bet, or they celebrate a finished company bet. Or they have a topic or the year in review, or whatnot.

But the most baffling thing about that event is that they use roughly the last 20 minutes - it varies, but usually one hour-ish - and then the last twenty minutes is a Q&A. Every single person in the whole company can submit a question in an app, and then everyone else can vote on those questions. And when it's time for Q&A, they reply to as many questions as they can - starting from the ones with most likes. And so the five, seven eight-ish - the C-suite people are on stage. They do their best to provide the best possible, most honest answer to each and every question. And this creates a fantastic direct dialogue with the C-suite and 5,000 employees.

Len: And as I understand it, as well - at least at one time, Daniel Ek was actually writing these long email replies to questions that were submitted through some kind of app as well?

Jimmy: Yeah, that's a slightly different story. But, yes. Any unreplied question they get in the Q&A - they do reply to it together the following week, a week or something, yes.

Len: That's so great to hear about that. Of course, it's all coming from a place of goodwill - but this sort of theoretical importance, this kind of communication has for efficient and productive management of a company.

One thing I wanted to ask you about specifically, because you wrote a blog post about it recently, was the leadership health check, which I believe came from the squad health check that you learned about at Spotify?

Jimmy: Yes. I was working in this tribe in this department, and the leadership team. Of the tribe of 60, there were maybe actually 15 or 20 people that had some kind of leadership or management, manager title. We wanted to figure out how we can improve. And someone said, "What a second - we're having the squads do the squad health check once or twice a year, sometimes more often. Can't we do something similar?"

So, inspired by the squad health check, we developed a leadership health check. It's a set of questions - "Do you have a fun at work? Are you having healthy conflicts? Is there a clear vision of where you're going? Do you feel that you are aligned?" There's all these aspects of collaborating as a leadership team. So we did that, and it was brilliant.

And then later on, I developed this further, with the client I worked with after that - and to great success. That's when I realized, "This is too good, so this needs to be shared." Then, I wrote a blog post about it. I think that when I promoted it on LinkedIn, that became my single most shared LinkedIn article.

Len: It's really interesting - the ideas that you get, I mean you get leadership together within a meeting, and someone is nominated the facilitator, and you have these steps that you go through. Where everybody gets a chance to report on how they feel, basically, and not just how they feel, but how things are going.

Jimmy: Now there's so many great, interesting discussions that comee from this. One question is, for example, "What's your stress level? Do you feel you have plenty of time? Do you have the energy to react to fires - or do you feel like you're constantly firefighting, never have time to think ahead," and so on.

And people obviously have different experiences, right? So some might go to green, "Yeah, I'm good." Others might go to red, and that's when you have your really interesting discussions. Or even more interesting, "Do you feel that you have a clear vision that guides you in your prioritization?" If someone votes green, and another one votes red - well you have something to talk about. So there's no right and wrong, but they're obviously perceiving reality differently. And if you want to work together as a team, as a tight leadership team - you need to sort those things out.

Len: You're reminding me of something - I forget which blog post, or maybe it was even in one of your books? But there was this - I guess it was maybe a set of squads that were doing health checks. And the resources that were devoted afterwards, were focused on the team that reported the most unhappiness, and the team that reported the least unhappiness. Because it was discovered that the team that recorded the least unhappiness was the most recently formed team, and probably wasn't assessing itself correctly.

Jimmy: No, they were in the honeymoon phase, where people typically don't really speak their true mind, and it's superficial harmony and happiness. The important thing when you do these kinds of health checks or service or evaluations - it's not just stare yourself blind at the colorful numbers, it's the actual discussions that they produce. That's where the value is. I can even argue that it's not really worth the time to track progress over time, because of factors like this. The true value comes from the discussions, from the insights - and the actions people want to carry out afterwards.The agreements and actions, and the commitments that spur from these discussions - that's the true value.

Len: It's not my field, I'm a huge skeptic of projecting too much objective being onto data.

Jimmy: Yeah.

Len: People often think that - if they see numbers, or if the words like "data" are used, then it's sort of, as it were, "Nothing to see here folks, it's all straightforward and worked out." When actually it can all be an illusion, and not refer to reality at all.

Just before we go on to your books, I wanted to ask you about a working agreement. This was a new concept to me, that I came across in one of your recent posts, and I was wondering if you could talk about that - what is a working agreement?

Jimmy: A working agreement is a set of bullets that the team agrees upon, and the bullets describe, what behaviors do we want to see in each other? It becomes kind of our code of conduct. So it's a summary of when we collaborate, when we communicate. Both face-to-face, but sometimes there's a lot of communication going on through comments in tools and Jira or Slack or email and whatnot. So, when we communicate and when we collaborate - how do we want to treat each other? What's important for us?

In the blog post you refer to, I present a workshop guide for how you can do it. There's tons of different ways, that's just my way. And by the end of this one and a half two hour session, you typically have a bullet list of 10, 15, 20 bullets that describe things of value. And it could be simple things - like, "If you're late, if you know you're going to be late to meeting, let the team know." But it could also be more profound values such as, "Don't violently disagree, speak your mind." Or, "Don't use sarcasm when you comment on other people's code, because it's so easily misinterpreted." It can be things like, "We give each other feedback often and frequently, and we love it."

So it can be on all levels, whatever the team feels is important to bring up. And the value of actually doing this explicitly is that each and every bullet, you don't add a bullet to this working agreement - unless everyone likes it to be there. So you have a vote thing with your thumbs - and unless all thumbs are up, it doesn't go in there. Then it's left out for a discussion later. So by the end of this workshop, you know that all these 15 bullets that are on our working agreement. We all commit, we did all commit to those bullets. And that allows me to hold my friends accountable for their behaviors.

Len: Right, and that's because voting thumbs up doesn't just mean like, "I think this is a good idea." It means like, "I can actually satisfy the condition."

Jimmy: Yes. "I believe I'm capable of honoring this." That's the true power, because once you've got that written down - then you can start giving proper feedback, hold each other accountable for their actions and behaviors. And you have something to improve from. So now we have the foundation - and next time you have a retrospective or a team meeting, you can discuss, "How can we improve our working agreement further?" I think it's a super powerful tool that all people that want to work really good with their team, should take time to draft and design.

Len: Moving on, I'd like to talk about your Visualization Examples book. I really enjoyed reading it. One thing it made me realize was how little information was ever on display in any of the onventional workplaces I've worked in. I've come across, in some work I've done on other projects outside of Leanpub - the idea of things like Kanban and visualization. So there's all kinds of ways of visualizing work. For those listening, one way - and I'll just quote from the book, is - you can "Use boxes, lines, rows and columns to describe your workflow and which states work transitions between.” So you can imagine, in an office, there might be a wall dedicated to visualization - to visualizing the work that people are doing.

And the standard thing - well not the standard thing, but one very sophisticated approach is to have - it sounds like it's not very sophisticated, but it is - is to use post-it notes. And I learned from your book - post-it notes, don't use the cheap knock-offs. But the post-it notes can be different colors, which can represent different kinds of things. I've interviewed Alberto Brandolini about this, another Leanpub author. And you can have various columns that things move. You can imagine things moving from left or right, from proposed to completed. And then you can do all sorts of interesting things, and we'll talk about a number of those different things that you talk about in your book, that can get creative.

But the fundamental idea is that there's more to visualization than - as it were, just this. And you have this great line where you talk about how, in front of these walls, you might want to think about, say, using tape or something to make a little box for people to stand in. And you say, "I found that for some strange reason people like to stand inside boxes."

It's funny, because this is actually the tip of an iceberg of how you can visualize your work. You can use visible, tangible things in your workplace to transform it. Including lava lamps, for example. It's just such a charming idea that you can have, say, a green lava lamp and a red lava lamp, and they can actually be connected to your product. And so, red can indicate, "Uh-oh, the website's down" - or something like that. And you can actually see this light change.

I just wanted to ask you about a few of these ideas that you set out in your book. One of which is dotting, can you talk a little bit about what dotting is?

Jimmy: Dotting, oh yeah - that's a really simple thing. Imagine you have post-its moving through columns, just like you described. So they moved from proposed to plan, to doing review - and done, maybe if you're working in an Agile team - what you typically do, is you meet in front of this visualization board of your work every single morning at 9 o'clock or something. And you talk about, "What work do we need to push for today? What should we collaborate on?"

Dotting is the technique, of - at the end of every daily meeting, you take a sharpie or whiteboard marker, and you put the dot on each post-it, that is in the doing column. So if a post-it accumulates two, three, five dots - then you should be suspicious. "Is someone actually working on this one? Is someone stuck, do they need help? Is it blocked? Are we waiting for something?" So this simple act of dotting helps them become aware of the progress of work. If we're stuck or not, do we need to act?

Another brilliant thing is that, I don't know why - I've introduced this so many times, and I've never ever said that a dot is a bad thing. But for some reason, people hate it when their post-its are being dotted. They don't want it. "Oh, no, no - I didn't do anything today, please don't dot it." "I'm not counting your work, I'm counting days in progress." So yes, calendar days - there's no value. I don't put the value in the dot itself. But what people tend to do is they try to finish what they started. So I always prefer that. Don't start new things, finish what you started first. That's one thing. And they also tend to break work down into smaller pieces, and you tend to find simpler solutions, and it's easier to see progress and get a sense of a forecast and so on. So that simple thing drives so many great behaviors.

Len: It's really interesting, because one of the things you can visualize is, not just the tasks that are being done, but who's working on them as well.

Another thing you talk is having little avatars. So you might have little discs with your face on it or a cartoon character that you like, and your name. And then anybody - it's just so interesting, because when you think about what you do in a normal office, it's like, "Who's doing what?” “I don't know." All I know is that they're sitting in front of a computer, probably.

Jimmy: Yes.

Len: But with these boards, with avatars on them, you can see what the person is working on. Where they're jammed up, what they've completed recently.

Jimmy: And that is that is the true power of visualization, I think. It creates a shared reality. In most offices. as you mentioned - there are no whiteboards. There is no way of telling what's going on, who's working on what, what's the progress, what's important now? And so on. You actually need to go around and ask people.

But if you manage to figure out the visualization - with columns and rows and whatnot, with post-its - that's useful. Then the team working on that, or the project - who are working on that, with that, that becomes their reality. So when they need to discuss options or decisions or make plans for short-term or midterm plans, they need to be in front of that whiteboard. Because that is their shared reality. It becomes tangible, not something abstract. I think that's the true power.

And also - when designing this visualization, they have to agree upon the process itself. Because that's a weird thing when you visit a workplace and you ask someone, "How does this process work?" And then you ask someone else, you're going to get a different answer. For every single person you talk to, they're going to perceive the process or rules differently. But when you actually put them together, and ask them, "Please visualize together what the process looks like?" They're going to learn that they have different opinions about what's real and how it should be or shouldn't be. And they're forced to agree upon a collaborative way of working. So it reveals the discrepancies in people's belief of how it is.

Len: And one of the really interesting things is that, there's just so much that can be visualized in a workspace that conventionally is not. For example, what kind of work a person is doing. Normally, if you walk into a room, in say an open plan office - you see a bunch of people in front of their computers. But one person might be on Facebook. Someone else might be in really deep work. And one way you have a visualizing this is called a "flow glass."

Jimmy: Oh yeah. Quite often I encounter teams that say - or people, engineers, typically developers - that say, "Sometimes I don't want to be disturbed." So how about we - in our team, we have a rule. If I'm wearing my headphones, you're not allowed to disturb me. But how would I know if you're just chilling with music, or if it's intentional, right? Other teams have, "If I have my Star Wars puppet on my monitor, then you're not allowed to disturb me." But how can I know if actually, you put it there intentionally, or if it's been around there for three days, and you have forgot about it?

But if you have an hourglass, a physical hourglass - and the sand is running inside it - then I know that you intentionally declare that, "I need to focus. I don't want to be disturbed." You flipped an hourglass, and if I try to approach and see that the sand is halfway through - then I can maybe make a decision to take a step back and come back after 30 minutes. It's a super simple way of signaling to others that, "Please don't disturb me right now, because I want to focus."

Len: The next thing I wanted to talk to you about is - a lot of the things that you write about in your book struck me as ways to make the workplace a place that's happy and celebratory. And one of the things you talk about is release credits.

Jimmy: Yeah, that's a good example, release credits. One thing I worked with - we started having the habit of, every second week, when the iteration of the sprint closed down - we took five, ten minutes, and we chaotically wrote on post-its, things we were proud of from the last two weeks. And we had different colors. So one color meant we shipped something to our users, another color indicated something internally within our team. So they are different, the colors have meaning. And then the bigger the post-it, the more proud we felt about it. So a tiny post-it was, "Yeah, this happened." A huge post-it - A5 size, maybe - meant, "This is super brilliant." So it was one simple and great technique to celebrate your own achievements and build a sense of pride.

But there's so many more things you can do to do this. Because you're usually so focused on work and the next problem, that you rarely take time to celebrate the hard work you're pouring into it. This is a way to create a sense of pride, but also communicating to others what we are doing, and what we have achieved.

Len: IYeah, it's interesting, and the idea's from movies - at the end, when you finish a movie - most people leave, but there are these credits. Unless it's a Marvel movie, and you're going to get some kind of Easter Egg or something like that, but at the end of movies, you celebrate the work that people have done - and you say their name and what they did. And when a project is completed in an office - what's to prevent you from putting something up, celebrating what you've done?

Jimmy: I've seen a few teams that have the luxury of having a really great designer with Photoshop-magician skills, and he or she created a movie poster after each sprint. And so it was a kind of a characterized movie poster with the title being related to the work or whatever. So it's only internal jokes, but still that's another way of creating pride and celebrating.

I want to add that you're kind of referring to these ideas as my ideas. They're not, I've been collecting visualization ideas for many, many years. So I think 80% of the stuff I write about in my book, is things I've seen somewhere, someplace - and I thought they were worthy of being shared outside that place.

Len: Okay, I'll try and make sure to qualify my representations of things, so I don't attribute other people's inventions to you. I guess I just sort of naively - I learned about them from your book, so I thought they must have been by you.

There's this great physicality to the examples that you describe, one of which is concept cubes.

Jimmy: Yeah. Sometimes we want to convey information. So you've agreed upon something, or you want to convey information, or you want to teach something. One way is of course to create a PowerPoint or write an email. Or you create something tangible that you can pick up from the table.

So, a concept cube. So imagine a big, big dice. I don't know? One decimeter cubed, ten centimeters cubed. And you write your stuff on the sides of that dice. And it could be - - you could have the working agreement. You can have the definition of done, you can have good programming practices or whatnot. And the beautiful thing about this is that it's a physical thing that lays around in your office, in your team room. And it just begs to be picked up and read. I've used it a few times to great success. I love it. I haven't seen it much - but those times I've seen it, it's been really fun. People play with it, read it, pick it up, and create their own.

Len: Speaking of dice, you actually talk about dice. You've got examples of people using dice in the workplace - for example, activity dice. So if during a daily stand up - and a stand up is this idea of a meeting where no one's sitting down, to try to make it briefer than it might be otherwise - the one thing you can do is you can have - let's say, a set of six different things that you would typically do during daily stand up, but you would only do them once - this might be the theme of each particular stand up. And so you roll dice to decide what to do that day, to introduce this joyful, slight randomness to what you're doing.

Jimmy: Yeah, there's another use of dice where you, say every Wednesday, you roll it and the dice will tell you a joint activity. So clean up your area, or have a joint lunch, or go for a jog together - or something.

In New Zealand, I discovered another way to use a die. That team happened to be six people. So they rolled the die and the die presented a name, and that person with that name became "today's awesome person". And he or she got a hug and an applaud. Nothing more, just silly and fun.

Len: There's just so many great examples. Another one is - I don't know why this was my favorite one, probably because it's just so right. But you write, "Dropping balls in tubes is a fun way to visualize data." Of course - as soon as I read it, of course it is. And so one thing you can do is you can have people kind of vote on things or express some information about something by setting up these different tubes with different labels on them, and then giving people like balls to drop in a version of the dotting, to some extent.

Jimmy: Yeah, it could be anything, right? And so instead of sending out the survey or asking people to tally vote on post-its - you can have plastic tubes which you pour in plastic balls or ping-pong balls.

Len: It's just so fun. And again - before we got to the fun, I wanted to do the heavy lifting, to make it clear that this is all about community, a lot of it is about mood in the workplace - an enjoyable place to be, where you're empowered and all that. But another very serious layer of it, it's about communicating.

Jimmy: Yes.

Len: And in an empowered, Agile workplace, communication is - you make it fun through these kinds of examples. But it's the price you're paying for that empowerment and autonomy.

Jimmy: I would like to add one aspect. Many of the examples I provide in the book also help to shape new habits. So as a team you might decide that, "Let's keep the daily stand up shorter," or, "Let's pair up and collaborate more often." Or, you're trying to create a new habit. So having a visualization for that can help you make that habit stick. So in one sense, visualizations can be a great driver for improvement as well.

Len: Moving on to the last part of the interview, where we talk about your work as a creator. You do seminars and videos and things like that, but you also do books.

Jimmy: Yes.

Len: And I was wondering - I've got a few questions. My first question is - what attracted you to use Leanpub as the platform for your books?

Jimmy: I got it recommended - but I can't recollect from whom, many years ago. And I found a few books, and then when I eventually got the energy and the idea to write this one, the Visualization Examples, it was obvious for me that this is the platform. Because I love the platform. The reach, the ease of reaching out and for people to download them, and even buy. I love the whole ecosystem you've created.

Len: And you had a really interesting process for creating this book - so it was, the Visualization Examples book was on Google Drive, if I'm correct?

Jimmy: Yes. Initially, when I first got the inspiration, I have to open Google - I'm sorry, Microsoft Word. And I started typing, and I just wanted to try out a few pages and how it felt like, and then I sent it out to my colleagues asking for feedback. And I practically got none. And one of them said, "Well, it's impossible to give you feedback on a PDF, this is crap. I have tons of feedback, but unless you convert it into a format where it's easier for me to give you feedback, I won't give it to you." "So what do you want?" "Well, for example, Google Drive. It's easy to mark a text and add a comment." "Ah". I didn't like that, because that meant I had to re-do work.

So I kept on writing and then I was up to 20 pages. But then I actually started to rethink. Because, I'm an Agile coach. I preach iterative development. I preach fast feedback. I preach - have close dialogue with your customers and users. So, okay, fine, I'll move to Google Docs. And I did.

I copied the things I'd done so far. And I used Google slides, which is Google's version of PowerPoint - which allowed me to do more a visual design as well. So I wrote the book there.

And then pretty quickly after that, I even wrote a blog post about me writing the book - and invited everyone who wanted to be part of me writing that book to access the document. So yeah, I've wrote the book publicly, online - which was a scary thing.

So if you were lucky, you would actually see my typing, correcting, erasing, adding paragraphs and so on - live. And people were, I think at one point I had, I don't know? 500 people asked for access to it. Maybe more? 700, 800 people - of which a sliver, maybe 10% actually helped me out with fixing the grammar, improving spelling, making chapters more clear, pointing out confusions or, "What's going on here? I don't get it. Can you write this in a simpler way?" And they even proposed some examples, which I later on added.

So, from being something scary, meaning - I published my work as I'm creating it, right? Usually, I imagine authors want to get it perfect, polish it before they present it to the world for judgement. Because feedback is a scary thing. So that was scary in the beginning, but then it became a life of its own. It almost because a community where the contributors or the people commenting, they started having chats about whatnot. So the discussions derailed into other things.

It was brilliant, and it also gave me a push to move on - I already had a fan club that helped me and encouraged me to move on. So, I loved it. And I'm actually writing a new book in the same manner right now. It's been on hold for six months, but I will continue after summer, I think.

Len: That's a really great story. Thank you for sharing that. The experience that you're describing is kind of one of the reasons Leanpub exists. But I think yours is the first story I've heard of someone who may have been - where they were writing and people could have seen it live, if they sort of happened to be there at the right time.

One thing that many people who we've talked to over the years have discovered is that, the right reader wants to help you. They want to help you. They feel good about it. They don't feel like you're taking work from them or something like that. They want to contribute. They want to help improve it. It might sound kind of trivial, but as a reader of something - there's nothing more, I don't know? Not exactly exciting, but, it's very fulfilling to find a typo and tell the author and have them correct it. Almost in real time.

Jimmy: I experienced that too. Some of the people helping out, they were really passionate. And several times a week, they checked in to see if I've written something new, and they helped me proof it. And of course, I added the acknowledgements to those who contributed the most in the book as well. It was really fun to give back. So no, I love that process, even though it was a little scary in the beginning.

And I made a couple of decisions. One was not to go with a publisher, because I just wanted to get it written and out there.

If you go with a publisher, you're going to get their feedback, which you have to act on. They're going to take on - in some cases, they take over the creative control you want to have - and so on. I just wanted this to be good enough for it to be released. So that was one thing. And then I didn't want it to be perfect. I wanted it to feel playful and fun.

But one thing that really scared me in the beginning - if I'm actually writing my book online, will anyone bother to buy it once it's completed? Because if people have access to the next page I'm writing all the time, what's the point of buying the full book? They already read it.

But that turned out to be wrong. Those who were involved and saw the progress, they were my promoters. They were the ones who told their friends, and -

Len: It's really interesting. One version of that experience that we've seen over and over again is people might make their minimum price - so Leanpub books can have two prices set for them, a minimum and a suggested price. You can set the minimum price to zero, but then you can have a suggested price of $10 or whatever. And one thing we've seen over and over again is people who get a book like that for free, and then they're like, "Hey, I want to pay for it now. Now that I've read it, I want to pay for it."

Jimmy: Ah, but you don't have that feature.

Len: We don't have that feature yet, but what we do is a workaround, which is just buy a new copy and then you can archive one of the two copies that you have in your library, so you don't see two. So it's a bit of a workaround. Eventually, we will have that.

But yeah, I mean - it's the inversion of an old prejudice that we have about the marketplace and money, that if someone can get something for free, then they'll never pay for it. It's just not true.

Jimmy: One thing that surprised me is that some people decide to pay even more for the Leanpub version than the physical copy. I actually sell a physical copy of the book on Amazon as well. Some people choose to pay more for the digital PDF version. Which, I can't hold it in my hands, so I guess it's their way of showing appreciation.

Len: It's funny - I love physical books as much as the next guy with a doctorate in English literature. But in many ways, an ebook is far more valuable. I mean, if you could say to someone, "This book will take up no space and you can read it anywhere at any time," that sounds like a magic book, and one you might - I guess you could probably get a sense of what I'm clumsily getting at, which is if you described - omagine you have a book you can search. Who wouldn't pay for that?

Jimmy: Yeah. I agree.

Len: But of course, we all know that it costs nothing to produce a digital copy of something - which is why we don't see it as being worth as much.

So, this is where we get very much into the weeds. You've used our Bring Your Own Book feature, which is what we built to honor the fact that every author has their own process, and they might not all want to use the processes that we provide. How do you produce your PDF's?

Jimmy: This is super simple, this is embarrassing. I write the first version on Google Slides, online. That's not the best layout. So once I'm done, I copy paste the text into a slightly better tool, Microsoft PowerPoint. Because I'm a PowerPoint magician through all my seminars and trainings. So I do my layout of the book in PowerPoint. And then, in PowerPoint there is a function that says "Print to PDF". So that's how I create my PDF.

Len: I wouldn't say that's embarrassing at all. Any process that you have that works for you is the right one. And everyone has their own tools that they're good at, and that they enjoy using -

Jimmy: Yeah, they will.

Len: And so some people just want to write in Google Docs. Some people - we've had authors use PowerPoint to produce books before. One of our bestselling books has a million words in it, and it was made in Microsoft Word, and the author hits "Export as PDF".

Jimmy: Whatever works.

Len: Yeah.

Jimmy: When I explain that I'm using PowerPoint for the design and layout - graphic designers or people who work with print, they get very upset. But I like it. It's simple and nice and playful.

Len: Yeah. And actually, one thing I wanted to ask you about, is, your book has been translated into five or six different languages already.

Jimmy: Yeah, maybe even more.

Len: How did that come about? Did people approach you? Or did you approach other people?

Jimmy: People reached out to me. They found me on LinkedIn or found out my email. People reached out and I have the same deal with everyone. That seems to be good enough, because I have more translations on the way. I just tell them that, "Yes, thank you for reaching out. I would love your help to translate this book to your language. And we simply split the Leanpub profit 50/50. The only request I have is that once you've done - once you've completed your translation, you send it out to four reviewers. No friends, but colleagues in your business in your country, and you act on the feedback. Acting means disregarding or correcting, but you need to act. You need to consciously go through the feedback. Once you feel you've done that, then we publish it on Leanpub."

Len: My last question about your books, is - they're full of illustrations. And these illustrations have words in them. So did you have to redraw the illustrations to accommodate different languages?

Jimmy: Yeah, I've done that twice. I'm not going to do that again.

Len: Okay.

Jimmy: And when writing my new book, it has also a lot of illustrations, but I've learned the hard way that you shouldn't draw text. Add text afterwards in PowerPoint, so it's easier to translate. So no, I've redrew on the text twice, and it was just too much work. I'm not going to do that again.

Len: I sort of double checked to see if you'd done it and I think it may have been a Spanish translation. And I was like, "Wow, that - if that's truly what happened, that must have been a ton of work."

Jimmy: And I don't even know Spanish, so it took forever.

Len: I bet. The last question I always like to ask people on this podcast is - if there was one thing we could build for you, or one thing we could fix for you, is there anything you could think of that you would ask us to do?

Jimmy: Yeah, but this is a big one. I would love - the thing I achieved with writing in Google Slides, meaning that people could simply request access to the document. And they can see me writing it, and they can add comments to pictures or text. But this is not a simple fix, right? This is a huge ask. But I would love to be able to do what I did on the Leanpub platform. Because it was so much fun, and I think it tripled the quality of my book. If that could be integrated into the platform - that would be, I would love that. But that's not a simple thing, I do realize that.

Len: That's great to hear that. I mean, helping - publishing books in-progress and getting feedback early on is one of the reasons we exist. And facilitating that kind of collaboration is part of our big vision. As you say, it's hugely complex to do. One way we've accommodated that is that actually - I don't know if you know this, but we have a Google Docs writing mode now. It's our most recent writing mode. What you do is you create a book on Leanpub, and then we automatically set up a folder in your Google Drive with some template Google Docs in it. And then you can actually write your Leanpub book using Google Docs, in this folder in Google Drive - and then just click to preview and publish right from there.

This is not Google Slides, but we actually already enable you to use Google Docs to do this. So you can get all the benefits of the collaboration you're describing, and still be hooked into Leanpub and generate PDF, EPUB, and MOBI and all that kind of stuff.

Jimmy: I didn't know. That's brilliant.

Len: We're pretty excited about it. People are still kicking the tires, that kind of thing. But we've had a couple of books made from it. And yeah, this idea of having the book kind of "live" for people to comment on and see changes in, is something that we're really excited to see.

And also - it's tooting our own horn, but it's pretty magical. If you know how to use Google Drive and Google Docs, the idea that you can produce your book and have it for sale, like an updated version in a bookstore by clicking a button, using Leanpub's Google Docs Add on, is pretty amazing. So we're really excited to see where that goes.

Well, thank you very much for that feedback. And thank you very much for taking the time out of your evening to talk to me and to everyone listening on this podcast. And thank you for using Leanpub, and being a Leanpub author.

Jimmy: Thank you so much, it's been a pleasure.

Len: Thanks.

And thanks as always 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've found it. And if you'd like to be a Leanpub author yourself, please visit our website at leanpub.com. Thanks.

Podcast info & credits
  • Published on August 9th, 2019
  • Interview by Len Epp on June 18th, 2019
  • Transcribed by Alys McDonough