Scaling Agile (With Giovanni Asproni From Zuhlke Engineering Limited)

Read The Transcript:

We’re trying out transcribing our podcasts using a software program. Please forgive any typos as the bot isn’t correct 100% of the time.

Ben Aston: Welcome to the DPM Podcast, where we go beyond theory to give advice that works for leading better digital projects. Thanks for tuning in, I’m Ben Aston, the founder of the Digital Project Manager. So, everyone’s excited about Agile, but how do you make it work across multiple teams or projects? How do you speed it up, and where can it go wrong? And how do you stop it going wrong in the first place? Keep listening to today’s podcast understand how we can scale Agile delivery and how we can make Agile work at scale. This podcast is brought to you by Clarizen, the leader in enterprise project and portfolio management software. Visit clarizen.com to learn more.

So, today I’m joined by Giovanni Asconi. He’s the principal consultant at Zuhlke Engineering Limited. I probably butchered that, but he’s based in London. He’s a software architect, a programmer, a coach, a consultant, with stacks of experience across all different verticals including tell-code, banking, oil, and gas. He’s been to lots of conferences, he’s contributed to various books. So, Giovanni, thanks for joining us.

Giovanni: Hello. Thanks for inviting me.

Ben Aston: And how should we pronounce the name of your firm?

Giovanni: It’s actually Swiss name, it should be Zuhlke.

Ben Aston: Oh, there we go. Yeah, well I wasn’t going to get that right.

Giovanni: I butcher it all the time as well, so don’t worry.

Ben Aston: That’s cool. So, yeah, tell us a bit about what you’re working on now, we were just talking about it before, but what would a typical day look like for you?

Giovanni: Well the typical day for me, in at least these days, is kind of busy, so I started at the beginning of June, a new project, in which I’m actually following my own advice, which is very wise. Yeah, after [inaudible 00:01:50] with the large customer of Zuhlke, myself and a few other colleagues we run an assessment of a very large scale program they’ve got, we are talking about 500 people, 57-60 teams, something like this, and now we are implementing part of the recommendations that is basically providing them with a system to actually gather some project and program matrix to manage the whole effort much better. So, is quite busy, I’m doing… technical leadership and the requirements, and then reporting to all levels of management in the customer company, writing also some code as it happens.

Ben Aston: Nice, tell us a bit about that assessment process that you go through. So, I think it’s interesting that you don’t just go into a company and say hey, you need to do… scram, and try and roll it out, but there’s an assessment involved, right?

Giovanni: Yes.

Ben Aston: What does that look like?

Giovanni: So, what happens in an assessment… what we do is try to understand what’s going on, basically-

Ben Aston: Yeah.

Giovanni: So, we speak with people, representatives of the teams, of management at all levels, and try to figure out what is happening on the ground, so we also do covert reviews for example, we see all the processes the teams follow, we see the way they commit code to the [inaudible 00:03:16], anythings they do for quality-

Ben Aston: Yeah.

Giovanni: We speak to the management to understand their view of how things are going. So basically we create a picture of the situation because this kind of large projects, they have many, many similarities but usually the details of the contests are quite different.

Ben Aston: Right, and so in terms of your recommendations, after you do these assessments for the large company, how different, though, are your recommendations each time when it comes to implementation? Does it all kind of fall back to the same kind of thing?
Giovanni: No, so it depends on what we find. I have to say that some things tend to be the same, because-

Mm-hmm (affirmative).

Giovanni: Just because we make mistakes in the same ways as it happens.

Ben Aston: Yeah.

Giovanni: Just to give you a quick one, is usually when companies scale up to very large scale programs. We are talking about maybe 100 people, 200, in this case, 500. I’ve seen it pop to 1300 in a single product. When they do that, they do that to try to go faster but generally, they don’t have the instruments in place to understand what if they are doing actually is bringing any advantage.

Ben Aston: Mm-hmm (affirmative). So, you talk about instruments, so what are the tools that you use to evaluate whether or not it’s… the scaling up that they’ve done by adding additional resources is actually working or not?

Giovanni: Well, we look at various things, so in my article when I talk about the prerequisites of… for scaling, we actually look for those things, so we try to understand if everybody understands what they are supposed to do, if they are pulling the same direction. You would be surprised how different people often see the goals of the project to be different.

