 Well, good afternoon everybody, and welcome to our session on get off your agile treadmill and build a community instead. We're very pleased to have this opportunity to present our Drupal journey. Oh, okay. Okay, is that better? No, we'll just dance on that. We'll just dance. Okay, so our agenda today is we're going to cover our Drupal journey at the University of Edinburgh, what we've done to build a community, and what we've learned along the way. Session should run for about, or the presentation for about half an hour, and there'll be plenty of time for questions at the end. So, I'll just introduce my co-speaker, Bruce Darby. He's the product owner of the university's content management system, based obviously on Drupal. Bruce joined the university 14 years ago. Previously in universities worked as technology support for disabled students. And Bruce is a keen online chess player, and welcomes challenges under the player named bruster underscore D on chess.com. Yes, hi, and I'd like to introduce Tim Gray, joined the University of Edinburgh in 2008, as our senior project and program manager. And previously to that, he worked at Volkswagen for 10 years, and he's an occasional, but very, very good photographer. Thanks, so we're going to start off with some information about the university, and we thought it would be different to play around at University of Bingo. So, there are some numbers up here. I would like somebody to call out a number, and then I'll tell you what the number stands for. And there are also some prizes. So, first person please. 390 is the number of websites we migrated from the proprietary system to Drupal. In 2014-15. 30,000 is the number of students enrolled at the university, beginning of last year. Next one. Sorry? 1996, Dolly the sheep was cloned at the Rosalind Institute. And one more. No, take the one in the middle. 2015, that was the year we launched our Drupal-based CMS, which we called EdWeb. Okay, so going right back to the very beginning, we wanted or we needed to build a new content management system for the university. And we put in a whole load of other technical solutions at the same time. So we built this new content management system centrally for the university. And we also had a Drupal distribution that we encouraged people to take and use as well. And right back in our business case, we said we wanted to build a culture of innovation, of collaboration, creative problem solving, and problem transfer and problem building. So we were really starting to lay the foundation right from this very beginning to build what we hoped would be a strong and vibrant community. So I'll take you a little bit through the journey that we went to get to where we are today. In 2012, we had an initial look at Drupal. There was a desktop evaluation that produced a small report and said, yeah, Drupal is something you can look at a little bit closer. So we then went on at the end of 2012 to have a proof of concept project. We took 11 key requirements and analysed these a little bit closer. To come to the conclusion, would we be able to meet these requirements with Drupal yes or no? The answer was all yes, so we decided to progress this. And in 2013, we had three other projects running simultaneously. One was on training, that was Drupal as well as Agile training. Technical investigation, we looked at the architecture, and the other one started to look at requirements gathering. July 2013, we started on our CFS development. We used Agile for this, and we'll talk a lot about that later. The end of 2014, we released our minimum viable product. Went on to release another four releases in total. On 2015, we launched the full client, and also, by that point, had migrated all the 390 sites from the previous system over to Drupal. We then went on with two projects each last thing a year, one with additional requirements, putting extra features into the system. Last year, we started on a collaboration pilot with some additional feature development. This year, we're looking at Drupal implementation planning, and that's why we're one of the reasons why there's a group of colleagues here at DrupalCon this year. And next year, then, we're going to move on over to Drupal 8. Okay, so as you could see, we had plenty of time to get things right, and we got onto our Agile machine in our streamlined position, and we shut off peddling furiously downhill. And yeah, we built a team that was efficient. It was productive. It was disciplined. I mean, this is what Agile is really, really good at. There's lots in there that can really help you to do this. And on top of this, we built processes that were strong, that were consistent, and we had plenty of time to practice them. So with all this, the combination of this with our team and with our processes, we got lots and lots of work done. So when we started on this journey, I remember the first meeting where we were talking about the development and how we were going to plan the project, and we were all very clear at the start that with waterfall, this just is not going to work too big a piece of work and it's going to take too long. So this slide here represents some of the things which were important to us. The university has quite a mature project management culture, but we had embarked on Agile projects of that scale at that time. We had done some Agile projects, but more, smaller, maybe three, four iterations and not certainly as many as we would need. So a few of the things that we needed, we needed team building, we structured meetings, our stand-ups, roles and responsibilities were key. The university is quite a diverse place. There's lots of different campuses and teams located in different places. So co-location was a key thing. We managed to get some rooms where for the duration of the iteration everybody came together. We were Agile in applying Agile, and we'll come on to talk about that a little bit later. Right in the centre there, one of the most important points of the project, chocolate cake. We wouldn't have got through a lot of deployments without that. So the Agile approach was really to break down the user stories and the iterations into manageable chunks. We went with a nine-day development iteration because people working in the project had other responsibilities. We had three days a week. The team came together for three weeks. So Tuesday to Thursday every week we worked on the project together. They released cycles towards the end of the project. So from two to five, we had three development iterations and one non-development iteration within each release cycle. We had the flexibility there to move the non-development iteration to places where it worked for us, depending on the user stories or people's availability, obviously with Agile, even stuff like that, without having to move the release dates. That flexibility was very good. We decided early on not to break the people. We did a lot of team-building activities with that, which possibly wasn't so common in the university. We celebrated our success. So at the end of every iteration, we made sure everybody had a drink or a coffee. When we released one of the releases, then we did something bigger. Activity went for a meal or something like that. That was very important to get everybody brought into the new way of working with Agile and the team as well. A little bit about project governance. Very busy slide. The key points of the four tiers there. So the top tier we had our senior management. We have a QA process within the university. We had a project board. The blue layer is the main project team. So the roles for all these people, we did change them along the way, and we'll come on to that later as well. We had an extended iteration team. People who needed to be involved at certain points in the project, but not involved in the core iteration. Then we had an extended layer with other stakeholders and other people around the university who needed to be kept informed of what we were doing. So what's wrong? What's the problem here? We're just saying that we've created a really good team, really good processes, working really well, we're getting loads and loads of work done. But on a big project, you can start to get stuck in a bit of a rut and you just tweak things really. You don't really make any radical changes and you plough in straight ahead. I think this can lead to a bit of a flatness within the team, a lack of vibrancy. It's not really burnout, as we already said, and I think a lot of teams do this. There is a lot in place. You stop your team from burning out, you eat pizza, you drink beer. But yeah, this lack of vibrancy, because we've just been going through these iterations over and over again or in this rut, and I think you can start to sort of lose sight, really, of the bigger picture. It takes us a bit small apologies for that. Two squirrels, one is storing his nuts for winter and the other is coming in with a nutcracker and one is saying to the other, Andrew, what's that? Just bring us stuff we can eat, fall. It's this thing about you're starting to lose sight of the bigger picture. You are going through the agile process, really, really good, and you are releasing small pieces of discrete functionality, which you're deploying and they go in live and everything's great, but you don't have any time to step back and think about what your product vision is and where you're going with it. So yeah, just losing sight of that bigger picture. And this has led to some people saying we should kill agile off completely. So this is an article from Nate Walkinshaw on a really good blog with you channel called Mind the Product. If you're not familiar with that, I'll definitely take a look at that, especially if you're into project management or product management in particular. So he was saying agile died while you were doing your stand-up. And basically his point was that the teams he said that he was involved with, that he was working with, had stopped involving the user or the customer in their process at all. And the ones that were doing it were Milo or in a team on their own. And they'd stopped involving their users in the process. And again saying that they were focused on the output and really focused on the agile process. It was all becoming about stand-up, it was all becoming about JIRA and the process itself rather than what you were actually producing. So it led me to start thinking about what we could do here. And really thinking, is there a compromise here? I love my project management methodologies and I love agile in particular. So I don't want to kill this off. I definitely don't want to do that. But I was thinking, could we stop the treadmill just for a bit and just get off? And so don't leave everything that you've learnt behind. We've just said that we've learnt some great stuff through this whole agile process or the team building or the building of processes. So let's not leave all that behind. Let's take this and use it in a different way. Something that's constructive and something that we could do together as a team, as a whole team together. So could we build a community instead? And the answer to that was quite simple, yes. Because the university is quite a devolved organisation, as I said before, and it has lots of communities already. And the university website programme, Bruce's area, they already ran several different types of community events. We have community events for web publishers. We have more technical community events aimed at various groups around the university. These sessions which were set up with these different groups, they always had a focus and agenda, certain themes that were covered, for example the latest developments with the CMS. And they also allowed adequate time for Q&A afterwards. So the discussion was motivated and people were talking about the various topics. And also most importantly, the people who attended these sessions, they were the users, they were either the web publishers or the people who were building sites. I said in the blurb about what we were going to do here, I wanted to point out some pitfalls along the way. And I know some of these are going to sound pretty obvious, but I think we've all been to stuff like this where people have got it wrong. It's worth pointing out that community building is not about sales and it's not about marketing, although of course they have those places, but don't get confused with that as being part of your building a community. And I'm sure you've all been to this sort of thing before where they have got it wrong and it's all a bit sleazy and creepy and they're saying come along because we love you and then actually they're saying sign here and we'll give you this contract. So community building is definitely not about that. And that's definitely not us, just to be clear. So what do we get out of it as the service owners, the people that run the projects and the programme? We get feedback and we get suggestions. The community is not backward and coming forward. They let us know what they think. They're the positive things, they're pain points. It gives people the opportunity to collaborate with us and also to contribute. Yes, and while we want everything to be on an equal level, you know, sometimes it is us doing some of the organisation and we're coming and we're saying this is what the focus is going to be until we are sharing our information and expertise. We are doing that to give a focus to some of the events that we do. But what we want is for the fact that the people that are turning up, they are our users and we want them to be able to tell us what they want. And not to look at our software and think, well, that's it. I have no say in this, I'm just going to have to put up with it. So, yes, we definitely want to foster this feeling of collaboration and then being able to contribute stuff to us. So we have these small communities that in one way or another are working together. We thought, well, let's look a little bit further afield. Let's learn from existing communities. Under the outset of this piece of work, a small team went to Drupalcon and Prague and we've been to substitute Drupalcon since. And we thought, well, let's look at these communities. What do these guys do in Drupal, Drupalcamp, Scotland? We went to host that once as well. What makes that work so well? What can we learn from that? Can we tap into any of these ideas? Could we borrow ideas from the open source model? So we did that and we picked up some ideas and we progressed that. So we started to have this idea about putting together our own university community code sprint. Two reasons, really. One is, as I said at the beginning, we had produced this content management system, this central content management system, but we also had put in a whole host of other technical solutions as well. One of them being this Drupal distribution that we wanted people to take in our community, in our university community, and customize and use and build and use this as their own live survey if they didn't want to come into the central system. But we found that we were very, very busy. As I said, we were on our agile machine and we were pedaling fast down here and we didn't really have time to support them in this community endeavor and we really needed a way to kick this whole thing off again. So we had some great ideas and we just wanted to see if we could kick this whole process off again. I mean, secondly, yeah, we always looking to continuously improve our community events as well in the same way that we do with our software. And so we are wanting to push the boundaries a bit sometimes and take a few risks and that's what we wanted to do with this community code sprint. So some of our developers had come to Drupalcon some years ago and they'd come back and they were enthusing and talking about going into the code sprint at Drupalcon. And we were just like immediately struck by how powerful an approach that was and we thought, you know, can we do this? Could we have a day where we invite developers from around the university to come and work on our content management system and live and breathe our code. And it was risky and it was quite scary. But yeah, we wanted to push ahead and see if we could actually go ahead and do this. And now down the line, we have had three code sprints. Our fourth is now planned. Each time 12 to 15 people have turned up and we have worked on and solved 25 or more issues which are now deployed and live. So yeah, everything working very, very well. This is a photo from our third code sprint and it's a photo that I really, really like. One of the reasons is that you can see people actually sitting and talking to each other. And yes, there are times when it's heads down and everyone's tapping away and coding. But at this point, yeah, people are collaborating and they're talking to each other and it's really, really nice. I mean, I remember the first code sprint that we had and I was just like absolutely terrified of going along that day. I didn't know if it was going to work and I didn't know if people were going to turn up. And then when I arrived half an hour early, everyone was there, laptops open, all sat ready and I thought, okay, oh God, this is going to work. And there's certainly a few things that you can do to relieve the pressure of that and the anxiety of doing those kind of community events and I'll come back to that in a minute. So I think the key to the success that Bruce will go into in a second was let's not reinvent the wheel. We had seen what works in the Drupal community and we thought, well, let's apply that and how do we apply that then to our process? And along the way we recognise we needed to be agile not only with this but also in the development project itself. As I said at the outset, we were in that experience with agile when we started but we quickly learned that we need to adapt our processes the way we thought at the start this is how everything is going to work and some things did work really well other things didn't work particularly well so some of the roles we changed throughout the project at the end of our iteration, we always looked at what was not being so good, what do we need to do better next time and we didn't just write that down, put it in a meeting but we actually went back a few iterations later and looked at it and said, well, we said back in December would we do this, have we actually done it, is it better now or do we need to make further changes and that was kind of what we did with the sprints as well and live and breathe the code and we gave it everybody who was participating in the sprints the opportunity to do that. Yeah, and as we've talked, I mean right the way through project management methodology in agile is this idea about roles and responsibility and we started to sort of have a step back and have a look at this and see what roles were involved and now they don't really have any formal definition and some roles have sort of moved over sort of gently from our project team and we've certainly used our agile skills to adapt these as we've gone along but just having a quick look these are sort of things that I've identified to do something like our code sprint for us and so we have people who are actors teachers and testers we have people who are developers we have people who are developer mentors we have people who are documenters and just going back to that photo we had previously we've got the tester in the room here we've got someone who is a developer mentor we've got our enthusiastic and dependable community members and I'll come back to this in a second we have other community developers sitting around we have people who are taking on multiple roles so someone from our support team who's also a developer and he's also one of our community developers and people that take on tons of roles from their technical expertise through teacher, community builder to even doing the documentation so yeah a room full of people taking on responsibility to get this sprint working so we have our processes we have our roles but what we really need in order to meet this work the last piece maybe in the puzzle is the champions here we've got Jordan Spieth, Andy Murray and the Dodger Nats on our man shaft sorry if there's any Austrians here but I couldn't find a world champion group of Austrians but it was really important to have people the champions for the service champions for the code and also champions for the community yeah and so some of these roles and responsibilities just want to go back and highlight a little and this was one of the things that we looked at our kind of senior stakeholder sponsor or believer and this was really someone at a senior level outside of our team who we noticed were being this really visible and vocal support for what we were doing so our first sprint pretty scary thing to do lots of people quite protective totally understandable but there were some really good people at a senior level that were talking about this at meetings supporting us when we were trying to recruit people to come along by emailing, mailing lists and forums and just doing that really helped support the whole process and they also really help drive things along as well because they are the people that are starting to say when is your next code sprint you know I'm out there I'm here in support for this when's your next one and so it's really helping us drive things along as well and then one of an incredibly important person is our enthusiastic and dependable community member and these are people who when they say they're going to turn up they do turn up and so I will sometimes contact them and say this is the date we're thinking of are you still interested in coming along are you going to be able to make it and that kind of releases the tension a bit on the day it just really helps when you know these people say they're going to turn up they are going to turn up and when they come along they engage with everything that we ask them to do and sometimes we change things you know we don't want to do the same thing at every single code sprint and here they are and we say and can you try this and they always say yes and they plough straight in and it just makes things so much smoother and so much easier and then at the end of it all they're there and they will give us some pretty you know it's gentle but it's honest and constructive feedback and criticism and we can take that again to improve our events going into the future so another couple of roles which are important at least one of them is very important is that the role of the technical expert and the developer the people who person who owns the code and our senior developer Mari is sitting here in the front the Mari along with other colleagues provides the technical leadership the in-depth Drupal expertise the code master as it were and the other role the one which I fulfil is the bigger picture from the programme there are certain activities project activities running in the programme but there are also activities going on outside the programme and it's good to have someone who has an overview of the dependencies risks issues opportunities with all the how does this all hang together how does it hang together in terms of resourcing for example and also reporting in terms of reporting that up to the portfolio level and then on to senior management and yes I mean obviously here I am totally overthinking it and now I'm going to say don't overthink it but I think that's okay when you're doing a presentation like this so yeah I mean we and I think as well recognising these roles is really really important because it then does allow you to say thank you properly to the contribution that people are making I mean it's something that Dries mentioned in his keynote when he's saying you know we really need to support these contributors better and that's really why we're doing this a lot of the things that people do are in the background they're taking responsibility on for it and it really helps things to be seamless and I think it's good sometimes just to be reminded about what people do and be able to thank them but obviously yeah don't strip out all the spontaneity let things grow organically and naturally otherwise you're going to kill the community so what benefits do we get from all this the community and the community involvement it can bring natural change it mixes up the team dynamics people are working with people that they normally don't work with it gets people out of their comfort zones doing things they've not done before and we found it taps in and recognises untapped skills so people that have come along to some of the community of eds who we didn't know had such great Drupal skills and we've been able to get them more involved which is fantastic and it refreshes and revitalises the process overall within the team and the dynamic of the content management system in itself because working with new people that's exciting and it's an opportunity for people to share their experiences and also obviously to learn from one another another benefit is that these users are the people that are actually using our product and you can learn so much from the very community that you're building these products for and it's just really nice to see them come along and see their involvement and enthusiasm for your product you can see that they have a real genuine interest in what you're doing and we are not building the next iPhone or a new sports car or a new generation of tellies we're building a good but functional content management system and to see people to almost building a relationship with your product is really really nice to see and it makes all the effort and the work and the fittingness around your day job it makes it all worthwhile and a really wonderful processor to see So we've told you how brilliant this all is but don't take our word for it let's listen to what a few people around the university say The University of Edinburgh is embracing the use of open source software to help us reach our strategic vision of building strong and vibrant communities within and beyond the university Our aim is to take the best of what open source can teach us about building communities within the university but also to ultimately contribute back to these global communities As the head of IT for the College of Medicine and Veterinary Medicine I have to manage a very diverse and complex set of business requirements It's great to see these requirements being met quicker and more efficiently by working collaboratively to help our community of resources around the university For us it's been a really really good experience We've developed a working relationship with the development teams outside our own college which is a first for us and we've designed and developed and delivered some new features that we haven't had before So for us it's been a really positive experience and really pleased to have worked on this project Good afternoon Drupalcon from Edinburgh The university website team have actively pursued the benefits of engaging, collaborating and contributing back to the university Drupalcon community We are glad to nurture and view this collaborative environment grow to benefit the university's website provision and have a positive impact to Drupalcon as well Have a great Drupalcon So we heard there from four quite different people from the development point of view somebody who's not been used to working with other colleagues outside their own school or college getting involved in this and we've heard from somebody from one of the business areas who is able to get features and new requirements quicker into the system We heard from the service owner who is pleased to see the continuous development of the system and we've heard from the CIO who is happy that we involved in this activity to build a community within the university and feed that back to the open source community And as we said we've always wanted to push things along and to have this continuous improvement So we've taken things directly from the agile sprint review or retrospective So at the end of some of our events especially at the end of our code sprint we do really go through all our accomplishments and go through the ceremony of appreciating the work that people have done and then we do open it up and often if we have time at the way round the room do the whole what went well, what didn't go so well what can you do better next time and we do always try and take this on board for our next events Obviously you're not going to be able to do everything but just small little steps here and there that can make a real big difference and take your community along with you So being a university we don't just do that without any governance a little bit of governance has to be So one of the things we implemented during the main development project was a CAB a change advisory board which gives the opportunity for people who take the distribution and develop something which everybody feels can be used a feature within the main CMS There's a process for change people can raise an RFC it goes through the change advisory board and then can flow into the CMS This is an idle based process and as Bruce said we adapt our community events in terms we adapt our processes for community events we don't go overboard on the change process for that we get the change manager involved before the code sprints so that they know which changes which issues are being worked on so that a few requests for change usually isn't required and probably another one of the very important ones and I think this applies to all project management use a little bit of common sense you'll go along way with it and the governance is actually really really important and you'll see this kind of spread around something like Drupalcon it is done very very subtly but it is there and it's done very well and I think that's the important thing because you need this governance in place but you don't want to kill that contribution and what you certainly don't want to do is take so much control taking responsibility for certain things because they are a fantastic resource intelligent, creative, innovative and you want to tap into that and you want them to take responsibility because it just helps you get more and more things done so yeah absolutely perfect governance important but just don't overdo it and to finish up so the conclusions we're saying refresh your team by stepping off your treadmill yes and don't leave your project management methodologies behind as we've said tons and tons of skills let's not separate that work out with your community events take what you've learned and apply it as well continuously improve when you find things that aren't working so well make slight and small changes in order to improve things yes and obviously look to existing communities great one here if you've not looked around before coming tomorrow and just look around and see that structure in place and what there is and all the sort of volunteers and everything and you can learn so much from a community like this and just to summarise all that take the best bits use them creatively and continuously improve and make changes and use that to the best you can thank you does anybody have any questions if I could ask you to go to the microphone and yeah it doesn't have to be questions it could be some experience that you have had communities that you've been building especially if it's from a more commercial slant we would love to hear that or people have tried things and it maybe has not worked or yeah you might feel that this is not something you would be able to do in your commercial setting be very interested to hear that oh dear does anybody have any questions if you don't have to go to the microphone don't be intimidated by the microphone yeah so I mean we have quite I suppose in some ways the university is a unique set up in some ways but in some ways it just mirrors another you know a wider community of users anyway but yeah I mean our team you know I'm talking about our wider team we all cross functional we come from different teams within the organisation but at the team that work on this project yeah we as a team worked to create these events so you know we took on some different roles and there would be someone who was a sort of or a team of people a subset of the bigger team who were this kind of community builder and it really is just getting an idea like the code sprint and just saying like how are we going to do this and it was just about saying you know get in permission to do this and then going out you know and just doing all the logistics like booking a room and just starting to advertise it and going out and talking to people directly and saying like are you interested these are developers who are in our university community but these you know we have a huge number of staff and we have a huge devolved university so this is not like a tiny little campus people like all over the place so we don't know them personally it's just you know we're having to go out and maybe speak to like the head of IT who was there and say do you know anyone can you recommend anyone who would like to come along is this something you would be interested in so we sold it as a concept and then from there as soon as people come to that first event then you're on a winner because they're going to go out and spread the word for you yeah I mean I'd say for this maybe it's like the code sprint or something like that is pretty unique and it works for us but yeah it's maybe not going to translate to everybody else but what you could do is go through that same creative process of just sort of widening out your horizons and looking at community like Drupal and just saying like how can we use some of what is going on here so you're not saying you would necessarily replicate this model this is something that worked for us and yeah I can see in a commercial setting it's probably much more closed and you wouldn't want people coming in but yeah I mean I think there are other things that you could do and you know we were open to anything really from the community so I wouldn't say you have to go this way but yeah just use the community for other ideas yeah Just to add on I think we were quite lucky in our situation of having a larger community of people with a Drupal knowledge all across the university who we didn't necessarily or we didn't work with closely but they all work under the umbrella of the university therefore they were there and it's kind of almost an untapped resource that we could tap into in a small with a small team in a commercial setting I see that being a bigger challenge one possibility would be to engage a little bit differently with your customer but that again brings its own challenges we want to keep the customer vendor relationship that needs to be quite clear for obvious reasons so I think we were quite lucky the University of Edinburgh is a very devolved organisation there is central CMS obviously this one we've been talking about today but it's not the only one every school or college has the right if you like to go away and do something on their own and a lot of them do it part of the motivations behind the distribution was so that we could put what we have developed out there and if somebody wants to take it away and do something wonderfully horrible it's up to them they can go and do that but there is an avenue through the change advisory process to come back in or to come into the central CMS but schools and colleges do have the freedom to take up other systems not only with a web presence with everything the look and feel we have a global experience language which we've created over the last few years so that anybody who's creating anything public facing or internal facing can use this global experience language so the look and feel the user experience should be the same across all platforms it isn't always exactly 100% but the take up of the gel has been very good especially over the last year and we are advancing that now putting more work into developing that further so the idea then is that if somebody wants to go away and do something else then they can take edgel across whatever platform and apply that to the application or the content that they are creating with the goal that the user the student staff or visitor has the same experience across should be for the user irrelevant where they are they should be able to jump from one system and it still has the same look and feel same IE not always the case but it's a work in progress I think we were again we were quite lucky that the university website programme had been around for four or five years before we actually started the Drupal project and they had been working and invested a lot of time and effort in building that community so that we tapped into it and we were able to pick up on that work and it helped in lots of areas not only with the development but also with the user stories with getting the feedback with being to get the message out there it certainly made us project manager for the development project it made the comms very very easy during the project to keep this was a two year development and people had been waiting on a new CMS for a long time so they were keen to have regular updates and it was fantastic just to tap into that channel use the different communities we have to get the message out there that didn't really answer your question though I guess starting from scratch there is a lot of work that has to be put into that in order to build this community up but if you don't start with the first step you don't make it anywhere on your journey I guess and the other thing not to underestimate is the amount of effort which goes into even when you have the community and that itself building that is a lot of work but building the code sprints you have to put in place things that Bruce was more involved in the code sprints than I was Bruce and Mary but the work which has to be put into that is quite significant and it has to fit in with everything else has to fit in with the other projects has to fit in with the service work which is going on as well as the day to day business as usual but I'm told it gets easier you've never said that to me before I think you have to be aware of the effort you need to invest at the outset but it is well well worth it any other questions going going going yes feedback I don't know the node number but if you could please go on to the triplecon website and give us feedback from the session that would be much appreciated thank you very much we can start a drink now thank you