 Mumbai has lots of construction, so it feels like I have an appropriate symbol for my talk which is Mumbai is always under construction and so there was a time, I'm beginning now, there's a time a decade or two ago when you would see this sign a lot on websites around the internet and the thing I realized when looking back and thinking about it was that it's a great symbol of our naivety and believing we could ever finish something because we created all these websites and so many of them and I for one and definitely to blame would stick these little signs and say don't worry I'll be finished sometime soon and a few years later we kind of gave up putting those signs on our websites because we realized we were never going to finish them but my talk today is about the fact that yes we gave up putting those stickers on our websites saying that they were going to be always under construction because we didn't want to reveal the people that we thought they were going to be finished but in many ways the way in which we still design and build and commission websites and software still seems to have this logo in it, we still in many ways assume that we're going to finish our software and then when people commission a website they're going to get a product and they can launch it, that's the end and I think we should do our best to dispel that myth but the developing community, the agencies and the clients, commission organizations are all guilty at maintaining this myth that we can finish and deliver a finished product and so I'm here today to tell you a bit about my explorations over the last few years since I realized that this is a problem for me and my own team and the kind of things that we explored to change this policy, to actually plan for sites that were never going to finish and what were the things we were going to finish so I hope I can talk today to people who might run Drupal businesses might be agencies that commission Drupal businesses or might be organizations that might commission a Drupal website and provide some kind of insight into the kind of things we should be aware of and the kind of practices we can put in place to assist us with websites where we give up on the idea that we're going to finish them and we take these stickers off our project management processes and our leaflets and whatever else we use to convince people that still worry you'll be finished one day so my name is Peter Baronell, I have come from London I work with a company called Code Positive which I'm a director of although today I'm officially an explainer and I try not to be the official title I've been a developer for 30 years, 20 of them professionally and start organizing meetups in London almost exactly 10 years ago so I'm hoping if I get the headspace to organize our 10th anniversary meetup on the 17th of March, that's committing it to the public and they help me get around to doing it so now this is a slide where I try to establish my credibility and tell you all the things that I've done so that you can believe the rest of my talk so I built an internet startup, a Drupal based internet startup we raised a million pounds, worked for five years, sold it for a pound so failed internet startup, but I learnt a lot from that I learnt not to build startups in Drupal, I'm going to say that up front it's not the right tool, it was five years of lots of education for me my recent project has been to establish a Drupal apprenticeship program in the UK it actually is now a government recognized qualification it's a foundation on level three in Drupal and it's been going for about three years and we've got a good number of 18 to 23 year olds coming through the program and it's been very exciting apart from Drupal stuff, I run a charity, I run an artist so studios, I've been an artist, I've been an activist I have way too many different things that I try to do with my time and one day I hope to learn to see anyway, that's enough about me let's get back to the talk so until possibly two or three years ago maybe a bit longer, but I find evidence of it on the website when you Google for Drupal Google... Drupals... yep if you Google for Drupal, you would get the Drupal's tagline being community plumbing and for many this was something I didn't quite understand but for me I felt that this, and I still feel that it's one of the best descriptions of what Drupal actually does provides that infrastructure that's plumbing and in the early days it was focused on communities and a lot of people communicating with it together I think these days although we've taken the slogan off the website and now we pretend and work now we are, a final business focus I think that community plumbing is still part of Drupal's core it has built us, it's our foundation but I think we've got bigger than that and so I would like to say that Drupal now provides organizational infrastructure really is the infrastructure that can support organizations in their day-to-day operations and I think that this infrastructure kind of work is the ideal place for Drupal small websites, there are many other competitors I often don't see a need to build a block of Drupal I don't if you can build it in WordPress, use the WordPress I've said before I don't want to build a startup in Drupal because a startup needs refined control of every piece of the US and with Drupal you spend more time taking features out of Drupal rather than putting them in but this sweet spot, this ideal situation where you want to provide a constantly involving reliable website that can adapt to an organization's environment with new features coming in a very regular level now that's something that Drupal does and I think that we can already achieve that and make Drupal the ideal tool for providing tools for organizations to run their business if we establish good practices and methodology is there allows to do that but that's more I think we as developers, agencies and clients all need to be aware of the real life span of our projects we cannot pretend that they finish at launch if we build projects and plan them according to a launch date we simply cannot effectively prioritize the work we do to make our sites ready last and so yes, we fail to get the real return on investment if we do not take a long term view from the start and so yes, I'm going to cover some of the theory of that long term view talk about some of the practical elements that we try to do with the development team talk about some of the ways in which we've had to evolve beyond being a development team in order to help the organizations we work with actually deal with the time scale which we talk about and then in briefly things that Dries was touching on this morning in his keynote the fact that we're moving to this fourth revolution where everyone needs some form of infrastructure and some form of digital infrastructure we have to be able to teach our organizations to adapt to this new digital age and Drupal could very well be the right tool for opening this part of that and that's what Dries was touching on in his talk today so yes, this idea of organizational infrastructure organizations need digital tools to help them do their work, their business and the websites don't have to necessarily be internal, external they just need to be the tools that support the day-to-day operation so a marketing company might need better tools to allow to measure and improve its marketing a solar power company might need better tools for managing its internal operations and its solar farms, that sort of thing all this kind of work requires that we are able to build a tool to solve a problem and that tool, solving a problem, changes the problem and then we have to build a new tool to solve a different problem because we now have a similar relationship between the software and the business and yes, so we have to constantly update these services to change the requirements because, well, we change the requirements by building a lot of release of our software now, I've ended up discovering that we've actually been building, my team's been building this kind of site for quite a bit of time our Drupal consultants need to be going for almost 10 years, 9 years and for a lot of that time we've had the same clients they've stayed with us for a very long period of time and the sites we've been building started to actually have a lifespan way longer than I was willing to actually admit when I began this project and now I've come to the conclusion that if I'm working with a large organization and they need a site that they're going to use to support their operations I need to start planning my websites the last for 7 years it seemed way longer than I expected, I said, but I did and really I built my start in 5 years and that was only just beginning I have worked with some of the organizations that are currently my clients for, I mean, websites which have already been going for 4 years and we've been getting so, 7 years, it seemed like a big number at first but in practice I feel it's the age for a decent website with the agility that we should be aiming for the thing is that because we don't actually see this whole lifespan we don't begin saying, alright, let me build a website that's going to last that long and work with my clients to understand that this website needs to keep evolving for that length of time because there's no launch the launch is the beginning, it's not the end and so from the moment we launch we're going to constantly want to add features and change the features if we don't take that whole lifespan into account we are building the landfill software we build, no matter how good our development practice is no matter how much care we take over each land code we're building rush because it's going to go at the bin we will not be able to serve the needs of the organizations we are trying so, how many care use some form of agile method? a good proportion of us and agile is in many ways created this is a graph that shows the traditional cost of change in a waterfall software that I'm from and it's pretty simple there are many graphs like this but essentially the later in a project that a change request comes in the more expensive that change is to and if you have a project that must now last for seven years with change requests coming in at every point possibly every month, even every week in that lifespan for the entire lifespan of that project that's not a very difficult it means that the older your site is the more and more expensive it gets to maintain which means that you never get to seven years you get somewhere around three years and you throw it all away and you start again because the cost of change just goes too high so in his book on extreme programming Kent Beck published this graph as his idea he claimed that extreme programming which was one of the methodologies that came before we classified what agile was he claimed that extreme programming could achieve this graph where the cost of change became a constant most people tend to say it's not quite that nice it still does go up over time but in practice that's our goal that's the holy grail of the agile methodologies is to achieve a cost of change graph that looks as much like that as possible and if we are going to build sites that must last almost a decade we definitely have to aim for that kind of graph so what this means is if you're going to build long term projects you need to have some form of good agile practice to manage that there are ways around it you can make up your own but essentially you need to know that lowering the cost of change is your goal and if the systems that you evolve and the various bits of different methodologies that you adopt for your team do not achieve that goal you get rid of them and you try again because you have to continuously aim towards lowering your cost of change that is essentially what the agile methodologies were created for and they still need to aim towards that and within proofable because we're not a purely code based system we have to manage configuration and there's various layers that are not always effectively captured in code we may have to adapt the agile methodologies to fit our environment and that's fine agile methodologies need to be adaptable that's their point as long as you remember that mantra lower the cost of change so let's forget launch that is one of my answers because the moment you start having someone say what happens at launch when you start planning projects for launch there's no reason why you should use any form of agile methodology at all in most cases you do not see any return on investment from an agile methodology if your project ends at launch there's no reason for you to build tests there's no reason for you to have name or standardize your building background there's no reason to talk about it there's no reason to bother about anyone else maintain your code up because launch is the end that's all I care about deliver the most effective project for launch do not use agile but if you can forget about it and from the start you are able to convince your team and your clients that their site will last for approximately 7 years then suddenly you can prioritize the things that make your site last you can take time to build your layer test you can take time to establish good style you can take time to do all those things which make agile far more expensive in the beginning than it is at the end so what we do in agile is we front load all the technical stuff and we do all those things that allow us to change their environment agile does not mean fast I think that's the mistake that people make when they step in agile is not fast agile in many ways is slower than it would have always been because we have to build the test we have to come up with standards we have to come up with ways for our team to work together but yes there's no reason to do any of those things if we haven't convinced our clients that you have to think about the long term maintainability of your work so yes understand and welcome change my mantra while producing this talk in the agile manifesto the second point make that very clear we must welcome changing requirements even late to development at any point an agile process says harness change and we make that an advantage and yes I love studying how it can change it really is mine so as much as my professionalism isn't it I haven't got the party mantra for my meditation but it is essentially my focus so I would love to get to this next stage of my talk and now show you some great examples of websites that my team has built that I've used all my theories and all these things we've developed and built something really good but I can't because unfortunately I have learned many of these lessons to how first of all we lost we lost a major client where I had to hand over a different agency and I realized all the things we didn't do that we should have done when you go and give someone else all your work then at almost the same time we had a giant agency we were then asked to take over a multinational website that we produced by a giant agency and we got to look at all the things that they had done wrong that stopped us from being able to take over and maintain their work and this got me thinking quite seriously about what are the best practices and the thing that we do first of all to allow for some form of continuity even if you change developing teams and I think that's for me one of the biggest holes in our organization approach to websites and especially continuity we don't have a plan for the one thing that's probably going to happen you're going to change the people and we have very few plans so this next section covers some development processes that we adopted a team we've also not necessarily implemented all of these for each project as we come in assuming a number of different websites we've learnt a few things and found some things were more important for that particular stage of the project and tried them on we've been through a few iterations what I'm going to share with you now are the things that are our current theories and they may change so this is the first important truth when exploring the is a tarot nature of change in any form is that change itself is consistent and any system that is coherent actually has consistent ways in which it is changing so if we are to build a system that allows us to manage change and reduce that cost of change we must be consistent that's there isn't any way around it to make sure that the work we do is consistent and so it needs to work across all team members again another of the extreme programming methodology so extreme programming has lots of those and I enjoyed it and one of the best ones says you can program any way you like bitnotch with us that's very true your team needs to try to make sure that each team member works in the same way on the same side not just at the same time but over time you need to make sure that your sites are built in consistent ways consistent patterns solve the same problem in the same way with the same tools and then make sure you document how you solve that problem so the next time you solve that problem even better than that plan the pattern for solving problems up front and if you start with style guide for your website which is another very important pattern that we have learnt the hard way makes life much easier if you want to maintain the site build a style guide right at the very beginning and obey your style guide it's just one of those simple tools that allow you to build a maintainable website and if you look at the atomic style guides that say first define the small bits and go up to how they group into large elements you define all the various patterns that you're used to build your website how do you list them how do you display a list how do you provide a team how do you filter them working out all those molecules of your atomic style guide will then allow you there to define before you build anything okay we're going to solve this problem we're going to do lists and blocks we're going to do this one using patterns and you can actually define a pattern before you start building a website and I know in many agile schools we're not supposed to try to do too much upfront design because it can be a waste but in Drupal perhaps we have some of the similarities that we need to adapt to and Drupal is one of those systems where experience makes a hell of a lot of programming in general but the knowledge of the systems the knowledge of the patterns means that you can have a exponentially different interpretations and also Drupal experience is rare so if you have a multi-discipline team with multiple different levels of skill we find that having your lead developers look at the patterns define how this problem should be solved and pass those on to more junior members of the team you're able to yes, effectively manage consistency without going on and having different people hacking at things just because they didn't know better and there were some around to ask a question saying how do I solve this as they went on and did it don't just build things build it the way it works and yes the other interesting thing with patterns is each website that you build may end up having its own set of patterns and you have to make sure that when people build on a website they use the website pattern not their own pattern and so your consistency across all team members within the specific context of the subject and patterns feel really hard to dodge we don't know where to start we say should I do this, should I try all the steps or do I talk about design I can't answer those questions because they also depend very much on your team but the best answer is have an easy place to have documentation and use it so when someone builds something start at a high level and say alright, we do this, we don't know and then every time you use the pattern we've tried wikis we've tried also things we have now finally although it has existed for many years we've adopted Confluence which is one of Atlassian's products because it just allowed us to work very quickly and the difference in connection between documentation that we needed without anyone complaining that I was too hard and I don't like wikis into acts and I've lost my index and Confluence did solve these problems for us and it has improved since we adopted it now this one is something that has I found it's ugly head a few times in my recent projects and when you take over someone else's work and they have some level of automation for how they deploy how they might test things if you were not part of that team and that team happened to then go away and they took all their processes with them and you're left with this website that obviously has processes and tools, but you have no access to them and so if an organization is going to be able to plan for the fact that it should have the right to change the development team at some point the organization that commissions the website must own the tools and the infrastructure to test and automate that website you can't as a development team say I know we can use all our tools and we're going to give you this website because we're not that's not a very open sourcing kind of thing we might be trying to lock in our clients to our processes but really if we want to be in the spirit of open source and actually give our clients the right service and plan for their continuity in case we decide not to work there anymore because that's also the other important thing some clients are just not worth having so you want to be able to leave them and still be nice and say great we built your website and here are all the tools for you to maintain the website and goodbye so it's a good investment to make sure that we set up the tools for our clients but yes, making sure that we say here's the website and here are the tools that support the website provided in some form the client can own themselves the Git repository should not be hosted on your web servers of course you can move around but ideally give the client a Git repository and say that's yours, maintain or at least look after, we're going to use it but it's yours the documentation should not be saying it sits on your servers luckily with things like Confluence that's how you can easily export so you can say great we'll put it over there we'll export our handover of the tools because I do think organizations that start taking their websites as supporting platform services are going to have to insist that they're able to survive the change of supply and within the UK government there's been a major push to use small enterprises IBM large corporations this amazing energy you say let's break the stranglehold of the big consulting firms and use small business to build their software has kind of fizzled out because small businesses could not cope with the continuity of supply they could not allow, first of all different teams to work on the same projects they could not allow someone to change suppliers because small businesses they sometimes go out of business and all these government projects ran into a lot of trouble trying to manage lots of small teams that could not offer them any kind of continuity once they deliver the project they're working with and so unfortunately I think the UK is very much moving back towards IBM because IBM solves some level of continuity and continuity for any large organization or government department is critical and we have to solve that problem so I'm going to step one level down let's talk about the things that your team cannot not do we can get away with some form of life documentation and we can sometimes teach things and recover for some these other processes but we can't not do these things if we want to have some level of reducing that cost of change in any website so you have to make your changes deployable and Drupal has made this hard features is a pain and if you get obsessed about making sure that every single bit of your config is caught in a feature or in code you're probably breaking the rule of making your change cheaper you can spend days trying to automate something that will take you 5 seconds so don't obsess about continuing integration it's not that important what's more important is the repeatable process you must be able to say you've got this work, so on this server it's now moving to that server achieve that in a way that makes it doable, repeatable and as cheap as possible and bit by bit automated man we gave up obsessing over CI and full automation a long time ago because I lost years of my life trying to solve some problems and then you have to do some form of automated testing you can't have a website that it's going to last for a long period of time where you build features 3 years ago and you haven't come back to them and suddenly something breaks but you haven't looked at that for a few years if you haven't got a way to test that you've got, first of all you're probably not going to fix it in a second when you've broken the first thing so, automated testing the problem is that Drupal's simple tests tend to be rather hard especially if you were trying to get your junior developers or junior builders who didn't know any coding but they can easily implement a path they can build their views they can produce the features but suddenly building some features and then saying great, now go write an object-oriented simple test to test that feature there's a big disagreement so you end up just not doing that big not quite by accident but almost we started our apprenticeship program and one of the first things we did on the apprenticeship program for these guys who had in many cases never used a computer or never done any program before had been a very light exposure we very quickly got them on to try the Hat the Hat is a natural language it's a simple language that allows you to script flow through a website clicking on things and making sure things exist and really it took a matter of days for someone with no program knowledge to pick up the Hat and within a week they were doing productive work then we could sell so really if you haven't got some automated testing find someone who has a very basic knowledge of programming say it's a tribe it's a horrible document there are some horrible learning curves to this and you do need someone who can do some debugging to sit down and read some arcane docs and solve some more difficult problems but in practice if you have an experienced person on call the Hat allows you to establish a testing department within this and it you know you will rewrite those tests many times and the testing process is one that will evolve and grow but it is still a very valuable very good and I do recommend you try I'm going to start moving away from the nitty-gritty only development team I can go on for quite a while to find the little things we tried and things that have failed actually I realized at some point when I was beginning this journey of trying to work out how the building sites that lasted yeah I went through a bit of an epiphany and I was sitting with a client before us and during the work we normally tend to do for free we take out an afternoon sit down with the client and filter out which stories we should look at which one we should focus on and come up with a set of stories we should include you know we thought this would just set up we tried to fix spread rates and so this was just a little bit we never really measured the beginning of the spread but after one of these meetings I sat down and looked at all the ideas that they really really wanted and I might convince them we're not going to be quite investing and realized that we could have charged tens of thousands of pounds to do their work but we told them not to we told them to go for a much smaller amount of work and I realized that hang on I'm just taking all this work out of my company for free and looking at this process is going well maybe if I just saved my client thirty, forty thousand pounds we must one after me maybe I should start charging for the service and so I started looking at the various things that we did and especially the things we did for free we thought were obvious and I tried to turn around the pyramid and say well if I thought that was the bottom what if that's the actual service and so I turned it around because one of the things that you're trying to do to reduce the cost of change is actually reduce the amount of change if you're trying to do the right changes or the right times you're trying to tell your client it's a waste of money let's get out of there it's a very important part of managing the cost of changing the time if you want your sites to last you need to make sure that you put the right features in and if those features aren't working take them out again so that process of refining your feature list to keep it stable is very important and it is very valuable so because we were developing that code was our product we didn't realize that we were working with organizations that in many ways needed far more than our code they really needed our advice understanding of this digital domain and again going back to Drees's keynote this morning this whole process of companies need to be agile companies need to adapt to the digital revolution they really do need help and the people we've given happened to be the people who've been part of this digital revolution for quite a while the developers the teams we just have to start communicating what we do in code to the people who are thinking about this in terms of business and so yes I went through the things that we did and I found a few of the things that we did for free things we thought were obvious and I started turning them into things that we could sell and that I realized what consultants do a consultant is telling people things that you think are obvious and they can pay lots of money so yes we became consultants in this process and the process of becoming consultants really took its own course and so we suddenly started doing consultancy kind of things because we couldn't really do our programming job if we didn't fix these things within the organizations first so I'm going to now talk about a few of the steps we've taken to help our clients actually give us the right kind of work so that we can do and one of the things that we realized after delivering this great big report of all these things that people could do and a seven year plan we really got in there and tried to help someone look at this long term plan for the website no one made it it was dense and so much effort into it they didn't care and then we did this again for a different client but we also gave them a picture and they loved the picture and then we realized what we were doing the wrong thing we were still talking developer speak to the non-developers and we had to tell people simpler stories that follow some kind of story arc if they didn't understand because yes our clients often are not interested in the integrity of we want this feature there some people do care but they care about their feature and they want to see that on their plan they don't really care about the entire plan so when you are starting to communicate with your clients you start telling them that you're going to have this long term plan for their website you're going to guide them through maintaining and building this system and one of the nice little story arcs that I found that helps when you're telling people about a long lifespan for a website it's saying that a website goes through a series of phases and in each phase you're going to prioritize the rights of your feature so the first phase is birth you start developing the basic structure and the essential elements of that website and in that first phase you might have that launch which is when you open it up to actual users and that's the point in which you start to actually define what is this website supposed to do because you had this idea you had a lot of assumptions they were probably wrong and you try them out and you realize people didn't want that so you go through this process of what I called definition where you say this is what we're doing and you actually manage to define more clearly what you're trying to achieve with your website and you've validated a few assumptions then you go through the process of once you understand this and the definition process might take a year it might be this whole a year or two as you go through this process of working out what we're doing and trying new features we now have a good idea of the kind of service we want to do at that point you then have to go back and try to communicate that again to all the people using your website so you then start restructuring information so the third phase tends to be what about our product page is wrong let's redesign nodes let's fix this up let's make it clear and then you get to the process of saying we've got all the stuff and we've actually got good content the fourth phase is often one of building strong connections between content so we're really refining your taxonomy finding ways to stop people from reaching near the dead end pages although you can plan on a bit up front really it takes watching your stats and watching how people use your website to really see how these different bits connect together and how you can give people real insight into the topics by connecting the dots in different ways and that comes near the end of that natural lifespan of sites and by that point we realize we can do all these new things we can connect these things in new ways that's the point at which people normally start thinking about their next website because they've learned all these lessons and you need to reincarnate at some point it's a very esoteric approach to telling a story about a website it's very unscientific but I don't think it's entirely wrong some websites will follow a different kind of flow but the point is tell a story that story doesn't have to be true it can be a myth but it's just a way to help someone see that there are certain priorities and kinds of features that you can put on their website so when you do have the organization where everyone wants their feature be plugged in tomorrow you can say well no we can look at that kind of feature in the next year and then that might fit in the next few months you can say well no next year but eventually they realize that you're not here there's some kind of the other thing I've realized and this might be particularly important for Drupal where we're doing far more than just code we're working with code layer, integration layer a process of choosing the right modules managing how those modules get updated we really need to become stewards we need to serve our clients and look after their assets because our clients love destroying their website that's somehow where it is they go and spend a lot of money and then they mess it all up and we have to find some way to guide them through this process and not just saying yesterday well we have to become stewards and actually tell them well you were trying to do this and so to do that you shouldn't do that you need to do this instead and that's another consulting thing that we used to do for free for now being able to go along and say well let's test your assumptions the idea of the lean start movement to be able to take the ideas of assumptions testing them and the leaks it's a great book to read I do recommend if you want to take on any kind of stewardship and looking after your clients the lean start is a great and convince your clients that you shouldn't just jump in there you need to say no first we're probably trying to do and have a process to go through before you add things to your list but yes there are a few different layers to the work we need to do for our clients code manage that product and this is this area which I'm going to get to now where we've had this idea of the product owner represents the client and it's still a very dev team focus it's all very much about what the development team do you want this, you have the stories yes the story should work with this so the challenge with that in many dev teams is that the user experience tends to be something that's kind of left out get this module, plug it in there and the dev team focus is on the code and the product owner is more of a business and so there are lots of elements that get missed out so there is a growing community of product manager so next step up of product owner which actually engages these different things and we found that it would be very valuable for us to establish a product management as a key service for our clients and then the idea of governance and how it works where we try to tell our clients that this website is the tool we've got you is to last and in order for it to last you have to approach in a certain way and you have to request features in specific ways according to processes you have to follow the style of that and actually the process of documenting and trying to enforce trying to set governance is something that if we don't take on that role no one is going to do it's very rare that you'll find someone in an organization who's really willing to stand up to their boss and say I am not going to implement your feature you know people just want to say yes to their boss and we have to help them so let's take my time so I'll touch on a few things product management the product manager sits at the center section of business, UX and tech it's a very challenging role but it's something that if you work with large organizations for long lasting websites I feel is vital one of the interesting things with this kind of platform infrastructure website you may have an internal development team but you're not going to necessarily have continuous roles you might have sprints that happen every two months, every three months but the organization doesn't want to stop planning its website, stop coming up with ideas in the period where there's no development team there so one of the product manager roles is to understand what the program is doing it may not necessarily be a program but they need to understand HTML and CSS and code and know the principles they need to understand the business they understand UX and so they work within the organization to help them keep evolving their ideas while there's no sprint happening or while there's no sprint in the immediate future and their job is collecting ideas and making sure that they are collective in a way to pass on to the development team and then refine them and have discussions about them so that by the time the stories and the acceptance criteria get to the development team they're in the right format and they're being thought through and they're actually meeting the right business goal whereas you can often in the scrum process just with an owner in an overwhelmed by a giant backlog of bad-eaten stories and it can be held you really have no idea how to prioritize them effectively and so that product management is pulling that away from the development team it's not separating it's not saying plan your software and give us a spec it's just about establishing the stories in an agile manner but independently from the development team so it can evolve in its own way and yes there's a growing community of people exploring product management there are meetups all around the world and it's definitely something to have a look at when you start using a website called ProdPad and it ties in with JIRA and there's a tool in it we use it to have these discussions with our clients so what your ideas there's some markups, writing stories our bad acceptance criteria they'll come through and then when and then we use that to manage our roadmap one of the things we managed to do it took a long time and a lot of work was get our clients to actually say alright we're going to do a sprint every two months for the next year so we actually put this in the calendar each of our sprints then have a theme and a focus and within ProdPad we managed that roadmap collecting their ideas putting them together so that ideally two months before we even start a plan to sprint we've had enough time to discuss and refine what our clients want in that sprint and that's been very good at reducing the stress I finally gave to that week before our sprint and realizing I haven't clarified that I haven't asked these questions this process of just giving ourselves a lot of runway and months in advance collecting these tools according to roadmap has been very valuable so yes the idea of having rules and processes for managing feature requests is something that many people are very approachable it is doable and can be done it just takes the right level of buy-in from the boss ideally you can get right at the top and get the level at the top to say yes we are going to establish some processes and that is how we protect our investment generally if you come if you keep focusing on the money you are investing a lot of money over the next many years in this website and you don't screw it up by saying do things in this way and sticking to those rules of course you can still screw it up but it can reduce that that possibility so the man I propose that you look up and read is Paul Berg he is in the UK he's got a number of books that are very valuable at helping you understand helping your clients understand what websites actually do and one of the things he does very well is get people to build a service manual to the manual that says we are the development world we are the owners within the company of the website we do this, this is our mandate this is how you should request things and here is our style guide communicating within the organization what the web team does whether they be just a product owner representative of the organization or an action team self and how they work making sure that that is clear and in practice the easiest way to enforce something is just to make it clear we've written flowcharts we've done all these things but only when we do pictures story, use pictures try to make it nice that's the only way people pay attention when you start telling them things and then they are very happy if you've just said we're in charge, you're going to do this like this generally people are much more willing to go and say we'll obey your process until they want their feature tomorrow and that's when having the backup to help you the other things that we found was amazingly valuable we went to one of our clients and they said can you fix our website and after looking at the websites and looking at the way they were managing it we just said no but we'll help you fix your organization and this is where we took their next step up to being consultants and we took their company mission statement we said nothing in there and they came up with a digital mission statement and we got them coming together in a one day workshop and we got them stuck this is what we want to achieve online and this is a charity that really depended on the website the website defined them and yet their mission statement mentioned nothing about the website and so there was a complete disconnect and in doing that we were able to very effectively start engaging with how they worked and then able to start dealing with technical problems because they knew what they wanted to achieve we helped them establish some processes and staging infrastructure and testing infrastructure and then finally we started solving some of the technical problems but it would have been much harder and close to impossible and we wouldn't have done any service apart from making the problem worse we hadn't actually taken the time to work out what they wanted to achieve see I'm two minutes over I'm going to do my final conclusion and the thing that I have learned in this process of trying to assist people to understand and manage change over time is that it really is a it's a symbiotic process as we try to build some software that supports us it changes everything processes to support change, we change and so this evolutionary process applies to the development team from the development organization and the client and to the software and it's this weird kind of sidewall thing that we are building to be building and the digital revolution that Dries has talked about today is really that every organization in the next let's say decade, in those how long will need to have some form of digital DNA they will need to start adapting and existing within the digital world and making sure that tools that they use can change because we are entering a period of such rapid change that any business wants to survive must be able to change quickly and change and so I hope that I can continue my explorations and make this change and I hope that I can have some more conversations with the people and their experiences I believe this is actually very important I think Drupal has a very powerful role to play in this process of helping people understand change and it's a far more than technical process it might be talked about software but the software then changes the business our agile methodologies have influenced almost every part of society and they are all about lowering the cost of change so yes, thank you very much that's the end of this video I'm sorry I haven't had any time for questions right now but you can email me you can tweet me I may not respond I'll use Twitter once a year so here at GreenMan my handle is Twitter I'm GreenMan quite positive thank you very much this slide you can come on this slide sometimes I have put it on my website for 3 years so definitely not there I'll get it to my website thank you very much you can put it on you can put it on