Ben Aston: Mm-hmm (affirmative)

Giovanni: They end up pulling in different directions. So, what I’m doing now… so look for use of metrics, you have teams, you have people. How do you know that they are going faster instead of… without using feelings, but actually real data, for example.

Ben Aston: Mm-hmm (affirmative). Yeah.

Giovanni: We look at the system design, the architecture if it suits the team structure. There are many things, communication channels which often in large scale projects tend to be ossified into kind of very formal ways, and then people are unable to solve problems quickly.

Ben Aston: Yeah, yeah. So, I mean, we’ll dive into your post in a minute, but in terms of just talking about you for a second, I’m curious to understand, from your vast experience of scaling Agile or maybe even just working on Agile teams. Can you tell us about, perhaps, your biggest screw up that you can talk about and what you learned from that? Where have you gone wrong and how can we all avoid doing the same thing?

Giovanni: One have gone wrong that’s been fairly recent, actually. It was not a gigantic screw-up but was a screw up in some ways and in that particular case I was sent to the ground to solve some situations, we had problems with some of our teams and some of the customer teams. At Zuhlke we work, often we work [inaudible 00:06:49] within the custom organization as well.

Ben Aston: Right.

Giovanni: And so many things went well but then actually what happened was some political situation in the company brought the project to an end for the wrong reasons. So, in that case, I guess that the learning there is sometimes, even if we seem to be aware of what is going on, sometimes we are not really seeing some things coming.

Ben Aston: Yeah.

Giovanni: So we had an issue with some internal political games within the customer company and we were caught in the crossfire.

Ben Aston: Mm-hmm (affirmative).

Giovanni: So…

Ben Aston: Yeah, politics is always important, however much we don’t want it to be.

Giovanni: Well, it is important, you know, politics in itself is not good or bad, yeah?

Ben Aston: Oh, yeah.

Giovanni: When you humans together there is always politics. The trouble is how you use it.

Ben Aston: Mm-hmm (affirmative) Definitely. And, in terms of again being kind of generic and high level, what, if you were giving someone advice who’s thinking about, and I think a lot of our audience would kind of be in this kind of boat, they’ve begun thinking about Agile because that’s what customers say they want, whether or not that’s what they need is another thing, or whether or not that’s something they can support is another thing. But what would your top tip be for someone who’s thinking about, hey, I want to start working Agile and I think most clients would say, okay, what’s important if you ask them, okay, how do you want your delivery or what do you want your delivery to look like? They would say, well, it’s really important that it’s Agile. So, what would your top tip be for someone who’s working with a client who’s never really worked in an Agile way before, or isn’t even perhaps sure what it is, but just knows they want to be Agile? What would your top tip be for someone in that position who’s tasked with implementing Agile with a client who’s not really familiar with it?

Giovanni: I think that the top tip is actually to understand and clarify expectations. So when people say we want this project, they want to be Agile, is what do you mean? What is the need? What problem are you trying to solve? Yeah?

Ben Aston: Yeah.

Giovanni: Because agility is not the goal, yeah, is a mean to an end, or to several ends so, and what I find is that often people decide that they want to be agile because they heard that other companies are doing the same and by doing that they are doing fabulous stuff, going very quickly and delivering stuff very fast, which is generally missing the point, yeah?

Ben Aston: Mm-hmm (affirmative)

Giovanni: So it’s about expectation management, I think, and clarification.

Ben Aston: Yeah. No, I really like that and I think it’s so important that the goal isn’t the process, the goal is delivering value.

Giovanni: Yeah.

Ben Aston: And delivering value more efficiently, and ultimately delivering results, rather than being focused on the way that you get there. Now, that can help. That’s not the end goal. So, sound advice. Thanks for that. And, can you tell us what is in your toolkit? So in terms of the tools are like software, tools that you use, or maybe analog tools that you’d use when you are assessing and implementing and when you’re helping a team [crosstalk 00:10:39] become more agile.

Giovanni: One thing that I actually use is very analog is my Moleskin. So when I speak with people to assess a project are generally…I’m not generally in the room with technology because, you know, if you open up a laptop, puts a barrier in front of you, yeah? You and the person.

