#0112 - Agile Project Management with Johanna Rothman

This is the no Nonsense Agile Podcast. Join us for discussions on agile product development and leadership with world class experts who provide valuable insights and practical advice to industry professionals. Subscribe now to learn the latest trends and best ideas in the field.

In this episode we talk to Joanna Rothman about agile project management. We critique fake corporate agile and discuss the drawbacks of offshoring your development work. We talk about the importance of continuous feedback, continuous delivery and cross functional teams. And we discuss project charters, budgets, scaling and the need to focus on outcomes rather than deliverables.

Welcome to the no Nonsense Agile Podcast. I'm Shane Gipson.

And I'm Murray Robinson.

And I'm Johanna Rothman.

Hi Johanna. Thanks for coming on today.

Thank you for having me.

So we wanted to talk to you about Agile project and program management because you've written a few books about this, but why don't we start by getting you to introduce yourself to the audience.

So I started off as a developer back in the 70s and I got into project management in about 79 or 80. Our boss wanted to have a per chart every week about where we were and what were we going to do next. Always focus on the critical path and we'll be fine. And so after the second week I said, the critical path changes every single day. So how much time do you want me to spend on this per chart versus how much time do you want me to spend on writing the software and talking to the hardware? And the mechanical guy, he said, oh, you guys give me such a headache. Show me demos. So we did a weekly demo every week for probably three or four months and that was great. So all of my books are about well formed project management and almost never do I have charts like a Gantt chart or a per chart. I do stickies on the wall. That's often helpful, but not any more than that.

And have you done program management as well?

Oh yes. When I went to Symbolics, I ran a software program in 1988. We must have had several hundred people on that program. Most of them were software teams, a couple of them were hardware teams, couple mechanical people. And what I said to people was, you tell me what you will deliver every month and you will then show me at least as often as every month. Most of the time we did continuous integration at Symbolics. So every morning we came in and loaded patches.

So moving on from your early days through to say, the 2000s, what, what were you doing then?

So I started my consulting business in 94 as a contract project manager, program manager, and then as I Started to write more books and go to more conferences. I branched out and did much more traditional consulting, not, not so much hands on.

And what's been your involvement with the Agile community?

I've been a part of the Agile community at least since the early os.

So what do you think is the state of agile project management today in.

Most corporates, so fake agility is really the norm. I rarely see any real agility. People say they're doing scrum and they're doing stuff in two week time boxes, which is often better than they were before, but they don't often deliver and they don't do a retrospective and they don't demo and they don't get customer feedback.

Yeah, I see an awful lot of phased project management that gets called agile. And this is being done by Accenture, Deloitte, kpmg, all of the corporate. So they're doing a phase of requirements that produces a big document, then they get the architects to do a big architecture document and then there's some sort of planning where you go and ask Infosys and other companies to give you estimates and you do your project plans and your business case and then you engage somebody and you say to them, we have to be agile because we're all agile today. So they'll have the development team in India with a few people onshore, work in three week sprints and then after they've been working for a few months, their own test team will start testing things in sprints because it's agile. After a few months of that, it will go to your user acceptance test team, which is obviously agile as well, since they do sprints. And then after about a year and a half and a few million dollars, you'll deploy it all at once in one go. And then of course you'll spend three months fixing everything that's broke, which is everything.

I have also seen that, and I see it mostly in organizations that outsource the crown jewels of their organization, which I do not understand. Why would you outsource the very stuff that enables your business to succeed? I don't get that part. I often see this in organizations with much more money than sense. But there's a reason for this, and that's cost accounting. Cost accounting can only work if you treat people like their resources and if you divine and conquer all the work. The worst part is they're not working in slices through the architecture, they're all working across the architecture. So the very first time, any kind of progress is when the testers come in and say, oh, this thing that's on page 350 of the requirements document, it doesn't work like that. Do you like the way it works now or do you want it the way you wrote it down? Well, if you have gone more than six months since you wrote the requirements document, everything has changed. That's huge risk to the product. Why would you do that? I bet these organizations are all very concerned about capitalization versus operating expenses. And so the more people want CapEx, the more they tend to divine and conquer, which is actually the worst way to be able to capitalize.

Last time I talked to some executives about this, I proposed that they do it internally with local people on contract and manage it themselves. And the business sponsor said building our e commerce system is not our core capability. Which surprised me because great majority of their revenue was going through this e commerce system. So how could you say it's not core?

