 All right. Good morning. Great to have you all here. You are very daring. You're coming to a very difficult topic now. So you obviously want to learn something. We are together in this challenge. And I will explain to you a little bit why. So I'm Henrik Esser. I'm working at a telecom company called Ericsson, very large organization. In that organization, I have done a pretty normal management career, you can say. So starting as a software engineer, project manager, project office manager, head of operations and programs, and so on. And I have a lot of experience and background now in large-scale agile transformations. And at the moment, I'm having a very interesting role. And that is I'm a sort of in-house consultant or organizational coach. The formal title is Manager Special Projects. And I'm running around a business area of 15,000 people. And I'm trying to help this organization to evolve and take the next step. And that next step for us is really business agility, you could say. We are not talking about business agility. We are more like discussing how the world we live in, what that does to us, and how we could respond to this one. And in parallel, I'm also doing a lot of voluntary work. And one thing I'm doing is that I'm working for the Agile Lines as Program Director for the Supporting Agile Adoption Program. So there we are exploring with some thought leaders, how can we advance agility in organizations. And today, I'm going to talk about Agile Finance. Now, I'm not an Agile Finance expert. You will find that probably out at the Q&A. But I have been in my roles of running project offices. I've done a lot with supplier management, with financial controllers, and so on. And in that background, I got in contact with actually IC Agile last year. And IC Agile, I don't know whether you know what that is. IC Agile is a training accreditation company from New Zealand, I think. And what they are doing is they are providing learning curricula, learning outcomes for certain types of trainings. And they have all sorts of Agile trainings. But now that business agility is getting more and more on the agenda, they have also now founded an Agile Finance track. And I was asked last year as a volunteer to lead a team of experts from around the globe. I see one person sitting here. Thank you for coming to explore what if somebody would offer an Agile Finance training, how could that look like? What are the learning outcomes that should be achieved by such a training? And that was a very interesting thing. And why do we do this? There is very little Agile Finance training, and it's not normalized. It's very unclear what Agile Finance actually all encompasses. And now we have formulated this in a nice, compact document where we say these are the learning outcomes. And those are actually creative comments. So all of you can actually, it's not yet fully published. It's coming soon. When it's published, you can go to the IC Agile web pages and download it. And you get some inspiration for what does Agile Finance actually mean. OK, so what am I going to talk about today? So this presentation is going a bit along these learning outcomes that we have identified. And it starts, of course, with what does Agile Finance with an Agile mindset actually mean. And then we are going to look a bit into some disciplines around financial handling. And one thing is budget and cost management. We're going to talk a bit about accounting and Agile procurement. And I will also very quickly talk about how to do the change, how could a change program look like, and how to address the change. So let's get going. Finance with an Agile mindset. OK, you have seen this before. Who knows what WUKA means? We all have been discussing this a lot of times. And it has been repeated now by Jürgen in the previous talk, so I don't need to go into this one. We all know these. But what we also see in our companies is that there is a friction. There is a friction because finance is somehow going against our Agile product creation. And somehow we are not friends with each other in our companies. So there is things like the financial targets that we get. They demand predictability. But our Agile teams are saying, we are ready when we are ready. We cannot predict, so a friction arises. So how much cost should we put on, should we reserve for a certain project when we don't know how long the project will take? There is a tight budget follow up coming from the finance community. And that feels like, hey, we cannot predict. And now you annoy us with tight follow up on our financial figures. The funding decisions usually are taken seldom. So many organizations and companies are still with yearly budget cycles. Budgeting, therefore, is seen as pretty inflexible. So that's one side of the coin. The other side is there is a lot of regulatory requirements. Of course, different countries have different regulatory requirements on how financial reporting must be done and so on. And that has a good reason. I mean, there should not be anybody doing bad things, like washing money or hiding things or whatever, paying taxes. So there is some reporting guidelines. And the question is, in how far is this conflicting agility? And that's often people think, oh, all these regulatory requirements, they are impeding agility. Is that really so? So we are going to look into that one. All right, so dealing with complexity, we are talking about the VUCA world, volatile and uncertain complex ambiguous. And we have learned a lot over the years about complexity. And one model that's very often used also in our agile product creation is the Kinevan model. Who of you knows the Kinevan model? OK, not everybody. So this is a model that was created by Dave Snowden. And there's a Harvard Business Review article from November 2007, which describes this. So I will not go through the whole model. But what the model basically says is as employees in the company, as leaders, we are confronted with different types of challenges. And it really depends on what kind of challenge are we confronted with. Is it a challenge where cause and effect can be easily understood? So if I do this, this will be the exact outcome. Or is it more unpredictable? If I do this, I don't know what the outcome will be. And one part of this model is this domain of complex. Complex means predictability is not really there. I mean, you could maybe say, half a year ago, we have taken a certain decision. And as a consequence of that decision, that and that thing happened. And then this was a consequence. That was a consequence. So looking back in hindsight, you can make sense of how you got where you are today. But half a year ago, it was impossible, basically, for you to say, I take now this decision. And this will be the precise exact outcome. And that's a dilemma in a world where we try to predict if that predictability is not there. People are asking for guarantees. How can we do that? So the Kenevan model suggests how to go about this one. The intellectual language here is probe sense respond. What it actually says is, we need to look at the situation we are in, try to make sense. What does this really tell us? What can we do about this one? And then you respond. You try something. And the approach is a very experimental approach, meaning we cannot know the exact outcome. So we rather do a little experiment, see that this lead into the right direction. And if yes, we go further. If not, we are trying something else. So this is how you deal with complexity. Now tell this to a financial controller. That's, of course, a bit of a thing. But this is actually what science tells us. So how can we make use of this one? Now, another aspect of the whole thing is when we want to adapt finance to agile organizations, I mean, we need to go agile. Agile is the approach to deal with complexity, work in short iterations, and so on. So we always use the agile manifesto, like individuals and interactions over process and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, responding to change over following a plan. Now when we show this to our friends in HR or in our friends in finance, what do they see? They look at this, and they think individual interactions over processes and tools. Actually, what interactions do we have here and our financial tools? Are those helpful? Helpful? In the financial sector, we are actually communicating a lot via tools and databases. We are recording figures. We are doing follow-up on figures and so on. Where do we actually interact? OK, so this might guide us in our thinking a little bit. Working software over comprehensive documentation. What the hell has that to do with finance, you think? Well, nothing. This isn't helpful for finance people. Customer collaboration over contract negotiation. No, that is an interesting one. How does finance focus on the customer? Is there a customer focus in finance? How can finance help product development focus on the customer is maybe another question. But somehow we get stuck here. We don't know what this really means. And then responding to change over following a plan. Well, this is an interesting one. How can finance get over these stiff rhythms that we have? That's maybe. We have rhythm, but they are very, very long. And they are not seen as helpful. So somehow the agile manifesto, is this really helping me being in a finance position? Probably not. So what could we do? Well, there's good news. And those of you who have been on this conference last year, so even a keynote about that one, there's another model which is absolutely compatible with agile. And that's beyond budgeting. There's another framework beyond budgeting. And me and the supporting agile adoption team, Jürgen was part of it. We have once been sitting together with Bjarta Boxnes, who is one of the drivers of Beyond Budgeting. And we have been looking through Beyond Budgeting principles and agile manifesto and principles just to see how compatible they are. And they live together wonderfully. So Beyond Budgeting is agile for HR and finance, you could say. So what does Beyond Budgeting say about this whole thing? And Beyond Budgeting is structured in a little bit different way. So Beyond Budgeting is a framework that is enabling business agility, and they are distinguishing leadership principles from management processes. So let's look at this one. Leadership principles. There's a purpose, engage and inspire people around bold and noble causes, not around short-term financial targets. It's a bit like we value this over that from a thinking point of view. But there already we see not around short-term financial targets. So there is a concrete hint for financial people, hey, this is something I have to think about. Values. Governed through shared values and sound judgment, not through detailed rules and regulations. Oh, that's a tough one for a financial person, right? There's a lot of rules and regulations. What does that mean for me? Transparency. Make information open for self-regulation, innovation, learning and control. Don't restrict it. Information open. How much financial information is actually a secret in companies? Does it have to be a secret? Those are the questions arising from these things. What would happen if we open up more on our financial figures? Organization. Cultivate a strong sense of belonging and organize around accountable teams. Avoid hierarchical control and bureaucracy. But isn't this what financial control is about? Hierarchical control. So it makes you think. Autonomy. Trust people with freedom to act. Don't punish everyone if someone should abuse it. That's also an interesting thing. Something goes wrong in our companies. And then we want to avoid that this might ever happen again. And what do we do? We introduce a new rule. Often we forget what's the likelihood that this problem might reoccur. And if the likelihood that the problem reoccur is very low, maybe you should not add another rule because you're just over constraining the organization. And then the last one of the leadership principles, customers, connect everyone's work with customer needs. Avoid conflicts of interest. That's interesting. It's a clear pointer towards the customer. And then there's management processes and they make this thing even more tangible. So rhythm. Organize management processes dynamically around business rhythms and events, not around the calendar here only. A lot of financial procedures are organized around the calendar here and not adhering to business events or business processes. That's quite interesting. Targets, set directional, ambitious and relative goals avoid fixed and cascaded targets. Plans and forecast. Make planning and forecasting lean and unbiased process, not rigid and political exercises. How many people are fighting for a budget because of political reasons? I believe that my unit or my operation is the most important one and I'm fighting for my budget and I even use strange attempts or strange measures to get what I want. Resource allocation. Foster a cost-conscious mindset and make resources available as needed, not through detailed annual budget allocations. Ouch. I mean, how many of us have annual budget allocations? Performance evaluation. Evaluate performance holistically with peer feedback for learning and development not based on measurement only and not for rewards only. How do we incentivize? And then the rewards themselves. Reward shared success, shared success against competition, not against fixed performance contracts. So you see that beyond budgeting, leadership principles and management processes, they resonate much, much easier with people who are working in these kind of roles. And as they are compatible, very compatible with the agile principles and the agile manifesto, this is maybe the thing that you can recommend to your financial people to look at. Beata has written a wonderful book about this one. I recommend also to read that one. That book also contains concrete examples how this is implemented. And we are going to look into a few aspects of this in a minute. All right, so changes of role of perception. So with all this in mind, it means that the financial profession needs to change and the role of financial people is changing. So what we know from the VUCA world is that changes need to be accommodated fast. And that means you need an iterative approach and feedback loops. And that means you need to move from seldom and big decisions to frequent and small decisions instead of having the yearly super big budget round where you need months of analysis of what is your business forecast and so on. You have to do this in a much faster rhythm. And that means also that finance is going from gatekeeping to being an enabler for decision making. So the purpose of financial people is much less making sure that somebody adheres to a set budget more going into how can we enable decision makers around the company everywhere, maybe even on team level, to take good decisions? How can we feed them with financial data? It goes from controlling towards management decision support, financial trend monitoring. So where is the world economy going? What does that mean for us? How is the financial situation in our business segment going and so on? So it goes pretty much from yearly rhythms to continuous rhythms, like what we do in the agile product development. This is of course very painful because these yearly exercises, they are heavy, administratively heavy. Lots of people involved, lots of discussions. And they take a long time. And when you then try to do them faster, everybody thinks like, but this cannot be done faster because just look at all the amount of work that's needed for our yearly rhythm. And the thing is, and you maybe know this from your agile product development, if you just go and start increasing the speed, shortening the cycles, people are becoming very creative in seeing how can we remove unnecessary stuff from our heavy processes. So there is actually, you create an incentive to make things much more lightweight. And people are creative. Once they start looking into this, they will find a way how to do this. And it's a bit like what we do in the product development. We always talk about continuous integration of our software products. This is like continuous integration of financial data and financial updates into management decision and strategy evolution. So it's really about guiding decision making in the moment rather than enforcing adherence to a previous decision and plans which likely no longer apply. Okay, so that is a bit like the foundation beyond budgeting principles and the chains of role for financial people. Now let's start looking a bit into some practicalities of the thing and let's start with budgeting and cost management. So what's the purpose of budgeting? So essentially what you want is that you want to direct your financial resources to the place that provides the most value for the company. And most value for the company, of course, means you want to have delighted customer, but you want to have them also in a profitable way. I mean, just customer delight is not the only thing. I mean, you can be very much delighting a customer but you can ruin your business. So how can we do this? Where is the place actually where money provides, where the return on your investment is the best one? And in a WUCA world, of course, this place where the money is invested best can change very dynamically. And that means we need to have these continuous rhythms and the distribution of the financial resources needs to have about the same pace as the agile product creation. So if we are able to release products not anymore once a year, but every month, maybe we also need a financial rhythm that helps us to root the investments in the same speed. So how could this work? And this is the thing that beyond budgeting is actually suggesting. So beyond budgeting basically says, there's three core purposes of a budget. The first one is target setting. Target setting is about what we want to happen. So this is the target. Then there's forecasting. That's what we think will happen. And the third one is the resource allocation, what it takes to make it happen. Now these three purposes of a budget, they are unfortunately in most companies merged into one process. And when you merge them into one process, you're ending up in a problem. Because then you do something like this. You have, for example, a sales target which should actually express what we want to happen. And at the same time, you base your forecast on that sales target. So you say, we are going to allocate that and that much money to this thing. And all of a sudden, you actually, you have mixed what we want to happen with what we think will happen. What's the consequence? The moment we know that these two are connected and you know, usually people are pretty good in understanding what I think will happen because they have my assumption. Then I get very cautious on what targets I'm going to accept. All of a sudden, people are very cautious on the sales target. Are the sales target then still ambitious and courageous? No, they cannot be. By mixing, for example, these two processes, you're just ruining the whole thing. So it makes a lot of sense to split these three purposes and make one process for each. So that's the first thing you should actually do when you go towards beyond budgeting. Separate the three. And then when you're separating them, then actually you can evolve the whole thing because once the target setting, what we want to happen is separated from what we think will happen, then you can make this much more inspiring and motivating and challenging. Then you can say, what we want to happen is this and we can be very, very bold in this one because it's safe. You can be very bold. It doesn't mean that you have now a personal, your bonus is connected to this one. Another thing that is important is make this relative wherever possible. It doesn't make sense to make sales targets in a volatile business environment because if the whole market goes down, for example, and you miss your target, that's not a nice feeling. And especially even it could happen that the whole market is going down, you are performing better than your competitors, for example, and you still don't get your bonus. So you should maybe do something like a relative target setting where you say, the whole market went down, doesn't really matter. We want to just have x% more net sales. We want to be better than our competitors or better than the average of our market segment. And the third one here is holistic performance evaluation. So it's not only about financial targets or whatever, it's about the outcome we create as a result of the company's efforts. Yeah, forecasting, when you separate it, then forecasting becomes a very unbiased thing. The whole gamification of this thing moves away. The forecast is really what we believe, what we truly believe will happen. You're not living anymore in dream world. And another thing in forecasting, which is also very important, is to limit the amount of details. We all know this from our agile product development. The more detail you put, for example, into a plan, the more you are getting into the illusion of control. You think you have it all under your control, but you haven't. So you need to limit this in detail. Yeah, and the resource allocation, of course, allocation of financial resources to wherever it's needed, that should be actually event-driven, not calendar-driven. Yeah, and that needs continuous mooring adaptation where needed and when it's needed. So this is like continuous integration of financial data and continuous learning on a financial side. Related to this is a big mindset shift, and that's also an interesting one. Instead of having one big upfront budget, you go to become cost conscious from the first penny. Actually, you're not losing control, you're actually becoming more cost aware and even more cost obsessed, and it's not only one person, the financial controllers who are the shepherds of the budget, it's everyone. So traditionally what you have is a budget level, a budget limit that you maybe have an annual budget or whatever, and always when something new comes up, the question is do I have a still budget left to accommodate this thing? And instead of that, the mindset shift and the way of working goes towards is this really necessary? You have a lot of mini budget decisions, one by one is going iteratively, and by that you have much more anchored in the organization the thinking of is this really necessary and profitability thinking. Okay, so much about budgeting. Then a couple of words about accounting. So accounting is very often related to regulatory requirements, and you could think that regulatory requirements are a very difficult thing to handle because governments are imposing a lot of constraints on companies. But is it really that bad? So examples of regulatory requirements are like you have to produce an annual budget, and you need to do your annual reports and so on. Then there is things, and that is the thing I was personally involved in quite a bit was capitalization rules for intangible X assets. So now how do we go about in the past when we had the big product releases once a year or every twice a year? It was like, okay, now the product has achieved market availability, now we capitalize the investment that we have taken. Now when you do this iteratively, when do you capitalize on things? This can become a very tedious thing. You need to find a way how to do this. And another example is revenue recognition for work performed under contract. The insight from all this when you look into this is that not all financial procedures and regulation need to change in an agile organization. So some of these are really like annual reportings, no problem. This doesn't affect your agile development or whatever at all. This is just a formal reporting to some institutions. No problem, we can still keep the old procedures. But then there's other things like the capitalization thing that you really need to think. And my experience is when you come across this problem and you sit together with your financial controllers and you start thinking, okay, how are we going to do this? You will find a solution. This is not an unsolvable problem. And there's different approaches to this. So what I've seen is, for example, that you, for example, say, you capitalize every single feature that you're developing. At the moment, the feature is available. You do it, might be pretty heavy. Or you make bundles of features once per quarter. Some have said we move towards an annual run rate on product development. So we capitalize it once per year. There is different ways to do this. It's no rocket science at all. And what we find also there is that there are these synergies between agile approaches and the objectives of compliance organizations. So sometimes compliance organizations also would like to know, where are we with this? And due to the agile approach, also you get more transparency on things. And transparency is actually something very good when you are talking about financial things. All right. Then some words about agile procurement. And that's also an interesting thing. I mean, I was working with supplier management for a while in Ericsson. And how do you sign contracts with suppliers? This can be a tedious process. And actually, Ericsson is a supplier to telecom companies. Those processes, they are really, really heavy with RFIs, RFQs, tendering, and all these kind of things. So, yeah, what we want to achieve is actually partnership. And that's the whole thing that's happening here. When we go towards agile procurement, it's very, very much about becoming a topic of partnership between vendor and order. So although agile contracts are more collaborative in nature, I mean, generally these contracts are collaborative. So for example, when we execute on an assignment, then often we have time and material contracts, for example, with our suppliers. And the teams in the supplier organization, they are almost like they are part of our company. Because we are in one software or product development flow, and we don't want to have barriers or hindrances or cues in this one. So we work fluently with each other. The question is more, how do we get towards that point where we can have the agile flow? And the approach there is to co-create a joint agreement based on a shared vision and equal partnership and consider then aspects like intellectual property rights and so on. Now that sounds very high level and theoretical. There is actually practical approaches. There are people who have developed a practical approach how to do this. And I'm going to show this. I'm contributing to the IC agile finance track. Mirko Kleinert from Switzerland, I think he is. And he has been looking into the topic of procurement. And this is the classic procurement flow. So you start usually with creating your business model canvas. You're thinking about your business model and so on. And then you think here are my key partners. That's one who of you knows the business model canvas, by the way, maybe just a few. So this is a way how to capture a whole business. Alex Osterwalder has created this thing. If you don't know it, go to the web and take a look at the business model canvas. It's a really helpful tool for capturing an idea of how a business works. One element in this business model canvas is key partners. When you create your product and your value proposition, what are my key partners? And that's the moment where you're going into procurement. So what you usually do is you have your business case and then you have some design study. You have a tender document. You have your long list of potential suppliers. You make a contract specification. Then you arrive at the short list after some discussions. Then you sign an offer and then you sign a contract. And then you can start your agile execution. But this takes a lot of time. The study here shows three to 12 or more months just to get towards signing a contract. And that's like eternity in the modern world. So how can we make this better and faster? So what they have been finding was that actually we can do this very much faster. The procurement phase can be actually, when you start this in a partnership way, it can start much, much earlier that you start co-creating. And what you do is, okay, you have your business model canvas and out of the business model canvas, what you get there is what's the purpose? Why are we going to do this? And that's a very important ingredient. So what you do is there is something that's called the procurement canvas that these guys have created. Also that you can download from the internet. The procurement canvas is guiding you in these contract discussions. And what you actually do is you invite potential suppliers into one room. It's almost like a scrum team, a cross-functional scrum team. And from the supplier side, you really want to have people who are later on involved in the execution of the thing. So it's really the people who are going to do the job. You invite them to the same room and you start sharing with them those parts of the business model canvas that are relevant. Why are we doing this? What's the purpose of this business? What do we want to achieve? And that's actually one part of the procurement canvas and then the second half of the procurement canvas is basically the supplier's answer to these needs. So in these meetings, because they are face-to-face, it's like a cross-functional scrum team, you're sitting together for a day discussing these things, getting a deep, deep understanding. Forget about communicating a tender document and all these nasty lists communicating via documents. You communicate with people, people collaboration over contract negotiation. You communicate the purpose. Your vendors are thinking about how could they go about this whole thing and then sprint after sprint, you refine it. That's the basic idea. And on this path, you might even throw out a couple of vendors. So sometimes there's, of course, a competition and this guy, Mirko, they have done these kind of things like this. Three vendors coming in into these meetings and they're actually competitors and they all have their sprint links and after a few days already, you see where this is going. Are they able to respond to your business need or not? And you can take those decisions much, much faster. So this very collaborative partnership, still competitive approach, makes you much, much faster. Another important thing maybe to mention is here, because this takes so long, all this thing, all this heavy documentation that you have been formulating. And that vision might change and then it might be that you have created the contract based on a vision that is not working. So here, because of the partnership, you have also a lot of sparring partners. Maybe your supplier will say, but wait a second, I don't get this. How is this? And out of the conversation, sometimes you find out, oh, my initial vision was maybe not fully correct, but I wanted to improve the business situation. All right. And then you are updating as you go. You are updating the procurement canvas and you get deeper and deeper in your understanding of how this collaboration could work. There's four critical ingredients that make lean agile procurement work. The first one is remove or minimize the handovers also in the procurement process and that is achieved by putting together a cross functional team into one room. It's the same thing as with a cross functional team, same idea just in a financial sector. Include the people who will do the work from the very start. So when you are meeting with your supplier, really ask for those people who are going to be later on the ones taking this further. Foster collaboration with all your techniques and approaches. So it's really like show the business model canvas, show your whole idea of what you want to achieve. And bring all into one room for a sprint like start of the project. So the communication is very important. Very agile, isn't it? But in a financial way. So, and then a few words on how to change. So this is just a very rough sketch of what you can do in the financial sector. How to change? How does an agile transformation in finance work? I got that question also in this conference in the last days. How do we manage to make the most important thing for my point of view is always first of all, it's a normal agile transformation like in product development just that they need to use maybe a different thing than the agile manifesto. Maybe they should use the beyond budgeting. So, first of all, it's not we versus them. If you always complain, if we in the product development make ourselves the victims of finance and we are always going in a victim approach to them saying, yeah, we could do so much better with rules and nasty regulations. That's not helpful. So it's rather embrace it and say instead of being next confronting each other, looking at each other, it's maybe better to say, okay, let's then side by side. This is our problem. How do we solve this? Let's join forces. In the case of the agile transformation that I was part of, we actually involved the financial people from the very start. So if you are at the moment and are going in agile transformation and you haven't done it yet, bring some business controllers in. Let them be part of this. Let them understand it. Those are human beings who are actually themselves quite interested in getting empowerment and all these nice things that come with an agile transformation. So their hearts will be very open for this and then the question is just how do we solve all the problems like capitalization questions and procurement questions together? It's not my journey versus your journey or I'm so right and you are so wrong. Let's make this together. So it starts with a conversation. What is our common goal? What do we want to go for? So in summary, agile finance is absolutely not rocket science. This is possible. There is assets, knowledge assets and tools available. The agile manifesto actually is not so helpful enough to guide finance. I would really recommend to go for beyond budgeting which is a much more suitable framework. Read the book if you like. He's taking speaking engagements. The role of finance moves from a gatekeeper to enabler. That is very, very important from a mindset shift point of view. Separate the three purposes of budgeting. Target-sectoring, forecasting, budget allocation. Separate them clearly. Have a process for each of them. The regulatory requirements can be fulfilled also with agile approaches. There is nothing strange with that one. There are sometimes some limitations of it but not to the extent that it hampers your agile company transformation. Use the agile procurement canvas for fast creation of agile contracts. That's another thing I would recommend. All right. With that we can open up for questions and we have a microphone over here. Thank you for the wonderful introduction. I have a question on the agile contracts. In the agile contracts it looks like we will engage with the favorite partners. But many times that may not be true. It could be a new territory and we want new kind of partners to be engaged with. How does that work in that space? With a new partner. Yeah, a new vendor partner who we are dealing with. So in the example which you showed it dealt with the favorite partners where you already have some interaction and you know how to work together. Actually, maybe I wasn't clear enough on that one. Milko has examples where he was inviting not only the favorite partner but maybe two others they haven't been working with before into the same room. So those three vendors although they are competing they are in the same room and they are together discussing with you as an example. So the business model, the business case and the procurement canvas. What is the business we are after? What is supposed to be achieved? And then those three vendors let's say the one that is maybe the favorite one from the past but maybe also the two new ones they go and think okay how do we respond to this one? And you integrate it. You come back into the room and so on. So you do this actually together and maybe you can say okay now here we have the most convincing answer so the others are out and then you can also argue you can explain much, much better why certain vendors have not been selected and others have been selected. So that's the suggestion that Milko has and Milko has also some real life experience from that one. We are still struggling in that space. The favorite vendors are vendors and the other for a longer period it is a lot easier. We have a tendency to reuse the same vendors as before but you always need to invite some new people because of two reasons. One thing is you don't want to lock yourself into one vendor and the other thing is sometimes it's just good to explore other opportunities to see whether there is somewhere else. Sometimes it could be just pure competence and that player is in that space. There is another question. My context of the question is actually a big entity which has its own legacy over the last I don't know 50, 60 years and in that context we are trying to bring this change, let's say. What in your experience was kind of the top two, three things that happen in Ericsson which actually started bringing this change and how much of this is the top down directive or it started at the top layer and then went up from the bottom. That's a good question. Ericsson hasn't gone through the whole transformation yet for us. One of the first steps was that's another interesting thing. When you see these, we need to go from yearly rhythms to shorter cycles. We started with monthly rolling planning. The problem that we did in the beginning was that we were still mixing all the three purposes of budgeting into the monthly rhythm which is a little it's a tiny step into the right direction. You have a higher frequency and the good thing, an interesting thing with that one was it was not the full step but at least we started to have a monthly connection point between the product development for example and the financial side of the company and because they wanted to talk more frequently to each other they could also talk about the problems arising and the changes and dynamics in the markets and that taught the financial people okay, this is a problem and people can't help, they want to solve the problem so they were starting to think okay, how do we go about that one and then a bit naturally we are not yet fully through with this one these three purposes get separated. So a good starting point is actually to go for higher frequency points and more interaction between the financial side and the product development side and then it develops a certain dynamics. How much of it was top-down? It was pretty top-down because agile transformations, that's an interesting thing, many agile transformations start top-down and it's like oh my god this is not agile, agile is not top-down the thing is you always need to start from where you are and when you are a hierarchically top-down company, you cannot just from one day to the next say okay and now you are self-organized, if you are up to it do it, that doesn't work so it really you need to start from the language that people are used to and that language is in the beginning actually a top-down language which means you are going to do this now and then but that's a leadership challenge, take the little step back saying okay now that I have told you that I start to move out. Hi, so this is Raj here I have a question where on one side we have this budget constraints and everything and on the other side we have this agile teams who are made to estimate in terms of let's say story points and there are a lot of this one where we should not estimate in terms of hours, when you see the traditional budgeting for a project or a product development we used to just see what is the scope and then we used to see okay how many people are required and how much time it would take based on some expert and this is the total cost of this project or product development but now the teams are given the autonomy to estimate in terms of story point and then give it back to the whatever so now the challenge is how to really roll it up from the individual scrum teams or kanban teams whatever they estimate and then to the budget where we still have constraints. And this is a perfect example where the three things target setting forecasted budget allocation are all intermingled and Jurgen was talking about this one how do you prioritize things you calculate things like cost of delay which is basically a question for where do I allocate my budget where is it most needed and then the question is really like what do we think will happen when you what you're saying is basically we are mixing those two and you need to separate them so what we did was okay we were starting to think about business cases okay we didn't talk about cost of delay so much but it's one parameter we think about where do we want to spend most of our budget so how do we prioritize the features that we want to implement but then from a forecasting point of view we said we have uncertainties on these features so how do we get that one out you know what from a budgeting point of view we are just making an annual frame for product development we just said we have X amount of people that are doing product development and we are just following up on this so you make it a run rate and but that you separate these two things and of course we did the follow up so let's say a scrum team or two scrum teams work on a certain functionality the business case says this has that and that high priority so it's the most valuable thing actually everybody agrees to that we have to work on and now during the development we find that although there is increased need of financial funding that's actually okay in that moment because when we did the budget allocation we were already saying we have a certain uncertainty around this one we have calculated the cost of delay we have done a certain risk analysis and even in the worst case we are still profitable with doing this thing so this is actually a question of budget allocation and then when it comes to forecasting that's a different thing you really need to separate those two no we don't allocate budget to the features we have an annual frame for all the software development is having an annual frame and then the we take out of that frame we say we need X amount of teams to work on that business item and the business item priority comes from delay and business case calculations and so on that much cost is accruing due to implementing all this stuff and this is the return and investment we expect and you are optimizing those things okay so we cut here and we can continue a bit if you like so you can come to the front and yeah thank you