 What less is large-scale from framework, what is safe is a scaled agile framework. This talk is comparing two things that are pretty much incomparable. So we basically decided to look them from a couple of angles that we go here, and one of them is work coordination, then there is batching and queuing, and then how to control work in organization and looking even from business point of view. So let's see how it goes. I'm Ron Neumann, I work with the less framework since 2005. It was not called less at that point, but it was still existing framework, and when we now look less literature, it basically was 2005, but we did there. And from 2008 till 2011 I worked with the safe framework, with a couple of big organizations, so I know how they work. You can leave them there. There's a question about the stuff there. So I'm a certified scrum trainer that you could see there on the slides if the slides would show that it is there. But at least it shows that I'm a certified less trainer. So why do you want to scale up agility? So basically the problem is that your organization is this kind of state. You have a huge amount of people there, a huge amount of things moving there or stuck there. So you want to get rid of this situation. So you want to scale up agility. Of course, the first advice is that don't do it. The more people you add in your organization, the slower it will go. There are already literature from 1950s showing that it doesn't work adding more people. They saw quote from Sage Project, that is one of the biggest, the first big software development project having over a thousand people. When the R&D manager was asked that what would you do differently when they have finished over budget, over time the project, he said that I would take 100 best people that I had in my organization and do the project with them instead of having the thousand people there. So how do organization then end up being wasteful? The answer is easily using common sense and fashionable solutions. Let's look how it goes. First in the beginning you have some business and then you have some developers developing something and somebody wants to give some money to the company developing the products and then you have some manager who basically pulls the people together and you are able to build products. The business is growing, you add more and more developers, you end up having more and more customers and it's not going so smoothly anymore. So what would you do then? You have verified the thing that having specialists in developing, testing, architecture and documentation work. So the common solution is that let's hire coordination specialists also known as project managers to coordinate the work. So the project management put the developers in nice boxes and basically the work start flowing. Now the business is growing even more. You keep on adding more and more people and even more project managers. Now the management has totally lost the picture but luckily they have still the project managers who are able to get something out of the system. Then it grows and grows and at some point you end up in a situation where even the project managers help there. The management is totally clueless. Everything is moving really really slowly and people are becoming resources instead of people. Management has this touched themselves totally from reality. They have no clue what happens there on the bottom level. And here we have then adjectives or statements that you see to work in this kind of organization. You have baiting, wasting, loss of knowledge, bad atmosphere, reorganization, un-clarity and it seems always when you try to do something in organization you cannot decide anything. The wisdom and power is always somewhere else. Have you been in this kind of organization? Of course here the solution would be that let's try to do it harder and you don't change thinking what is there behind. You keep on adding project managers, you keep on specializing people. It doesn't move anywhere. Or then looking at agile, fundamental change of thinking. Putting people instead of this kind of driven by project managers in this kind of teams that are customer-centric, focus on delivering products to customers, having business people directly work with the customers. But this would need basically fundamental change in thinking. This would mean that the organization would become agile. Less of this kind of talk describes how safe and less tries to move from this kind of project-based organization towards agile organization and what kind of solution they provide. So what to do? Scrum seems to work on one team and then there was the safe framework where you have Scrum there somewhere in the corner. It's there somewhere and then you have lots of other people there on top of it. But it seems that if you know that Scrum works on one team, it looks like safe would be one of your solutions. And then there's the less framework. Basically where Scrum is in the center. And one of the slogans is that large-scale Scrum is Scrum. So the differentiator factor is that you put Scrum in one corner of your graph or you put Scrum in your center and then you add things there that enable Scrum. Like principles. How should we organize our organization? What thinking there is behind? Then how to create, how to adopt less in organization? What kind of management support there is needed? And then what kind of structure we need there? And without forgetting that some technical excellence is also needed. And this is bigger picture of less, but let's not look at that more. So the key thing here is how you organize your things. Do you organize on technology specialization or customer specialization? And let's first look this kind of a component technology task specialization and how does it look like from the people working there and how the work is going through the organization. So we have some teams here. They focused on technology. They deliver something front and middleware, back end or whatever. This is typical way of organizing teams. Then you have the customers somewhere and the customers, of course, want to release from somewhere. There is a problem with the customer. Typically the problem is delivered to the product managers. And what should the product manager do with the problem? They have collected information from customers that we need to build some features. But we have this kind of technology specialized teams. Which team would do the feature? Of course, we need somebody there. Typical that somebody is, we need some enterprise architect or something like that. Who is splitting the work towards the teams. Now the teams could start working on the things, but there is huge amount of dependencies between the teams because the features or the customer problems, they are not technology specialized. They are specialized on end to end. So we need there somebody to coordinate it. And who is the coordination typically? It's the project manager. So we added their enterprise architects and project managers as minimum when you have technology specialized teams. The more teams you have, the more people you have. Typically there. Now about the deployment. Which team is going to deploy it? All of the teams are building their own technological part. So none of the teams can deploy it by themselves. So typically what we need there, we need some kind of system integration. Testing. Or even continuous deployment team. But that is separate team from the teams who develop the work. Typical roles that you see in organization who preprocess the requirements from customers are listed there. There is a huge amount of things. And I'm not going to read them through. So these people there, they discuss about things. They generate huge amount of ideas, what to do. So where they put their ideas is of course the tool in agile development that's called the bloated product backlog. You have lots of ideas from enterprise architects, system specialists, system analysts, business analysts. And they store all their ideas in the backlog. You can basically look any organization, how they work, that looking at their backlog. If they have huge amount of nice ideas in their backlog, you can bet that there's huge amount of people generating them also. This is not the only problem with the thing that your backlog gets about bloated. But when there is a problem in one team, they are busy on doing the work, so what to do then? You probably need on adding their more people. That's the common solution. Of course, they are not busy, but other parts of organization are busy. You basically keep on adding people there inside the organization and adding more and more people in each of the unit. And why does it happen so, is that you hire people for the specialized skills like in database or in the frontend. They can never transfer one part of the organization somewhere else. So the organization just keep on growing and growing because you tend to be always in a busy state. And of course, one part that is always busy is the system integration and testing and the organization just keep on growing and growing. So how does it feel to work in this kind of organization? You are working in one of the development teams there. Luckily, you have technology that you can work with. But actually, you don't. Enterprise architects, the specification people, they give you the work. They select the tools for you. So basically, you just work there by limited, how organization limits your freedom. And the other thing is that do you see ever the customers or the problems, know you get just requirements for you and you implement some requirements. Do you see any end results? Maybe, maybe not. But at least you don't see how your requirements contributed to that end result. So it's not even really fun place of work. So what would be an alternative on this instead of organizing in this kind of a technology or task specialization? It is of course customer-centric feature teams. And how does it work? We have a customer, we have a team. Customer has some problem. And the problem, of course, somewhere in the organization you have a product manager, product owner, whoever does the work with the problem. He prioritizes the work using some kind of a backlog based on what he thinks is most important. Gives the work to the team and the team is discussing with the product owner to get the work done. And then at the end you get some release deployment. This is basically what Scrum says. You have teams who take full responsibility of creating product input. Now when you scale instead of scale in this kind of a technology or task domain, when you scale the Scrum teacher teams there, how does it go then? You just keep on adding these kind of teams that take end-to-end responsibility of delivering the product. And they deploy the product directly and clarify the requirements directly with the customers. If you are more interested, there's a website called featureteams.org. It tells much more about feature teams. But the basic idea is that everybody knows Scrum with one team Scrum, one team is viewing the work. So basically you just take these development teams and call them feature teams and multiply them. How do you control them and work in an organization? We have a big organization. There are a lot of teams there in an organization. So how to control to get something out of the organization? Or there is still a person, he's still alive, William Auci. He came with this kind of an idea that there are three basic control mechanisms in an organization that I go through. He invented those and then he is also famous about inventing this kind of theories on top of theory Y and X that were developed by Mike Gregor. So what kind of control mechanisms he found out in organizations? He basically identified three things, market control and then we have a bureaucratic control and client control. And he identified this by looking at how work is enabled in an organization, how to get work done, how people control each other, how you control the organization that the output is something. In a market control it's simple. You have some business agreement, it's very exact. I give you money, you give me product. It's very simple, that is. You specify an agreement, everything. If the product is not coming when I want it, you pay me a fine. Then there is a client control. But you find out that all of the organization this is happening, there are people working having informal rules how to get work done. What William Occhi found out, this is only thing that works, this kind of client control and work is interdependent, ambitious or we cannot define it. Because then you have to discuss how to get work done. There's no other way of controlling how the people get to work done. Then there is a bureaucratic control that pretty much everybody knows. And it's based on hierarchy and formal power in organization. One example of bureaucratic contract is this kind of employment contract. You go to work for one company and you sign the contract and the contract says that we give you money and you work for us. But it's not full contract. You basically just decide because of the money the management is able to give you work and you assume that the management is evaluating you fairly. Now it comes interesting when we look at the client control the work is something that you cannot define. You don't know how the work is happening. How can the management evaluate your fairly? If the management is using bureaucratic control. Probably not very well. And lots of the conflict inside the organization becomes the management thinks that they can control the teams using bureaucratic control and hierarchy of power. So let's look at then three layers in organization and where these control mechanisms are most prevailing. These are in all of the part of the organization but where it's mostly used. This kind of top business management works with economical reality. They use market control. Then we have content workers who use client control they have to get things done, agree how to solve technical problems that you cannot specify how to solve them. Then we have a middle management using bureaucratic control because they are there in the between. They are detached from the reality. So basically all their work is pretty much following the processes. Make sure that we follow level of authority and things like that. So what do they do then the middle management? Analyze, coordinate, intermediate, execute and this is basically what they do there. So where is the actual power? The power is in the top. We have a top management, typically some business unit leader and he has the power to decide how many people we hire what products we have in the organization. Do we buy some other companies or things like that. Then we have this kind of a low level. The content workers they work with the technical reality because they have to actually achieve something and they can decide what to do there. And in the middle we have this kind of a dependent power. Middle management they depend on each other and then they also depend on the top and the low level. This leads to politics. And you wonder why your managers are always in the meetings is because to get work done in the middle you have to discuss with other people. And in politics there's nothing bad with that. It's just ways of discussing getting something done. It's just only way of doing that there. So let's then contract how this kind of a scale agile framework looks in these kind of control mechanisms. And basically it has some client system social rules there. As I said in the bottom we have this frontiers. We have lots of written rules, processes, roles, description and hierarchical power decided that who will decide what. And then we have their top, we have the market system basically the enterprise deciding where to invest money. Even most of the portfolio layer in the safe is just coordinating portfolio. It's not actually making key decision where to invest money. Now if we contrast that directly with the scrum. This kind of market control is nicely achieved but we have in the beginning product owner basically discussing maybe with the business side of actually making the key decisions at least. Then the team is left alone to do the work. They can coordinate the work whatever they like. There is no bureaucrats there to say that you have to do the work like this. And then the team is evaluated. What did you achieve? The product owner gives feedback and also the product owner is evaluated at the end. So how does then looks for the less framework? In the beginning we have product owner deciding what to do with the team. In the middle team is left alone and then at the end there is basically something coming out and the product owner is evaluating the team. So how then to coordinate work inside the organization? Manage dependency by coordinating people's time. It's basically the coordination chaos that I described there. And this is basically traditional way of doing it and basically you have the projects there coordinating people's work. And how does they reflect to the kind of levels of control? They basically you have big level of bureaucratic control there in between. And there is this kind of another way of doing that. That's pretty much when you have teams that are technology focused and basically you have then programs coordinating that time. It doesn't change much. Little bit less bureaucracy because teams take more responsibility but still the coordination between the teams is done by the program and separate pros there. Now when you move to feature teams what happens there then? Each team is responsible of coordinating their work inside the team so they are able to create the product increments and then we have some business person hopefully make some decision what they do and the team's job is to work as broadly in the technology as possible and make it happen. Teams coordinate if there are some dependencies between the teams and this is basically the key thing when you have a feature team they should be very little coordination between the teams. If there is some teams take responsibility for doing that. So what happens to the control layers? The market control moves closer because we have actually the business person making key decision the client control moves upwards and then the bureaucratic system hopefully goes smaller when the teams take more and more responsibility. So how to move the focus away from project to customers then? What is the key thing there? And the key most of the organization how they have organized organized this kind of a silos we have some functional department typical departments are testing development specification and then projects go there across this. So this is not way of organizing in ways that you can work with the customers because each of the department can only talk about testing and is the customer really interested in testing? Not much. Basically the idea would be to create product organization where you have teams able to discuss directly with customers because they take the whole requirement in and create something end to end towards customers. And of course this is then the challenging part when you move from this kind of a functional organization to product organization because what happens to the managers their top is not specified. At least less managers are needed or they become team managers. But this requires some management decision. How do you adopt less? Basically the key thing is here. You create structure so that the teams are able to work directly with the customers. This is the key thing in adoption. Of course when the teams start working directly with customers and try to create something end to end probably the technological skills needs to increase and you have to create some kind of a technical enabler so the teams can actually deliver something end to end. Now you discuss with this kind of a manager there in organization what do they say? It's not possible changing everything. And basically changing everything is really, really risky. But if you don't change nothing will happen. Change without change is impossible. So what you want to do is that you want to focus on some part of the organization and change that one to be agile, having feature teams, moving towards large scale scrum favour. But that's part that probably would be how many people we have in this room now. It wouldn't be the whole organization. You define some part where you start and then you learn how does it work in the organization and what works there and what not. You're not moving the whole organization to use large scale scrum favour unless it's really small. So why would you want to do that? But why the economical reasons there? And the reasons are basically we have component teams and programs or we have a feature team. With this kind of a component teams there's always coordination cost. It's necessary ways there. You are never getting rid of it. Somebody has to coordinate work with the component team. When you have feature teams they coordinate their work and limit dependencies where you focus is in learning. You basically broaden the knowledge of the teams. They learn more of their technology, more learn of the customer problem as well as all of them. And this is something that is investment. It should start paying off at some point. A flow of the work in the organization. Who is missing when we have this kind of a business management, frontman workers and bureaucrats there in the between. Of course the customer user. Typical organization when they have huge bureaucratic layer, how they do the coordination. Basically it happens like this, the middle management, they have lots of coordination roles and they also take work of coordinating the customer problems towards the frontman and towards the top. And how they are solving this problem is that let's keep all those middle management roles there or at least pretty much of them all the work is going from the customer throughout all the layers in organization until at some point they reach the teams. Now when you move from technology specialization to customer specialization what is the key thing there that you have to keep in mind is that when you move the team specializes on understanding customer problems they are able to work more directly with the customers because they understand their problems. They start speaking the customer language instead of what SQL lines we need to have in the database. So how that is a device to do in the large scale framework is then in the beginning product owner represent customer discusses with customers how to prioritize things. Then during the sprint basically team should have requirement analysis sessions with the customers so they know in the next sprint what to do. And then at the end of the sprint teams get direct feedback from the customers how they work it was achieved. So basically moving the teams closer to the customers but then the problem is that in the large organization huge amount of teams only few amount of customers. It's simple but it's not easy. You need to structure the things in the correct way so you make it happen. And then how to run this kind of a big meetings with lots of teams so customers get something out of that and how the teams get some feedback out of that. There are solutions. They are not even coming from less. They are coming from lots of other things but how to run this kind of a big session with lots of people effectively. Huge amount of facilitation techniques they are available. Though why would you do it? Why would you create organization that talks directly with the customers and courses the teams to learn? Because if the team is not learning they are not able to talk with customers and they are not able to deliver any meaningful software for customers. They don't learn to do more things together. The key problem here is that learning causes anxiety and according to Edgar Schein only survival anxiety is bigger than learning anxiety. So the key thing is that you create organization that the teams in the organization to survive here you have to learn. So and you can be amazed when they have to learn they start learning. If you give them chance that they just do the requirements they keep on doing the requirements without much learning. This is really leadership challenge in organization how to form the organization and how to basically get it happen. It's not an easy task. Like any real change. It's not easy to create real change in organization. Then batch size and cues. Guess fundamental formula that we have coined that the longer you need plan longer if you have really specialized teams. Basically the reach of the planning has to be longer. Why is it so? If you aim for high capacity utilization you need to plan longer if you have really specialized teams. Because none of the customer requirements are evenly split with your team so if you want to have all the teams busy on something it's good to plan longer because all of the teams get some work. We have not really formalized yet the mathematical proof behind that but we are working on it. It requires some analysis. So save batch size. How much work in the safe you typically plan. You have this kind of a release planning meeting that you do every second or every third month depending on organization and basically you move work from there outside the system inside the development system. And then the program is over and basically then you start another program plan. Nothing though prevents that you could release several times this kind of increment there in the safe but what this picture says is that you plan for the whole two to three months and you create, you move huge amount of work inside the system. Then compressing logic and scramble back choices. Basically you have some work to be done and then you have less system there. You have a sprint planning meeting. You move work something to four weeks inside the system. And after that you have some increment ready. Nothing though prevents even in the list that you could release every day. So what's the problem with big batches? They typically lead to high holding cost lots of working, progress lots of use in organization and things like that. But there are some laws there in the why it's done so in the ways where you are not able to do and let's look first picture of state. So if this kind of a planning cost is high or releasing cost is high basically basically your optimal batch size would be somewhere there and basically to minimize the cost. Only way to move this kind of a smaller batch size less so the safe meaning would be that your planning and releasing cost gets down. To minor it safe is not advocating anything like this but maybe it is kind of special about this. So then how about less there? The key thing less was that we plan for two weeks and after two weeks we aim to release something. So that basically tries to move our batch size smaller mind forcing us to reduce planning and releasing cost. Otherwise after two weeks you have nothing done. If you have three months time to do it it doesn't force you to reduce the cost. It just tries to drive organization to be faster just by having short iteration. Then cues there that we discussed a little bit but I have a picture here that shows what it happens. You plan the sprints and you plan the work on some level in the release planning meeting so you can after release planning meeting commit. It basically focuses on optimal resource utilization. Of course in the less we have cues also but the cues are only for two weeks and basically those are over. What it optimizes is that the outcomes after it release. Everybody probably have seen the problem with being this kind of a cues inside the system and big batches and what is the problem there so I'm not going to go through it. But this is the nice quote from Stefan Tomke and Donald Reiner saying is that cues delay feedback causing developers to follow unproductive batch longer. They make it hard for companies to just evolve to evolving market needs and to detect weaknesses in their product development before it's too late. So cues and big batch size is actually quite big problem. So we have 15 minutes time. So we have 15 minutes. So we don't skip the slide. All right, business view. This was in the coordination chaos, the situation in the beginning but we discussed you have some customers, some business, some team doing it and then you keep on adding their basically teams or members there and basically while you add more people there you tend to add also more managers. And if you look from agile manifesto but it says that business and developers should work together and things like that and when you have lots of managers they're intermediating things it doesn't really follow agile manifesto. So when we put there this kind of a if we don't change anything there in between we put there a framework that allows us to call as agile without changing many things basically it doesn't change anything. You still have the teams there they are separated from the business and separated from the customers they have huge amount of coordination roles and hierarchy there in between the less solution in this problem would be that let's put this thing to work together and of course it seems to be too simplistic and basically as we discussed on organizational design you need to change how the teams are organized it doesn't really work otherwise and of course you add there some business person to drive the teams and how to scale up the business person there is some solution for that and of course without forgetting that the team should also discuss with their managers and managers you'll be there to ensure that we have capabilities in organization and we hire good people still I mean people live and they are basically stay in our organization as long as possible. Now something about the summary of these things Save the slogan is program execution one of the safe values then less was scored by one person like having to be customer-centric learning is the slogan to be there While your proposition in safe scale agile in safe it is improved program execution, improved coordination and maybe lean on agile base of working also there with less basically minimal bureaucracy could be one solution program processes agile in best practices and then solution in less is basically you need to change your organization to focus on customer control mechanism bureaucratic and in the less the control mechanism is basically trying to use the mechanism from scrum basically market control and inside client control and then adoption and scope there in the safe is basically one program at the time or one layer at the time and in the less it's one product at the time and if your product is bigger than 100% it's just one part of the product Did it take 5 minutes? Alright then we have more than 10 minutes for questions No question You don't need a mic for the question Yes basically when you have a really specialized teams and you want the teams to be fully utilized 100% utilized and you have some customer request coming inside the organization you can be pretty sure that the work is not evenly distributed some teams are really busy some teams have lots of capacity So let's add some new feature there It distributes totally differently but it needs some work for the one team that is really busy So to make the work happen that we need from one team that's really busy, we extend the planning scope so they can actually do it Specialization factor is basically it should, we haven't really thought how to measure it Probably you could measure it on how widely they work on the code base or how wide skills the teams have together How to accommodate production issues I'm not going to go into that detail on any of the frameworks Yes The cost is more just because you plan longer No, it is a sprint planning and the release planning is of course there is a release planning but it is adjusted after each sprint So it fits for your purpose If you don't want to change anything you get the framework where you basically can nicely put it on an organization with minimal changes or you take another framework that you basically sets in the beginning to achieve some significant change you actually have to change something Some persons have called I was in one of these kind of a seminar or conference in Finland called this kind of a safe as a Trojan horse of Ajalli Basically roll out But if you discuss with manager that we are going to bring Trojan horse in our organization that will destroy our organization how would the manager look at you? They fit in the organizational layers nicely Quite nicely Yes So somebody mentioned that safe and less are Yeah, they have history and Nokia both some of the history and your question is about what? Yes And safe was mainly used at Nokia mobile phones and less is still used at Nokia networks and where is Nokia mobile phones now Maybe it didn't have anything to do the Ajalli framework that they used there But yeah Safe is unsafe No, I would say that it's really safe for the people in organization Nothing will change or something will change there but not so much Very well adaptable It just says that how you form your teams that the advice is that you can have teams across the globe but try to have the teams in one location one team here and one team in US Instead of having this kind of a half team here and half team in US and they can't discuss with each other ever because times are different And that's not even coming from less I think it's just coming that forming teams like this is pretty much impossible There was a team that scared the customers away Maybe It's up to the basically discussion with customers that how often you want to come and see it How often you want to give us feedback making sure that we are developing the right product if you have some customers It could be that you develop product without any customers You just try to develop product for the market that doesn't exist at all There was something here Use it's voice, popular I have no idea Sorry, I have this kind of a thinking that Have you ever seen any organization when it does something so it becomes more simpler Basically I've never seen it They always come more and more complex If you start with quite many roles there and hierarchies you probably can bet that they invent more So it's highly unlikely that it will become simpler I have no answer for your question I don't know the future of the sake What you are able to do with it How does it compare with Nexus? I have not really studied Nexus so much What I've read about it a little bit seems that Nexus is just how you have themes and form a little bit with the themes without thinking much about the management of an organization or the adoption of the things in an organization Somebody says that my view seems to be correct Any other questions? Thank you