Yeah, I don't understand it either. When execs say that to me, I ask them to draw a diagram of how they make money and then the bottlenecks associated with how they make money. But I think most execs don't really understand how they make money.

Yeah, I think also it's a case that they often have gutted their project management and software development teams in the past to save money and so now they just don't have many people left who've done it before. They have people whose main experience is managing vendors and that's all they've got.

Yeah, my experience is if you want a really helpful product that satisfies your customers, it's much more important to figure out how do we develop and deliver software products ourselves.

The big problem is that those phased waterfall or water scrum fall projects just don't have a feedback loop. So you don't learn what you're wrong about until the end. And then you find that you were wrong about the requirements, you were wrong about the architecture, you were wrong about the code, you're wrong about the testing, you're wrong about implementation. There's just problems galore everywhere.

That's one of the reasons I wrote the Project Lifecycles book. Because if you don't actually know what you're doing or how your projects work, you can say we're agile because we're working in sprints. Sprints are like the least agile of agile approaches. Why would you wait two weeks to deliver something if you could get feedback tomorrow?

Shane, you must have some thoughts on Agile project management.

It's two words that should never go together. The core Problem is a project has a beginning and an end. And when we look in software or organizations, it never ends, it's continuous, it always lives. So the whole philosophy, the whole terminology of a project is saying start here and finish here. And that's what's important, not build a capability that's ongoing. When we build a product, we are saying that that product will be continuously developed and maintained. When we have a project, we bring in all the bad behavior that is related to a beginning and an end.

So what happens when you have a hundred software people and then you have 10 products that these hundred people are responsible for? And there's ongoing development, but not all at the same time. And you need more than 10 people on every one of these 10 products. Sometimes you only need two or three, but more often you need 12 or 15 people. If you only had 10 people per product, that would be fine, but you don't. You need more than that. What do you do when you don't have enough people to support all the products that you have?

So now we're going talking about scaling, not the problem with projects. And my answer to scaling is focus and prioritization. So why do we need a hundred people? We know that smaller teams are far more efficient and effective. But let's go back to the idea of a project. A project is beginning and end. What you talked about is a sustainable bunch of people that are constantly building out the product. And that's good behavior for me, that's a good pattern. But this idea of start and stopping is the core evil that brings in all the problems.

So let me push back a little bit more on you. One of my financial services clients has a hundred people and they actually have 225 products that they are responsible for. All I had to do was ask, how long have some people been waiting for you to change what they want in their products? And they said, oh, some people have been waiting for years. So I said, when your WIP is that high, your cycle time is also that high. So supporting these products is no longer sustainable. Now it's time to get something off the shelf and not customize it. They were very big on customizations. So instead of projects, what is the problem you are trying to solve? Even though I happen to find projects as a container for what we will do now and postpone the rest until later, I find that very helpful. Every time I think about no projects and products, instead I worry that we continue products for longer than they have a right to exist.

Yeah, so you're bringing in good Ways of working, managing your work in progress, looking at cycle times, looking at value, determining that when a requirement hasn't been delivered in 12 months, it's no longer a requirement. It's not valuable because nobody screamed. They're all good ways of working. They're all great patterns. They have nothing to do with projects. Now your idea about containers, yeah, time boxing, bringing in the theory of constraints. That helps us work in different ways and that's great. But as soon as you give it that word project, you go back to a big book of dumb ideas. You bring all that legacy crap that comes with that word project which is founded on the idea of a beginning and an end. And everything you just talked about was about continuous and that is product thinking. So that's why I get really opinionated now because I say that there is products ways of working are continuous and are very different to project ways of working.

But what is it about projects, Shane, that upset you so much? Is it the traditional authoritarian hierarchical nature of them?

Oh look, there's 101 patterns. There's, there's watermelon reporting red on the inside, green on the outside. There's disenablement of teams. There are middle managers who are in charge of all the communications with stakeholders. There's stakeholders abdicating on their responsibility for prioritization of value, for delivery of value, for actually being involved in what has been built and made. Trade off decisions. There's 101 anti patterns that come with the term project. They make us deliver something that costs more, less valuable, less feasible and even worse, the people doing the work don't enjoy it. They go there for 12 hours a day to deliver something that has no value and it becomes disheartening for them.

Yeah, I don't think projects have to be done like that.

Don't call them a project, call them an iteration.

