Johanna Rothman Interview - Agile, a Decade Later
12 years ago I interviewed Johanna Rothman About managing people and her then new book “Behind closed doors: secrets of great management”.
A few weeks ago we ran again into each other on twitter and decided to see what changed in the decade that had passed in our views on management, agile development and everything in between. We decided to record a new conversation, and here it is.
You can listen to the result or download the file above above (1 hour and 15 minutes).
I’ve also did an auto-transcription of the interview below. It’s not perfect but it’s good enough to get the information out. When I get more time I’ll try to smooth out all the rough edges in the text..
Some of the topics discussed:
Teams and Iterations then and now
When to use flow and iterations
Agile grey areas and zombie lands
Convincing managers
Agile Scaling Frameworks thoughts (SAFE, Less)
Products vs projects
Choosing what to work on
Program Management
Collaboration on remote teams
Managers collaborations and metrics
Challenges in transformations
Product manager vs product owner
Types of documentation
Theory of Constraints, Kanban and Agile.
Writing skills
Lean Publishing
Relevant Links:
Johanna’s website: https://jrothman.com
Johanna’s Books: https://www.jrothman.com/books/
Johanna’s blogs/articles: https://www.jrothman.com/articles/
Interview transcription:
Roy: [00:00:08] Welcome to the big interview where you had a rough man 12 years later. Joanna Nice to see you again.
Johanna: [00:00:18] I'm great. And it's so nice to see you too. And 12 years ago we did not have this technology. We actually had to meet when I was in Israel which was not a problem but.
Roy: [00:00:34] People and interactions over process and tools
Roy: [00:00:37] As they say it's a new world though it's a new world. Joanna is currently in theU.S. while recording this. I am here in the near Tel Aviv in Israel and we are going.
[00:00:56] We were we were kind of you know you and I we got we we spoke via Twitter and we realized we haven't spoken in a long time. But we still have a lot of the same interests. And in 2006 I know we got to I got to interview you all about agile process and leadership and a bunch of project management stuff. And we thought it would be a great idea to do like 12 years later. How have things change. Interesting interesting thing we've we've learned and you know just to have an interesting discussion. So why don't we just get started. So.
[00:01:39] You know your'e a very successful author and trainer you've written a bunch of those as well. What's your latest. Just by the way I just wanted to make sure to get that out of the way. Maybe we can use it in the conversation as well.
[00:01:52] So the book that I'm finishing right now with Mark kelpie is "from chaos to successful distributed agile teams- collaborate to deliver".
[00:02:04] Wow. Yeah. Yeah that geographically distributed agile teams because it's really.
[00:02:12] Boy oh boy people really have trouble.
[00:02:16] So we can have we're like have a conversation about why you know why you ended up writing that book etc. Before that though I want to go back to you know 12 years ago we had a bunch of discussions but when we look back in the past decade.
[00:02:36] What have you seen changed in you know in the agile world and project manager management world. You know in the past 12 years so we so you know I'm sure you've seen things change and working toward specific areas cetera.
[00:02:50] So what are the main main things that you see that have changed.
[00:02:57] So when we first spoke all those years ago it was. Relatively easy to have a month long iteration. Right that that teams only worked on one project at a time maybe a little support for that product for that product that previous version that was out there. But. It was OK for teams to work on something for a month they could actually define what they were doing for the next month. They could develop and test it and it was it wasn't easy but it was doable. And now the pace of change is at least every two weeks very very few teams I meet are doing a month long iterations and often the teams are not working on just one project at a time. They're working on a little bit for this product and a little bit for that product. All this stuff and and of course support. And they're still trying to use iterations which I find so interesting that they're they're using a tool that does not really lend itself to the problems that they have.
[00:04:15] So you don't see it as a positive you're seeing the team stress themselves to a point where it doesn't make sense to use the currents and say the rituals that they used to use before.
[00:04:27] I'm not saying it. I started to see this I think about it must have been about 2010 or 2011. I've been teaching my version of an Agile class which is not SCRUM specifically is specifically the KANBAN method. It's more a mashup of when to use iterations versus when to use flow. How do you estimate when should you not estimate. I mean all that stuff right. You know me I've I always had my own version of everything and I found that when I taught that people said oh we can use like this from column A and that from column B and that from Column C to be successful. Now we don't have to try and do what the frameworks are saying that we have to do because the frameworks are not really working for us but we thought it was us not that we were trying to misapply a tool okay.
[00:05:30] So when you teach that for example that it's really interesting to me because I think that's something that a lot of teams struggle with. When you teach when to use flow when to use iterations what would be some of the major deciding factors like that.
[00:05:48] So if if it's possible for the product owner to not change his or her mind and if it's possible for the managers not to inject more work into people on the team then iterations might be a great opportunity to manage the WIP the work and progress. Right. Because every. That's the whole point of agile approaches manage the WIP, finish stuff so you can changing on to the next thing. But if you can't can't do that if the product owner is under a lot of pressure from customers or the product managers or or whatever and the managers are not capable for any number of reasons of managing the project portfolio. So they ask people to do things they're injecting work into the team then yeah don't don't use iterations use flow. Yeah.
[00:06:48] Do you find it that. It's a challenge for teams to move from iteration thinking to flow based thinking is that you find it to be difficult or easy to move a team from one to the other. I'm sure people aren't so comfortable with changes.
[00:07:06] So it's firstly the change and partially. Somebody said to them you have to have this board and it's a SCRUM board. And it's an a tool regardless of their location. Let me roll my eyes a little bit more and therefore if they can if they have no control over the tools that they use and they only have access to a scrum board and many of the tools do not allow you to easily move from a SCRUM board to a KANBAN or from a KANBAN back to a scrum I mean it's just columns.
[00:07:43] I don't know what the problem is just columns.
[00:07:47] So so so I'll play devil's advocate for you for four minutes and I'll say that in the past decade or maybe five or six years before you know in anger almost that I got the chance to work at some of the biggest companies in the world. You know you have a lot of experience with huge companies and you know what I've noticed is of course that's when we're dealing with enterprise. There is there is no black or white. There is just a lot of very very different shapes 5000 different shades of gray and so less so what we would end up with is you know we're trying to change something. Is we would end up with a company that has no policies and rules but also going through transformation.
[00:08:43] OK.
[00:08:44] So it seems to me that you know since transformations take such a long time there. There will be a period of time which is not a few weeks. It's probably a few months to maybe a couple of years where the teams will have to work with the tools that have been dictated while management kind of makes up its mind of what they really want to enable them to do. And so in that area grey area like a zombie land where you kind of try to move that but you're also kind of forced what are some of the techniques that you like to use or that. Now the ways that you try to accomplish you know missions of transformation. Or do you just say you know what if that's the case. Well it's there's nothing to do here. Move on to a company that's either smaller or it has already done the transformation and mindset change. I would say that. isn't most of our work as consultants to help the company kind of understand what it really is trying to do which means we live in a gray area most of the time.
[00:09:53] You're right. Sorry I appear to be. Having allergic to questions.
[00:10:02] yeah....
[00:10:04] We'll see how I do. You might have to edit this. OK. So. I think the key is. When when a company says we will have we will define our processes for all of our teams and all of our people even though we want to use an agile approach which is based on change I mean I actually.
[00:10:36] With a contradiction there obviously. Q When you encounter this contradiction which you will in your life what are the steps that you take as a consultant to try to solve this contradiction.
[00:10:49] So I asked them what what value are they looking for. And they often say I want to see velocity I want to see the burndown chart and I say. Okay. How what what decisions will you make .
[00:11:05] Who are the or the people addressing those questions.
[00:11:08] So first I start with the first line manager. It's almost never enough. Right cause somebody over there. Decide that. But I asked for the first. I asked them the very first person who might be able to change it.
[00:11:24] So is that usually what product owner or project manager scrum master or someone else.
[00:11:29] So it's often not anybody in the team are associated in the team. It's often somebody above the team. And so in the end what they often say to me is we really want to understand that the team is making progress and I say can you go to their demos can you watch the software being built. Well I'm a busy person I don't have a lot of time. I say OK so how often could you go to their demos. Could you go to their demos once every month. Would that be sufficient. Well I knew really. I really need this to report every week and then I go back and ask them the question again What are what decisions will you make based on this data. Well I just need to know that they are doing their job right.
So we go into this little circle think and after we go into this little circle thing before it really becomes an infinite loop I say to them. So you you're telling me you want to know that they're doing their job. I'm suggesting that you can go watch their demos. You're a very busy person. And so watching the demos does not really seem to fit for you know how about if they recorded that demos and you could watch them at Twice speed.
I mean how long could a demo possibly be for what you're interested in or what would you like to say the roadmap narrow so you can see what's actually been done. Or would you like to see a different chart such as the product backlog burnup a chart that shows you here. Here's how much was in this particular feature set. The team has done this much and then they do this much and then they do that much. So you know that that feature set has done and then that's when they start to say oh maybe some of that would work. Especially that product backlog burnup chart.
And I say them the product backlog burnup chart has nothing to do with velocity and nothing to do with the burn down for a burnup right because it's for their product. And what you want to understand is what is the product doing not what this team has done for given iteration. Given whenever. And then when we figure out what they really want these people want something they have a right to ask for it. Can we offer something else that will be reasonable. And then if we can offer something else that's reasonable how can we shift them so that the team now has the capability to change their own board.
[00:14:35] So from there to the capability. So I had a few interesting discussions with the various managers in various roles and a lot of them seem to have a fixation on and I realize I'm using this session as Q&A for my own special needs. But hey this may be useful to other people listening as well. A lot of managers that I see live in a hybrid world where on one side are using agile metrics such as burned down but then they'll put in old fashioned managerial spin on it for example instead of measuring velocity in points. They'll still measure velocity in time and they'll even try to measure that per person in the team because they want to try to optimize right. And I've had a lot of you know sometimes even tough conversations about it with people and I find that a lot of it goes back to the education that most people have had with a specific way and once a person believes that this is just the taylorist way of managing people in the way of you know optimizing each percent. You find that deep is the only way around that is just take all these managers and leaders and put them through like a training workshop and just say ok brain time everybody or you think that there is kind of an incremental way to slowly get them to acknowledge that there is value. Because I can see what you're doing with what you said before.
[00:16:13] But the reason I'm asking this is because sometimes by having those hybrids we actually might get even worse results because the measurements will actually hurt the behavior of people such as you know we're measuring coverage. And so what we're going to get is coverage we're not going to get quality just going to get coverage. So that's an example of no measuring velocity of a specific person in a team and by name would only hurt performers that person or being you know being named for something. So what do you think is an incremental way or is it like OK everybody hold the boat there is no other way but we all get together for a day just talk about this needs to change and the order needs to come up from about above that no longer is discussed. What do you think is the right way to go about that stuff.
[00:17:09] I would love to have a day with managers and brainwash them.
[00:17:14] they have A lot of time right. There are a lot of free time.
[00:17:15] Sure yeah. So so I have yet to have that day. I often have an hour. Sometimes only 30 minutes. So I say to them. Let's talk about what you want. Do. If you if you have to compare what one person does versus getting the product out the door. What you really want. And they almost always say their product at the door and I need to know that that person is working.
[00:17:47] I say OK but let's assume for now that that person is working but the product at the door is what gains your revenue or keeps a customer or acquires a customer or something like that minimizes waste right whatever. Whatever the metric is so I say I'm not sure you know about this but the best way to get the product out the door is to have the team work as a team. I'm not talking about that mobbing stuff you don't have to do that mobbing stuff although it would be really great in that team doesn't have to pair. But the more the team collaborates together to work together as opposed to separately then you don't incur a cost of delay. Now notice when I said I actually used the word cost of delay and every manager's ears perk up kind of like bunny eears right cost ! delay!. We know that those two things are bad.
[00:18:51] So then I can talk about the issues of cost of delay where when people multitask when they're not available on other things. Right because they're they're spreading out say they are not focused on this one particular project. That means that they will be cost of delay while other people wait for them so I I walk them through the thinking I don't actually show them any of the graphs that I have. I don't show them value streams first I don't talk about cycle time First.
[00:19:28] I specifically talk about the things that matter to them and what matters to managers is accelerating the rate of what they think is production. How fast can they get the product out the door. How fast can they acquire another customer. How fast can they retain a customer. How fast can they get rid of waste. So all of those things. And that's where I think that we in in the agile community really can use our knowledge flow and cycle time and flow efficiency and optimizing up at the team level and then optimizing up at the product level. Keep keep moving up. What what people think of is the hierarchy to really make a change and.
[00:20:21] And then then the manager says to me okay I get that for the agile teams but I got all these waterfall teams. What the heck to do with them. And I say ask them to release something every three months and they say yeah and I say you can take a cue from the release train people. Right. We often did release trains back in the 80s released trains are nothing new. I think I first started to use them in I don't think it was 79 but certainly 82 Yeah.
Roy: [00:21:02] So you're referencing the release trains that exist today. A lot of people who hear about really strength from SAFe from Scaled agile framework. So you're saying that the term is not new. Do you think that the implementation is new in some ways. There is no novelty implementation or is it really going jumping the gun a bit. No one is looking at these new frameworks that have come in in the past few years such as Scaled Agile framework and large large scale scrum which is called less cetera. Did you find that these things are more just a rehashing or a real you know modeling of existing you know Frankenstein of multiple things or are there any kind of innovation there. What do you think about those in this context.
Johanna: [00:21:58] So I am not a fan of any of the scaling frameworks because when you scale a process you end up with more hierarchy and more control points. As opposed to more autonomy for the teams.
[00:22:14] Now I will tell you I mean you know one of my books says Agile & Lean program management Scaling Collaboration across the organization. So I take me we had this perfectly good name which is called program management which is how the core team Sheppards the business value across the organization making sure everybody does their job is legal doing theirs a sales doing there's it's deployment doing there's right everybody has to do their job.
[00:22:46] And then the software program team which is infinitely scalable assuming you use small world networks where the teams say honor really need to be at that program team meaning I'll either ask Roy or I'll ask Johannah or or I am part of another small program that is part of where 1 person goes and they tell me what's going on and their job is the program team's job is not to do Stanis but to resolve impediments that the team members are linked to enough in the organization that they can figure out what's going on for themselves. So yeah. So it's a different approach it's not a scaling process it's scaling collaboration. And when you have a framework especially SAFe which I have to admit they keep updating the picture. I don't understand the picture. I'm kind of a smart person. But the picture is too hard for me to understand. So I might not get it but every time I see a really good SAFe implementation it's terrific RUP it's a wonderful rational unified process. It's it's really outstanding at that. But for me that's not enough change. No no no. Yeah I don't to do that.
[00:24:21] I got the chance to work with a couple of organizations that have implemented or are in the process of implementing SAFe and we're talking about really larger orgs here. Hundreds of thousands of people. Yeah. And what I've seen you know a couple of insights that I've had is first of all what's safe seems to be doing right is that it gives a good enough excuse for waterfall people to adopt Agile because it basically is kind of or at least it tries to be in some way agile wrapped in bureaucratic flow which basically means here is a different waterfall but it's really hiding inside of it. A lot of agile processes. So it's like oh do you need a chart for this. Here's a chart for that for Extreme Programming or here's a chart for a SCRUM team that tries to get you know burn down or whatever. Here is a communication issue. OK so now you have a booklet that you can go and open. So you know what to do with this specific step.
[00:25:33] And I think in a way that's kind of like braces or you know when you're trying to walk his project it's like agile with crutches. But and in a way it tries to solve the problem of connecting the dots in larger organizations that are trying to move forward in a specific way and maybe it is rough in some way. What I've seen in latest latest version is that it tries to adopt a loop at least at least in some way. A lot of it sucks in a lot of these concepts like continuous delivery et cetera. And he said ok no this goes right here. And then he can do that. So it's kind of like an excuse he's like get on the train and then we will give you a chance to work in an agile fashion.
[00:26:21] Now on the what on the other side what I've seen is in a larger organization the problems are the same problems which our teams live in a bubble and that even if you are part of part of an agile stream the communication patterns are still broken especially in organizations that do a poor job of getting everyone on the same mindset. So I've seen teams that are part of an agile released train and are stuck on something and they think that they have nobody to turn to. There is nobody to help with the impediments. And then there are these specific you know. First of all we're talking about PIs which is you know program increment. We're talking about three months increment suddenly again. Somehow this has become another waterfall base something. And so it takes three months to change something technically SAFe has a way to change things in the middle. And there are special buffer iterations in the middle to handle that stuff that requires communication between people that have special roles and in organizations.
[00:27:30] What I see is that those roles are not always implemented by people either not at all or by the right people. So there is nobody to turn to to fix impediments on time and so suddenly you say I guess that waits for the next PI. And that really hurts because there is good but maybe it is an impossible equation to solve. So maybe because what I heard you say is like the org is too big. It's not going to work. You have to go back to the words of agile at agile really works in small teams. So what does an organization that has a huge you know huge software project ahead of it try to do when it's you know does it just say no we're just going to build this whole huge thing in a very very thin you know light line and just a small set of people is just going to build it. It is going to take probably longer but it's going to be managed by a smaller set of people. Or is there a way to you. I would say divide up the work is that's an implementation detail. But is there a way to scale a large software projects in a large org.
Johanna: [00:28:42] So I've used the program management. Like I wrote about it for only about five or six hundred people on the program not thousands. only 5 or 600 so we had many many teams. And I think I think one of the questions I have for people is are we dividing it up by products. Or by function. Because when we take a product perspective. We often discover we have fewer people. Than we thought we needed. So. Maybe that's one way it may be. I mean look if you have 12000 people working on one product I suspect you have several products there. Right. That's I mean that's just not been my my experience now. I I haven't experienced everything. I mean I have been I have worked with very large divisions of very large companies where they had anywhere from 5000 20000 people in a division. But that division had several products or more than several. And I what I keep seeing managers wanting to do is make progress on everything all at once instead of picking and choosing. This is the project portfolio problem that it's so difficult for and especially I think in larger organizations who do you even say no to. Right. You get work coming in over the transom right. People kind of lob work at you and you're supposed to start on it. How do you actually say no to something if you if you can't even tell who the stakeholders are.
Roy: [00:30:46] So how do you. So you're saying that right now the best way that you see is a traditional program management and core team that kind of directs like the firehose in a way this is now the word goes out way. Now the word goes our way and this is the direction that those companies they kind of a traditional view in a way it is a hierarchical top down view. Is it does it does it include some of the same issues of kind of cause that can cause I got the chance to work in a in a place that kind of has like a core team and management team not doing agile specifically. And I remember just all the different meetings that occurred and nobody really knew what everyone else was doing. And like three people at the top and everyone else was just kind of working in the dark. So I don't know what I'm working on ask that person. Who just knew maybe 10 percent more. And then it's like Lego pieces. So that's the intimidation in my head when I hear program management. I didn't read the book that you wrote on that specific subject. Obviously that's OK. Yeah but I'm sure you know that a love to hear as well.
Johanna: [00:32:07] So when I think about program management I think about enabling the teams to deliver their work. It's not that their program teams control everything and especially not knowledge. The program teams enable . They clear impediments across the organization. So I I have been a part of several programs where they had multiple program teams not just the core team in a software program team but several software program teams and several core teams. I felt that that was kind of crazy. That was that was more hierarchy. But if you don't have a lot of hierarchy how can you arrange this . And that's my whole perspective.
[00:32:58] If we go back to the very large organizations I think that one of the issues is what is driving their desire to be to use an agile approach. What is it that they want to get out of using an agile approach. And often they say to me it's time to market. So or time to release or time time for something they almost never start with technical excellence. So if it's really about time then how can we then possibly the very first thing they do is just divide up they're very long releases into 3 month chunks. I mean that's what I did back in the 80s and the 90s now except I did one month chunks.
Roy: [00:33:49] Do you think it's like an agile slippery slope if you can do three months you can two months maybe into one month as well so the skills grow because of that because of the ability to just split and slice these that you're looking for them to grow. What is this skills that's missing in the organization to become faster in a way.
Johanna: [00:34:10] So I think I think there really big skill is this notion of collaboration as a team. Right. So many people have and market nine knows this when we were writing that geographically distributed agile teams. Look there's so few teams actually collaborate as a team. They they are so affiliated with their functions right the testers feel pulled back into a test. The developers feel pulled back and doubt that they don't collaborate as a team. And I think if the one thing we could do is help teams figure out how to collaborate as teams then all the other stuff might fall into place. I'm not sure if it would really fall into place but we would have a much better shot now.
Roy: [00:35:04] So obviously there are you know there are many impediments to teams working collaboration, a lot of it is not people not wanting to do it. A lot of it is you know the system itself is built in this specific set of rules of what's allowed and what's not allowed. So for that to be enabled what is a skill that is you know management needs to adopt to be able to you know allow teams to collaborate better.
Johanna: [00:35:33] So I think that there's a mind shift that managers seen managers actually need to collaborate among themselves. Managers too often are pitted against each other which is exactly the wrong thing for any organization. Why not have managers collaborate for the betterment of the entire organization.
[00:35:59] And so there. Is the collaboration mindset the experimentation mindset. I am continually astonished by how little experimentation managers do. Right. I mean I knew I did not know everything about management and I would actually say to my teams either or one team were an entire division. I want to experiment with this this month. I need your help. I need help with this data. You know I I am asking you to gather this data from me and some people really wanted to prove me wrong. And some people help me but I learned an awful lot by experimenting.
[00:36:49] I guess the third thing is really seeing the whole . If we if if instead of looking in our fiefdoms as managers how can we see the whole and ask how can we better at the entire organization as opposed to the whole. Now there's a huge problem with me with the way managers are paid and incented. Right now they're incented on their own narrow piece and they're incented as a zero sum game. So it's not a win win for everybody. It's I WIN YOU LOSE. Which is crazy.
Roy: [00:37:30] So do you think that the metrics that we use can help you know adopt some of those new skills. So for example what are some of the metrics that men want to look at were being measured by to enable more collaborative behavior.
Johanna: [00:37:48] So I'm actually starting to right the agile management book and bits and bits and pieces. I'm running it as a novel. And I think that one of the incentives is how can you coach and mentor others and how can you help the entire product. move along so I'm not so sure we need to move to product based organizations where that projects are no longer useful. I find their projects are very useful because I don't know but I'm sure you and I have the same problem. I have more projects than I know what to do with. And there's really only me and any outsourced people I have as part of my team. So I want to be able to start and stop projects so I finished stuff and I release stuff.
[00:38:45] I might not be able to do all of it all at once but I can do something that's good enough for now and then move to a different project. And I think a lot of organizations are like that too. They have more stuff than they know what to do with. But how do we help managers collaborate with with a product management function and say how do we carve off enough now of this product to create a project so we can start it and finish it and then go on to something else. So for me it's all I probably not articulating this very well but it's how did we see the whole for the organization. And then how do we help whatever piece that is move forward and get it done.
Roy: [00:39:36] So as a generic idea that sounds amazing but what metrics measure those things well how do you know. I mean because in the world that I'm you know at least familiar with in some way the world of software which are also big obviously are you can kind of measure the output of the system by you know deployments to production you can measure escaped Bugs you can be you can measure you know lead time from one point to another etc. So there's these are for example metrics that to me but it encourages the sort of behavior that will eventually lead to that.
[00:40:20] But how do you measure that someone for example is mentoring or coaching other people or what are kind of maybe it's just impossible. QUESTION But do you need. Maybe you don't even. But is it makes sense to look for a metric that says if that number goes up or down I know you're doing a better job of doing that.
[00:40:45] So all the that is before you answer. Yeah I don't know the name of the speaker but I know that I'm in Norway. And he talks about the fact that everything is quantifiable you can measure technically anything you can even measure love in a way by you know or you can measure how much a customer likes your product by you know either how many clicks there are in something specific et cetera et cetera. So can you quantify you know coaching or something like that there are many. I'm wondering what you think about that.
Johanna: [00:41:20] So was that Tom Gilb. Yes. Yeah. Yeah that's one of Tom's things I do. I don't know the answer to this yet. And there are pieces of it. I think that there that there are ways to think about this. First is throughput how do we measure cycle time lead time for an entire organization and my experience is that as I learn as I get better my throughput goes up right now it does not go up evenly over time. So every book has a different number of weeks or months or years to point out. But I am I am better every single time I work on a book.
Roy: [00:42:11] yeah. So your velocity increases.
Johanna: [00:42:15] Yeah. Yeah. So you might think about cycle time you might think about throughput any of that might be helpful and that's some of my learning from all of my previous experience and some mentoring and coaching and classes and whatever. So I think that there's something about the throughput or the lead time for a for an organization. And the problem is if you're working on a 100,000 person organization that number is meaningless. You have to come back down to our product level. Right. It's just you yeah you have to make it reasonable in some way.
[00:42:59] I think that there's also something about the number of questions that you ask and answer and the number of decision points. How often did you have to insert yourself into what decision point and how often does a team successfully make that decision without you. Yeah I think that this is very scary for many people. But the only way for people to learn how to take more responsibility is for them to do it.
Roy: [00:43:35] Now I fully agree that. To me that really brings about. You know when I when I talk about the elastic leadership I can say you can measure your effectiveness as a leaders by how much a bottleneck you are. So the more you are needed the less effective you're actually you actually are in coaching other people etc. So you can literally measure and that's qualifiable thing how many questions do you get from people where those people could have you could have taught that person to solve it or enable that and solve it versus how many that you really are the only person who could have solved it and either one of them is an important number because one of them is a systematic problem and the other is ta coaching problem. So I think I really connect with that as well. Yeah. Okay cool.
[00:44:27] So actually given all those things right with all these you know grand gestures of trying to change organizations. What are some of the biggest challenges that you're facing these days. Over the past few years with customers. Well what are the things that you find the most difficult to tackle as an agile consultant that you know seem to be either repeating themselves in one variation or another or there was that one time that you know has not happened again but you're not sure what to do about the things that stumped you in a way. I'd love to know.
Johanna: [00:45:09] So. The biggest problem I see is the product owner problem and that's because we are product managers. And product owners who work with a team and too often those people are the same people. So that product owner does not spend enough time with the team or the product owner spends so much time with the team that's a PO stops being. In touch with. What the customers want or need. And that I think we have a real. Product. Management problem where we have to have the strategy for the product at the organizational level. We need the tactics and the team and sometimes we need actually help creating stories.
Roy: [00:46:07] Would you mind For my benefit and maybe other people listening what do you see as the main difference or definitions of product managers vs PO as I see a lot of confusion with a lot of organizations myself included by the way.
Johanna: [00:46:22] So I might not get this right because I'm still working on this. Yes there's a product donor book in the works also. I know you're so surprised. But for me the product manager is the person who goes to the project portfolio your team and says I've done an impact map. We need a project to do this thing to deliver this kind of value to the organization. So a product manager is thinking strategically what does the organization need for products and services now. And I actually think that there's a team of product managers for any given organization. They might not be working as a team right now. What we need them to work as a team as a collaborative team.
[00:47:16] And then there's the tactical work in the team. So who writes the product purpose or the vision. I would hope that that would be the team with the product owner. So there are often people go out to visit customers on a regular basis. Those people cannot be product owners right. If they're if they're out three to five days a week they can not be working with the team and we need somebody to work with the team.
Roy: [00:47:50] So our PO is internal facing and a product managers is external facing ?
Johanna: [00:47:55] For me that's what it is right now. And I think that those people need to be on a product value team where they collaborate together. Working at these various levels to talk about what should be in the roadmap when . are are our customers asking for this kind of a thing now or do they want that kind of thing later. So it's a product owner would actually create the roadmap and involvement. I'm a big fan of continual planning but it may be with input from the product manager if you get a lot of input from a product manager. But I think we have to separate those two roles.
Roy: [00:48:44] It seems to me that if you're saying to the product managers is the person who is really connected to the products and the product owner is more of a translator for proxy for a product manager. That makes sense?.
Johanna: [00:48:57] No I think you're right. And I I wish I could say that it was. I don't know how to get the team closer to the customer unless they actually visit the customer which I think is a really good idea. Yeah but I'm trying to bridge that gap between the people who are always out on the road and the people who are in with the team.
Roy: [00:49:21] So so so the problem you're trying to solve is that the absence of product owner because they're always out. So we want to have an internal facing and then and then we have to solve the communication issues between them because you want them to have the same same brain in a way like the same person possesing two bodies in a way.
Johanna: [00:49:44] Well I think that I think that product managers are not accustomed to writing stories I mean. I mean I come from a time when product managers were supposed to write PRDs. They didn't do that either. They said to a BA go write the PRD.
Roy: [00:50:04] And you still believe PRDs BRDs. Let's talk about documentation for a second. What documentation do you think we need to get rid of even in larger organizations. And what is absolutely necessary for you think we still think you know I remember 2006 behavior driven cucumber based. I still see organizations trying to implement that stuff. Do you still see that as the end goal do you see something else. Do you think it should be that with a combination something else maybe something that you thought was true. Now think you know I was wrong that something else is true. How do you see that you are engaging in the actual music business.
Johanna: [00:50:48] So I would really like people to document a picture of the architecture in on paper. Let me show you a piece of paper write a piece of paper. So not in PowerPoint.
[00:51:06] Not in Vizio not in any drawing tool. I want to see them drawn on a piece of paper maybe put an image of that paper on the wiki and say as of where recorded in the sun January 17th as of January 17th 2019. This was my best picture of the architecture. And then as we started to implement features and we make decisions about what the architecture should be what the constraints are we add to that picture. And then at some point we say okay we are not past the point of no return. It is time for us to define the scheme or define the architecture defined find something is the same way for me with the requirements. I'm totally fine with big picture roadmaps.
[00:52:02] I'd love big pictures right. I think in big pictures I wouldn't know a minimal marketable feature if it bit me on anywhere. At the very beginning of a product right or project I wouldn't know it but I have some ideas about where some of them might be. So I'm happy to evolve the roadmap all the time. And for me as long as I understand what does Done mean what are my release criteria. How who am I delivering this project for and what what will make them satisfied. Then I I do is little documentation as possible but as much as necessary to get there. So I have yet to ever see any requirements document be useful.
Roy: [00:52:58] Let me challenge you a little bit on that. Okay you mentioned the piece of paper I have. Just in case I have another one here. I think those are the last two pieces of paper on earth.
Johanna: [00:53:11] My office is full of paper
Roy: [00:53:17] So but we're talking about a large large ish organization. Where does that piece of paper go. Does it go on a wall with a specific team. What about remote teams what about teams on the other building on the other side of the road. Where does that piece of paper go is it really is it. Is it a pipe dream that we were able to use it or does do we have many copies of the piece of paper on many walls for example.
Johanna: [00:53:47] So I'm not sure that copies on walls or not are a bad idea. And maybe have I mean as we have either iteration or cadence of finishing and demoing and reflecting reflection inspecting and adapting to whatever it is we do every week or two why not update that that paper on the project wiki. I'm assuming there's a wiki and might be something else. But why. It's our unbelievably cheap. You know why are we so worried about saving bits. This is not like when I was a young programmer right there. I mean I I don't think I can find a USB stick right now. on My desk. . Let's not discuss that.
Roy: [00:54:40] So are you saying we should use weeklies or should we use walls. Like I'm really saying what is now in and agile you know the documentation way where does documentation live?
Johanna: [00:54:51] So if you need to keep this is another it depends answer.
Roy: [00:54:58] also another book?.
Johanna: [00:55:00] Maybe maybe not if you need to keep a history of how we were thinking until a certain point right. We often find we thought this way at the beginning then we thought this way in the middle and then just before it was time to make a decision. We catalized those ideas. Decided what we were going to do for now. One of the nice things about an agile approach is it does not cut off our potential too early in the project so we might want to keep a history of what we were thinking and decisions we made if we don't need it don't keep it. Yeah.
Roy: [00:55:42] You know you know I'm facing these I'm facing one of the customers has a huge project that they basically inherited from offshore teams and they have to maintain it and add stuff to it. And I'm thinking to myself we're having this conversation what would it have been. Because currently right now of course you know it's chaos.
[00:56:01] Nobody knows anything the communication boundaries are so difficult that you know even when you do get the person to ask that person might not know everything and that communication is so difficult between different continents that now. Very nice. It's like the old modems where you can hear me like you know for every 100 words you get five of them right. Right. So the communication's horrible.
[00:56:27] I'm thinking what would have been the best documentation in this. Now what would we have killed for at this point. And I'm thinking in one of the best things that I've ever encountered is you know on a wiki a set of videos where a person literally says they're recording with a microphone. kind of like the way you're sitting now with a in that case it was a PowerPoint but he was recording the screen and that person was explaining the architecture and that decision even if it was five years ago.
[00:56:59] Because now we understand the main intent and you still see the big picture of where things were. as you can see this thing is now no longer and a set of those videos would have been a lifesaver. And I'm sure it would have saved hundreds of thousands of dollars of people just wasting time trying to find out why how something is working or not working and where it was the right person to even ask that question.
[00:57:27] So maybe the documentation that the new that documentation is video and in the video and audio and not ncessarily the paper I'm just being kind of spit balling here as an experiment.
Johanna: [00:57:41] There's no reason not to do that now. I think and again I think that when even even ten years ago we did not have the tools that we're using right now. It was a lot more difficult to create video. And even audio ways. Not that easy. So if we have all these tools why not use that now.
Roy: [00:58:12] I'm going to change the subject for a second because I have something I've been you know kind of I promised myself this year that I would do that I will get into understanding the large scale framework so less and SAFe and all that stuff because not because I might agree with them because I don't necessarily agree but it's very difficult for me to discount something that which I don't feel I fully understand yet. So I said this year going to teach courses and all. Each one of them.
[00:58:40] And by the way as a side note I noticed that a lot of you know people that I meet in the conference circles etc. they will publish their own stuff etc. but they rarely go to trainings by other people in the industry. I don't know if it's ego or time or whatever. And to me that you know I am also to blame on that I've also not done my job well enough to say you know what I think I know what I'm doing. But what are the other people doing. I might read a book or read a few articles. It's almost like what I'm going to go to a person's course and just sit there like a regular student. No I am a published author and I know it's such a stupid ego thing anyway. So that's that's my resolution. That and losing a few pounds.
[00:59:31] But one of the things that I've I've heard a lot about and I've decided to also learn other than SAFe and less is a THEROY OF CONSTRAINTS (TOC) because the way I see it a lot of the stuff we're talking about kanban as well is based on those things and lean and the Toyota method. They're connected in a very deep way. to TOC which has been adapted to multiple types of industries but I have yet to connect the dots in software to me today. TLC combine is the best representation of TOC in a way. But I don't understand well enough about suicide. Do you have experience with that do you. Is it a formal experience is it something that you've tried. What are your thoughts on it. I haven't taken the course. I'd love to hear what you think about .
Johanna: [01:00:29] So back in the early 90's I experimented with buffers in projects I said to people don't add buffers to your estimates and I only asked people to estimate for a month at a time what they would be able to deliver. Right. I wanted something to deliver at the end of the month because I was using more of a staged delivery lifecycle at that time. Not quite agile but. staged delivery .
Roy: [01:01:02] And just for the listeners. I think the reason you were mentioning buffer is because in TOC the buffer rope method is it is a very prominent thing. so that's why you're mentiniong it right.
Johanna: [01:01:14] Right. That was so I had read the goal in the early 90s and then I read a few more T.O.C. books. I've been friends with Clark Ching for a long time and he wrote rolling rocks (downhill).
[01:01:34] I don't remember if it's downhill or uphill and then his most recent book about bottlenecks and the focus method. So that's all TOC. I'm friends with Jack Vincnt who actually lives in my little suburb here of Boston and we go out for lunch every so often and we talk about T.O.C. and Agile and the KANBAN and all this. when We were totally geek out for lunch.
[01:01:57] It's lovely. And so I. I have not actually taken a TOC class but I think I understand it pretty well. Which is what is the constraint in the system. How do you optimize for that constraint. So I've written several articles that people tell me are really a theory of constraints article which I was not planning on when I wrote that article.
[01:02:29] So one of my clients actually has you know 11 UI people and 45 teams. Every single team needs a UI person. What do they do. They they ask for a UI person. The UI person comes and sits with their team for two or three days and then goes back into the pool. So they have a problem. They have to wait and ask for another U.I. person. I mean this is the cycle is mind boggling. Yeah. Mind bending and and just perturbs everybody yeah. Everyone is kind of out of their mind.
Roy: [01:03:11] SO in the world of TOC how would you handle that.
Johanna: [01:03:14] So I said to them only have teams only may make sure that a UI person is on every team and if you don't enough UI people make the team bigger. So they all finish something right. So instead of having 45 smaller teams have 13 large teams or whatever it is for the net the number of U.I. people don't have 45 teams because you're not you don't have 45 teams now. You just think you do so optimized for the UI people.
[01:03:51] Well how were the UI people gonna learn anything. I said how the community of practice. Right. They still need to learn the devs in that way everyone else needs to learn. But you're not counting the throughput that you think you have. So optimize on the constraint that you have. So for me it's identifying and optimizing that constraint. So back end back in the 90s it was about buffers because we all thought that the schedule was constraint but it wasn't and and now it's how we see the constraints that are there.
Roy: [01:04:32] So do you think that KANBAN is a good presentation of TOC or do you think it's a parallel. It's more of a like the interpretation of TOC in software. I'm talking about specifically kanban in software. Yeah.
Johanna: [01:04:47] So yeah. So let me if you put together a convent board for your team you can see your flow. And now you can see where the constraints might be. Right. So it's not that I think Kanban implements T.O.C. As much as it helps you visualize your constraints because often I often find teams have once we figure out what it is that one constraint it's not one constraint it's 14. Well we can't deal with 14 constraints we can only deal with one at a time.
Roy: [01:05:30] And to me it's really is kind of I'm looking for that maybe that doesn't exist the Holy Grail that the theory of everything. The thing that connects all the parts you know and I've been reading about unit testing and leadership and devops but there are things that unite all these dead the problems of implementing those things are usually not taken at all human related and those human related problems are connected to systems where this humans interact. Those systems create those bottlenecks or or incentives. So maybe that also kind of maybe by understanding that base under that base it's like understanding gravity in a way. Right. It's not that we use gravity every day to solve a problem by understanding that gravity exists. We can create tools that leverage that knowledgeetc. So to me that's that's how I think about it and that's why I think I'm going to learn safe less. My feeling is that theU.S. is going to help me. I think it's actually going to help me figure out something and figure out something that I've known design patterns in a way when you when you write code you do design patterns if you don't realize just like you're writing Arby about you see. But having a name for that thing and realize that thing repeated it has a name and then has variations and it has no obstacles and patterns do it. I think that's a language that the today's missing for a lot of managers as well. That kind of thinking maybe is part of the occasional system of management.
Johanna: [01:07:09] So I actually think that there's two things here that you and I would both agree on. I think that too few organizations focus on technical excellence that if they had technical excellence they could actually get a lot more stuff through their system and that they had managerial excellence they would have more humane more usable systems of work. So I am. Please continue to work on the technical excellence. I am starting my journey well are continuing my journey on the managerial excellence part.
Roy: [01:07:53] So speaking of that you know before we kind of go. So you're in the process of writing this book which is all about distributed teams.
Johanna: [01:08:03] Yep.
Roy: [01:08:04] What else are you kind of involved in these days any kind of training courses people where can we find you these days. on and offline.
Johanna: [01:08:14] OK so online everything is jrothman.com cause you know I got my domain name back when it was fine to have our first initial and your last name. So everything is there my books are ךך there. I have online workshops I have in person workshops. I am about to about to announce my writing workshops for Q2 and I need to figure out how to get the product owner workshop up and on teachable.com So it's all right so there's more there..
Roy: [01:08:50] are you doing writing workshops.
Johanna: [01:08:53] I offer writing workshops.
Roy: [01:08:57] if you want to be a book author. Is that what.
Johanna: [01:09:00] Well the first thing is actually to to free your inner writer. Right. So. And this is for nonfiction all of the ideas work for fiction also. But I'm focused on nonfiction. So how do you actually sit down and write on a regular basis. And then the second workshop is about publishing cause and then I really want to get the book wrting workshops up which is first. There's one about writing the book.
[01:09:30] And then there's one about publishing and marketing the book.
Roy: [01:09:34] Wow I didn't realize that you're also kind of jumping into that world as well. That's very interesting. You find that there are a lot of people are interested in trying to jump into that ship and for some reason or they don't feel comfortable or they're looking for those tools and it's hard to find you know the kind of that kind of training.
Johanna: [01:09:54] So a lot of people don't realize that writing is not editing right that if they're writing down just writing and cycling to make sure your ideas are there is very different from the final editing you do later. And a lot of English teachers taught people oh you must edit Everything you write. Well yeah maybe but not while you're writing it.
Roy: [01:10:23] Do you think writing the writing you're teaching who's your target audience is it people who already want to write or do you think this helps. Also people never planned on it but that skill will help them in their job. And your day to day job.
Johanna: [01:10:38] So I've I've had people who were consultants who are coaches who are actually entrepreneurs of many stripes where they say I need to write. It takes me too long. I've got to figure out how to do this faster and better.
[01:10:57] So it's all it's all that.
Roy: [01:11:00] What do they need to write like like letters or memos or like blog blog posts. Right.
Johanna: [01:11:08] So a lot of a lot of consultants have blogs or are write articles for other places because the SEO points back to them.
Roy: [01:11:19] OK cool. Anything else that I should have asked you but I did not.
Johanna: [01:11:26] I'm sure that there's plenty. But I think we've we've gone on for long enough so that's probably fine. OK.
Roy: [01:11:33] Well Joanna thank you. It's been a pleasure. I will probably see you again in about ten years.
Johanna: [01:11:40] Let's hope it's not that long.
Roy: [01:11:43] Yeah it's been a pleasure as always I hope like is there an upcoming conference what people can find you in the next few next six months.
Johanna: [01:11:53] So I'll be doing a bunch of the no fluff just stuff and uber conference conferences in this next few months. I have my submissions in to the agile conference we'll see if they take me.You know it's always it's always a crapshoot.
Roy: [01:12:10] Is this funny that the agile conference proceedings or some of the most waterfall based proceedings ever is is this is the most ironic bureaucratic nonsense I've seen in a while. Isn't that crazy?
Johanna: [01:12:27] I find it quite humorous that we have to propose stuff a good nine months in advance and give an entire outline of what we're going to do which might change it.
Roy: [01:12:40] Yeah exactly. But I find that the process of book writing is very much the same it's the opposite of agile because you have to create a table of contents in the first place and then you have to fit the book into that plan. Now obviously you're going to change your mind. So luckily a lot of publishers are very very happy to change it. But for some reason you have to come up with a full book in your head before you start writing it.
Johanna: [01:13:06] This is why I do not work with any traditional publishers at all.
Roy: [01:13:11] You work with leanpub.com These days as well ?
Johanna: [01:13:14] All my books are on all my self published books are on leanpub.com. I I cannot imagine a time when I would actually work with a publisher. In the future I cannot. I mean maybe it'll happen but I am...
[01:13:33] So Mark Kilby and I we organized this book several times and and we totally reorganized. What's in the chapters. Never mind that. But why did they ask us to do all this work that we're not going to use again.
Roy: [01:13:52] And for the viewers listening to this LeanPub is an online publishing platform we can actually deliver your book early and even get paid for it for specific sounds that that throw away as the book becomes bigger and bigger. So you kind of have this continuous delivery way of writing a book and I even the elastic leadership book that I wrote actually started on lean pub and then I moved it to a traditional publisher because I found that the marketing was better. That was the only main reason. So I kind of try to get the best of both worlds. Like early feedback and then OK traditional.
Johanna: [01:14:32] That's why that's why I need to have two workshops for book writing. One is the book and one is marketing and publishing or publishing and marketing. Yeah.
Roy: [01:14:43] Perfect. Okay Johanna thank you very much for your time. It's been a pleasure. And hopefully we will meet in one of the future conferences I'll put links to all to to your website and your books and all that stuff. Thank you again and thank you very much everybody for viewing and feel free to leave comments or send us questions via e-mail. Thank you and have a great day.
Johanna: [01:15:08] Thank you.
