Interview: Scaling Agile with Johanna Rothman

What does "Scaling Agile" actually mean? (01:31 to 03:33) So, for me it means a whole bunch of things. The first part is you have the ability to take functions, you have developers, you have testers, you have UI or UX people, you might have technical writers, you have DBAs (Database Administrators), you have whatever you need, and they create a cross-functional team that delivers features, as you said. The next step for me is about scaling what one team does to this ability to collaborate among several teams so that they can all produce a product together. And this is much more difficult than just one team working on their own. There are several other ways to think about scaling Agile. The next part for me is this adaptive planning so that you plan and re-plan at the project portfolio level to say which project is the most strategic project for us now, and at the product level so that you can do more continual planning for the products that have projects in progress. And then there's how you scale Agile across the organization where you bring in finance and HR and then how managers change how they manage. So, I've been writing a series of posts on my blog I'm almost ready to publish the management post today, because when we were preparing for this I thought: "You know, it would be really nice if I had a bunch of blog posts to point people to". So I'm almost done with that series. Does it actually make sense to scale Agile and Lean to the whole enterprise? (03:40 to 05:44) Maybe. (laughs) And the reason -- This is, I know, all of you are rolling your eyes. It's a typical consultant's answer. It depends. And the real thing that it depends on is how often do you need to change what you're doing. If you don't need to change, if your organization has a very stable product and you have stable customers and there's no innovation that you need, then no, you don't have to do Agile or Lean, you can do whatever you want as long as you keep getting the same results. When you stop getting the same results you might need to change something. But here's the thing I have seen, it almost does not matter what industry you're in or what organization you're in, the pace of change has changed. When I started to work back in the '70s, – so, yes, Alexandra, I did start to manage projects before you were born, and what can I say? I have earned my gray hair –. And I think that the key is, everything was slower then. We did not have cellphones, we didn't have Internet, and thank goodness that we have them now, but that means that since people have information at their fingertips what they want to be able to do often changes. So almost every industry needs to consider how can I use Agile and Lean approaches and ideas to increase our ability to respond to our customers? Will you have to change? Probably not, not all at once, but should you think about it? Yes, you should think about it. What actually is it that makes it so difficult to bring this technique inside larger organizations? (06:07 to 07:57) So I think the biggest thing is the cultural change. Yes, everyone changes and what they do and how they do it, so instead of working in functions we're working cross-functional teams, and the issue here is not that it's one cross-functional team that delivers value – that I think of as the software developers and testers and whomever – it's that we have cross-functional teams for the product with the product manager and the product owners and maybe even customer support saying, "Here's what we need to do for the product over a period of time". We have a cross-functional team for the project portfolio so that we decide as an organization how will we implement our strategy. We have cross-functional teams for management, they have to decide how will we assess our current financial measures so that we know what to do next. We have cross-functional teams for HR. HR cannot work in its own – Oh, I'm gonna offed people here – bubble. We have to bring HR into what management does. HR cannot tell management what to do and management cannot tell HR what to do, and that is a cultural change. We are so accustomed to thinking about the hierarchy where we have functions, the functions are vertical, and instead we have to have this cross-cutting teams all over the organization. That's a huge change and it makes the culture all different. Why would a company want to switch to Agile? What are the main benefits that they would expect to derive from such a big leap in culture? (08:01 to 12:14) So, first of all, I would never say to change everything all at once. I recommend, as I suspect that you folks do, that you take Agile approach to moving to Agile. You do a little bit at a time. You experiment, you try something, you gather some data and then you assess the results and try something else, or maybe continue with that experiment. So that's the first piece. And the second piece is the value that it brings. One of the most interesting things about the way we measure and deliver value now in our organizations is something that we don't actually do. We do not assess the cost of delay. Introducing the cost of delay So let me talk a little bit about the cost of delay. Think of a sine wave where you start a the left with a little bit of, you grow a little bit and then you have this very rapid growth and then you have this medium thing at the peak, and then you tail off growth at the end. That's the typical sine wave, and I hope I'm not confusing anybody. That is how we assess sales right now for the organization. It does not matter what you sell or what products or services you sell, they start off small, they grow to big, and then they tail off at the end. And when we have a cost of delay we push out our ability to recognize revenue, so we push out from the left to the right so we have a delay in recognizing revenue. Our revenue tends to be shorter, so instead of getting to the top curve we don't get that high. And then the delay, if we delay introducing a product or a service for a month we take out the maximum sales per month, and then we tend to have an earlier end of life for that product. How cost of delay changes the way you see the portfolio If you start thinking about cost of delay that starts to change the work that you work on, it changes it at the big picture, at the project portfolio picture, it starts to change it at the feature level for teams. Now all of a sudden you get to say, "What would allow us to deliver value faster?" And maybe we start at the team level 'cause that's often easier, right? We start with the project at the team level and say: "If we do this thing, can we recognize revenue faster? Can we reduce waste faster for ourselves?" Because that allows us to recognize revenue faster. And I have found that if we start to think about the cost of delay at the project portfolio level and at the program level, then we can say, "This is what we need to do at the team level so we have a constant delivery of value". Now, this is a lot harder in products with hardware, mechanical or hardware, any of that stuff, you cannot be totally Agile because there's phases at the beginning where you have to do some setup, you might iterate in increment through the project, and then you have phases at the end, because you're not going to replace hardware on a regular basis. But you can do this, if you think about what would allow us to deliver value earlier, and that starts to change how everybody thinks, and that starts to change the culture of the organization. If somebody wanted to sell Agile and scaled Agile to their organization, how should they present it to their hierarchy? (12:27 to 15:34) Introducing Cost of Delay ÷ Duration So, this is, this is where they say it might be useful to think about cost of delay divided by duration. And this is one of those tricky things, this requires a little bit of prediction, what do we think this feature or this project is worth to us, and even if you say: “We're gonna pick a number out of the air we think this feature is worth” – I'm gonna use dollars because I'm not very good at using any other currency, because I'm in the U.S., of course. – “We think this feature is worth $10,000 and it's going to take us two weeks to deliver it”. That means that the cost of delay is gonna be $5,000 a week. So if we get it out in the next two weeks we have no cost of delay, but if we actually delay longer, our costs go up. Now, let's compare that to a feature that is worth $100,000 but we think it's gonna take eight weeks. No, let me do four weeks because I can actually do that. So we have – I don't do arithmetic very well, I do math extremely well –. So we have $10,000 over two weeks and $100,000 over four weeks. Which one is the most valuable? The $100,000 over four weeks. One way to use Cost of Delay Now, if you ask me I'm gonna say: "What is the first piece of value that we can get out so we don't have to wait for the four weeks and we can recognize some of that revenue earlier?" And that's one way of using cost of delay. Now, that is very different from saying: "Here's the estimate for this project". So the estimate is: "We think it's gonna take four weeks, and we think this other thing is gonna take two weeks." So if you only look at the estimates you might say, "I don't know, we can get something out after two weeks from this smaller thing." But if we look at the value, this changing of ideas from estimate of time and cost to the value of the time and cost, and then if you're like me you'll say, "Let's not wait for four weeks". Now you have something that allows you to proceed in a way that provides more value to the organization faster, and that's – I have had mixed results bringing that to higher-ups because they're so accustomed to thinking about estimates of time and scope, because that's all we had in waterfall, that's really all we had, we could not see value earlier. But now that we can see value earlier we have other options to discuss what value is. What would you recommend as techniques or approaches to sort of further develop an Agile and Lean frame of mind? (15:40 to 19:24) So, I always suggest to teams that they start with themselves. I mean I actually set this with people that they start with themselves, right? Each individual person can say: “It's not so much about what I do, how can I help this team deliver value? And, what is the smallest thing that we can do to deliver value today?" Helping team members reframe how they think of their work So, I often encounter architects who say: "I need three months to work on the architecture for this product." and I can say "I bet it will take three months if you add it all up together, but how do you know that you'll be right?" And they look at me and they say, "I'm really smart, I've done this before". And I look at them and I say, "And how many times have you been wrong partway through the project?" And they say, "Sometimes", because they can't say "Always", they can say “Sometimes”. So, what I say is: "Instead of taking that three months at the beginning, why don't you do the smallest possible thing that is not architecturally sound, that uses a flat file instead of a database, that might not even use the entire product architecture but you treat as an experiment? What is the first thing you could get out tomorrow that would give you data about what the architecture should be?" And when they say stuff like that, when I say stuff like that to them they often say: "Oh, if I can use a flat file I don't have to have a schema", I say: "Yes". "I don't have to worry about performance right now?" I say: "No, but you might want to do a feature that gives you data about performance". "Oh. I don't have to have all the notes? I don't have to scale to 100,000 users?" I say, "No. What if you had 10 users? What piece of value could you deliver tomorrow that would allow you to do this now?" And they say: "Oh. I gotta go to my computer, I gotta write some code". And when they say "I gotta write some code." I do this little happy dance, and then I'm totally obnoxious, then I say, "Can you write the code with other people?" "Oh, sure! Let me tell them what they need to do". Okay, so the "let me tell them what they need to do" part I might work with them there or I might not, I might wait until the next time. A small change that makes staying on track easier But that's how, when you free people from the constraints of "I have to do it right the first time" to "I have to" – And you change that to "I have to experiment right the first time", that allows them to do totally different things, and I find – And then when we look at it, when we retrospect at the end of the project, yeah, they spent three months working on the architecture but they didn't do it all up front, they did it during the project and they were able to make changes, and did we have to, did we take a wrong turn and have to back up? Absolutely we do that, but our wrong turns are not very large and our backups are not very large, so we're able to get back on track much, much easily. What techniques can Agile teams use to collaborate with non-Agile teams? (19:28 to 22:50) So, one of the things I really love is the ability for a program, especially, where you have multiple teams to deliver internally at least once a month. Now, some of you on this podcast are saying, "I got you beat: we deliver internally and externally much more often than once a month". But I have found that with waterfall teams, especially people who were tightly wedded to waterfall, they have a really hard time delivering in that short period of time. Set deliverable-based milestones So what I say to these program managers, I say, "Set deliverable-based milestones as often as you can". Once a month is good. If you can only start with two months, start with two months, see if you can bring it back down to once a month. And then say to the waterfall teams, or at least the non-Agile teams, "I don't care how you work inside your team, I care about your delivery, and we need your delivery for this program in the next month. So however you do it internally, that's fine, but remember we only need this much” – and I hold my hands together to show that it's a small thing – “and you need to deliver it as a fully-tested piece of functionality”. So if you do, if you want to do all of your work by waterfall, that's totally fine, but keep your functional specs small, keep your architecture specs small, keep all your specs small, and then get right into coding and testing. So when I… I'm kind of cheating, I'm actually suggesting that they work in a staged delivery lifecycle, which is an incremental lifecycle, not interative and incremental, but it's a very easy transition from waterfall teams, because if they do a bunch of speccing and writing of specs and stuff up front, they're much more able to say, "Oh, OK, if she, that crazy woman over there, she wants us to deliver just these features for May or for June, I can do that, I will, I'll just deliver this stuff by the end of next month". I don't call them month's iteration, I don't call them sprints, I call them a deliverable-based milestone, because that's what it is, and when you talk about milestones with non-Agile teams that's a word that makes sense to them so they have a little comfort there. So, I guess I kind of speak in their language so that they are able to deliver what I need them to deliver inside the program. Can we say that scaling Agile has reached a level of maturity where we can see a body of best practices develop, in other words can we consider that scaling Agile is now mainstream? (22:52 to 24:55) Oh, I wish we could. (laughs) I don't think so. I think that since everyone does their own version of Agile and Lean there's no best practices yet. I think that you can say that there are principles, right? The small value, the small deliveries, the working by value, we have not yet talked about managing WIP, Work-In-Progress, that's "W-I-P". But, yes, I mean, all those principles apply, but I don't know that there are any best practices. I don't know that people need a cadence for their program versus an iteration for their program. I don't know if the entire program can work in flow, which is kanban boards everywhere, or if you need some iterations and timeboxes. So, for me best practices are an oxymoron. I understand that many practices can work, and I do not yet see that there are any best practices that we could always apply and everyone would get the same results. I think we are still creating our state of the art around scaling Agile, especially to programs, and certainly anything more than that. What is your opinion on frameworks such as Scaled Agile Framework, also known as SAFe, Scrum of Scrums, DAD or LeSS? Are there any clear winners today, a framework that gives better results? (24:56 to 29:26) I hope not. (laughs) So, when you and I spoke in preparation for this I said I do not believe in any of the frameworks, I do believe that you should look at them and read about them, although I have such a problem with SAFe. Perspectives about SAFe To me SAFe conflates a number of separate issues. So SAFe has this issue with the project portfolio and the product roadmaps, and they talk about it in the same way. And for me the product roadmap is about this project at this time or program, and the project portfolio implements the strategy for the organization, so it's many projects. So I think that that part is just ... Maybe I am too stupid to understand SAFe, but I'm a pretty smart person, I've been working in this industry for a long time. So if I'm too stupid to understand it ... I don't know, but even if you find that as a starting point my experience is that planning only on a quarter boundary is, first of all, very expensive, and insufficient planning. I do not know of a project or a program that stays still for that long, for the plans to be valid for an entire quarter. And it sounds like I'm picking on SAFe, and I can pick on any of the frameworks equally. The problem with thinking in terms of iterations So they all have this notion of iterations and I find that the more you think about scaling Agile to the rest of the organization past one team, the less you can think about iteration-based Agile, you can think about the cadence of planning, but the idea of things staying put for an entire iteration, that just does not seem to work. It doesn't work for any of the management teams I know, it doesn't seem to work for the project portfolio teams, it doesn't seem to work for the program management teams. Prescriptive approaches I worry about being wedded to such a prescriptive approach, and the problem I see with Scrum of Scrums is that Scrum, if you do a scrum or a stand-up meeting, it's all about recommitment from the team members and asking how we can move things to done ourselves. And the problem when you have not quite inter-dependent work once you move above team, you can't see my hands but I have, I have a circle for the teams in my hands and I go above and above and above, the more you move above a team the less often you have people who can work together for their work. They have to provide independent work back to the program, independent work back to the project portfolio team, independent work back to the product management, the product and their value team. So when you start think about independent work, why would you have a stand-up? It does not make sense, because the people on that team, while they are cross-functional, do not actually work together on the deliverables. Their independent work contributes to their deliverables. So, I really worry about this, and stand-ups are horrible for problem solving. So use a problem-solving approach for problem solving. I mean, you might use Lean Coffee, you might use any other kind of problem-solving meeting, but thinking about what you do as a stand-up, hmmm, I have trouble with that. So, can you tell us a bit more about these problem-solving tools and meetings, because I think that's something that is of particular interest to our attendees. (29:30 to 32:07) Oh, so I have ... Back when I started to run programs I had a "problem of the week", so we would have a weekly meeting that I timeboxed to one hour, I asked people to send in their problems that we needed to solve at the program level. And I what I said to them is: "Send me all your problems, and if I cannot help you address them, because I have the bandwidth to help you address them, then we will put them in for our problem of the week". I've been using this technique for a long time and it still works, because we might do a little bit of check on the milestones at the beginning "Where are we in the program?" And then we go to the problem of the week and we do problem solving. So, I don't know if you're familiar with Sam Kaner's work about how groups work in meetings but we explore around the problem – that's the divergent ideas – and then we converge on a solution. So you can do this with several problems in a one-hour weekly meeting, and then you have action items. If you don't have action items at the end of that meeting you do not have a useful meeting, right? A useful meeting starts with an agenda and action items, and it ends with action items. And the interesting is that Lean Coffee also allows you to do this. You can then generate the list of issues to address in the meeting. That allows you to create the agenda for the meeting in the meeting, you discuss each of those issues in a timebox way, I like eight minutes as a timebox, and then you have a final timebox at the end to collect your action items and make sure that people know what they're supposed to do. Any kind of meeting you do that has an agenda at the beginning, whether you start it, whether you sent it out in advance or you generate it at the meeting, and ends with action items, and you have resolution to things and you have action items, that's a great meeting because that means you're making progress on these problems. So, I really like a problem-solving meeting for whatever kinds of problems we need to solve in the program or wherever it is we are working in the organization. How should someone approach implementing Agile in such way as to make Agile work when you've got hardware or a physical aspect to the product that you're managing? (32:08 to 36:30) So here's what I do: I ask the hardware people to generate their list of constraints, and often the list of constraints is footprint, or heat, or heat dissipation or something like that, it's almost always related to the physical product. And I ask them to generate those constraints at the beginning. No, I did not say generate the architecture to manage those constraints, I asked them to explain what those constraints are. Landing Zones And then there's a technique known as landing zones, I believe that Erik Simmons from Intel wrote the first paper about it – I have it referenced in the book – and that says we need… Heat dissipation, for example, is always inside a plus or minus, and footprint might be a very small plus or minus but it's always a plus or minus. So, where do we land, how do we negotiate heat dissipation inside of this footprint? Maybe there's a power thing also. And that, you might not be able to create release criteria, but you keep them in mind. Using simulations to iterate on hardware When you define the constraints at the beginning and then you say, "Please iterate on the design", because hardware looks a lot like software, and so does mechanical. You can iterate on the designs and simulate your way through these constraints. And the really nice thing about the simulations is you can show people the simulations just like a demo. So you can iterate and it looks a little bit different than actual for a software team because you're not producing final product, but you're producing demoable product as you go. Going to prototype And then when you're ready to go to a prototype, because my idea of hardware and mechanical is you always do prototypes and then you do pilots and then you finally have production. So, when you have a prototype you're ready to marry any software with the hardware, because there's almost always firmware or software or something involved in this, even if it's just boot-ROM. (that's a way to boot things) So you marry... the software people have been demoing all along, they've been simulating, they may even have a hardware simulator, and then you can start to marry everything once you have a prototype. Now, when you have a prototype you again iterate through what you have to do for the hardware and mechanical stuff and the software. It turns that a lot of this iteration is a lot of back and forth. Software can help get Hardware where you want it to be My experience with hardware is that, – I love you hardware people – but my experience is that hardware always think they can do a lot more than they actually can, because you're almost always pushing the bounds of physics, and the software people have to come in and kind of, you solve the problem behind that. So the hardware people did not quite get to what they wanted to do but we can do that with software instead. And that's what the prototype and pilot time of the project is. But here's the cool thing: if everyone iterates a lot during the iteration stuff then by the time you have a prototype you have not that much more time before you go into a pilot, which allows you to keep your pilot time short, which allows you to get to production much earlier. OK, that definitely makes sense. So that would be also a way to manage the cost of the prototypes and the overhead that can come with small iterations because then you'd wait until almost the last moment before actually producing the prototype. (36:35 to 37:18) Exactly. And the fact that you have short iterations and small demos means that people get the feedback a lot faster. So I want the feedback in the hardware, I want the feedback in the software, and I want to – and if they look at each other's demos now they can say, "Oh, I didn't know you could do that". And that's from both sides. So now I'll ask them to collaborate where the hardware could be. In your book you mentioned that a program should increasingly think of itself in terms of a product, and that's the trend that we've seen with the customers. Can you remind us of the interest and benefits of seeing products instead of a program? (37:20 to 40:02) Sure. So when you think about, at least when I, I'm gonna talk about me, okay? I'm not mind reader, I'm not talking about any of you, but I find that for me, when I think about a product I think about why we are delivering this product and who our customers are. That feels different for me than thinking about a project or a program. And I know it's a little bit, some of you are probably shaking your head, "Oh, it's that Johanna, she's being wacko again", but I find it, when we think about the product we think about the entire product, we think about what do we need to do to bring this product to market. We stop thinking about: "It's just software and I don't care what the marketing people have to do". Changing the way everyone thinks about the project So as a software developer I might not think about what the marketing people have to do, but when I see something on the board that says, "Generate performance data from marketing communications", I think, "Oh, I have a product that's not just about my software development, I need to talk to my Agile project manager or my program manager, and talk about what do I need to do to make sure I deliver this information to the marketing communications people so we have an entire product". And I find that that helps us optimize up a level. So we're all about optimizing at the team level, and especially for a program, we wanna optimize at the product level. So once we get the team working together so that the team delivers features, the team needs to also be able to look up a level and say: “Does the program need anything else from us so we can deliver a wonderful product?” So, in your experience, how good a company at seeing that, at zooming out, in a sense, to the entirety of the product? (40:06 to 40:13) So the more functionally organized an entire organization is, the harder it seems to be to do this. And this is, that's because the rewards reinforce the functional silos. Once you start to be more cross-functional, and I'm not saying you reorganize your entire organization, don't do that, but when the rewards start to be cross-functional, then people say, "Oh, I should look at the entire product". So we want people to deliver products. We've talked about incenting people for project completion, which I think is kind of not so hot. Maybe not totally crazy but not such a good idea. But if we talk about: "Are we able to recognize product completion?" because that might be more than just a project, now all of the sudden we can recognize revenue faster. So, how do we get the entire organization thinking about the products and services we provide as opposed to my job? So, this goes back to seeing the whole, which is one of the Lean principles, and for me it's all tied together. I really want people to be able to say, "How can we create great experiences for our customers?" whether those experiences are hardware or software products or some other service. "How do we create an entire product so that we are able to satisfy and make our customers happy?" Can you give us an example of what a cross-functional benefit would look like? (42:06 to 46:54) So, one of the things I've seen is that people... OK, let me tell you a story, and I hope that we stay on time. So, I was a project manager a long time ago, and my manager said to me, "I'll give you a bonus if you deliver this project on this day". I said, "Sure, I can deliver today if you don't care about the entire product". And he looked at me and said, "Are you giving me sass?" I said, "No, I'm not trying to give you sass. But here's the key, I don't have any control over marketing communications, so I can finish this project when you say, and that still not gonna give you the revenue because you're not thinking about the product. And it does not make any sense to incent me because I have an entire team". So this is before I knew about Agile and Lean. "We can do anything you want, I don't know about making this particularity but we can have something to deliver by that day, but I cannot bring in all those other people I need to bring in. So, until you, if you tell me what you want: Do you want to deliver this product by this date or do you want me to finish this project by this date?" And he sat back and looked at me and said, "I'll get back to you", because he really did not know what he wanted. Cross-functional teams that work together understand who contributes what So this is -- I've been a big fan of paying teams for teamwork, so if you, I'm not big on bonuses I realize everyone loves their bonuses, I think you should pay people a reasonable salary and then work by product. Because individual work, in any knowledge work individual work is not quite material, especially if you're moving to Agile. The more people collaborate, the better the product is, the faster it gets out. Why would you incent them on individual work? So, I worked with another team where we actually made this amazing deliverable, and the manager said to me, this is back when $10,000 meant something, he said, "Since you were in this project on time I'm giving you a $10,000 ...", $10,000 was a big, a lot of money back then, "bonus". And I said, "Well, it can't just be for me, it has to be for the team. " So I'm gonna tell the team, “Here's the money, and you guys decide what to do with it". I was wondering, am I doing the right thing? Am I gonna create a series of monsters? So I said to the team, "Here, you have $10,000. It's not really mine, I facilitated you, you guys did all the work". So they said, as like one person they turned to the technical writer and said, "She should get 40%. She should get the most of it, and the rest of us will split the rest". And I looked at them and I said, "Why don't you do this by individual vote? Write on a sticky what you think everyone should get, because I'm a little nervous about this". So one person said I should get $1,000, which I thought was very nice, and all the rest of them said 40% for this technical writer and then the rest divided up evenly among the team, and, of course, nothing for me. So, and that was fine because they had decided it among themselves. So when I read the stuff I said, "Thank you for the vote of confidence. I will pass on this. I will make sure none of the money comes to my account. I will make sure that the company pays you directly because otherwise I have to get taxes and this is horrible". And they decided, right? And it was not, I think it took them 20 seconds to decide even when I asked them to write it up in a card. – I don't know if I used sticky or cards back then – but, I mean, they decided what to do. So, cross-functional teams that work together understand who contributes what. Managers do not understand. So let's get the managers out of the equation and give the power to the teams. Now, this does not work if you have one person driving and controlling the team. It does not. This has to be a cross-functional team that is self-managing.