You're very big on saying that if you use a word like project comes with a very large amount of behavior and culture and values and I don't agree with that. I think that's magical thinking what you said, Shane.

I see this in product oriented organizations all the time. I wrote a program management book and two project management books and in each of them I say the end result of this effort is a product. And as long as we think in terms of the product, we will make better decisions. It's very easy for organizations to focus on the process and not focus on delivering value to the eventual customer. And anything I can do to help my readers and my clients to focus on delivering value that's fine with me. One of my supposedly agile clients never talks about the word agile. Never. But they say, what will we do for delivery today? That's what they talk about. And some of my senior leaders have been so burned by the whole agile nonsense, they don't talk about agile either. But they all want agility.

If that word's a trigger word, don't use it. What I often hear is, I hear that the project management people have the same excuses as the safe apologists. The safe apologists go in and go, we know safe really doesn't work, but at least the executive are bought into some kind of change. So we, we'll go in and we'll pretend that we're following safe and then we'll do the right thing. Well, it's the same as project people that go in and go, oh look, we know that project management doesn't actually work, so we're going to call it agile project management and bullshit. Just stop using the word. Projects have beginning and an end. That is a bad behavior. Use any other term. You want to say that it's continuous ways of working that are feasible, viable and add value to the organization and the customer. And then I'm happy. Just don't use the project word because the beginning and the end is a wrong pattern.

I think projects are inevitable because organizations fall behind. They have things that they're supposed to do, they don't do them. There's a whole lot of politics involved to get some attention and budget on something and they need to catch up. That's why they have projects, because they need to catch up with big budget and resources and focus.

How often have you ranted against the lack of leadership and management large organizations? And you just use that lack of management and leadership as the excuse for a project.

Yeah, I agree. If you had really good management, you wouldn't be falling behind and you'd be treating your products and services like a garden and you would be building them, cultivating them, maintaining them. But the thing is that people do fall behind.

So one of the reasons managers use less than logical decision making is because they don't know any better. What passes for leadership and management training is all about spreadsheets and nothing about people and value, which is why I wrote the Modern Management Made Easy books. I keep writing about this stuff because people are still doing it wrong. It's been wrong since I started to work and it's still wrong. The only difference these mediocre agile approaches are doing any good is, is because they're shortening some of the feedback loops, not the very long ones like Murray explained. That's just a waterfall life cycle or a phase gate dressed up in agile. And I don't know what to do about that. If you're not going to invest in your own company to make money, I don't get it. But it's all about the feedback loops and the faster we learn from our actions, the faster we have a chance of doing something right. I am very big on looking at the flow metrics, not just because large WIP creates longer cycle time in aging, but because the more collaboration we have in our effort, the more we manage our WIP and the more we collaborate on fewer things, the larger the team can be. Fred Brooks talked about this when there was this whole hierarchy of the chief programmer who then handed off the work to other people, who then handed off the work to other people. And even when I started to work, we still had this idea of the chief cascading work down. Well, the fastest way to get work happening in an organization is with small networks. Now you can do this with either collaboration in the team or collaboration across the organization. But the more collaboration we have, the lower the wip, so we have a shot of finishing anything that's of value and the lower the cycle time. And I think that because of resource efficiency thinking and cost accounting, managers are not incented to actually create collaboration which creates more capability. Back in the 90s, my boss said, you need to rank every single person in the engineering organization. And I said, no, why would I do that? He said, you're in charge of it all and you need to rank everyone so I know who we can cut. I said, that's not how you do layoffs. If you need a layoff, the way you do layoffs is to say what are we not going to do anymore? And then who are all the people who are affiliated with that stuff that we're not going to do anymore? And are those the people that we want to lay off? Look at it from the strategy, not from the tactics. He said, that's not how I work. I said, okay, how do you work? He said, we'll take the 10% lowest ranked people and we'll yank them out. I said, let me ask you this question, where do you rank developers and testers? Oh, the testers are always at the bottom. I said, I rest my case. Why would you create second class citizens when we need an entire cross functional team that grows together to create products? I said, you can do anything you want, but I'm not Doing this nonsense with you. And he said, fine, you're gone. So that was fine.

It is the case sometimes, though, that there are people who don't have the skills and experience that they need to be effective. For example, if you outsource your work to an offshore development team in a low wage country, you'll get 50 people who've got two years experience and five people who've got five years experience. And there's a massive difference between the skills of developers or testers who've got two years experience and ones who've got 10 or 15 years experience.

