 Good morning Thank you for joining us here at agile India 2014, I hope you'll enjoy the opening keynote. I thought it was quite illuminating I Learned a couple of things from especially the social message at the end So today we're talking about from lean startup to agile enterprise so taking agile outside of the traditional domains of IT and Taking those concepts from the lean movement and the agile movements across the entire organization So let's start with a question Chrysler Kodak general foods compact digital What do all these organizations have in common? That's not a rhetorical question. I actually want to answer They're either they've gone bankrupt. They've failed. They've been forcibly acquired by another organization All because they couldn't adapt all because as an organization their business model Was stuck in the past and when the world moved on they didn't move with the world Kodak is the great example. They developed digital photography but What did they do with it? They thought it wouldn't actually become a viable product stream for another 20 years When instead we all have digital cameras in our mobile phones So let's look at something a short video. This is only a couple of minutes long only a minute long This is the rise and the fall of the fortune 100 companies. We're actually taking to the fortune 50 1985 1995 Here we have Chrysler 2005 We have a couple of companies coming back These are American companies by the way, so you may not recognize all the names Now let's look at 2013's top 50 companies and compare that against 1985 27 of the top 50 companies Sorry 27 of the top 50 companies no longer exist in the form that they did at the time They have either shrunk to a smaller market share to what they started with or they have been forcibly acquired Or they have gone bankrupt So who am I? My name is Evan laborn. I have flown in from Melbourne, Australia I work with organizations around the world on adaptive businesses making an organization making a business Agile lean and agile everything from the human resources to finance sales and marketing and of course our IT Let's do a little bit of a Q&A here hands up if you're a software developer Okay, about half of you all right, so For those of you who are developers or in the IT space everything that we talk about today Applies to you. In fact, you should know it okay because you're at an agile conference You understand the concepts, but what I want you to learn and what I want you to take away from this talk Is that you can go much beyond test-driven development much beyond scrum and product delivery and we can apply those into every facet of an organization so We live in interesting times our economy is changing the rise of mobile technologies the rise of big data the rise of The cultural changes which are coming through the next series of generations and their expectations of how business Operates means that business needs to do something better. It needs to work in a better manner so Let's just start if I use the words individuals and interactions. What do you say? over Thank you, and if I use working software over comprehensive documentation Now excuse me now if we're talking the agile manifesto We need to make a few changes It's no longer working software Working software is great if you're building software, but what if you're in human resources and you're doing a recruitment drive? What if you're in sales and marketing and you're trying to get a new client? So we change the business rules away from working software to Working products and services completed customer requirements or if you use Martin's concept completed intense So what we want to do is we want to have a complete business transformation and this business transformation will be derived differently depending on the organization Your organizational culture your organizational strengths and weaknesses your organizational demands from your customers and your clients Regulatory environment that you work in will all drive how you create an agile organization In some cases, it's going to be straightforward Many of you in fact probably most of you work for an IT organization Or a large IT department within your organization. You've already adopted agile internally. That's why you're here But we can go beyond that and we can take the organizational culture across the organization Not just in the minute part, which is IT or the major part which is IT so I'm going to Give you a little bit of an idea about cultural change now Some of you may have seen this because I have shamelessly stolen it from IT agile and armored 60 This shows the change of an organization now This is true whether you're changing IT or whether you're changing the board of directors You can't just make one change You can't just address Processors if you put scrum in an organization, whether it be IT or finance It will fail. Your organization is bounded by your organizational culture and it acts as a constraint It acts as an elastic band or a hair band that constrains your organization to a certain shape If you push if you put scrum in there and you keep pushing scrum in While you're holding scrum while you're working it You're going to be pushing at that organizational culture But the minute you stop pushing it's going to snap back people are going to fall back to their traditional activities So we need to address change not at a single level But at the organizational level across the entire spectrum from leadership people processes tools So change occurs at all levels of an organization whether you're changing IT Whether you're changing finance or whether you're changing everything so Let me tell you a story. So like all good stories. This starts once upon a time in a land about 10,000 kilometers away This organization had a problem. Okay, and that's problem was it was successful Now this sounds like a good problem to have but Being a very thoughtful and forethought organization they saw this problem as Success now does not equal success in the future They need to be able to adapt they know that their customers are fickle now create a product and they may sell a hundred million copies of that product in the first Year, but in the second year they may sell 10 So they need to be able to adapt to changing market environments and adaptable business So what did they do they looked internally and they went Do we have an adaptable business function a business function that works for us and the answer was yes IT Okay, because IT had taken on Agile specifically a combination of scrum and Kanban scrumb and as some of you may call it And what they had done is they had produced a product They had worked with their customers. They had adapted to their customers needs And so this organization it was it was a financial services organization to be specific This organization took that idea and said, you know what we can apply this wider And so they started with their human resources area Okay, they made that adaptable. They wanted to recruit people who were Adaptable they wanted to grow the business What I'm going to talk to you about is their journey Okay, the steps that they took to become an agile organization You can follow a similar path once again your journey will be different depending on your strengths and weaknesses But this was their journey the journey that they took The first thing was we defined a vision Okay, a business goals. Where are we going in? 12 months in 24 and five years time. What do we want the organization to look like? And you'll do the same whether you're transforming an IT organization IT department or an entire organization now a Vision is nothing without metrics. We need to actually prove. We got there. We need to prove that we're on our way Okay, now if we take lean startup principles This vision has to be quantifiable. It has to be something that we can accurately measure But it has to be realistic measure Similarly if our vision is wrong, we need to be able to pivot change okay Our vision for the company in five years time based on our current understanding of the market may change Maybe we write mobile apps today, but tomorrow Mobile apps are passé everyone's doing them So we're going to find a new strategy a new corporate path that will make our organizational our organization adaptable to whatever changes the business brings I Tend to recommend organizations have rather than one portfolio rather than a strategic direction Have four or five strategic directions have them complimentary or contradictory in many cases pick the ones at a certain times which work for your organization and If they don't work drop it Strategy is not about following a plan. Okay. No general has a plan a Strategic plan for a battle and then goes into battle and that's what they do a Strategy is a goal and they'll have multiple strategies depending on the terrain on the Weather they'll have different ways of working in different circumstances. We're exactly the same The next thing we need to do is we need to communicate this to everyone an agile organization What do we value? Okay individuals individuals and interactions So this isn't a journey that the executive take alone. This isn't a journey that the IT department takes a learn This is a journey that the entire organization needs to be aligned to if they do not align If they do not understand the journey, then they won't come with you At worst, they'll actually work actively against you Okay, now this is actually not necessarily a bad thing and I'm going to be a little bit controversial and say They're are going to if your organization is going down the agile path you're building an agile organization or just an agile IT department then If there are people who won't come along for the ride Maybe it's better for them to be in a different organization. Maybe they're not the right people for your company We do talk about redundancies in any sort of organizational transformation. This is not a dirty word This is something that you work with them about it shouldn't be a surprise If you're going towards an agile approach Then they should know 12 24 months in advance how things are going and if they can't operate in that environment It should be obvious to them as well as to the executives of the organization whether or not this is working Alongside that we have to have our agile recruitment policy We want to hire people who have the right cultural fit. We want to hire people who can adapt there is a place in organizations for drones people who Do the work that they are told and who have no initiative of their own. Okay, that's not necessarily a bad thing but in an agile organization We talk about teams. We talk about empowered teams if an individual can't take on the authority and accountability that empowerment Requires then why are they there? Pivot at this point in our Process we're probably six to twelve months into our transformation All right, and in the case of the organization the organization. I mean I'm using as a case study They were 12 months in okay, so we use retrospectives everyone here knows where retrospective is scrum Yes, don't need to explain it wonderful, so we use the concept of retrospectives to drive organizational change Each individual is empowered to recommend Improvements, maybe if we try this maybe if we try a different way of working. Let's introduce estimation No, actually estimation didn't work for us. We're gonna go no estimates It doesn't matter what the actual outcomes of the retrospectives are as long as you have them and the right people are taking ownership Actions are coming out of those retrospectives and the organization can change I put the word pivots in here Okay, in in a lean startup concept pivots is literally we have identified a customer need It is different to what it was yesterday, and we're going to change the organization 180 degrees to address this new organizational strategy this new customer suite of requirements The retrospectives are how you pivot they give you that mechanism that way in which the organization adapts This is one of the most important Processes or concepts to have come out of scrum Oh in fact come out of agile because I actually predate scrum as well Another organization. I'd like to talk about briefly the New Zealand post group New Zealand post group is Literally the postal service in the country of New Zealand just if you don't know where that is It's just to the left of Australia or right of Australia This organization is big it contains a bank Okay, it is a group of companies only one of which is the postal service Okay, so we're talking very large revenues in the billions of dollars So New Zealand postal group They have they use agile for their Executive teams they have a strategy Kanban board, which I'll show you in a minute, but this I want to talk about This was one of the greatest ideas that I ever saw New Zealand post group put together they have their Kanban room They call a sorting room because of their post group so they have to have some postal metaphors in there Okay, but this they have one wall or in our case. It's actually a door Okay, which has an elephant on it. So who here knows the term an elephant in the room? Yeah, mostly an elephant in the room is something that everyone knows is there But nobody's actually willing to talk about And let's face it if you do have a literal element to elephant in the room You're gonna have problems. Okay, you need to get it out of the room. So this is a door anyone can put a little post-it note on it and it forces that to be discussed it Forces that topic whatever it is Okay, I think our estimation mechanisms are quite bad You don't even have to put your name on it. Okay, it can be an anonymous feedback, but it forces that conversation to occur Here's where things start to get tricky We have two concepts in the lean in the agile world Okay, continuous delivery and incremental delivery Now what I'm about to say is highly simplistic and wrong. Okay, but it is a good rule of thumb. Okay, processors like Sorry processors like scrum. Okay XP Promote an incremental delivery iterations sprints, whatever you want to call them two weeks three weeks four weeks of work timeboxed and encapsulated all right finance Marketing legal R&D these are all business processes that work well with Increments of work. Okay, your legal department can plan what they're going to do two weeks in advance in many cases In some cases they can't I'm talking generally here. Okay, your finance team when they're building a budget They're building that months in advance Marketing your marketing department are going to put together marketing strategies. In fact, I have a case study which I'm working on it on at the moment, which is a and marketing team that uses scrum to promote their Marketing campaigns and they use a very lean startup approach if a marketing campaign cannot provably make an impact within the Four weeks of their iteration Then they will drop that campaign and try a different one Continuous delivery is the domain once again. This is highly simplistic for the domain of lean and Kanban. Okay, it's not about grouping work into Iterations, it's not about two weeks of work Human resources sales customer support media and communications are all reactive Okay, all their requirements come in so quickly that they can't actually Group them into an iteration So we use a different style of an approach. We use a continuous approach continuous delivery We all heard the talk about continuous delivery Continuous delivery works outside of IT if you're human resources and you're doing a round of recruitment You have to recruit 20 new software developers Okay, it doesn't matter whether you recruit them all in one hit or whether you recruit one in the second Then the third then the fourth in the fifth all the way up to number 20 Because you're continuously delivering or deploying New resource as soon as they become available as soon as they finish that recruitment process but this doesn't work if we don't actually track it if we don't actually put in place the mechanisms to validate that what we're doing is correct Okay Now we talk about Kanban. Okay, sorry. We talk about Kanban as a mechanism for Visualizing flow Kanban there's nothing uniquely software about Kanban. It didn't come out of software. It came out of manufacturing manufacturing So the same rules as long as you can visualize a consistent work process as long as you can create a value stream map of a process Human resources sales and marketing. It doesn't matter as long as you have that value stream map as long as you understand your whip limits Then you can put together a Kanban board to visualize the flow of that work We also have our restructure No agile approach. No agile organization can be strictly hierarchical Okay, now I'm going to come across some Tension talking to an Asian audience about breaking down hierarchy I work with a lot of organizations in Singapore and Malaysia and Philippines and India and one of the most common issues I come across with an agile business model is Well, I'm a senior software engineer. What do I tell my wife if I'm now Just a team member if I'm just one person amongst many So it can't this is one of the hardest parts of breaking down those cultural barriers But we actually want is a lean efficient communication matrix and I'll explain about that in a minute This is Maslow's hierarchy of needs Okay, this is often aligned is not necessarily accurate, but it is a model of human motivation Okay, at the bottom we have pure psychological. Sorry physiological motivations food water shelter Okay, this is where your minimum wage employment comes in. Okay, if I'm a Chai waller if I'm just there serving tea Then all I'm getting out of my job is food shelter The basic physiological needs, but we're intelligent Okay, we go into software programming. We go into development. We go into business because we have drives We have motivations. We are interested. We are passionate about the work that we do The more passion that can actually be applied to your work this level of self-actualization Then we have our agile business management or our or our agile approach to work I want you to be empowered. I want you to come to work Not just because you get a paycheck, but because you love it and this is the difference between traditional employment and Agile employment or agile business We of course have to have coaching. Okay, we want our organization to understand The critical thing here is this Customers we all know the value of training and coaching for staff managers and so forth We've been doing it for years But your customers need to understand what it means to be agile and that's the hardest part If they don't want to be agile, then you're not going to be this is one of the things that I particularly love about Agile we have our own nomenclature. We have our own language Our language is not the language of business Nobody cares what a sprint is Okay, nobody cares what a scrum of scrums is nobody cares what a what pair programming is We need to translate this into language that business understands Iterations rather than sprints. Okay, not daily scrums daily stand-ups. Say tell it what it is Okay, it's no longer test pair programming or test-driven development because those are software specific. It's now test-driven work Okay, pair work. It doesn't matter what the work is It doesn't have to be software so We now into the second year of our transformation Sorry, I'm just checking my time Yeah, we're now entering our second year of our transformation here We start to transform not just the simple things, but the organization. Okay, we have an agile executive We have an agile board now our board of directors can be agile Board of directors are responsible for the governance of an organization if they can't adapt to changing market circumstances and Approve the pivoting of an organization to address new issues then the organization can't be truly agile from the very top to the very bottom okay from the Basic janitor who needs to decide which room to spend the most time cleaning. That's an agile decision All right to the board of directors who needs to decide whether or not they're going to address Mobile development or big data, honestly, it doesn't matter as long as they can make those decisions This here is the executive Kanban board from New Zealand post group Okay, this is a wall an entire room Anybody can walk into this room in the organization and see the corporate strategies and the work towards each step Okay, as they go. This is brilliant This is one of the greatest ideas because this just not shows this is the portfolio of work that they're working on but more than that It shows that where they are the dynamicness the dynamics of their portfolio and if something turns out to be not worth it that can change Okay, we have our agile key performance indicators Okay, KPI's are important because we need to measure if you want to be brave enough Okay, here's my favorite KPI for an agile organization failure If your senior executives can't prove that they have failed can't prove that they have Managed a failure then should they get their bonus? I don't think so because unless they can prove they have learnt unless they have proved that they have identified something that is Performing poorly and improved it then they've not made any substantial benefit to the organization failure is a positive KPI That's my recommendation to you Okay, we talk about agile financial management There are ways in which we can encapsulate budgets in an agile way monthly budgets rather than yearly budgets team contingency and of course an understanding of flow a Budget is effectively a pipe If you want to add more walk it work into that pipe one of three things are going to happen either something falls out the end Okay, as in you don't finish something You extend the length of the pipe you add time or you increase the size you add resources This is how you have to visualize your budget in an agile context. You can't get more work for the same money We now continue our organizational restructure We we have cross-functional teams. We now start to move towards facilitation based management our managers our business leaders are no longer Authoritative it's no longer. You will do this because I tell you it's tell me What's the best way that we can deliver deliver this product? All right, that's a great idea I'll give you two weeks if there's any issues. I will try and get it out of the way come to me if you can't deliver Okay, is a change in the way that we lead This is true whether you're leading an IT team or whether you're leading an entire organization Communication is key by breaking our teams into Teams of seven plus or minus two We stop having our communication overhead is reduced the more the larger team is Okay, the more the greater the overhead of communication So what we want is to have this flow if our team is massive Let's break it into smaller teams. So our organizational restructure becomes nodal. It becomes a cell structure Individual self-contained empowered self-organizing teams okay, our Customers need to be agile Okay, we talk about the level of trust Reference trust my customer comes to me because they're recommended Contract trust I trust my customer because I have a contract saying if they don't do the work Then there are penalties and liabilities attached to it That's not agile. We want an agile customer. We've got to be up here. Our customers need to partner with us Our customers need to be part of our work processes rather than just the end output okay, if It's an agile question your customer needs to understand these three questions. How much is it going to cost? How long is it going to take and What am I going to get? If this isn't the answer to your customer and if they don't accept that answer then they're not agile You need to work with them to understand what the outcomes of those are if they're a partner They'll understand if you just have a contract with them. Those answers are not going to be sufficient We talk about pivots once again We're here at the end of the second year. We're trying to change We've already changed our organization quite significantly, but the market is also changing with us If our market doesn't adapt sorry if our market if we don't change to our market We don't pivot the organization then everything we've done is in vain Okay, we talk about once again continuous improvements. We continue to visualize and track our workflow We introduce burn down charts. We introduce cumulative flow diagrams statistical run charts all of these are agile tools that we use to visualize process and Progress doesn't matter whether it's software the same tools apply whether you're talking human resources Whether you're talking sales and marketing or whether you're talking the board of directors All right stage three. We're entering our third or fourth year in the example. I'm using in the transformation I'm talking this was year four Okay We finalize the organizational restructure. All right, our teams are dynamic. They are small They form and reform depending on the business needs Okay, we we no longer a matrix organization. We no longer have silos. Okay, there are still business functions There's still a team or several teams that are responsible for finance several teams that are responsible for marketing and communications Okay, so these teams still have core functionality But the team members may change the finance team may have four accountants But they may bring in a graphic designer or a technical writer as needed to try and develop this specific requirements to the customer Okay, our organization is purely dynamic Okay, managers are responsible not to lead. This is sorry not to manage but to lead to facilitate Our organization transforms from a traditional structure Down to a much more agile structure business functions. We have coaches and we have some managers. Okay much simpler This is the city of Edmonton Okay, or specifically the IT department in the city of Edmonton. They went through an agile business transformation Okay, they no longer have traditional business functions Okay, they have people who are responsible for certain functions Then they have teams that form and reform as needed and they have a number of coaches to help facilitate the process okay To make this work larger organizations are going to have a skills audit They're going to have a skills register. Okay, if there's ten thousand people in your organization And you need a technical writer. You don't know who to bring in so there would be a registered that you could look at Okay, we can bring in many of the agile processes test-driven work Pair work. These are processes that works regardless of whether we're talking about Software or not. Yes, automation is hard when we're not talking software It's hard to automate human resource recruitment. It's hard to automate the annual budget There are certainly some things we can automate and where the possible we should like that's a good practice But we can still define our test cases our acceptance criteria before we start We can still pair and have one observer and one driver We still have our retrospectives I keep harping on about the retrospectives because the retrospectives this is our mechanism This is how we drive change so This brings us to the end Okay, you spent the last 40 minutes listening to me talk about how to build an agile organization. I Have to say there is a community that is coming together agile business management org There are a number of case studies articles It's quite small at the moment We if you are interested, please join us if you would like to submit case studies If you'd like to have more ideas come and talk to us So on that note, thank you very much for listening to me Questions no questions that all made sense. There we go. I knew there had to be a question of financial management There are ways in which we can encapsulate budgets in an agile way monthly budgets rather than yearly budgets team contingency and of course, okay an understanding of flow a Budget is effectively a pipe If you want to add more walk it work into that pipe one of three things are going to happen either something falls out the end Okay, as in you don't finish something You extend the length of the pipe you add time or you increase the size you add resources This is how you have to visualize your budget in an agile context. You can't get more work for the same money We now continue our organizational restructure. We we have cross-functional teams We now start to move towards facilitation based management our managers our business leaders are no longer Authoritative it's no longer. You will do this because I tell you it's tell me What's the best way that we can deliver deliver this product? All right, that's a great idea I'll give you two weeks if there's any issues. I will try and get it out of the way come to me if you can't deliver Okay, is a change in the way that we lead And this is true whether you're leading an IT team or whether you're leading an entire organization communication is key by breaking our teams into teams of seven plus or minus two okay We stop having our communication overhead is reduced the more the larger team is Okay, the more the greater the overhead of communication So what we want is to have this flow if our team is massive Let's break it into smaller teams. So our organizational restructure becomes nodal. It becomes a cell structure individual self-contained empowered self-organizing teams okay, our Customers need to be agile. Okay, we talk about the level of trust Reference trust my customer comes to me because they're recommended Contract trust I trust my customer because I have a contract saying if they don't do the work Then there are penalties and liabilities attached to it That's not agile. We want an agile customer. We've got to be up here. Our customers need to partner with us our customers need to be Part of our work processes rather than just the end output Okay If it's an agile question your customer needs to understand these three questions, how much is it going to cost? How long is it going to take and What am I going to get if this isn't the answer to your customer? And if they don't accept that answer then they're not agile you need to work with them to understand what the outcomes of those are If they're a partner, they'll understand if you just have a contract with them those answers are not going to be sufficient We talk about pivots once again We're here at the end of the second year. We're trying to change We've already changed our organization quite significantly, but the market is also changing with us if our market doesn't adapt Sorry, if our market if we don't change to our market, we don't pivot the organization then everything we've done is in in vain Okay, we talk about once again continuous improvement We continue to visualize and track our workflow. We introduce burn down charts We introduce cumulative flow diagram statistical run charts All of these are agile tools that we use to visualize Process and progress doesn't matter whether it's software the same tools apply whether you're talking human resources Whether you're talking sales and marketing or whether you're talking the board of directors Stage three. We're entering our third or fourth year in the example. I'm using in the transformation. I'm talking this was year four Okay We finalize the organizational restructure. All right, our teams are dynamic. They are small They form and reform depending on the business needs. Okay, we we no longer a matrix organization We no longer have silos. Okay, there are still business functions There's still a team or several teams that are responsible for finance several teams that are responsible for marketing and communications Okay, so these teams still have core functionality But the team members may change the finance team may have four accountants But they may bring in a graphic designer or a technical writer as needed to try and develop this specific requirements to the customer Okay, our organization is purely dynamic Okay, managers are responsible not to lead. This is sorry not to manage but to lead to facilitate Our organization transforms from a traditional structure Down to a much more agile structure business functions. We have coaches and we have some managers. Okay much simpler This is the city of Edmonton Okay, or specifically the IT department in the city of Edmonton. They went through an agile business transformation Okay, they no longer have traditional business functions Okay, they have people who are responsible for certain functions Then they have teams that form and reform as needed and they have a number of coaches to help facilitate the process okay To make this work larger organizations are going to have a skills audit They're going to have a skills register Okay, if there's 10,000 people in your organization and you need a technical writer You don't know who to bring in so there would be a register that you could look at Okay, we can bring in many of the agile processes test-driven work Pair work. These are processes that works regardless of whether we're talking about Software or not. Yes, automation is hard when we're not talking software It's hard to automate human resource recruitment. It's hard to automate the annual budget There are certainly some things we can automate and where the possible we should like that's a good practice But we can still define our test cases our acceptance criteria before we start We can still pair and have one observer and one driver We still have our retrospectives I keep harping on about the retrospectives because the retrospectives this is our mechanism This is how we drive change so This brings us to the end Okay, you spent the last 40 minutes listening to me talk about how to build an agile organization. I Have to say there's a community that is coming together agile business management org There are a number of case studies articles It's quite small at the moment We if you are interested, please join us if you would like to submit case studies If you'd like to have more ideas come and talk to us So on that note, thank you very much for listening to me questions No questions that all made sense. There we go. I knew there had to be a question You spoke about marketing becoming agile the question that I have is Agile is an experiment or a successful experiment in deploying new things in releasing new functionalities and releasing new features but most businesses also have a day job which is to Collect money collect revenue. So, so how do you break this jink of? Improving your current work and doing something new because most Most developers have a day job to write code and they can do that using agile It's agile is not just an experiment. It's not something that one team tries and then if it works great It's the entire software development lifecycle adjusts to How do we become adaptive? Okay, I talk about transformation and yes a transformation is a program of work Above and beyond okay, you're your day job, but the point of a transformation We talked about a vision the very first slide in this transformation was vision that vision is our end state Where are we trying to get to when we've hit that end state? It actually doesn't matter Okay, once we've hit that end state. We no longer transforming because we've transformed Okay, we still have the retrospectives because we still want to adapt but the major transformation is now over so Yes, a transformation has the cost always has a cost whether you're transforming to agile or whether you're transforming to a matrix structure Okay, it doesn't matter. There's always a cost But yes, the whole point is to improve the day job another question Hi, like you know, I have a small startup and I work with a bunch of people who have just come out of college People who don't have much of an experience and I also do they have passion They do I mean then good as long as they have passion passion over experience any day sorry continue and We are a services company and we have a marketing person who is not you know related to it at all And my concern is like, you know at this point of time when my team was really working on Four or five different things, how do I bring in agility in them? So working on fire four or five different things is is exactly what agile is about it's about identity like trying different ways of Releasing a product whether it's software your marketing person needs to be embedded with your software team Like you have a startup which means your employees. What ten something around that yet seven employees So you have a very small team they should be working not Independently but together every time your startup every time your developers release a new feature release a new function And we talk about lean start up We talk about being able to pivot being able to release minimum viable product The minute that minimum viable product is ready the marketing person needs to have a strategy of how they're going to market it How they're going to build that brand? All right, and then when the next comes up the marketing person needs to be ready So they have to be together. Okay, this is why I talked about cross-functional teams You don't just have a marketing person over here and a software development team over here You have one team seven people seven plus or minus two is your team size Everybody in that team should be working together for the common outcome And in your case it is getting a minimal viable product to market and having a marketing strategy to promote it One Hi, my question is You just mentioned that you know we have to transfer the organizations so various support functions like finance and so Think about an giant organization which is having a 50 years of history and is successfully running and They do have to implement agile. They have adopted one part of it But the other part of the other support function is working just fine So what if I throw up a question as to if I'm working fine? Why should I change? Very good question and the one that's usually asked to me. Okay. Okay. If everything's working fine Why should I change now? My argument to that is because it's working fine is when you should change It's working fine today. Okay tomorrow Something may happen the market may change and things are no longer working fine And if you're not ready for that change your business can collapse I talk about those fortune 100 companies at the beginning. They were going fine Kodak had hunt up like about was it hundreds of billions of dollars in revenue? Okay, and now they're like one of the smallest companies. They've been bought and sold a number of times. They're no longer a going concern Okay, so when things are going fine is when you need to prepare when things won't be You assume that things are always going to be fine Okay, then you will go the same way as Chrysler as Kodak. So that is when you have to change I'll leave it there. I'll have take if you have other questions, please come and see me I'm the one in three piece suit. I should be fairly easier to find I Have a book. I have to Obligatory I have to mention it. There's a book signing tonight If you have there are copies of my books in the conference bookstore Feel free to pick one up. It's a significant discount for the for this course sales hat off If you do have any questions, okay beyond that, okay? That's my email address. That's my Twitter handle I'm relatively active on Twitter or come and see me during one of the breaks. Thank you very much