 So, hi, I'm Alice, I'm the delivery manager at Wonderroot based in London and my presentation is going to focus on the benefits of Agile. Agile is an umbrella term for several iterative software development methodologies. The most popular of those are Scrum, Extreme Programming and Kanban. And in this presentation I'm going to focus on four key areas where Agile benefits over other project management styles. So initially I'm going to look at how Agile reduces risks, how it avoids the common risks from fronting teams that use more traditional styles. I'm also going to look at its effective delivery style and what facets of Agile lend to its effective delivery rate and high success level. I'm also going to look at the quality and how the final quality of the product benefits through using Agile with its continuous learning, continuous deployment, that kind of thing. And I'm also going to look at the transparency and how the measurable qualities of Agile lead to more efficient teams and more transparent working styles. So let's have a look at how Agile reduces risk. Here we have some nice charts provided by the Chaos Manifesto in 2012 and they compare waterfall to Agile. And on the right hand side you can see that Agile has a 49% challenge rate compared to that of waterfall. And any challenge is something that a project comes up against during the lifetime of the project that can set it back. So you can see that there's actually a significant difference between the challenges that are faced by waterfall projects and those faced by Agile projects. The orange bar is the most interesting and that's the success rate. And you can see that there's only a 14% success rate overall for projects that are conducted using waterfall where there's a 42% success rate for those that are done using Agile. That's a three times the success rate, the waterfall for Agile. So that makes it significantly more successful. And then obviously, inversely to this, you can see that waterfall has a 29% failure rate compared to that of Agile. So that means 29% of projects undertaken using waterfall actually fail whereas only 9% do. So 20% less projects actually fail overall using Agile than does using waterfall. But why is this? That's because Agile produces the highest value products first. And by providing these first, they prevents any key parts of the project, so big key issues that you want doing, being incomplete or unfinished by product launch, whereas waterfall spends a really, really long time planning. So you can see here in the graph, there's an orange line which denotes Agile and then there's a green line that shows the project moving through with waterfall. And at the beginning of the project, there's a huge amount of time spent where nothing's actually built, whereas inversely Agile builds all of the high value products first. So it means that the special things and the things that are really required in your project aren't missed out. And it means that real progress is constantly visible throughout an Agile project. But this means that failure is not an issue. The highest value products are delivered first. So there's no possibility of the project ending incomplete. Problems can be identified earlier on. So this means that they can be rectified immediately. With waterfall, it's sort of a long project plan. Things happen at the beginning and the end and development happens in the middle with Agile. Things can be changed and developed and edited throughout the life of the project, which means that any issues are identified. And also high valuable testable products are created, allowing identification of any improvements or specification changes that may happen throughout the lifetime of the project. So this means that inevitably failure is not an issue. But how is this achieved? So this is achieved through effective delivery. Unlike waterfall, Agile's done iteratively. There is a slightly longer planning phase at the beginning of an Agile project. However, unlike waterfall, the planning is done throughout the lifetime of the project. And after every planning, there's an analysis, a design, a code, a test, and a release. So this breaks the project up into sprints. And it means that at the end of each sprint, there is a testable product that is produced. And it also allows innovation throughout the lifetime of the project. People can identify improvements or any extra functionality that's needed throughout the lifetime of the product. It means that more interesting things can be built if something doesn't work in the way that somebody thought it might, then this can be changed. And it means that delivery is measurable. We can actually see how the team is going to work throughout the lifetime of the project. You can see the actual remaining efforts and the ideal remaining effort on this chart. So the ideal line is the one in orange. And the actual effort of the developers can be seen in green. By using a backlog and rating the separate user stories, so all the different points that people want building by rating them with effort points, a team's achievement can be tracked throughout the life of the project. So this means you can see if they're ahead of schedule or behind schedule. This could be because they completed a lot of easy tasks or somebody may have been ill. But it means that it can identify areas of failure and success and provide a visible timeline, which means that progress is visible and there's continuous stable delivery. So there's not huge dips and gaps and things like that. People can know what they can achieve and there's no horrible supports to the end. Okay. And what does this mean? It means that unlike fixed big contracts where changes or failures in a project can have massive impacts on changes in budget and time, things like that. And like that in Agile, it means that change is free. So if a requirement changes or previously agreed functionality does not meet the needs of the client or that sort of thing, enhancements can be easily included. So there's no increasing cost because the iterative way that Agile is done, it means that any changes can be put into the next sprint or they can be easily scoped out. And Agile teams positively welcome changes even late on in the project phase. So it means that even towards the end of the project, because developers aren't pushed for time. In this case of waterfall where people towards the end of the project seem to be quite pushed for time and things are getting a bit horrid. Unlike that in Agile, people are ready to take on changes and that kind of thing, which inevitably come about at the end of a project. So higher quality products. If we look at the comparison between Agile and waterfall projects, we can see here the orange line denotes Agile and the turquoise line denotes waterfall. And you can see that throughout an Agile project, there's a huge amount of learning with waterfall. There's a plateau of learning between the initial design phase and the launch. And therefore the quality of the final output with Agile is higher as things are released early and regularly. So products that don't work can be re-evaluated and learning takes place throughout the lifetime of the development. So any bad methodologies or things that don't work aren't repeated and it doesn't cost the project. The thing with waterfall is that the majority of learning comes after launch. So that's where nasty surprises are found. Because once the product's launched, a lot of learning happens unlike Agile where we kind of have this sort of even level of learning throughout with waterfall. You kind of get a lot of hidden surprises. So Agile's continuous learning prevents those nasty surprises. Also, stroke to Agile's style means that testing's done throughout and it also provides an in-depth understanding of the progress of the project. So here with Agile, critical bugs are caught early on in the project because every sprint produces a testable product. Stories are considered incomplete until they have zero critical defects, which means that at every point the product is testable. Automation can be used to provide higher productivity for the testing team, which means things are checked more regularly, more efficiently, and it means that the output is of higher quality. And what does this do? This results in a higher level of transparency. The continuous feedback in the way of retrospective, so at the end of every sprint, there's something called a retrospective which allows people to evaluate how they did in their sprint and what their developments were like and any problems that they overcame. Using these retrospectives, there's a high continuous feedback loop which means people can reevaluate what they've been doing and everyone is included at every stage of the project. And it means that there's no single point of failure. Everybody is continually involved and it means that people are less inclined to refocus the project and change the priorities as in waterfall where towards the end of a project people will change the priorities, move things around, and this will put a lot of pressure on the developers. And it means that everyone is on the same page regarding progress and expectations. And this means that kind of the one team model that's used within agile, which means everybody is equal and all the badges and sort of name labels are left at the door, so management and developers and everyone alike put their opinion in and everything is welcome and it means it combines stakeholders and developers and provides a mutual sense of ownership. Everybody owns the product, everybody's working towards the same thing and management are continually included, unlike in waterfall. Developers are then not put under any stress and remain more motivated throughout the lifetime of the project. It also encourages coordination and organization between the team members and therefore there's 100% visibility, nobody is hidden from any issues that are raised, everybody's involved. And this means there's an environment of trust, which means everybody's happy, the developers are happy and the customers are happy. And that provides agile with an ability to deliver projects on time, risk-free, efficiently, with the highest quality and greater visibility. And as I said earlier, provides a happy, motivated team and a satisfied customer. Thank you very much. Hello, my name is Matty Fachter and I'm originally from Finland, but now I work for Wunderroot here in London as a UX designer. And here's my 10-minute talk titled design as a part of the agile process. The perspective of this short talk used to explain some benefits of agile model compared to traditional waterfall model, a bit like Alice, but in a kind of a design perspective. In a waterfall model, designers have been the ones who've been isolating themselves from the other team members and then later came out of their caves with some graphics and designs ready to be coded. In agile model, the whole process transforms itself from what was a couple of monologues to a fast-paced, productive dialogue with the whole team. As they say, two heads are better than one and we have lots of heads in every team. In traditional waterfall model, there have been kind of ultimate designers who have had all the knowledge and all the answers to every design problem ever. Of course, that's not possible and there will always be unexpected usability issues and unnecessary work. If all the decisions are made by the designer alone in the beginning of the project. In agile process, we test and fail all the time. We have to chop the whole process into smaller pieces and try to figure out all of them together as a team. It's much more transparent and safe. There is no one who would have all the answers. We try to face problems together and make decisions only when we absolutely have to. As you just heard from Alice and you will hear much more from Steven Vesa, we don't really know a lot about the project in the beginning. Nobody does, but in the agile model, it doesn't matter that much. I have an example for you. In the waterfall model, the discovery phase is usually done with minimal information about the process, often without much data. It's quite common to just design a final layout in the beginning of the project. If it looks good, it becomes kind of a guiding light through the project, which has started, but we are already making decisions about the things that are going to be done months from now. And who is participating in that? Designer alone usually. He might even get some feedback once or twice after the design is finished. In agile, discovery phase is made by the whole team, including the product owner from the client. And only necessary decisions are made. Every decision is based on facts and data as much as possible. Knowledge and skills of the whole team is in use, and it makes discovery phase much more structured and transparent because everyone knows what we are going to decide and design. We aren't trying to swallow it all at once. In the agile process, we don't run around making finished layouts for websites. We don't know what they are going to be like. We chop up the client's needs and try to get some stories out of them. In the beginning, we call them epics. And in the discovery phase, the layout might look like this. Just a few lines of text and some quick sketches. Something to start with, something to build on. Getting everybody on the same page and trying to realize together what kind of goals we actually have. When we actually start working with the layouts in the sprints, we try to put the design process into smaller pieces to make it easier to see the whole scope. This is done by the team. As a team, we decide what is important and what needs to be done first. It might be just a wireframe, like here, to the homepage in one story. During that sprint, we try to iterate and make that experience as good as possible. In order to make that process even more visible, we can put that user story into even smaller pieces. We call them tasks. We can make that layout piece by piece if needed. In this case, one task could be to design the best possible container like this for this layout. And we can iterate that task in that task and try to make that one piece of design work. As a team, we know much more about what worked and what doesn't. In the end, that container may end up looking something like this when it's finished. And it fits into the hole like it's designed to be there because it is. If we realize after a few sprints that we don't actually need some of the components, we haven't used too much time to design them. We design only what we need so clients are only playing what they actually are getting. All the parts of the traditional waterfall model are also included in the agile process. Traditionally, they've been hidden inside designer's brains and shown only in the final version. We'll do wireframes, visual designs, prototypes, and testing during the actual process. But we don't make them just once. We make them all the time during process. And to finish, design is, and has always been, at its very nature, very iterative. You know, you know when you hear that dialogue in your head that, oh, I think it works better like this. No, I was wrong. This is the best way to do it. Agile process makes that part of more visible and easier to handle since it's a very open process and chopped into pieces by the whole team. So thank you for your time. And I'm happy to answer all your questions later. Great. Thank you so much. We're going to move on to Steve right now. All right. Hello, my name is Steve Parks. I'm in the UK office of Wonder Proud where we're known as Wonder Root. I'm going to talk about a specific project we did, a best practice case study, to show how some of the ideas that Alice and Mutti presented have been put into action. Now, I'm going to split this up into five small sections within my 10 minute slot. I'm going to focus on the education of those taking part in the project, most specifically the client, collaboration, learning, small delivery cycles, and regular review. And the project I'm going to focus on is a very interesting one. We did some work recently and still are for the UK's Ministry of Justice, a client you really don't want to get sued by. The project was to help them find a way to manage the recruitment and careers of judges online. And a key part of the reasoning for this was obviously the usual government pressures of reducing cost because there are cutbacks, but also they wanted to improve the quality of the service, improve the quality of the candidates that were coming out at the end, but also improve the transparency and diversity that was coming through this, that long being a kind of misunderstanding of how judges were recruited and people perceived it as kind of a tap on the shoulder in a gentleman's club. That's not, of course, how it was, but the more transparency that can be brought to the process, the better for everybody. So we began working with them by, first of all, we kind of understood through the procurement process exactly where they were at. And we persuaded them that agile was going to be a great way to manage that project. And the reasons for this were because it was high risk and there were lots of unknowns and it was a fairly long-term project. Therefore, kind of all the key ingredients that make for a great reason to use agile. So it was their first ever agile project. So we decided, first of all, there was a real piece of education needed. And we worked with a wide range of their team. People who were going to be involved in one way or another quite closely with the project, either being the product owner or key stakeholders or being kind of specialist knowledge people within the organisation that we would need to rely on. And we gave them a two-day intensive training in agile and then ongoing coaching during the life of the project, because it's a lot for people to take on. It's a very big step change. And it, in some ways, goes very much against what everyone gets taught at business school and so on about the ways to manage projects. And so it requires that level of trust, that level of communication, but that also that understanding of the whole process. So here you can see Vessa, who's the next presenter up, being one of the people giving this training session to that client. But beyond that, it was not just about training the senior people. It was also about training those throughout the organisation. So during the start of this project, every single member of the client organisation received at least a few hours training in agile what it meant and how it worked. And that was key to the success of the project. People really understood what we were doing, how we were doing it, and why we were doing it that way. Beyond that, collaboration was really key. Now the education helped us get to a stage where we all spoke the same language and it was very clear communication. What we believe in very much is a one team approach. And that means we don't just act as the agency and have them act as the client and we only meet once in a while and we exchange information that way. We believe in having a true one team that is borderless. Agile was originally designed for use in in-house development teams. So therefore this kind of one team approach was inherent there in the way that the process was designed. It relies on such open, transparent and regular communication that we have to try and replicate that across the client agency divide. So therefore we publish everything we're doing with the project completely transparently and openly including our budgets and our staffing and everything else the client can see. At the same time the client is invited into our company chat room, the client is invited to all meetings and we're really encouraged to be at all meetings. So there's nothing that the client can't know about the project. And at the same time we demand that there's nothing we can't know about the project. So we go to project steering groups. We have meetings with senior stakeholders. We go and talk to staff day to day who are working on the project. And that collaboration, that one team approach, the client in this project really got it and they were fabulous at working with us in that way. Next up, so we've had some process of education at Agile. We've set up collaborative working. The next thing then it's really important for us as a team to learn about the business of the client and also for them all to learn about different parts of their organization. In this case, because there was a very clear process that the site or the system would have to support, we began with a series of process mapping workshops and we would get team members into a room to map out exactly what they did and how they saw the process at different stages. And as part of that we managed to help the JSE make more efficiencies within their process just from the way they worked normally even before the system was implemented, just from helping to understand what their process was and unify different teams across the organization. We also did a number of workshops with key stakeholder groups, including judges and including as well the panel members that conduct the interviews for judges. And here's a workshop where we just gathered lots and lots of their ideas for the system and their concerns and their worries and their hopes onto a wall and clustered them into groups of ideas so that we could begin to understand the priorities of the different use groups. We also did a range of user research with researcher traveling around the UK, interviewing all sorts of judges and potential candidates in different places and that was key. But also what was key is having done that piece of education so that everyone in the organization understood agile, including understanding how to write user stories. We then, a member of the team at the client, made this wonderful ice box with a reminder of how to write a user story on it. And this was put in the staff kitchen with a load of cards pre-printed with the template for user story. The idea being that as soon as anyone was doing something in their day-to-day job that they thought are and must make sure the system supports this, they could write a user story for it. And over the course of the project, over 400 user stories were contributed by the staff in this way. And again, every single person in the organization contributed at least one user story. What we're trying to avoid there is this idea that we go into a darkened room as an agency, we deliver a system, we come back and we demo it and someone who has to do the day-to-day work goes, what do you mean it doesn't do X? I need to do X every second week. We're trying to avoid those things falling through the gaps. So involving everybody in the kind of discovery phase is really important. And after that discovery phase came a number of high-level epics. Mutti referenced these as well. And these are just really, really high-level user stories describing the kinds of people and what they need to be able to do and why they need to be able to do that. This really high-level picture, it's amazing how this helps to get common understanding of the big picture of what the application is going to cover. So also after this we came with a very clear mission because we had to get everyone on the same page where this was headed and the decision was the mission would be an online judicial recruitment service that is so good people prefer to use it. Now there's a lot of keywords within that, but prefer is the most important because so many times IT assistants are introduced and people are forced down that route and they're badly designed. What we wanted here is this implication that they would have a choice. So in order to make this successful we have to make this a system that they would prefer in order for it to be used. And what that means is us focusing on the user and the user need and that is key to any successful agile project. That's why there was so much work with them in discovery. Then the project gets into delivery and the small delivery cycles are the key. This is the reason why at the beginning of the project we know the least about a project we ever will and at the end of the project we know the most that we ever will about the project. When does normal project planning happen in waterfall? That's right at the very beginning of the project when we know least. So what we prefer and what we obviously what agile dictates is regular delivery cycles where instead of the traditional way we do all the planning at the beginning then the analysis then design so on. You break in smaller parcels of work and you do regular planning and then for each piece of planning you've done you then do the small pieces of analysis design coding testing and release and then you go through the process again. What this means is you're never going too far wrong before getting a real test of the work that you're doing and a real understanding of it. You're delivering the high priority high risk work first. Regular review of those small pieces of delivery is also key. Now we tend to do demo videos a lot of the time as well to capture what's going on in the system but the key is it's a real life demo. You're actually showing the system. You're not showing just a spreadsheet that looks pretty or you're not showing just some fancy graph or something. All you are showing is what is really existing on the system itself and that is key because the client knows then they're building trust and they're really seeing the real thing not just your promises is what you're doing the real thing that you are actually delivering and they can have a go with it and that's when you get the best possible feedback. So the other thing is really simple regular reporting so this is just a simple traffic light system so you are measuring are you on track with the goals of the project the schedule of the project the budget the blockers and the risks and as you can see a project goes through the different phases here and things get brought into a caution level or even a risk level and then they can be discussed more clearly but at a glance everybody can see the status of this project at any stage and can see the history of that status and the trends. You also talk about risks on a regular basis you're always analyzing what kind of risks there are in a project and what the movement of these risks is and you can see the different risks here and where they're moving on the chart and what the trends are so you're measuring the impact of the risk and the probability of that risk and therefore what matters is you want the risks moving to the bottom left hand corner those that are still in the top right hand corner are the big risks and that's what you really need to focus on. So what we would suggest then for succeeding with Agile in an agency client relationship or on any project is it's all about education so everyone understands what true Agile really is. Don't do fake Agile or fragile as it can be known because that's not real. Do work to do true Agile because that's where the benefit is. Collaboration the one team approach getting everybody together so they really work very closely and no things fall between the gaps. Learning the discovery process is one of the most important parts of any Agile project to succeed really understanding what the problem is who the users are and what they want is key here. Delivering in small cycles because that allows you to get regular checks as to what you're doing and then also having regular reviews so that the client or the product owner is always getting a regular chance to steer the project change the way that things go moving forward and you can always then make sure the project is on track. So that's how we succeed with Agile on projects at Wunderroot or Wunderkraut as we know across the group and it's now over to Vesa. Thank you so much Steve. Thank you Steve. So hello everybody I'm Vesa I'm the CEO for Wunderroot and today I'm going to talk to you a bit about how to how to sell Agile. The reason for this is most of our customers are pretty new to Agile they may have some experience in it but more often than not they really they always had some experiences on either fake Agile or not experiences at all. This is sort of a short version of this if you want to see a one hour talk about the same topic go to the www.drupalcon-hunter.com website I did a session same stuff in there so the recording can be found from the site so have a look. All right so I want to start by saying Agile is simple but it's certainly not easy so anyone can actually learn how to do Agile within like say two-day training for Scrum for example you will know the technicalities on how to do how to do Scrum after that. But you know in order to really get the benefits out of it and really take the big shift in mindset to Agile that's going to take years for most organizations. So it's good to understand it's you know if you start selling an Agile approach to your boss and you start selling the benefits and so on it's going to take quite a while to actually realize all of these benefits and it's going to require some professional help from companies like us as well. So this is manifesto for Agile software development. This is sort of the core of Agile if you will as far as software development goes and it's really common sense basic stuff like individuals interactions are more important than processes and tools and you know all of this sounds great right. But what we actually see a lot in large organizations especially is like half as Agile instead. So it is kind of say like well we can do individuals and interactions over processes and tools but we still have to have extremely strict process and tools to control that process and so on and actually the individuals we call them resources instead because you know that's what they are for the company. So this is what I call fake Agile and it actually destroys most of the benefits from Agile. So you have to give up on some of those tools and control and so on in order to get the real benefits. So let's compare a bit. This would be your fixed scope versus Agile. Three key things that I've chosen here. I'm highlighting a couple of things here. So transparency in your fixed bit approach you have what I call 95 percent complete which is when you can't access this this thing is like almost done but it's not completely done and nobody knows how much work the last five percent is going to actually take. This happens a lot in projects. In Agile we have real progress visible. We actually know what's done done. We have a definition of when things are done. We do stuff in much much smaller iterations smaller blocks. So it's easy to track the process based on real progress not just imaginary gun charts for example. Time to market. Traditionally we create a large RFP or at least design everything up front whereas with Agile what we really do is we instead just deliver the highest value items first and we can actually push them all the way to production. So our time to market this is much much faster. It's not like we are skipping on any of the design or planning. It's just that we do it in a smarter way as was explained in the previous sessions. Pricing in theory fixed bid is fixed. In real life not really. In real life fixed bid is like more like this. This I think it's a real picture from construction industry but the same applies for software definitely. So the small boat is the original contract and the big one is the change order. So a lot of companies actually do make most of their money from change orders. In software it's certainly the case that a lot of money comes from that to companies. It's much more profitable to do say change orders than to do the original original bidding. In agile changes are free so you don't you don't have the problem of change orders at all. So as Steve already explained the knowledge gained during the process means that we can do better decisions and we can always postpone all of the decisions to the latest responsible moment. Responsible being the keyword here because you know if you don't decide at all it's much worse than making a bad decision in many cases. But you know postponing decisions means that we have more knowledge when we are making the decision and means that we are going to be making higher quality decisions in the end. And this leads to something called the Pareta principle which is not from software at all. It's from economics but the same thing applies here which says that with the initial 20 percent of the effort we often get 80 percent of the end result. This is certainly true if you're working with triple maybe like 95 five ratio even. And it means that the initial bits of getting everything in place are highly valuable but the last tweaking of the details may not be so so valuable. With fixed bits we are sort of committed to doing all of the polishing all the way to the end. And that's that's not really worth the trouble for the customer anymore. It's not generating any real value. So in our job we can see like OK now it's good enough. This is going to be this is going to be you know what we use. So for one second let's dive into a real options theory of it. If we had a say like a tree number lottery in place we have two ways of playing it one being the traditional way you invest three euros you get one ticket and then you know you may win or you may lose and that's it. So your investment is always three euros. What if we could just play like first number and we only would have to decide on the second number after we already know if the first number is a winning number or not. This means that over time you know when we do investments over and over again we would decide like 10 percent of the time we would invest for the for the second number and only in one percent of the cases we would actually invest into the third number. So on average our total investment for successful lottery ticket would be 1.11 euros with with the options and would be three euros always. Yet quite a few companies they choose to play the lottery with with initially investment of three euros and you know there you go. So you don't have to commit all the way in agile you can just see like okay let's see if this bit works and if it does let's move forward so you don't have to do like massive contracts upfront. So what about like in which cases should you use agile and what kind of agile and so on. So let's have a look at different kinds of projects. I'm talking about different mandates here. I'm not talking about money because obviously cost of a mandate is a bit different if you're doing your project for Chinese customer in China or if you're doing it in London for UK based customer. So basically within let's say less than 30 days you're just fine with waterfall process because let's face it in the end like one spring is basically one tiny waterfall always. So it doesn't really make any sense to try to apply like agile practices and all that for tiny, tiny projects. You can however apply some lean principles and for small websites say less than 100 days something like Kanban or Scrumban which is like combination of Scrum and Kanban. Some of those variants actually work much better than Scrum for example. So you can do them in a very lean way and you know that's what I still call agile. Slightly larger and you know simplified Scrum, most Scrumban works well. Large websites typically 300 to 1500 mandates Scrum works perfectly well. In that case you have enough iterations in them and for large sites you really probably want to make the project to multiple smaller teams. Right so this is for all of the vendors out there basically. So what if a customer still says like okay I want to have fixed scope in my project and let me be clear about this agile is not only dynamic materials you can have a fixed budget it's just that you shouldn't have fixed scope. So basically you can always decline just say no walk away what we do a lot is we decline and we explain why and we explain why you know the project's more likely to fail and so on and last but not least you can always take a massive risk and offer fixed scope and risk losing most of the benefits and see how it goes. I wouldn't recommend it. To end this in my opinion in 20 years we will have two kinds of companies. We have agile companies and dead companies really because the competition is going to eat the non agile ones alive. So if you are not there yet I would highly recommend on seeking for experienced companies like us to help you to move to the agile side of the the fence in projects. Thank you. Thanks so much Vassa and now on to our last speaker. Hello I'm Marele Nassar and introducing our work what we have been doing in Estonia and public sector to improve its efficiency by standardizing 11 ministries to one true but distribution called government portal. At first I would run through brief introduction about Estonia and its progress in IT to give a generic background to all our work. Estonia is a small Nordic country 1.3 million people size of a Denmark young country in EU. Fact to underline is Tiger Leap Foundation what started to support ICT in schools and that's the strategic move from where everything else rolls out. Tiger Leap had educational focus and it was a kind of mix between public and private initiatives. Some paperwork were done. Those papers are guiding our work. Forcing open source, distance analyzing software, interesting documents, not too long, good reading. For example software framework tells the public sector must make an effort to raise awareness of the open source and benefit from it while both creating and using it. For example the web framework tells a public sector institution must have a website and they need to use human readable URLs or editable documents should be submitted in the ODEF format. And oh yeah that's the architecture. Xroad core technology has been used in Estonia since 2002. There is also Xroad EU project what is led by the Estonian Information Systems Authority and is meant for all EU countries who wish to create innovative cross-border e-services. There's hardly no public sector web platform without some integration with that beautiful thing. And that's the outcome. I listed some random e-services what have been present so long that we are so used to all of that that all of them who don't use them seem really outdated. For example taxes, yes tax declarations were first big thing what everybody knows this so no paper tax declarations for more a decade here. To put it in all in the context that's it. It's transforms like that just basket with the mushrooms and berries are missing and like that you can start a company, declare your taxes, make appointment with doctors and check how your kids are doing at school. Now when all those systems what I just spoke about are ready and highly used government office was taking another task to give all the state similar visual identity and now we are arriving to the most interesting part. Something around 2012 government office made a spectacular job to bring together all the people who would tell something about it all of them. They made the decisions first platform will be developed centrally second it will be named government portal it will be 13 different sites with independent CMS course but would have the same look and feel. Look and feel have to be same but technical solution will be recommended but not forced and everybody need to migrate at the beginning of 2014. RFP came out. We were the only one who proposed RUPA and we won great. It was getting really busy in the beginning of 2014 and they pushed deadline to June. We were doing great again all ministries were our clients we made it by the right date we deployed six sites out of 13. For the future we are waiting for new visual identity for all the rest of public sector for all their sub institutions now but that's not it. Things are still evolving and I give you an example it's the strategy of ministry of finance we were helping to create it it's until 2017. They already made a decision that government portal will be the platform and they are also just waiting for new visual identity to come out. So let them be many. The whole project as it started in 2012 and involved so many different parties has a lot of interesting details and now I just point out some of them. The main thing it saves money in every aspect. Tech path like maintenance cost is one huge but also unified manuals training process. I did ask for concrete numbers but there is not yet. I have been it has been just a few months from deploying and needs a coordination of 11 ministries to provide reliable data so you can imagine that. And anyway it's all about information it makes it so much easier for all the people. It's about interaction between institutions themselves but also providing better information structure for the public in general. Having so much communication with state through web it's much easier to find what you need if information is located exactly in the same way on all ministry sites. And the team. First decisions were made by many people but the team itself was not that big. One project manager with two three developers working as also government office told it was more a communication project than IT project. That's why the product owner was a government offices communication specialist. We have very good relations with them at the moment and they are happily sharing our common experience of all of it. For them it's part of Estonian IT success story. Even if it needs some time testing for now they are admitting it also. And of course several third parties all the IT departments testing content editors and so on. I don't go technically deep at this point. Just some keywords for those who are curious. State needs to be supporting everybody so VCIG highest standards are applied supporting not only people but different devices. Integration with subendix roads you will see them also on the next slide but it's about these challenges and aggregating all the content types where there was more than 10 of them. Biggest challenges integration with other systems of course like subendix road mentioned earlier. Migration was a big issue as those sites were being multilingual full of link documents custom CMSs about risks. It was a public tender project so everything was quite fixed and carried risk accordingly. Luckily we had great people from our client side so all the obstacles were solved naturally and didn't turn into failures. We are giving by the way the déquisitions at Truppal Games and in Riga we made back-to-back case study with government office people and some latrine government officials where they're showing much interest what we are doing so we'll see. And this is the work what we have done by now. Ministry of culture, agriculture, economic affairs and communications, foreign affairs, government office and government. Yes they look the same they are really happy with us and we are sure that when the new phase of public sector transition will start we will have very interesting time of working together you know standardize all the sub-institutions also. So thank you for having me here feel free to share with me any of your thoughts and comments. Thank you so much looks like you guys have been really busy the sites look really beautiful. So if anyone has any questions please let me know in our question and answer section you can still enter those in whenever I'll just go back to our slide deck. So just as a reminder some events coming up if you miss the beginning of our presentation we have TruppalCon Latin America happening in Bogota, Colombia you can check out the current status of the site and what's happening there at latinamerica2015.truppal.org we have selected sessions so we haven't posted them yet so look for that this week and next week and we'll start to get everything together and we have a really fantastic lineup. We have Truppal Global Training Days coming up that's our low-cost or free Intro to Truppal Training that we have available many of our supporting partners and other community members will host Intro to Truppal Trainings in their community to help bring other people into the project and propel it forward and of course we have our webcast series you can check out some upcoming webcasts soon our next one will be November 11th on Hiring Great Truppal Talent and we'll take a look at our Truppal Jobs Board from the Association. So it looks like we don't have any questions right now though I'm sure everyone is available via email if you have a follow-up question and I just want to say thank you again to Wunderkraut and our presenters today their supporting partner and we want to talk about our organization memberships and our individual memberships they help fund our scholarships our grants our servers the project and more so if you have any questions about becoming a member there's a sliding scale so you can adjust accordingly really great thing to support the project and the association thank you so much we'll be recording it please don't forget to take your post-webinar survey and we appreciate your time and thank you Lauren for waking up for your gift actions yeah it's okay lots of coffee thank you guys bye bye