Ben Aston: Yeah, yeah.

Giovanni: And writing down with a notepad is much less threatening. So this is the main hardware tool that comes with me. Pen and Moleskin.

Ben Aston: Yeah.

Giovanni: In terms of other kinds of tools, I actually use software to…I copy my notes into software. It’s called Scapple, the one I use. That is…basically allows me to write things and connect things together but not in a…you can connect everything with everything, so it’s not simply a tree structure

Ben Aston: Right

Giovanni: But is more a bush or a forest, which I find it helpful. I write down all sorts of thoughts. Actually, this might be another thing, so, when you are talking with people, assessing something it’s not important to only listen to what they say, yeah? Is important to also read the room. So, understanding that if they are relaxed, they are tense, if they may be saying something they are not convinced about, is important to actually read the people themselves, as well, yeah.

Ben Aston: Mm-hmm (affirmative)

Giovanni: And another suggestion is when you talk with people in this kind of assessment you need to do that in a safe environment. So, for example, when I do these things, if I need to speak with developers about, in a team, about their views of how things are in the project, I make it very clear that I don’t want managers inside in the room. Okay?

Ben Aston: Right.

Giovanni: And I do the same with the managers, as well, because, you see, even in situations where people tell you, yeah we are a very open company, everybody’s free to express their thoughts and whatever, in practice is always more complicated than that.

Ben Aston: Yeah.

Giovanni: So safety is super important.

Ben Aston: Yeah. And going back to more software tools, in terms of actually running Agile projects, do you have a preference for Agile project management software tool that you often recommend? Or does it really depend?

Giovanni: It does really depend. It does really depend. So, in general, what I would say is if you are in a situation where everybody’s always in the office a whiteboard works very well. And then maybe you can take pictures of the whiteboard if you want to say something online or stuff like this. Even if you have a team that is not distributed but people work from home or sometimes from home, sometimes from the office and things like this, then it’s better to have electronic tools. One tool that is very common is Jada. I don’t particularly love it because it’s slow and has its own problems, but it is better than a whiteboard when you have people that are in different locations.

Ben Aston: Yeah.

Giovanni: Yeah?

Ben Aston: Yeah.

Giovanni: So, for me, it’s really context-dependent.

Ben Aston: So apart from your Moleskin, and did you say the name of your note-taking bush tool, that’s called Scapple?

Giovanni: Scapple. S-c-a-double p-l-e. Scapple.

Ben Aston: Okay, Scapple. Cool. Are there any other tools that you’ve discovered recently? I know our audience always loves to hear about new tools. Is there anything else that you’ve found recently that you’re like, ah, this is incredible, people should be into this?

Giovanni: Not really. To be honest, I don’t even look for that. I am in a phase in my life, and professional life, where I’m not really looking for the special tools, you know? Often keeping it simple is the best thing you can do.

Ben Aston: Yeah.

Giovanni: Okay, so what I would recommend is the simplest tool that does the job in your [crosstalk 00:14:57].

Ben Aston: Definitely. Definitely. Cool, but let’s talk about your post, and I think this was a really interesting post, all about how we scale Agile. And it’s a well-known fact that adding more people to a software project isn’t necessarily going to increase productivity, as you mentioned just now, and actually in most cases when we add more people often what we see is a productivity drop as confusion starts happening, people get confused about what they’re working on, why, how, integration becomes difficult. So, there must be a better way, though, to get more stuff done. So, Giovanni’s written a great post which outlines rules, the law of scaling, prerequisites for scaling, some considerations on team structure. And so if you haven’t read the post yet, I recommend go to thedigitalprojectmanager.com and check that out.

Let’s go back right to the beginning and talk about why this is important and for the uninitiated, for people who are thinking, hey, well, do I need to know about scaling Agile, tell us why should we care about scaling Agile at all? You’re a consultant in it, you do this every day, but why is it that this is your job? Can you tell us why it’s important?