Yeah, but we should apply agility to it. Treat as a hypothesis. So we have a hypothesis that we can actually operate with 10% less people. Let's not get rid of the people and then see if it works. Let's experiment and say, what do we need to change to reduce the number of people that it takes to build the thing we're currently building or to build less. We could say that Elon Musk has been successful because he fired most of the people at Twitter and Twitter's still around. I'd argue that actually nobody I know is on Twitter or X anymore. The value of that organization is gone and therefore the hypothesis was wrong. So treat it as an experiment a bit. We think we can do this and when. When it pays off, do it. If it doesn't pay off, you're doing something wrong.

Yeah, I like bet thinking as well.

Yep, me too.

Okay, so let's say that you have an initiative because you've fallen behind and you haven't invested in your products and services. And so now you need to catch up and just say, we need to replace our main E commerce ordering system. And your stakeholders are saying, how much do we need to put in a budget for this, Joanna? How much is it going to cost and what's my return on investment going to be? What would you do?

So that's where I say cost is the wrong question. How much do you want to invest for how long in this effort before you see any return? First of all, how can you estimate anything at the beginning of an effort when you don't know what it's going to be? I live outside Boston. I live literally eight miles from the financial district. It can take me anywhere from 22 minutes to 65 minutes to get there. It all depends on what kind of a car I'm driving, if somebody else is driving me so I don't have to park anywhere if there's snow. Why would I have to give an estimate at the very beginning of an effort when we know the least. Instead, how long do you want us to experiment with this and when do you want to see something useful? So when my kids were teenagers, I gave them a clothing allowance because the last thing I wanted was their hands out all the time for clothing. Because if you know anything about teenage girls, they can shop past they've dropped. So it was very important that they have the capability and responsibility for learning how to manage their money at that time. And I said to them at the beginning of the year, would you like all of your money in September or would you like me to give you half of it now and half of it in February? In February the sales will be on, so you can get two or three times more clothing if you can wait until February. And they said half and half. And then when my older daughter ran out of money in February because she spent all of her money on winter clothing and she didn't have any for the spring, she had to get a part time job. So the younger daughter actually learned from that. She said, I would like a quarter now and then a quarter later, and then a quarter later and then a quarter later. Why would we not do this in an organization? In what other lifetime do we allocate all of our money? Yes, we have to allocate enough for the mortgage and know that we have enough to buy food, we have allocation buckets. Why would we commit to all of this money up front before we see any return? And return on investment is totally meaningless for a software organization. Because what happens if I take something out of the product? Does that make the product more useful or less useful?

When I'm coaching teams around prioritization, I'm teaching them to define small things they can build based on the feasibility, viability and value. Describing the value in a way that a stakeholder can determine what the most valuable is. But whenever I go into a group who needs to prioritize, we are forced to put estimations in. So we say, here's 10 things, here's the description of the value they'll deliver. Which one would you like? And they go, how long are they going to take? But why do they need to understand cost when they should just focus on the value? What's your thoughts around that?

So I think you can help teams understand their cycle time. And if we have a general cycle time where 80% of our stuff is four to five days, that's roughly one thing a week, and then another 20% is either much lower or much higher, then you can still say what one thing do you want this week? And that really helps people understand that they can get one thing a week. And if they want A, B and C, they can get three of those probably in about three weeks. And then that's when I start to talk about cost of delay, where we say if you want A, B and C, that's probably three weeks, and if you want D, E and F also that's probably another three weeks. Now, if you're really focused on value, what is the cost of delay for D, E and F? Maybe you should put them first.

You know, I was thinking of a project that I consulted on a little while ago. They had two week sprints and a 12 week cycle time, which means that everything took six sprints to do and nothing ever got finished in the sprint it started in. And the reason was because they were working in silos and they called themselves an agile team. But the test team just refused to collaborate with the dev team. And the dev team are often just really confused about what they're supposed to do because they didn't have anybody in product finding things properly. I did a lot of work with them to focus on reducing cycle time and we got it down to two weeks and it made such a massive difference to the flow of work through to predictability, to value delivered, to morale. So I think it's really useful to focus on cycle time.

I really don't know how to do anything without cycle time. In thinking about what the cycle time means for the work that we want.

To do and, and for people who don't know, you can get it out of JIRA with cumulative flow diagrams if you use it properly. Let's talk about jira. Do you think JIRA is helpful for agile project management or is it just a micromanagement tool?

