Let's talk about using Agile with non-Agile stakeholders. So those could be audiences inside your company or external customers, other partners that you're collaborating with. Here we have this Gantt chart again, this sort of non-Agile thing. And to draw a parallel, I will have entrepreneurs creating new ventures come to me and say, well I know there's a lot of uncertainty inherent in my venture. And that, from my prospective, the right investment of my time and the guiding items I want to use to manage my team, it's not a business plan. I know that it's overly elaborate for what I have visibility into. But, I have an investor that I need to have and they're demanding a business plan. Well, what I would tell them is if that's the case and you really have to do it make sure you understand what they need out of that business plan and do your best to give it to them. But, don't necessarily go back and run your company with that plan now. It doesn't need to change the way that you operate. You have an idea about how you should operate, and then you have certain audiences that you need to satisfy, so the job is not to change the way you do business, it's to satisfy the stakeholder with whatever it is exactly that they need. So use your design thinking tools, for instance, finding the right problem and then driving forward to the right solution instead of just saying, okay they need a business plan. I'll go and write a business plan. Because that's very wasteful. A. You may not be giving them exactly what they need, and B. You're going to be spending a lot of time and confusing the issue for yourself internally. We want, and let's say this is a manger inside your company. Well, we want our managers to be perfect. We want to go to them and say hey, I have these ideas for using Agile and product design principles, isn't this really great, we're going to fail fast and they say no, my God, I think I'm going to get in trouble with my boss because this is too crazy. You know, make sure you know your audience and nobody's perfect. A lot of these ideas may be new to them. They may not have had the time to understand them in the way that you have. So make sure you understand what they need and go to them with an audience specific message. And if they need things from you that are sort of contrary to Agile in certain ways, figure out what the real problem is that they need to solve and then figure out what the right solution is. And focus on that and doing the right thing rather than completely following some arbitrary script that was created for, who knows why and probably doesn't conform with Agile. So here are a few specific examples and a little bit of sort of mini narrative to describe the situation. The first one is ask for generalized budgets vs specific headcounts. Where does this come into play. Well, very frequently, I'll work with a big company and we have an Agile team. They're doing a new product or a new system internally and they've done their first couple releases and they're killing it. It's great. So their manager says hey, nice job guys, and congratulations. I'm going to take your team from seven to 28 next month so we can pour fuel on the fire and scale this thing up. Now Agile absolutely scales, but as you know it scales in small teams. So they can't immediately go from seven to 28 people, it's not that kind of situation. So they know that that'll kill the golden goose, and what does this manager do? If it's a big company they don't want to miss out on the budget cycle. On the other hand they know that they're going to be mostly spending time trying to figure out what these other 21 people should do, and they're going to be expected to dramatically ramp up their output, which they're not sure they'll be able to do. It really is a difficult situation. So, one tip is to ask for a generalized budget versus a specific head count, kind of like if you were managing your own PNL almost. And the idea is they're going to say hey, great job, we want to ramp up the team and you're like what am I going to do. And you want to explain to them that Agile can scale because you don't want them to come to the conclusion that your team is permanently small and they can't invest in it because it probably is a good place for both them and for you to expand. Just not quite that quickly. So instead, they may tell you hey I need to submit a budget. And then that's you know their specific problem. Well do they really need to submit individual role by role head counts or can they just submit a general number? You don't talk to them about that because you're probably not sure exactly how many devs versus testers versus whatever else you may need. And maybe you need money to go travel and see your offshore team or go on a research visit to look at users. And so, as for generalized budget, explain to them why and see how that goes rather than just filling out the template. And here's a second tip. Collaborate on specific objectives and agree to a process rather than an arbitrary schedule. And this is for the situation where management has come to you and said, look we have this big initiative. Let's say, we're rolling out a new sales force into the marketplace and your software is going to be the thing that they use to manage all of this stuff. So I need a detailed schedule with dates because that's what I think I need to make sure this whole thing is going to fit together and be okay. Well,it's not a completely unreasonable thing for them to ask. They know that they need software to power the sales force and, yet, you know that if you lock up all the specific details and that's what everybody thinks is the definition of success. You're very likely to build something that's very inferior to what you could've delivered if you were using these Agile processes. So my recommendation is, instead, to work with them on what is it that we exactly know that we need for this audience. I mean, do the things that you've learned how to do already. Go learn about those salespeople, learn about the channel, show them how you're going to find out what makes sense and tell them about. Not in great detail, but tell them about your iterative process and how you can keep them informed about how things are going and then thirdly, focus on those thin slices. So remember, think about first, okay, let's talk about what we know about this. What would we absolutely, positively, have to have on day one of this sales force being out in the field to make sure they're okay? Because it may be that their mindset is, well, we should try to cram as much software in as we can because that increases the odds that this sales force is successful. But as you know, that's a fallacy, especially if you're trying to schedule this out in advance. Instead focus on nice, thin slices. Try to test those early. Tell them hey, I want to see these sales people before we even roll out the whole grand scheme of how they're going to use the software and what they're going to do. Let's try to get them in in two weeks and test some initial stuff with them, and make sure they can use it, so that is my recommendation. The tension will often be, well the Agile team doesn't want to agree to anything because they're doing Agile, and I have all this stuff I have to orchestrate. Well, agree to a specific process to help work with them and make sure they get what they need instead of a specific schedule with lots of detail that's predicted in advance. Here's another example, here this happens all the time but we need more specific dates for a marketing or PR thing. The same basic thing applies. What do we want to be able to say about ourselves? Let's talk about that and then I'll figure out what functionality and work with you on it is going to be impressive, and link with your narrative the story you want to tell through these marketing and PR channels. And, okay. This is sort of the solution of last resort. If all else fails, if your ability to find the right problem and work iteratively with your stakeholder to get to the right solution just fails. And they say look, it's your job to make a schedule. Just get me a schedule. Then keep your deliverables very general because you don't know enough to be more specific. It's unclear what they need to be able to do with this schedule. So, they're going to tell you, look I just need dates, give me a schedule, I don't care about your Agile, or whatever. So, if that's the case, give them a schedule, put items in there, and make them as general and implicitly make them as sort of problem-focused as possible, so for instance. Let's go back to the sales channel example. So let's say, hey, release 1.x is a solution for account entry. Well, there are going to be accounts, they're going to have to be entered. Let's say you feel like you know that, that's probably okay. Now that doesn't stop you from saying all right, well let's step back, look at the problem of what these people need to do, they need to sell stuff and back into this. It's probably sufficiently general that it's not going to pin you down into something that doesn't make sense. Do you want to do account stuff first as your first iteration, maybe, maybe not. But it probably won't be something terrible so think about how you can frame the deliverables in terms of problems, implicitly or explicitly. And then create the best schedule you can, but try to avoid having it giving up and having it dictate exactly what you do each step of the way. And then continue, don't give up on your stakeholder either, continue to try and understand better as you go along how things are working for them, use short cycles, try to put working software in front of them so that you can learn about what they really need. So those are a few techniques for working with internal stakeholders who are not operating with Agile principles and cadences and how to get them what they need while still being successful with Agile. And we're also going to look at here shortly how you can work with big customers. This is another thing a lot of big companies have. And solve a similar type of problem where they feel they need advanced dates.