Giovanni: I’d say that it’s important to know about scaling because sooner or later you’ll come across it. Especially if you’re working, even medium companies, but especially in big ones, projects for some reason tend to grow big, in terms of number of people involved. In terms of what I would recommend in general is, don’t. Don’t try to scale it or, first of all, try to sort out the situation you have at the moment. Why do you want to scale? What is the reason? Are you sure you can do that? For example, in the prerequisites, I put things like if you don’t do those things, well, forget about scaling because what you’ll have is a bigger mess. And also it’s interesting that I can tell you that all the large scale projects I’ve come across, including the thirteen hundred people one, that one was amazing, thirteen hundred people read two thousand repositories and just a gigantic thing…a mess, a messy one. Usually, these kinds of projects you need more than twenty, thirty people to actually do a good job. And I’m not joking, I’m not exaggerating. So just to make sure. There is a friend of mine that once told me, half tongue in cheek, half-seriously, told me that the number of people to put in for your project, any project, should be the minimum between the number you’ve got and time.

Ben Aston: Right, yeah.

Giovanni: But, in general, is you really need to work effective and efficiently to start with before growing up.

Ben Aston: When we’re talking about scaling Agile, obviously the theme that’s coming through is keep it as small and as lean as possible because that’s the way that you’re going to maximize efficiency, that’s the way that you’re going to maintain clarity on the objective and make sure that you’re all delivering value. But, beyond that, in terms of the approach or the processes and systems that you put in place when you scale Agile and you’re working with this five hundred person organization, is it always a one size fits all? Or do different people and teams need to be managed and have different architecture of that process to make it work?

Giovanni: I think that one size fits all never works. It really never does. Probably especially for large projects because when you have five hundred people, a thousand people, may fifty, sixty, a hundred teams, the population is so large that invariably you’ll end up with teams that have different needs, different preferences, different styles. That said, there is an element of uniformity that needs to be introduced somewhere, [inaudible 00:19:30] because otherwise, we’d be impossible to actually understand what’s going on for the overall project. My suggestion there is, usually, in general, let the teamwork in their preferred way but what you need is some interface, especially reporting systems or the way of reporting progress, of showing what is happening, of transparency, somehow there should be some interface that is consistent across the teams. Otherwise, for management can be impossible to get the hang of what is going on.

Ben Aston: What does that reporting look like? [crosstalk 00:20:12] How do you keep that uniform across teams that want to work in different ways?

Giovanni: There are many ways. For example, instead of imposing Scrum to every single team there are some things that need to work in a more flow based way, probably because they have some event based work flow. Let’s say teams that are doing development but also user support, for example, the cannot really commit to user support for a couple of weeks. When the user calls, you better do something. So its more event based. Teams like this have different needs but from a high level, instead of focusing on the springs or on the floor or something you could always focus on what is the [inaudible 00:21:01] in terms of stories, features, epics, whatever they are measuring. So, if five of the teams are using Sprint or Cobana or something similar, you can still measure that. You can still do that level of analysis. You can do all sorts of level of analysis, [inaudible 00:21:22] you can do level of analysis of what is happening in the code, as well, which is one of the things that I’m doing the current project. Measuring, for example from the code, there’s also how the teams interact or, more often, interfere with each other.

Ben Aston: Right, yeah.

Giovanni: So there are different ways to, there are many ways to actually do that.

Ben Aston: Talking about then what does good scaling look like, and what does bad scaling look like. It sounds like what you’d propose is giving the teams autonomy, rather than necessarily dictating. So, dictating as little as possible and just ensuring that the connections between the teams work well and efficiently and that you are able to analyze across different teams how progress is being made to give management a good, clear idea of the velocity and where the projects at. But what else does bad scaling look like to you?

Giovanni: For me, bad scaling is scaling that is done, usually, by [inaudible 00:22:37] somebody high up in the management chain decides that everything is too slow, they want to go faster and they throw people at the problem. That is a typical scenario. It’s common enough that it’s worth highlighting. That is the most typical one I’ve seen.