JIRA was built as a support ticketing system, not as a way to manage product development work the way people use it. It's a micromanagement tool. If you could assign one ticket to a team or two tickets to a team, that would reduce their wip, reduce their cycle time and make it possible for everyone to see what they're doing. The way we use JIRA in our industry is just broken.

Yeah, I find it's quite good if you use it completely vanilla out of the box with Scrum and Kanban and you use user stories, you don't use tasks or subtasks. But I find that managers love to break it down into individual tasks with hours tracking. And JIRA is thrilled to bits to be able to give managers that sort of capability, they'll give them anything they want. So if your managers want a very bureaucratic approach, Jira's there for you.

One of my clients really tried to use it to create what they called user stories, which were really lists of tasks, and make a roadmap out of those and then convert that to the project portfolio. And I said, that's not the data you're looking for that will not get you what you want. And he was so convinced it wouldn't. And no it didn't.

Let's talk about what good looks like. If you are engaged on a project, you are going to set it up to be as agile as it could be within that time box and budget. How would you go about it?

So I actually really like to charter a project. And the way I charter a project is to spend a couple of hours with the person who understands who are the customers we want to use this product and what problems are we going to solve for them. So it's all about the product and the problems. And then we spend a couple of hours saying what's the first problem we want to solve and can we release something and get it out to our customers every day, or do we have a minimum adoptable feature set before we can release it to these people? What are the criteria around what the customers are willing to take and then what is the one, two or three things that we need to do to show ourselves we can do that now? I don't want to do a two week time box of requirements. I don't want to do a two week time box of architecture. I want the entire team involved in understanding what is it that we have to do to solve problems for these people who will buy this product, what do we need to learn and how do we satisfy these customers? The longer I work with more agile, focused people, the more I really like a cadence of delivery, which if I had Marseille, we would deliver something every single day and a cadence of planning and, and the cadence of retrospectives and the cadence of demos that if we cannot actually deliver to our customers, that we demo to as many people as possible so everyone can see our progress. And that allows us to be agile in the sense of what the Agile Manifesto meant all those years ago.

What sort of people and skills would you have in your team from early on?

I really like people who understand architecture, not necessarily an enterprise architect. I have had several run ins with people like that. We also need people who will ask questions. I find testers really excellent at asking questions. So I want a mix of people. If there's several tiers of the architecture, I want at least one person from each tier. So I want as many people who understand the solution space. What did the internals look like now? It's possible that a product person only starts off understanding the problem space, but they need at least facility with the solution space.

So it's not just the technical people you want, the product managers. What other sort of business people would you have in the team from the beginning and throughout?

If they have information that we need, I want them because otherwise we've played telephone with them.

What about people with skills in user experience, research and design?

I would really like it if the people who do the front end understand what users need and want. I think that a lot of user experience people want a lot more time on the front end to experiment. But I think we need to just say user experience is a lot like architecture. It will continue to evolve as we proceed through the product development and we can, we cannot just stop it.

So what you're talking about is a cross functional team from early on. So a team that has all the skills necessary to take a product feature from idea all the way through to implementation and feedback as quickly as possible.

Yeah, yeah. And deliver something every day.

Deliver something every day. That's more XP than scrum.

Back when I learned about Scrum in the early os, I said, okay, I get that. I'd been working in month long time boxes. I've always worked with a totally cross functional team. Why would I not work with them now?

Yeah, all right, so let's say we're going to scale up because we have a lot of work to do. Would we have 50 people just in one big team or would we have people in smaller teams and then some people spread over the top?

When I think about program management, which is what I think you just described, all these people are in service of one product, one business, one large chunk of business value. So if we can agree on that, then I really like a program team which is composed of the software program manager, a program architect for the entire product, and often a program product owner. You might call this the product manager for the entire product. So I really like cross functional teams that work across the product and then they might have a designate to go up to the program team. But I don't like a lot of hierarchy. In fact, I much preferred when, when all these cross functional teams figure out themselves how to collaborate together. That's a small world network. And small world networks scale fractally. They can scale almost infinitely so if.

You have 50 people, you've got maybe four or five teams and a few people in the program layer. How do you communicate the risks and issues and goals up and down and sideways. Do you have a good approach to doing that?

The program charter, which is all about who are the customers, what do they need, how do we describe them so that we're always focused on delivering value to that customer. If we only focus on the risks about the project, we are doing ourselves a disservice. We need to focus on the risks to the customer and we need to focus on the risk of us being able to deliver something to that customer.

