 My name is Fredrik, and this is, so we are here from Sweden, and we're gonna talk about how we achieved 10 times better quality with agile transformation. And as Sean said, I don't know if you attended his talk earlier. This is our experience, and we hope that perhaps you can learn something, but from it, but it's not how you can do. I mean, you have your own environment and cultures and everything, but I think it's good to spread the word that it's possible to be successful with agile, and that's what we want to do. Okay, now my mic is on. We have a goal of our own with this presentation, and it's about our key factors of the transformation, and the goal is we want you to understand why those key factors are so important for us. And we also want you to remember those key factors. These are our goal with this presentation. One thing that is almost important also for us is trust. We put the trust on you, because we want you to influence our presentation. You've been able to prioritize the presentation parts beforehand, and we also want you to ask questions during our presentation. Feel free to ask questions. So we said that you have been able to prioritize the talk, and it's sort of an experiment for us, and we have had in the conference again that we had a link from our talk to a web survey. I don't know if anyone, you have voted, but anyway, you had the possibility to do it. We have the voting here now in the list. We have a talk backlog, and we're gonna have this whiteboard where we have the sprint or the sprint, and also we have parts we have in progress and when we have talked about them. So we have divided it also, the board, into two sprints, and each sprint is 18 minutes. So it's time-framed, and it's two sprints, so then we will be able to re-prioritize in half time, then, if we see that we run out of time or something. And I won't go into the parts. They are in the conference again, if you want to have a look. We have time-framed all of them, or we have done like short sizes of how long time they will take, and we can show the current standing. This is the current standing from the survey. From the votes. And we're gonna run the presentation in the same way that you prioritized it. So we're gonna start with the key factors that have most votes, and so on. So perhaps, yeah, it's not a natural order, but it will be a prioritized order instead. And why do we do all this, Fredrik? It's because that's how we work in agile projects. We start with the most important things, and we don't want to skip them. Often you have the most important parts at the end of your presentation, and it could make sense, but perhaps you miss it then because you don't have time to tell your audience about them. And yeah, that's the way how we live and work, and hopefully it will be a more interesting presentation. We will see afterwards what you think. And as I said before, we will be able to reprioritize in mid-time. Okay, let's start with the first print. Could you move those notes to the first print, Fredrik? Yeah. Which one fits to the first print? So key factors, effects, road map, and problem description makes 80 minutes in total. So is this clear for you? Any questions so far? It's clear. Let's go. 80 minutes starts now. The first note. Key factors, then I move it into progress. And I took it. No one forced me to take the part. So these are the most important things or principles during our journey, I think. And the first one is a goal. Or some people call it values, but we call it goal. And it's really important to have a goal to strive for. And to make it possible for everyone to strive for it, it's very important that it's clear that you have discussed it, so everyone understands it and also supports it. Otherwise, there's no use of having a goal, I think. And when everyone understands it, it could be possible for a team to walk their own path. And that leads us to the other factor, Michael. This is our other factor, and it's a symbolizing trust. And we think that when everyone understands and supports the goals, it's powerful to work with trust. And when we trust the teams, they can take their own responsibility to reach the goal. This was our key factors. So you can put it to done? Yep. Oh, not yet, really. Sorry, not done yet. What makes it done is, for us, we have seen that the combination of those two makes it very powerful. If you have both the goal and the trust, then you have a very powerful tool. It's our experience. And it's also our most important principles. And these we don't negotiate with. Now we're done. The next part is effects, what we did with... In progress. Oh, I'm sorry. What did we achieve with this? So I'm sort of the manager of this project, for lots of projects we have. And for me, before I did spend lots of time handling tasks and resources. And now I don't, basically. Another effect is greater participation. Now we feel now that everyone cares more about the whole project. And we see that because they've got lots of ideas nowadays and lots of improvement suggestions that we didn't get before. And also we see much more cooperation between individuals and between the teams. We do almost everything together now and we didn't do that before. And that we think results in much better quality. One example is we are two speakers here today and we are doing that because we have been able to evolve this presentation between each other. And of course, other ones have looked at it too, but it's good to be true. And if I get sick, we have a backup in Michael, he could have performed it. So, and it's also more fun. And we think it's get better. Another effect is better communication. And here we have a lot of help with the agile structure. Now the stand-ups, the stand-ups. And we also sit together in open office that frames communication. We also have feedback loops for communication. And our customers have been, they are more involved now than before. They really appreciate this way of working and they feel they make a difference because we listen to them and we can change immediately. If we show something for them and they say, oh, I would like it this way, then we say, okay, they get response immediately and it seems like they like it. And we also ask them for their opinions and it feels much better than having it as it was before. We also have better flow today, much less bottlenecks and stops. And because everything we do now is visible and it's visible physically. We have all the tasks on whiteboards in our office today. We're gonna show it more later. We also have this climate of helping today which makes it easier to have flow. Also the good communication we're talking about helps. We also have cross-functional teams today, which makes less stop, better flow. We have a method for structured improvements. As you know, the agile methods provides the structure for continuous improvements and the most important one is the retrospective, basically, where we do our improvements. And we've also started with learning days and, like Michael said, feedback and coaching within the team that is structured. And our staff is much happy today. And we think that co-determination creates self-esteem within the staff, comfort and joy. And we think they're also proud, very proud today of their work. Yeah, they're often so happy, so I'm sort of embarrassed. I think, I don't know what we have done, but they seem to like it. That was the fix. Should we put it in done? How are we doing with the time? 11 and a half minutes left. The next one is the roadmap for the transformation. And the roadmap is basically how we did it. How did we do the transformation? We're gonna show it in a timeline. Maybe it's more visible then. Okay, everything started in the late 2011 with an idea. And the idea sounded much like, what if we keep teams together for a longer while? What happens then? And the more we talked about this idea, we thought the better it sounds. So, okay, let's try it. So in the beginning of 2012, we did start a pilot. We handpicked seven people out of four to five that we believe could be a good pilot team. And we said to them, okay, we're gonna try this. We're gonna try to keep you together. And the reason is we want to have better quality. That's the only reason we do this. And I was the scrum master for this team. And they asked me, okay, how are we going to work? What methods should we use? And I was like, well, I don't know. And someone said, well, maybe we should try these agile ways, methods. And then we thought, well, we can try that. So everyone in the team got this book from a Swedish author, Henrik Nieber, says the book name was Kamban versus Scrum, how to make the most of both. So everybody read it. And then we sat down and had a talk. How should we work? What principles should we work? Kamban or Scrum or a mix of it? And now everyone in the team could have their opinion. And we also formed our own goal for this pilot team. I didn't thought of that first, because I was thinking this better quality goal was the only goal we should have. But the team made their own goals. And then we started to work. And we saw by start that this is going very good. The quality increased from the start of it. So it didn't took that long. When we reached September, we did put together another team. I was the Scrum master of this team too. So we had another seven people to this team. And I did the same thing. I thought I did the same thing with this team as the first team. But now things didn't go as fine as the pilot team. We couldn't see any increase of quality. So we were thinking about why aren't this team doing as well as the pilot team? And then we got it. The first team got this goal, better quality. We should do this by better quality. And they were really self-organized. And the other team got this goal, do as the first team. Basically, do as the first team. So when we realized that, it was kind of a ha moment for us. Then we had to work a little again. They had also to read this book, of course. And then we sat down and made our own principles. And we also made our own goals. And now everything was working fine again. We can see an increase of quality directly, I should say. So now we're in the beginning of 2013. After these two, the pilot team and the team two, we thought maybe we don't have to wait anymore. Let's roll out the agile for a whole project. So we put together team three, team four, and a supporting team, and also this coordinating team. And now everyone in the project was within a team. And by this time, we had realized that it's good to ask people if they want to do this. At first, we didn't really ask, I think, when we put together the pilot team. But now before we did this, we asked everyone, do you think this is a good idea? Is it something we'd like to do? And we also discussed how we should form the groups or the teams, we call them groups, but they are actual teams. And that ended up with this constellation. So, and now we'll go back in time a little bit. Now it's late 2012, around October, November. And I had this, another idea. And the idea sounded like, what if we let the team pick their own task? Before this, we had the product managers and the product managers handling tasks to people and teams. But then we thought, what if they should pick their own tasks to work with? So we did like we did before, we tried it. So in the beginning of 2013, when we had all those teams, we made this project sprint planning for the whole project. We're gonna talk a little bit, we're gonna show it a little bit later. But it's all about putting all of the teams together in one room and make the sprint planning together. That's what it's all about. And that one also went fine from the start, I think. Okay, when we look back at this time, from the late 2011 to the beginning of 2013, we think of this period as the agile transformation of our project. And this is the period where we realized that goal and trust is very important for us. Especially around this team two constellation where it didn't work so good for them at the start. But when we sat down again and gave them a clear goal and made them self-organized, we really realized that this is important for us. So, and do we stop after we have done the agile transformation? No, we didn't stop. So now we're into the agile evolution part, I would say. So we continue to work and we are developing our methods all the time. I will just show some suggestions that have come up from within the projects, the teams, different teams. Earlier we didn't have free seating, now the teams can select how they want to sit and as long as it works for everyone. We celebrate victories like our deliveries. One team prepares dinner or lunch for the rest of the project and then it goes round and it's also a nice way, it's really appreciated. We have this feedback, structure, structure of doing structured feedbacks within the teams and it's coaching a way of finding the driving forces for all the individuals in the team and perform better. We have updated our goals because, yeah, sorry. Yeah, or we said, we told them, we clarified the goal and let them make their own goals to reach that goal and earlier we asked, gave them the goals from group one and said, these are your goals and it didn't really work. So did it answer your question? Yep. So now we updated the goals, so we asked our customers and within our organization we have goals and also within the project we have goals that we want to reach so we coordinated all the goals and had a chat together the whole project and selected new goals basically and after that the teams went back and put up their own goals to reach the project goal and it seems to be a good way of spreading the goals and make everyone work with them for a while. It takes a day but it seems to work. And also we have started with learning days. It's sort of self-organized training performed within the project. So the co-workers can select what they want to do. They have to do it in groups and they have to show what they did the day after. Present a 10 minute abstract of what they did to everyone. So it's also a good way of sharing the result of the learning day. Okay, two minutes left. We're ready with a roadmap. Move it to Dan, okay. The next one is for you Fredrik. Oh, sorry, we're not ready yet. No, I'm not ready. Important principles. So we took the ideas to do this, came from within our project and we think that's really important. So it wasn't the management that told us you have to do this. I think that's a good way of doing things. It should come from yourself, not from someone else. And you have to dare to try and it's accepted to fail but you have to learn from your failures, of course. And we take everything in small steps. We say evolution instead of revolution and we use test, evaluate, change. So we try something on and evaluate how it went and change if we have to. And if we are unsure about something, we use a pilot. So we just try it in a smaller, just one team or something like that. So now. All right, sorry. Roadmap to Dan. Yes. How much time do we have? Half minute. So let's start with problem description. So what was our problem now? This is an awkward order. We had quality issues, serious quality issues. So our customers weren't satisfied with what we did. So we had 80 stopping hours in production over a year, in a period of a year. And that was way too much for our customers. So they did complain. And we had to release those corrections in 11 emergency patches. Oh, now the sprint is up. First sprint is up. Time's up. And we didn't really get to the end. We didn't get to the end of it. So what should we do? I think we should move it to this one, to the sprint two. Yeah. And then we filled it up with results of the transmission, now and then, and a practical example. I don't know if we have much time for more than that. We'll leave the rest. We'll leave the rest. That's good. Okay. So let's keep on with the problem description. Yeah. The sprint two starts now. Yeah, we had this 11 emergency patches and we just released four times a year. So 11 emergency patches, they were quite disturbing. Especially since it stops the product in production for half a day to release those patches. And the customers, they were not satisfied, of course. So that's what we had to work with, the problem. And also, yeah. And also our own staff was quite dissatisfied because those 11 emergency patches made us stop working from our regular processes and start working with emergency progresses. And since there were so many, it seems like we almost worked on emergency patches because, and that made our staff quite dissatisfied. What did we do before our agile transformation? We had DSM, sort of an, it's an agile method, but it didn't help. We had, did use DSM since back in 2003. So, we thought we had to do something else. We, so we launched a quality assurance program and the assurance program came up with a couple of, or an action plan with IDs that we should try, but it couldn't really find a common point of failure. So, but it said that it's important. We saw that we needed more communication. That's why we started those teams, the pilot teams. Seems like this is, and we also did a certification. So, we took a certification, this ISO 20000, and that made us clear of our processes as they were then, but it was really hard to change those processes. So, I don't know, it gave us something, but it was hard to change them. So, that's why we, it didn't work, I think. But the, and the good thing about DSM was that our customer got used to being involved in what we did, and also they are very into prioritization. They know how to prioritize. So, now we're done with the problem description. Yes. Let's move on with the result of the transmission. This picture says it all, I think, it's about increased quality. It's the number of patches we had before the transformation and after. So, our goal is, of course, to reach zero patches in production, but we haven't reached that one yet. But perhaps soon, we hope so. We still have something to aim for. And this picture symbolizes satisfied customers. Of course, our customers are very satisfied. This is our second result. Of course, our customers are satisfied with the increase of quality. And how do we know that? Because we make service, but most of all, we know it because we talk to them a lot. It was a short one. Yeah, good. Good. So, that was the result. So, that was the result. Now it's, the next one is now and then. And what is that, Frick? Sort of a comparison of how we worked before and what we do now. So... It's the basic difference, maybe, in how we work. So, what we have seen, that before we didn't, we had goals, but they weren't clear. We haven't worked them through with the personnel or our coworkers. So, we didn't really know what they really meant. And now we have. We have a clear goal and everybody understands it and supports it. And we have it on the project level, as Frick talked about. And we have it on the team level. And we also have it down in the individual level. So, it goes from, up from the project, down to the teams, only way, all the way down to the individuals. Yeah, we have the centralized control where I was in charge of everything. And I had to do a lot of planning, but nowadays, I don't. Because I have the self-organized teams. Yeah, and you answered the question. Now we have self-organized teams, all the way. So, for me, this has been really good. I have time to be more visionary and do things like this. Earlier, we had focus on a task. When we started the project, I had to create a project group and put people in and it was a hassle, basically. And now we have the focus on the team now. The team sits together and if we have to move something, we move tasks now, not team members. And we can also assign a project to a team or two teams, perhaps, if we divide it. Or three, or all teams. Actually, we don't assign the projects, they take them on. And earlier, we were sort of spread out. We had different locations where we sat. And sometimes the developers sat in groups and the testers, they were situated somewhere else. And that was also not the best thing to do when we see it. And now we sit together. And it's important principles. We should sit together. That's important for us. It's so much easier to communicate. Are we done with that one? We're done. Okay, how's the time? Done. We have 11 and a half minutes left. Maybe we should be able to do more. Okay, let's start with the practical example. And the practical example is about the project, the sprint planning for the whole project I was talking about earlier. And it's a sprint planning session where we have actually divided into two parts. The first part is preparation, the preparation part. We have this big whiteboard, much bigger than this actually. It's about four meters wide in a special room that we have. And on this whiteboard, we actually do this before every sprint. So the preparation starts by us calling our customers other product owners. So the product managers and the product managers sit together with the product owners. And we actually do a prioritization of everything that is to be done in the project. So here we have tasks from different projects. These colors symbolize different colors. We have this product one, and product two, and product three. Actually, we have more projects and more tasks, but this whiteboard don't fit anymore. So you have to imagine a bigger whiteboard and more tasks. We also, almost every time, we have some internal tasks like that represent technical depth, like fixed unit tests and stuff. So we call our product owners. And together with them, we move tasks from the total backlog. Could you help me, Fredx, maybe? Into, and it goes, something like this. This product one is the most prioritized. So we put the product one into the high lane. OK, we have the high lane and the medium lane and the low lane. And here we have two different techniques, technique one and technique two, also that we have divided into. So the product one is the most important project. So it's up in the high lane. And then we have the product two. It's not that prioritized, but quite prioritized, things the product owners. And then we have the third project, and it goes something like this. And then we have our internal tasks. And then when we have done this, we talk to our product owners, and sometimes we can see that if we do this task, it's quite the same as this one. So if we do it, it's much more efficient, and it's cheaper for you. And they almost every time say, yeah, do it. So sometimes they say, and we can say that maybe we should do this. This is not as prioritized. And we do this together with our product owners. What did you say? The question was, what is the thing? The technique one and two. The technique one and two. The techniques we're working with? Is that the question? Yeah. We work with Java and Juniface, or the techniques? So basically, the teams are divided into tech teams. Like they either work with Java or Juniface. So they're cross-functional, but they do different. No, different, no. It's just the different techniques. Like, we have several products that we work with, but some products are written in Juniface and some in Java. So that's the difference. And it's still, we have the part, or the teams can't work with both, or they don't want it to. They wanted to work either with Java or Juniface. So they have their focus, and that's why we have divided the board into that way. OK, and this is pretty much what we do in the preparation phase. So after the preparation, that's typically like 30 minutes in the morning, in the afternoon, we gather everyone in the project. And we gather in front of the board. And all the project managers tell, they tell all the stories, basically, what we should do this sprint. And it's very important that the high lane is emptied, so nothing should remain there. But if the teams want to, if they see that they can do this task together with this, and it won't cost more than they can do it. But it's important that for us, the product owner is not in this meeting. He could be, or they could be, in the future. But right now, they are not there. Sometimes we give them a call if we have something to understand. Because this meeting is more of a work meeting. It takes, like, one and a half hour. All the teams discuss the notes and the meaning of them. And we have, like, short sizes. We have estimated them beforehand. But they do more detailed estimates if they think they need to. Because they know how much they could put into each sprint. And then they grab the tasks and put into their own board. And this board is always up in this room. We have dedicated for this. So if one team doesn't have enough things to do, or they are done, they think they can go in here and check if there are tasks we should do. And also, of course, we communicate between the teams. So they help each other at first. Quite often, we end up with teams shifting tasks between them after a while. That's a common task. But the basic thing is that the teams pick their own tasks. And this has been quite an effective way. It's quite simple. But it's an effective way of spreading what we're doing during a sprint. And we started off with having goals for a sprint, too. But we don't have that anymore. But it could be effective. Sometimes it depends, I guess, what you do. But we dropped it after a while because we didn't need it. Or we didn't want to have it anymore. And one other thing is everything gets visible this way. Everything is on this white board all the time. And even those things that we don't pick, they're still there at the board. So the teams can go pick them after a while if they have one out of tasks. Are we ready with this one? Yeah. OK. Good. Now we have time left, Fredrik. What should we do then? Oh, we have done well. Let's see, have a sign. Yeah, the groups, they take the task with them to the teams. They put them up on their sprint board, sprint planning board. Can you repeat the question? I was just confirming the understanding that tech one could have G1, G2, and tech two could have G3, G4, something like that. They are the small internal teams, right, of techs. But yeah, it's that. So are there questions? Or didn't we answer the question? I have thought you clarified. Once again, then. No, yeah. That needs to be it. How much time do we have left? So now we have some minutes left of the sprint, but I decided to put in the summary to the sprint. And it's not even on the board. So let's move on to that one. So we just want to repeat the key factors, the most important things we have learned during this. And it's the goal and the trust. And this is really what we work with all the time. If we wonder, how should we solve the problem? We think of this, what does the goal say, and how could we trust our coworkers to solve it? And that's basically how we solve all our problems. So earlier, it was quite common that someone came up to me and asked, Frederick, how should we do? You have to decide. You have to decide this and that. And if I went there, everything stopped. And nowadays, it just flows. That's the flow picture we showed. I don't get questions anymore, basically. People do. And if they do too much, I can tell them, OK, next time, perhaps. I don't tell them to ask, but you have to think more if it doesn't go well. But I still encourage them to try, because that's what I want them to do, think by themselves. It's better if we have 45 thinkers than just one thinker. We produce so much more, I think. And we have more fun, too. Now the sprint is finished. OK, questions, non-serves. We have a question. Wait, wait, you should get a mic. So when we talk about this goal, so do you guys define the goals per sprint? And are these driven by the requirements, or what is your major drive behind getting these goals? I didn't forget. He was asking about the goal. How do we define the goals? Maybe that was the question. Where do we get it from? Is it requirement-driven? No, the goals live longer than so. I mean, we have a picture here where we have our updated goals, so you can see them. So these are the goals that we have decided within the project team. And we have asked our customers and our organization and also ourselves, what do we want to achieve? And what do we think is the best goals for us? So we put up these short-term goals and the long-term goals. We had this workshop session for a half day, maybe, where we worked with these together. And this was the goals that we ended up with. And we have put them up on the wall so we can see them all the time. And then when we had these project goals, each team worked with them and tried to understand them. And from these goals, they put up their own goals to be able to reach these ones. And actually, we had the meeting after all the team had gathered and selected up on their own goals. And they told everyone that these are our goals. And they were different for each group or each team. But that doesn't matter as long as this is our vision or the goal we strive for together. It doesn't matter which part we take because we are different as humans. We don't think the same way. So if one team wants to do it in one way and another team wants to do it another way, it doesn't really matter for me as long as we strive for this. And that's when we can trust the teams. I know they are working towards this. So some guy and a developer he asked, why don't we strive to work faster, produce more? And I said, that's okay. You can do it in your team as long as we keep high quality because that's what our customer asks for. They never ask for efficiency in a way of working fast. They always ask for quality. They want high quality. And the thing is when we have high quality, we can produce so much more. So actually, since we started this, we have reduced the workforce by half. So just half of us are left. We haven't said that, but it's because we are doing so much, things so much better. So we started to work, but the other ones are not, they are still working with us, but they're doing other stuff instead. So it's been really good. We have another question here. Wait for the mic. How big is your team, people? Yeah. The whole project? Yeah. Or one team? Yeah, okay. Whatever is your span of your team size, whatever this is applicable for. How much is that? How many people are there? In total, when we started, we were like 45 people. 45 people. Yeah, and then we had five teams. But now we're down to three teams. So how do you, see, the key to success of any of these initiatives is the trust, okay? So how do you keep this sustained? See, people are together, and I think probably it's about three years, okay? And probably, I don't think you keep adding, and moving people from the team, right? So how do you sustain this? One of the things that you said, one team will cook further there, or something like that. Okay, I heard that. Yo, how do you do that? Yeah, nothing wrong? Well, one of the things we do, we have those feedback loops. We have structured the way we give feedback. So four times a year, our scrum masters give feedback to the team members, and then we have structured the way the questions that we form them. So we have, basically we ask questions about the project goal and the team goals. So we give feedback and also take feedback back from the members. So that's how we can know how our team members are, if they are happy, if they are working towards the goal, or if they're not. And we are working a lot with finding everyone's driving force, basically. And when we work like this, I think it makes it easier for us. We talk a lot with our coworkers, and we ask them, what would you like to do if you could choose? You can choose immediately, but when we're working like this, it has made it possible for us to, or given us the opportunities to let our coworkers choose what they would like to do. And yeah, that way I think we can produce so much more. So they are free and they can select what they want to do within the constraints we have put up. I think time is up, is it so? Time is up, yeah. Thanks for us. Thank you. Please give us, you can always come up to us and give us feedback. We really would enjoy that. Yes. Thank you.