And then, from there, things that bring to bad scaling, for example, are project planning where the planning is done based on capacity planning. This is a hundred person E-R effort, so we’ll hire a hundred people and we’ll finish it in one year. It doesn’t quite work like that. Or these questions don’t work so you need a victim of a better, more refined view of planning. One things that I’ll suggest, in general, because of course it’s not simply leaving the things alone, you really need to have the appropriate people with appropriate skills in the teams. So, for example, if you have a team of young people that are inexperienced without anybody to actually guide them then they go off to the tangent to implement something, some little piece of code in a beautiful way but is probably not that important in the grand scheme of things. You need to have the appropriate people. But in general, the best way to scale is actually involve the teams and the senior technical people. Basically asking them, can you do with a few more people? Do you need help? Have you got work for more people? This is the best way to actually start the conversation. People doing the work are the ones that know that if they need help or not.

Ben Aston: So, awareness, really.

Giovanni: Yes, awareness is definitely important. I would add another thing I think is important also. This is a bit controversial now, I hope to ruffle a few feathers. One thing that is important for people in a project is to actually understand what their real role is. The controversial thing is the following: if you are talking about softer projects, this is what I do so this is what I’m an expert on, now, in any softer project don’t let people who are actually indispensable, that have to be there at all times, are programmers that actually write, programmers, I mean, people that write the code, I’m not even including testers, and people that use the system, and some users because these are the two things that have always to be there in a successful system.

Now, the fact that these are the only two that are mandatory for successful system doesn’t mean that the others are not useful so everybody else is optional, project managers are optional, consultants are optional, like me, or testers, because depending on the kind of project you need, you may or may not need them. So, in practice, this means the role of the people that are optional in this context is actually to make the programmers more effective and more efficient. It enables them to do a better job. Now, if you, as a project manager think in these terms, you start asking different questions. So instead of telling the team what to do, you start asking the team what do you need from me? What can I do for you so you do a better job?

Ben Aston: That’s good. In terms of then the best scales Agile that you’ve seen, can you talk about what you think made it work? What do you think made it so good, like at it’s very best? What does that look like? It sounds like it’s a team that’s empowered, that is supported by people that are trying to enable them to do their best work, but talk to us about the different ways that you’ve seen scales Agile really work well.

Giovanni: Now, really work well, I’ve seen it only once or twice and for not very large systems. I’m talking about work with five teams or something like this, so we’re talking about maybe fifty developers and testers, something along those lines, in five, six teams. When I saw that working, basically it was a situation where people knew what they were doing, they knew what their place in the grand scheme of things was, and those saw to implement features, functionality, to get stuff done, they knew who to talk within the other teams. So there was a level of formal communication but a lot of informal one with people who actually knew what they were doing but still was small. The very large I’ve seen all of them had big, big issues and they could do with one tenth of the people they had. It’s simply because they were scaled, as I wrote in my article, they were scaled for the wrong reasons. They just threw people at the problem without understanding if that was working or not.

Ben Aston: So in terms of out of the box scaled Agile frameworks, like Scrum-like scale, large-scale Scrum, what’s your opinion on those? What’s good and what’s bad about them? If someone’s decided that they need to do Agile at scale because, like you’ve said, someone at the top has decided, hey we need to deliver this thing faster, what about those out of the box frameworks? And, did they work or not?

Giovanni: I know of some situations where some of these work. I know for large scale Scrum, not in projects where I was directing role, but where some other consultants that I know were involved. It worked, but they saw that working only once or twice basically because the appropriate context for the framework. So, in general terms, I don’t like this out of the box frame or [inaudible 00:28:57] because, basically, they try to cast you project into their shape. So a characteristic of any framework is that for them to work they assume a surrounding context. So if your surrounding context doesn’t fit the framework, you are in for an interesting time. And also, they tend to focus a lot on structure but they don’t focus enough on what people actually do, day-to-day. And the last one, also, this is actually my biggest bug [inaudible 00:29:31] with out of the box frameworks, especially with Safe, I have to say, is that they design in a way that makes management feel a warm feeling of control, but is not really helpful for the people actually doing the work, using the framework to do the job.

Ben Aston: I think that I would say the same thing as well about Scrum, just as a whole, in terms of a framework, and I like what you say about any kind of framework or process assumes its context and that context has to be true in order for it to function properly. And I think sometimes management might think, well, the solution to this is that we just need to do Scrum because it’s all written down on a piece of paper, it’s easier to understand, and we should be able ship stuff faster and more efficiently. But it doesn’t take into account the team, the project, the clients. It doesn’t take into account anything, really, other than just describing a process and I think sometimes people can get caught up in the process or the framework, rather than just thinking a bit more intelligently about, hey, well, let’s work out a process and a framework for us that works for our team, that works for this project, that works for our client, and the limitations that we have. And I think people can be quite nervous about that thinking, but it’s not Scrum. Scrum says we should have Sprints no longer than four weeks so we’ve got to follow the rules, right? And actually, we can be a bit more nuanced about it.

