 So this talk is going to be a little bit different from the ones you'll probably hear. I'm not going to talk about the technology. I'm not going to talk about agile practices or processes, or I'm not even going to mention the manifesto that much. This talk is more about how other business functions work. Here's a quick call of hands. Who here works in IT in some fashion? Yep, most of you. That's pretty much what I expected. This talk is not going to be about IT. This talk is going to be about everyone else who's not IT and how you can actually work with them to convince them and help them help you become agile. An IT division is not self-contained. It might be a silo, it might be a matrix organization, but you have interfaces to finance, to HR, to sales and marketing, to all the other different divisions and functions across the organization. What we're going to talk about is how we're going to align across the organization so that you can be successful. So let's actually have a quick little bit of a question and answer here. Where is your problem? Where is your pain point in your organization when you're trying to be agile? HR? Which HR policies? KPIs? Performance metrics, yep. Where else? Performance abilities, yep. Job descriptions, position descriptions. Who's the business? Marketing sales? Very good. So that's a fair misconception and it happens quite often. Agile isn't faster. Agile is sooner. And it's not necessarily cheaper, no. So we'll talk about most of these things and I'll make specific attention to call out some of the HR issues and some of the sales and marketing issues. So just for those of you who don't know me, my name is Evan Laborn. I'm currently based in Singapore. Though I grew up in Melbourne, Australia, and Sydney, Australia for the last 36 odd years. So how's the cricket going? Not well for you or not well for me? Beautiful. All right, good to hear. So let's actually start with the core principle of why you're in business. Here's another show of hands. Think of your company's outcomes. What are you producing? Who are your customers? Is your company focused on a technology outcome or a non-technology outcome? Hands up for technology outcomes. You're writing software and selling it to other people. About a third of you. And the rest of you are in supporting industries. You're producing IT software functions to support the rest of the organization, correct? Yes? Lovely. So here's what you need to understand. In those cases where you are not the outcome of the organization, where what you're producing is not being directly sold, you are supporting function. You're there as an enabler to make sure that the rest of the organization can be successful and as successful as possible. So in Jeff's talk this morning, he spoke a lot about outcomes. And this is actually very important to understand because you're often producing outputs. You're producing capability or a function which needs to have a behavioral change, an outcome-based change that will affect your business. So think, what are your outcomes? What is your business, not you, not your division, not your function, trying to achieve? And this is homework for you. Write that down. Not outputs. I don't care if you're producing widgets. I don't care if you're mining the Serengeti. I want to know what is the outcome that your business is trying to achieve because you need to know that. You need to know that so that you can actually help position IT as an enabler. Not as an enabler of we're going to provide Microsoft Exchange but we're an enabler of we're going to provide an outcome and support the outcomes of the organization. If you can align yourselves with the outcome, the way that you can achieve that, be it an agile approach or a non-agile approach is, well, it becomes much easier. So let's then look at something else. We all know enterprise architecture as a specific meaning but I want you to think one level up. I don't want you to think of enterprise architecture as how all your software components all fit together. I want you to think of your enterprise architecture, the structure of your business. What are the silos? What are the structures? Who reports to who and why? Understand how it all fits together and from there you can understand the value drivers. You can understand who is actually going to be your constraints and who are going to be your enablers. Does that make sense? So here's the question that you're all here to understand. How can you be agile in a non-agile business? And the majority of businesses aren't agile by their nature. Business management theory since the late 70s, in fact if we go back really since post-World War II, has been very command and control. Has been very much along the order of we have a market, we're going to work in that market, we're going to produce our products and we're going to satisfy our customers. Great stuff but we build patterns and processes and models to support and enable that. So what does this mean? Think about it in terms of once again an architecture. An architecture is not the same as a piece of software. You don't write your program, your software language to actually replicate and emulate exactly what the architecture says. An architecture is an abstraction. It's an abstraction of the pattern of how things should work. Your business, your business enterprise architecture is exactly that. It's an abstraction of how things work in reality. Here, when we're actually talking about being agile, your organization puts in place these abstractions, these patterns to try and understand and control the chaos that is by the very nature of business. Business is chaotic. It is a chaotic system. We're outside of the control of the business. There are, whether it's 100 people, 1,000 people, 10,000 people or 100,000 people, and in fact the larger you are, the more chaos, the more variance and ripples occur through the effect. What we're trying to achieve here is there's a pattern. There's a pattern that puts some level of control and understanding over that. If we don't know what that pattern is, if we can't work within that pattern, well we're going to be completely stuffed. There's no way we're going to actually be able to, going back to the first slide, understand and align ourselves to the outcomes. But those patterns aren't agile and we are. How do we actually do that? Let's look at a couple of common interfacing functions. There's three I want to talk about primarily here today. The first is going to be finance. I'll spend a little bit of time about that, but I will focus a lot more on HR and I'll focus on sales and marketing. If anyone else has any other questions, pop up the hand and we'll try and address the questions as we go. So, what is finance responsible for? What do they do? Cash flow, accounting, account receivables. They're responsible for making sure your business continues to have money. They're not the sales. They're not there to convince people to get new money in. They're a hygiene process. They're there to make sure that the money that comes in is treated in an appropriate way, is managed appropriately, they manage the budgets. Who here has an annual budget that they work with? Who here has a three-year forecast? Who here has a five-year forecast? No one has a five-year forecast. Excellent. A lot of organizations do. And five-year forecasts are not agile. How can you be agile if you know three years in advance, even one year in advance, what projects are going to be funded? How's that agile? How's that taking advantage of the changing opportunities, changing market, so that you can actually adapt and change? You can't. It's impossible. So, what do we do? So, first of all, you need to understand the interface. You need to understand what your interface to finance is going to be. So, once again, back to you guys. You tell me, what is your interface to finance? What do you do that your finance department needs or vice versa? Budgeting? Yeah, absolutely. You're going to do your yearly annual budgets for your teams. And value management? And value management, yes. That's an entirely different conversation about why that's a bad thing, but let's leave that one aside. Revenue, project to crews. You're going to have invoices come in and finance is going to want you to validate and accrue those monies. Procurement, absolutely. You're offering not staff, but contractors, are you going to be bringing in an external vendor? These are all things that you interface to finance. Let's go back to the question about outcomes then. What does finance want from you? Not... We know what they're going to do. We know that they want you to do recruits. They know that they want you to write up a forecast budget so they can plan for the next 12 months. Why? The outcome that finance is trying to achieve. Pables being done properly is an output. That's a hygiene activity. It's an output of what finance does. I'm asking what the outcome is. What is the chain? Sorry, start with you. They want to enable the teams. Actually, that's a good one. Financial help for the organization. Still not quite an outcome, but yes. Predictability. Yes, that's a beautiful one. Predictability. Let's look at a couple of these. We'll take predictability in the first instance. Finance wants predictability, especially if you have shareholders, especially if you're a publicly listed company, because finances stakeholders aren't you. Finances stakeholders are usually the board. They're there to produce and make sure that the board, who don't understand the day-to-day operations of how this business is what it's doing. They don't care whether you're agile or not. The board wants to know, and through them the shareholders, are we going to hit our revenue targets for the next six months? So, what's a great way of predicting revenue targets or cost targets? Waterfall. Waterfall is a beautiful way of saying, this project we've speculated out it's going to cost $100 million over the next three years. If I'm finance, I love that, because it gives me predictability, because it gives me a measure of financial health. I know how I'm spending and how often I'm spending. Finance doesn't necessarily like an agile approach. In theory, because for them it enables the chaos. It changes that predictability. Does this make sense? So, hang on, let me just go back. Thank you very much, but yes, you are right. It is false predictability. How many times does your finance department do write-downs? How many times do budgets get... You do a three-year forecast, and the second and third-year budgets get cut by 30%, because the predictability doesn't actually exist. It never did exist in the first place. There's a false sense of security that comes from these sort of processes, and it's actually quite misleading, and a lot of companies have gone out of business or been acquired, because they've been unable to be competitive, because they've had this false sense of predictability. So, I'll talk a little bit more about how we turn the agile in a second. Let's look at another function, HR. Everyone loves human resources, don't we? What is human resources accountable for? What do they do? Payroll. Do you want to get paid? I do. Payroll, what else? Performance management. Sorry. Line management? Oh, time management. Yeah, sometimes. Talent management, recruitment, talent acquisition. They often hold the training budget. Okay. So, now, same question as before. What's the interface to you? What's your interface to human resources? What do you need from them? You need people. You need resources. I hate the word resources, but it is the term that is being used. You need staff. You need talent. People to come in and do something, whatever that something happens to be. What else? Yes, that's it, but that's more of a constraint. They will constrain you. They will give you a policy which constrains what you can do. Now, are constraints a bad thing? No, constraints are actually really good. Without constraints, it's hard to innovate. I'm going to question that one. HR does do that. I just don't think they should. All right. So, let's then look at the second question. What are their outcomes? Who's their stakeholder? What does HR... What are they trying to achieve for the organization? No. Sorry. Let me just approach that one. God. Some organizations, yes. Employee satisfaction is an important criteria. It's an important aspect of how that organization and how HR will run. But in general, HR isn't actually there for the employee's benefit. Nine times out of ten for most organizations, HR is there for the organization's benefit, not the employee's. It's why if you have issues and concerns around your engagement with your manager or so forth, it's usually better in the first instance to try and use someone other than HR to try and resolve those issues, either a direct communication, something like that. Because HR, they're there to protect the company's interests, not yours. Sustainability of... Talents. Talents, yes. You want to have a consistent workflow... Oh, sorry, a consistent working community. Your staff, your staff growth. You mitigate that. Your staff growth. Mitigation of risk to the business, absolutely. Through, yep, policies sued. And hell, you also... Sox compliance. All sorts of regulatory compliance. Each state, each country that you're operating are going to have different labor laws, which you will need to comply with. So they ensure those compliance. So once again, HR is a hygiene process in many organizations. It provides other supporting functions in terms of recruitment and talent acquisition, but it also performs a hygiene process. Now, let's look at, from an agile perspective, what do you need from HR? We said you need people, you need staff. Absolutely. What else do you need from HR? Nothing. That's it? Anyone? Do you need HR to define your roles and responsibilities of the people you want to hire? Yeah. And the process description says HR writes all roles and responsibilities. Then I'm going to say that's how it currently operates, but that's not what you need from them. What you need from them is appropriate talent. The fact that they do these other capabilities is something that we'll talk about. Okay. So performance appraisal, absolutely. But should HR be doing that performance appraisal or should the managers... That's it. HR usually drives the process. They set a common standard so that I will appraise you and you in exactly the same way without fear or favour. It doesn't always happen. There's always bias, unconscious bias that comes in. But HR itself, in most cases, isn't involved in the performance appraisal process. Some organization... I am talking very generically here and I should have said this at the beginning. Everything I say is generic. Every organization has a different culture and a different way of operating. It's impossible to be specific to all of you. So does that make sense? So let's now look at sales and marketing. So this is the third division that is a common interface to an IT team. What does sales and marketing do? So they will manage customers, they will manage lead generation. What else? Customer acquisition? Branding for the marketing side of sales? They get products out and money in. Very well said. I like that. Yes, products out and money in in all sorts of different ways. What's your interface to sales and marketing then? As an IT team, what do you do that sales and marketing needs? Or what does sales and marketing do that you need? So your interface is to deliver a product on time. Who sets the time? Product management. Does product management talk to you to ask you how long it's going to take? Or do they just say we need it by the 30th of June? You're lucky. Sadly in a lot of organizations, it must be done by this date because this is when our marketing campaign goes live. Pre-sales. Yes, absolutely. You as an IT function will probably be involved in pre-sales. You'll understand the customer's demands, needs, what their pain is. Provide the information so they can sell the product. Sales and marketing is a division. It's a function within an organization. Your organization is going to be selling different things. If you're an IT company, then yes, your sales and marketing is going to be doing is selling professional services. Once again, generic. So what is sales and marketing outcomes? I think you actually probably put it very succinctly. The outcome, products out, money in. Does anyone have a better outcome for sales than that? I think that is pretty succinct. Business growth, yes. It's aligned to that, but it's not just a matter of an existing... I'm selling 10 widgets a year. I'm selling 10 widgets in 11, then 12, then 15. There is an expectation. The organization has an expectation of continual growth. It is the capitalist way. All right, so let's now have a look at business agility. So there's a natural evolution in business agility. Organizations are slowly over the last 10 years, starting to realize that the commander-controlled approaches of senior executives and management aren't working as well as they used to. So what does this mean for you? This means that we have a opportunity to actually help the business become agile. Now, there's a couple of ways that this occurs, and I'll talk about them in three different tiers. The first tier is where you are agile and your interfaces to these supporting processes are simplified, streamlined, in such a way to enable you to be agile. The second tier is where you are agile and you're helping and enabling these other supporting functions to be agile as well. Little a agile. They may not use Scrum, they may not use Kanban, though in some cases that can be quite beneficial, but you can actually help them to take on these principles and values of agility. The third tier is full organizational business agility, and that is actually very hard to achieve and very rare to achieve. But just be aware that it does... many organizations will take that third step to organizational agility, and I'll talk about that just at the very end. So now, how do we help finance? So I'm going to give you a couple of things, a couple of tactics that you can take and actually work with finance. Pain point number one of most agile IT divisions, the annual budget cycle. Agreed? We all hate the annual budget cycle. How is the agile budget cycle not agile? Well, it tells us how much we're going to spend on what project 12 months ahead, usually 18 months ahead because the budget's usually planned at least six months before the financial year. Finance, and this isn't an agile thing, this has been around for the last 20 odd years. Finance has the ability to create what are called rolling budgets. Think of this as an abstraction layer. Finance works in a yearly cycle, that is their cadence. Finance has to work in the annual cycle because that's what the regulation, the financial years, tax returns, all that, all those processes, that's their cadence. So because finance has that cadence, they force that cadence onto the rest of the organization. What we can do is we can help them to actually obfuscate, abstract that cadence. Finance can work annually, but why should you also have to work annually just because they do? By having a rolling budget, I won't get into the specifics in terms of the financial details, but it is effectively a month-by-month budget that there are spikes, shifts up and down, which may change depending on circumstances, but nine times out of ten most monthly budgets will roll on from the previous one. Money not spent in one month carries over. There's none of this end of the financial year, spend all the money because we won't have it next financial year because it will go away. It is a means of ensuring agility in IT supported by finance. Contingency and trust. Team-based contingency is a very powerful way of enabling IT functions, but if they still have an annual budget to be agile from a financial context, what is contingency? Your budget is for, let's say, an agile team, seven plus or minus two. Seven people is going to cost us X amount. This is my team size. As finance, I'm going to give you an extra 10% a month, 15%. It's very rarely more than 10%. 10% to 15% to spend at your discretion. It is discretionary spending. You can't go out and have a big party. It still has to be a business, a related business expense. But by giving you that funds, which once again should roll over, if you need to scale up to a new contractor or a new product or tool for a couple of months to take advantage of a new opportunity to meet those deadlines, you've got the contingency, the funds available to actually, once again, be agile. And let's go back to the outcomes of finance. You said, at best, predictability. If I, as finance, even with my annual budget, give you a 10% contingency, I have a level of predictability, surety of how much things are going to cost and what the flow is going to be. And if it's not spent, and if you're not spending your contingency consistently, then great, we'll reevaluate. But for you to be agile, for you to take advantage of change, beautiful way, but it requires trust. Your finance team has to trust you to spend that money wisely. Contingency won't work without trust. And we'll talk a little bit about communication and trust-building a bit. Cadence, flow, and transparency. Now I'm going to talk about the second tier of business agility. And that is financial agility, not IT agility with finance support, but actual financial agility. Yeah? Okay. So there's two points there. So the question was for those who didn't hear, contingency is bad because you're always going to use it for day-to-day things. It's not necessarily going to be used for innovation or those spikes of behavior. Now, so there's two points there. One is contingency is there to be used. So using it every month is actually not a bad thing. And if you need to spend it to actually achieve the goals, the changing goals which are set to you by the business, then great, you're using it for the right purpose. If your baseline budget, however, is insufficient, contingency is not... contingency isn't. We'll give you 20% contingency, but we're also going to cut your budget by 20%. That's not contingency. That's just a whitewash of agility. It's meaningless. So going to that second point of trust, they have to trust you to actually be honest with that. And if you say that your budget... I've got a team of seven. This is what my funds... my costs are going to be. I have a team of 100,000. This is what my costs are going to be. The contingency is above and beyond my budget. Now, it might be 5%, but it needs to actually be available. And interestingly on contingency, contingency should cascade. So if I'm the CIO of 10,000... of 10,000 people, I'll have a very large contingency, but that should actually cascade down to my outcomes-focused team. So each of my teams is focused on an outcome and achievements. So I'm going to say this is your contingency. This is your contingency. So the contingency isn't at a department level. It's at a team level. Or it should be anyway. Once again, it comes to where that level of trust lies. The team leads, or do they only trust the CIO? Okay? The trust needs to be at the level where the contingency needs to be spent. I wouldn't think of it as insurance. The problem with thinking of insurance is insurance implies something's going wrong. All right? I'm spending the money because something is going wrong, and that money's there to fix it as a risk mitigation. The problem with having it thinking it that way is it stops you from actually innovating. I want you to spend that money on something better, not just because something's not going as planned. Oh, you can use it as an insurance buffer, but thinking of it as that has a cognitive limitation. All right? So cadence, flow and transparency. We're now talking tier three here. All right? We know the cadence of finances annually. All right? We need to understand what their flow is, and we need to understand about transparency. Agile? Does agile like transparency? Yes, it does. We are very transparent, open communication. The great thing about finances, finance is also very transparent. They are taught to be transparent. There are certain cultural behaviors which, from an agile perspective and from a finance perspective, fully align. And one of those is transparency. So we can actually leverage the agile manifesto and those aspects of agility to actually convince them that there are some parts of being agile beneficial to you. And from an agile and from a finance perspective, transparency tends to be it. So let's now look at human resources. I'll spend a bit of time on this. Metrics and KPIs. Don't we love those? Those are their favorite things in the world, aren't they? So what do you need to do? You need to help them define what an agile KPI is. Why? Because you're not going to get them to get rid of KPIs. KPIs are pretty much a stock standard part of any business and has been for the last 20, 30 years. No more. So because you can't get rid of KPIs, you can't beat them and join them. We'll help finance develop a set of agile KPIs and associated job descriptions. It's not a matter of finance writing them for us. It's a matter of us saying this is what we need. What are the principles of agility? Cross-functional teams, collaboration, communication. We all agree. These should be part of our KPIs. These should be part of our job description. My job description should not say tester. Tester is not cross-functional. Tester is a function, a singular function. I don't want to hire a tester. I want to hire someone who has testing capability but can also pick up and start to do some unit testing, coding, code reviews, someone who can actually sit with a business. I want someone who is cross-functional and cross-skilled. I want someone who can work in a team. These are the KPIs that we need. Bonuses, team-based bonuses. Rather than saying you met your KPIs but you didn't, therefore you get your bonus but you don't, but you're on the same team. That's a misleading metric. The team has an outcome. An individual out of a team has an outcome. Bonuses and the KPIs associated with those bonuses should be at the team level, not the individual level. Once again different organizations will be structured differently as to how this all can operate. But the point is, you need to be able to help and work with your agile teams, sorry, your HR departments to help them understand how to be agile. And this comes to communication. We'll talk about that in a bit. Agile recruitment policies. Now we're talking Tier 2. An agile HR process. Now is that possible? Absolutely. I've got some great case studies of, actually let me jump one forward. Kanban for HR. I've got some great studies that show that HR teams, they can't use scrum because they can't iterate. Their cadence is greater than one to two weeks. Their cadence is daily. They are very reactive in most cases. Once again different HR departments may differ, but in general their cadence is too short for a scrum-based approach. But Kanban, as a flow as a way of dealing with a prioritized backlog of inputs, which changes on a daily basis a traceable, trackable measure of activities to deliver an outcome. These are all things that are amazing ways of actually embedding agility within HR and HR loves it. I've worked with four, five HR departments in converting them to an agile business approach, all using a Kanban style approach. And every single one of them there has been an empowerment effect for the HR staff. And we're agile. We like the whole point of having that team-based, that facilitation, that team-based outcomes. Now, one of the things about the agile recruitment policies who here when, in your organization if someone in your team resigns, do you take that job description put it out to market and replace that role? Is that how most of you work? Yeah. Now what happens if you've got two applications who were brilliant? What would you do? You would hire one? You can? That's the thing. If you don't have a most organizations work on a position basis if you don't have a vacant position you can't hire both. It doesn't matter if both people will add value to the organization you can only hire one or go through the six month set of paperwork to create a new position and the associated business case to actually get the funds to hire the second person. A true agile organization and we're now talking about tier three here a true agile organization is going to look at a rolling recruitment process. I'm not going to have positions I'm not even going to have job descriptions I'm going to say these are the outcomes that we're achieving this is our outcomes-based team this is what we're doing. Do you think you can add value? Do you think you can work towards doing something? If you do here's our email address pop your resume and we'll have a look at it and that just sits there that's a permanent job at. It never closes and I'll look at your resume and your resume and your resume and I go you know what in the last month these three people have applied out of 20 who I think are really good let's bring them in let's give them an internship or whatever your actual recruitment process is but if you're going to add value to an organization if you are actually going and think of value as outcome there's a revenue driver there's money coming into an organization if you're going to add value then I'm going to hire you because you're going to add a net revenue positive to the organization and if you don't I'll fire you you have a three month probation period use it make sense? alright sales and marketing sales and marketing is funnily enough the hardest to make agile why? anyone have a guess? that is a symptom of why? yes they have quarterly quotas? anyone else? pretty much it what's in it for them? root cause 5 why's why is that problem? what's in it for them? why is that a problem? why isn't that agile? incentivized based on what they sell because we've hit the psychic point sales and marketing is by its very nature an independent cutthroat competitive behavior because they have quotas to meet because they're just there to sell the product I'm talking sales here not less so marketing so by its nature sales is actually very hard to make agile so what do we need to do? first of all we need to teach sales about collaboration we want them to collaborate with one another in such a way that and with us so that we can align the sales and the development cycle too often I'm now specifically talking here about if you're selling IT products if you're not selling IT products the relationship tends not to be quite so strong but if you're selling an IT product and they go and commit to a date to a customer then you're stuck with that date it acts as a constraint and you have to scramble to try and finish everything in time whether it be a full on custom built system or just a configuration of a platform so what we want to do is align those sales and development cycles so what the customers sorry what the sales people sell and the development team can deliver is aligned with the customer's expectations if you want to be agile get rid of your sales team have sales people and embed them into your delivery teams get rid of commissions commissions are a negative behavioral trait to agility because A encourages that competitive behavior we don't want competition we want teams two there is a lot of evidence that shows that beyond a certain base level of remuneration there is very little net positive value to bonuses three bonuses drive a further negative behavior even when it's a team based bonus they can actually drive a negative behavior around what do I need to do to get my bonus not what do I need to do to make the customer happy once you've got those sales teams embedded you've got those alignments of sales and delivery cycles once you've got the sales people to actually communicate with everyone collaborate as a team then you can have a highly efficient, highly functioning sales function capability within your organization it is hard to achieve but when you do achieve it it is the most amazing thing you will ever see happen to an organization I've seen organizations increase sales mostly through repeat customers by 80% by using this approach to be fair that's my best case scenario not everyone is going to have the same benefit but these are some of the things you can achieve from an agile organization eliminating commissions so it all comes down to communication this is the fundamental aspect of how we are going to achieve this the title of this talk selling agile across the enterprise we are not telling them that we are doing agile and expecting them to align we are using agile agile is a great way of delivering products and services in an efficient way we know the sales pitch we need to give the sales pitch to someone who isn't IT we need to convince HR that agile even if they don't want to be agile what's important to us in being agile is beneficial to the company let's go back to the very first slide what is the outcome of your business why are you in business alright when you are selling agile to someone outside of IT you don't sell it in terms of how good is agile how effective it is at Scrum teams communication improves it's about those outcomes of the business so you need to find those business drivers alright let me just go back to the slide you need to find those business drivers in terms of here I am I am IT your HR how do I convince you now I am here in India there is a stereotype in India of that competitive negotiation the thing about competitive negotiation which we all tend to learn in market places and even back in Australia the problem with competitive negotiation is there is a winner and there is a loser there is one person who gets their way and another person who doesn't necessarily it only works when I can walk away alright I'll give you two bucks for this it's going to be 20 I'll give you three I'll go buy it from this guy over here but when you are negotiating when you are talking with your HR department saying we are using agile and they go well as long as you comply to this as long as you comply to this regulation but we are using agile when you are using agile API you have to comply to this regulation but you have to comply to this regulation you can't walk away you can't walk away and go to the other HR department and ask them so this is a this is a negotiation strategy this is something that you are going to need to actually start doing with these departments because you can't lose not you can't lose in terms of you are always going to win you can't lose because if you do lose that's it it's over you are stuck with an agile IT team that has all these complicated and very inefficient interfaces to non-agile departments you can't afford to lose so I want to volunteer from the audience I will pick someone if I don't get a volunteer I won't stand there face the audience so would you like to introduce yourself to everyone it's very learning I thought that I knew all about agile and Scrum for a long time but I knew that I know nothing now and the real learning will start now speaking with guys like Diana Larson, Jeff Patton now I have this is a different perspective altogether altogether for example business right it's BU and silos I realize that we are operating in that and just now I had this realization okay so has this talk made sense to you have you been able to get some ideas of how you can be better in terms of business of course and it all makes sense what I am telling you makes sense yes so tell me a little bit more about the work that you are doing at Cisco I am a Scrum master I serve about 5 teams I also serve about 4 other teams indirectly I help my architects in grooming I do conflict management negotiations part cultural part basically I am the Scrum police without a danda okay so where are the issues that you are finding in terms of you have got agile here within your Scrum teams you are being a Scrum police but you have got all these surrounding systems and processes where are those issues what is happening there in the last one year and we are pretty successful there challenges how do I scale to the next level people are bored of ceremonies people are bored of stand-ups a lot of other guys we know what works we don't know what works and we are okay with it you bought a very interesting point about contingent workers for example now after that earlier we didn't have any contract one of the clause in the contract that team should be having a deal of agile now I am thinking that I will add that clause in the contract because it helps to speak in the one language so do you need any help in your organization in doing this sort of stuff bringing in a consultant such as myself to possibly help in some way but the scope of influence and scope of concern concern is the influence I will definitely try absolutely so just as a reference point my daily rate is around 4,000 US a day so is that something that you would be able to accommodate we constantly alright so we can go on but we will stop there I think you get the idea no when to walk away so did that make sense okay we are building a relationship okay I am building credibility if I am talking to HR if I am talking to finance or sales and marketing I want to have that level of credibility with them I want them to know that I am not just here to sell agile to IT but I am here to go look I understand the outcomes of HR I understand what you are trying to achieve I know how you work so I am credible when we have a conversation it is not just an us vs them conversation it is like okay I believe I believe you know what you are doing so then once you have credibility you can build a relationship once you have that relationship you can start to then have those conversations around change, improvements credibility and relationship are the first two points you don't even talk agile at this point you are talking what are the pain points of HR what pain do we cause you that we can try and fix have that relationship find a concession point I didn't actually do that because we didn't have the opportunity but find a concession point is more around there are things that you can't win find out what they are before you begin a very good example external legislation labor laws for HR tax law for finance there are certain things that you can't win on know what they are and be willing to give them up naming the first price now interestingly you did a counter tactic and I will explain that in a second if you name the first price you can anchor the conversation so in an agile sense it's not a money conversation it's an agile conversation we are naming agile as the way to do it we are not asking them how would you do this and hoping they say oh agile we are saying you know what agile is going to help you do this we can actually help you do it in this way now the counter to naming the first price is actually to ridicule the first price so be aware that there is a counter to that ask questions let them understand that you are actually interested in what they want and know when to walk away at a certain point you are not going to be able to win the conversation and basically you just have to go we are just going to have to find a way to work together does that make sense any questions about any of this no alright two final points first find the value drivers what do I mean by value drivers these are the no let me take a step back what do I mean by value what is valuable what is valuable to your organization income absolutely so when I say value drivers I am saying find those levers find those controls in your organization that you can pull and leverage and say okay reputation and income are important I am going to frame the conversation with finance HR sales with everybody around those value drivers the value proposition align the agile value proposition in IT to the value proposition and the value drivers of the organization then find the revenue drivers value drivers is a very broad statement it is about what is important to the company revenue drivers is what makes the company money and ultimately you are in a company you are in business to make money let's not shy away from that fact you need to find the revenue drivers in your organization understand where the money comes from and find a way to align what you are doing to that either as a support function where you are enabling the revenue drivers or as a direct function where you are creating revenue in the first place so if you understand your revenue drivers if you understand the value proposition and you can align agile and your conversations that you have with HR then you are in a very good position so on that note I have about 5 minutes remaining any questions I have you spoke about the interesting things so can you please dwell more into that you have already a product owner you have a product manager who interacts with the sales teams they all together make a strategy so for example marketing guy, his purpose is to create a customer I understand him being in the business or embedding with agile teams I understand that but can you please dwell more about the sales guys embedding in that in the life sales is separate sales from product ownership product ownership and sales can be one and the same or they can be separated where they are separate where you have a product owner the product owner tends to represent the customer they represent the person who wants a product, wants something being created whereas sales represents the business sales is there to sell a product to the customer so the product owner tends to come after what I can think of in terms of I'm really talking about turning sales from the traditional boots on the ground knocking on doors, selling a widget to account management I have a product owner I have a series of product owner who represent the customer I have sales who act as an account manager to actually ensure that a lot be continued alignment and to get those revenue drivers flowing again and again to ensure continuous and repeat business other questions we found that we have delivery team which is deeply embedded they are kind of open managers and we found that it is way more counterproductive because last time we created 31 versions of the estimate 31, okay there's a whole series of questions I have to ask there I probably don't have time for all of them but maybe we have a chat afterwards but my first question is why are you estimating like that what value where's the value where's the value no here the problem is more deep rooted where the customer has not bought into a jail okay so the whole value chain is not there and that's why these are the symptoms okay when you don't have a buy-in to agile from a product owner from sales or from a key people in your stakeholders and that's the whole point of this conversation is that's when you have those breakdowns and that's why you put in all these workarounds and make it work what I'm saying is you shouldn't have to have those workarounds if you have that conversation if you have the ability to build an agile relationship even if they don't go agile even if they don't use Scrum or Kanban at least get to the point where you can have that conversation with them about how can you have that agile interface if they can't buy, if they don't buy in then sometimes you do have to know when to walk away there's a point you made when you talked about being one of the most difficult nuts to crack I didn't quite understand it because I thought they had quarterly cycles which is better than yearly cycles the cadence is irrelevant like agile you'll find nowhere in the agile manifesto a line that says we will iterate weekly or monthly or quarterly there's one of the principles and I should be able to do this from memory but I can't is around with the preference for shorter time scales that's it it's not about doing it faster it's about collaboration and getting the right outcome even that's not what I'm asking they actually have shorter cycles compared to finance and yet you're saying it's more difficult for them because it's not about the cycle time it's about the collaboration and the communication they're competitive they don't have a team they will fight with one another in really bad organizations they will still clients from one another in the same team that's as far from agile as you're going to get and you need to break down those behavior patterns to even have a chance of having a level of agility in sales depends on the size of the organization if it's a small organization with one sales person per region yeah sure you won't have a direct competition but a lot of the larger organizations where you'll have three, four, five organizations and I'll use a consultancy as an example a consultancy I recently worked with and I won't name names in each major city they had about ten sales and each one had a company that they were responsible for but they were always trying to poach work off each other because their bonuses were individual and so if they could bring in a sale from someone it didn't matter who to the company so if that behavior will change sure you're not going to have that competition with one sales person but at the same time one person isn't a team if you have one sales person it's not a team in and of itself and you may as well align them into the development cycle then so they're part of a team does that answer your question? it always depends the answer to every question I get asked is it depends anyone else? all right if you have any other questions about business agility or anything like that I have a couple more talks on fixed price contracts and value stream mapping on Saturday so feel free to come and have a look at me and if Australia wins then I'm very sorry I'll see you guys later thank you very much