Yeah, I find organizations start by talking about outcomes in order to justify the budget. And then as soon as the project starts, they forget about it and they never talk about it again until somebody comes along three years later and does an audit. But the moment you start something, outcomes are forgotten and they get turned into deliverables. So how do we get the ideal team to focus on outcomes given that the work has to be broken down into small pieces so they can do it?

So this is where working through the architecture, just like an xp, makes all the difference in the world. I really like thinking about feature set. You might have 25 features in a feature set. You might only have three. It does not matter how many there are. There are distinct deliverables that add value to the customer. Each of those is a story. Collect all those stories and you got a feature set and we don't have to talk about anything else. Is this a theme? Is this an epic? Who cares if you have 25 things that deliver value? I'm not talking about make a database that does not deliver value to anybody. So I've worked on products as complex as mobile phones. You probably cannot deliver something of value until you have the operating system. But you don't need the entire operating system. You probably only need the texting function and then the calling function in your own network. Now, you would not release that to the greater world, but you can release it inside the organization and see where they are. Anytime you start to think about feature sets, it always has to be tied to an outcome that the user will want.

I think one of the key things here is that you actually measure your outcomes and you iterate towards them. So you measure your current situation. Let's take a very simple one. Lots of projects would say our project is to improve our shopping cart conversion of sale by ripping out what we've got now and putting in some big new thing. That's the whole Justification. But what if we measure it now and then what is the first thing we can do to improve it and then measure it? Because the thing is that if it's taking you two years to get any feedback, you're not thinking about outcomes. But if you can do something in a few days and you say oh yeah, that made it worse or that made it better, now you're really focused on outcomes. So it feels to me like a fast feedback loop with real customer and user experience is going to make you focus on outcomes a lot more.

Exactly, yes.

All right, Shane, did you want to go to summaries then? What do you got?

All righty. Love this one. This was great. So we started off talking about no more Gantt charts. And it's because the cost of updating those documents as a form of collaboration is much higher than the other patterns we have. So as you said, show me what you built. Let's have a conversation about it. And then you talked about this idea of outsourcing, the crown jewels of the organization. Why would you get that and give it to somebody else to build for you? There's some things that aren't important and you could probably outsource those if you have to. But apart from that, if it's part of your core business and that's what you're there for, why would you give it to somebody else to build for you? I love the quote, testers testing the solution against out of date requirements document. They're not testing it against solving the customer problem. That's the whole problem we have where we chunk the work up and do the requirements early and then split the teams into separate teams. I'm a great fan of self sufficient teams, cross functional skills, light documentation, constant feedback. And those were all the things that you were talking about in there. You brought another means to it that I hadn't thought about, which is back to Taylorism and cost accounting, managing control. But this idea that organizations are managing via cost accounting instead of just reporting via cost accounting. Love the idea of getting executive or the team to draw a diagram of how they organization makes money and then ask them where the bottlenecks because that's where we should invest time and effort to add value. And then you brought in the idea of how do we help them prioritize what the next most valuable thing is. One of the techniques is cost of delay. If we could quantify the cost of not doing it right now, then we can help them understand that trade off cost. And then you talked about people focused on problem space and People pro focus on solution space. That's where the role or skills of a product manager, product owner was meant to fix. And it's helped, but I don't think it solved it. And then I love the quote, teams figure out how to collaborate amongst themselves and then we infinitely scale. So our natural reaction when we want to scale teams is to put hierarchies in place. Even teams of teams is a form of a hierarchy. Every time you spoke, what I heard was ways of working that were founded on agility. And I think if we took the word project and program of everything you wrote, it would make me so much happier. Because you're talking about ways of working, you're talking about adapting to change, you talk about empowering teams, you're talking about focus on cycle times, you're talking about all the patterns that give organizations the ability to change faster with lower risk. And then somehow you just add that project and program word on it. So let's just go rub that out and then I'll be a happy boy. But no, that was good. There are lots of great patterns in there. So thank you. Murray, what do you got?