Following the rules just means you’re following the framework. It doesn’t mean you’re delivering value better or faster or more effectively.

Giovanni: I agree, I actually agree. In fact, the first time I actually, long ago, so I’ve been [inaudible 00:31:49] development since 2001. I got involved in that when I was little, but the first time I’ve actually introduced extreme programming in a team, at that time extreme was sold as thirteen practices and things and stuff. But the way I approached that was with a team we agreed what our goals were and started small using the one or two practices that gave us value and then we could learn them and then we could build on them, maybe adding some stuff on top. This is actually another important aspect when you go with a framework that has quite a few things that you have to use at the same time. You also get overwhelmed with the amount of stuff you need to learn just to use the framework. And this is especially true with things like Safe, or Scrum@Scale. It is just too much.

So, ideally, even if you start small, any project, if you start small, with a small team, you can actually learn everything from the very beginning. Then you can grow in an orderly way, improving your process, adapting as you go, adopting new practices, adding new people if necessary, but doing that with actually a reasonable way. We are humans, we can’t learn too much at the same time.

Ben Aston: We can’t learn too much at the same time and if we suddenly have a framework forced upon us, we can go through the motions, but then what you find is that people think, okay, well yes, we’re doing this Scrum@Scale thing and on the surface yes, they’re doing that but actually they’re just reverting to the same way that they’re working before and you were just creating overhead because people are trying to adhere to certain practices or processes that actually is divorced from their real works. It then becomes this smoke and mirrors, where people are trying to not get in trouble but really just want to get on with their work and do it the way they were doing it before.

Giovanni: Yeah, I agree. And, as a consultant, I see these all the time. We were doing Scrum, we do the stand-ups and during stand-ups everybody says something, but nobody’s actually listening at any point because all they want is to go back at their desks and continue with whatever they were doing before. Or retrospectives that become whining contests. People start to moan and whine and protest, then leave the retrospectives, no actions. Things like these. Basically, they go through the motions without understanding the reasons for doing that or without understanding how to do those things in a way that is actually providing value. In fact, this is what many companies do now. They [inaudible 00:34:54] what they say, the Spotify moment? Plenty of companies now go with the tribes and chapters and things, and the funny thing is that, as far as I understand, I have never worked at Spotify, but I understand that even Spotify doesn’t use the Spotify model because they continuously adapt their processes to their needs.

Ben Aston: The great thing about the Spotify model though is that it feels like it makes sense, right, so people watch the video, which I think is a really helpful video, and we’ll put this in the show notes, the Spotify model. It makes Scrum feel like it makes sense at scale, or at least show how it feels Agile, there’s pretty pictures and it’s lots of circles and people in groups and working together. The reality is, we have to create a process that works for our teams, that works for our projects and the type of work we’re working with, and the context. And I think that’s what’s coming through in our discussion for me. Context is so important and we can’t put blinkers on and ignore the context. We need to embrace that context and when we do that and treat our teams as, not just names on a piece of paper, but accept the fact that people are going to work differently and different teams are going to have different needs, then it’s going to be a lot more effective.

Giovanni: Yeah, that is very important. And one thing, actually, that I think in reference is of my article that is a book that I strongly suggest that is called “Six Simple Rules,” which is interesting because I’ve used those rules in my consulting work. The first one is: before doing anything, any changes, know what your people do. Don’t assume they are doing stuff in a certain way, just go there and see what they are actually doing, the difficulties, the problems. And then from there, you can start actually creating something that makes sense for the organization.

Ben Aston: Mm-hmm (affirmative)

Giovanni: Instead of assuming and then coming up with pre-made solutions.

Ben Aston: So for project managers, so most of our people listening here will be people who manage projects, they’re project managers or producers or product managers. For someone in one of those ancillary roles, they’re not producing code and they’re not a user, what would be your most important take away for them? What do you think, as someone who’s trying to support the process and not get in the way, but help their team do better work, what’s the most valuable thing that they can do to provide most value to the team?