Yeah, I think the current state of agile project management is dreadful. More than 90% of the organizations I've talked to are doing siloed, phased and gated waterfall, with the dev and test team doing half of Scrum badly and managers using JIRA to micromanage everybody. It's just not delivering the benefit of being agile. The big problem is that you're just not getting any feedback and you're not focused on outcomes, you're not delivering value. Why do they do it? It's Taylorism. Scientific management from the 1910s as implemented through cost accounting. It's something you learn as you go through the corporate world. This is how it's done. I think managers are very afraid of initiatives or projects that don't meet their executive's expectations, and so they try and control everything and nail everything down. It might work if you're running a factory producing pencils, but it doesn't work when you're doing software development. In software development, there's always considerable uncertainty about what the problem actually is and what the solution actually is. And you don't learn those things until you do it. And yet everybody's demanding that it'll be written down upfront and the scope and time and budget all be fixed and it never works. And those projects always go way over. Time and budget deliver quite different scope that was expected at the beginning. And everyone forgot about the benefits five minutes after they start. So they don't deliver the business benefits expected and they just get called Agile now because they do a bit of scrum in the middle, but they don't do the most important part of scrum. They don't do the retrospectives and the continuous improvement. My view is that if you did real retrospectives where you looked not just at the team, but also the blockers outside the team, you would transform your organization and reinvent Agile from the ground up just by doing that. And it's one thing that people hardly ever do, or they just insist that it focuses on the team. I think it's just too threatening for too many people. It's just such a big disappointment. I think that the real benefit of doing agile projects well with cross functional teams that have the business people and the technical people from the beginning that are getting feedback every day from real customers and users is enormous. If you just delivered the same value but you deliver it every day instead of after two years, you get a big improvement in your return on investment anyway. But then the other massive advantage is that you actually learn what you really needed to do very quickly instead of what you thought you would need to do, which was always going to be wrong. I also really like what you were saying about giving away your crown jewels. Just so many companies have just decided that they're going to engage big offshore service providers to build their core systems that are responsible for everything they do. It's like outsourcing my brain and my nervous system to the cheapest people I can find who are going to do a crappy job because they don't know what they're doing because they're new and inexperienced. It's a nightmare. I don't understand it, but organizations keep doing it. There was an article in Harvard Business review in the mid-80s which said it is not important, it's not a competitive opportunity. And I think a lot of business people said, oh, thank God for that. It's also complex and difficult and these people were just so annoying. Thank God I go to somebody else. What else? I think risk and issue management is critical in all types of projects. And the way we do it in Agile projects is just by doing it every day through feedback and continuous improvement. Love what you're saying about Lean visualizing the work cycle time. I think we're very aligned on that. I like to start with getting key people together and having a charter and then finding out what we can do as quickly as possible. You know, I've always found that stakeholders insist on having a Budget that's defined up front. And so I like to have as big a budget as I can get away with, which is usually not enough anyway. And then fixing the budget, fixing the team, having the goal, but making the scope flexible and getting agreement on that in the charter. So we have a goal, we have some outcomes we're going to achieve, we're going to allocate this much money and that's going to give us all these people and they're all going to be full time and cross functional. And what we're going to do is manage our scope in a very flexible way. So we might not do all the things we thought we were going to do at the beginning, but that's because we've learned that there's better things to do to achieve our business outcome and we'll demonstrate value every day. We're not wasting your money. So I've had good success with clients, even in contractual situations in doing that and it worked well and they liked it. But there are managers you can't persuade. I think there are times when people like us have to walk away and say, I can't convince you, I can't persuade you. I'm an expert in this and now you're demanding that I do a standard SDLC with a strict change management framework. It's time for me to go.

I have fired several clients because if you look at my body of work, it's all based on agile and lean principles.

So this has been really good. How can people learn more about you, Joanna?

So everything is on jrothman.com J R O T H M A N Com. All my books are up there. I have at least one course that goes with every book. I'm still working on the project Lifecycles course because I anticipate that will be a self study course and then an option for coaching. I've been doing a lot of trusted advisor coaching for executives and senior leaders and a bunch of program and project management coaching. I find that the more people want to support their organization's ability to change, the harder they have doing it. I work with people to figure out what is the simplest thing that they could do right now that would help. And sometimes that's getting the cycle time down, sometimes it's the project portfolio. It's whatever this person has in their area of responsibility. So I've been doing a lot more middle and senior leadership coaching and consulting.

All right, that's great. Thank you very much for coming on.

Thank you for having me. This was really fun.

That was the no nonsense Agile podcast from Murray Robinson and Shane Gibson Gibson if you'd like help to create high value digital products and services, contact murrayvolve. Co. That's evolve with a zero. Thanks for listening.