Giovanni: Well, I think the most valuable thing they can do is actually understanding what their team needs from them. So just ask how you can help them. And the thing that I also recommend project managers, by the way, I’m on of the Agility people that actually likes projects managers because the fact is project management work is important, especially when you have medium-large projects. Somebody has to do it. So, it’s not like we are Agile, we don’t like project managers, go away, and then everything is a mess again. But, the thing that I will suggest also to project managers because I see that this is often missing is assume that the people working on your project are doing their best in their context. So don’t second guess people; ask them. And then you’ll find that you’ll have plenty of help to provide. Especially programmers, they probably don’t want to get involved in anything to do with budgets, schedule, things values kind of bureaucracy documentation that has to be done is important, but some of the people involved simply don’t want to do that.

Ben Aston: No one wants to be ultimately responsible for the budget, the schedule, or the statement of work. And I think, again, it’s refreshing to hear you say that when most conversations about Agile nobody’s really talking about those things but they’re there, they’re central to our world in that someone paying for a project wants to know when it’s going to be delivered and wants to know how much that will cost and what exactly they’ll get and that’s something that, in most conversations about Agile, it’s kind of glossed over and it’s kind of assumed that this is just an internal team working on something, there’s endless budget, endless time, and no one really cares about exactly what’s going to be done when. [crosstalk 00:39:58]

Giovanni: Those are things, and this is also why, personally I’m skeptical with many conversations in the no estimate camp because some of these people talk about you can do [inaudible 00:40:14] you have to do to have a best effort there, people want to know these things. Your customers.

In this respect as well, for the work of project managers, when they want to give schedule or forecasts or something to customers, ask the people doing the work to provide the estimates. Don’t ask them to give you better estimates if you are not satisfied with the number, okay? So if it is too long or too expensive, just don’t ask, do it again, and give me less because when you are doing that, what you are doing is you are not asking for an estimate, you’re asking for a commitment, which is a different thing. So if you are not convinced, my suggestion is, ask questions. Why would it take so long? Can you explain, please? Why is it so expensive? But they have to be genuine questions. And if it happens to be that that is the best estimate, what you need to do is actually to have the guts to defend your team in front of your customers. If you do that, your team will love you for that.

Ben Aston: Yeah, definitely. It’s so important that, as project managers, we’re not just doing top-down estimating, where we’re, you know, we’ve got 100K so trying to slice the pie into different pieces and then enforce the developers into that. I like what you’re saying about, it is just an estimate and I think the communication around estimates is what’s so important. It’s hey, this is an estimate, we think we can deliver it within this time, but we’re working with technology and it’s complex. So it is important that we communicate that to the client and it’s important that we interrogate the team, in a nice way, when we get an estimate from a developer that seems really large, more than forty hours a weeks work, that we break it down, but then you also ask the developer, why are you giving me this, why do you think it’s forty hours? Can we break that down? Try and break it into those smaller chunks as much as possible and then keep asking those questions, and I think that’s where a project manager’s role within an Agile, whatever that means, environment is so important is because our role is communication.

We’re communicating. We’re this hub of communication between the teams and the clients and the customers, making sure that we’re providing clarity. Clarity in terms of vision and direction. This is what we’re doing and why we’re doing it and this why it’s important because it’s going to deliver this value. But also, in terms of clarity of communication, like this is how long we think it will take, how much it’ll cost, and what we think we can do in the time that we’ve got.

So, Giovanni, thank you so much for joining us today. It’s been great having you with us.

Giovanni: Thank you very much. It was a pleasure.

Ben Aston: And I wonder what you think. Have you tried scaling Agile? How did it go? What works and what didn’t work? Tell us in the comments below. And if you want to learn more or get ahead in your work, come and join us, come and join our tribe with DPM membership. Head to thedigitalprojectmanagement.com/membership to get access to our slack team, templates, workshops, office hours, eBooks, and more. And if you liked what you heard today please subscribe. Take a couple of minutes to leave an honest review for the DPM podcast on Apple Podcasts. But until next time, thanks for listening.