 Fantastic, alright thanks very much for your patience everyone, we just had a slight technical glitch here at the beginning of the conference so thank you very kindly to Agile Ware from Canberra, a little plug there for the replacement adapter. My name is Mark Matushka, I'm the Chair of the Business and Strategy Track and I'd like to welcome you to the very first session today. It'll be my honour over the next two days to introduce the Business and Strategy sessions to you and today we have a session entitled Applied Agile for Drupal Projects by Vessa Palmo. How's that? Close enough. Close enough, ok I'll work on it over the next couple of days. This session will be of great interest to everyone out there struggling with implementing agile project methodologies for their Drupal projects. And I'm particularly interested in personally, I warned him I was going to throw in a question here right at the beginning in the intro, how agile projects can be costed because that's irrelevant to a session a little later on today. Tricky question, I know and I saw a tweet regarding that. So I'd like to introduce to Vessa Palmo, he is CEO of one of Europe's largest Drupal organisations, Wunderkraut, which was formed last year with the merger of four smaller Drupal companies, Node 1, Crimson, Miera, which I'm sure pronounces incorrectly, and Wunderkraut, and they took on the name Wunderkraut. They operate in either nine or ten European countries and together make up one of the largest, if not the largest Drupal company development company in the world. Pretty close. You would have seen in the session guide that Vessa has significant experience managing hundreds of projects, hundreds of web projects, some of many of them Drupal have recently. A particular note is his mention of large project failures, along with hundreds of successes of course, which indicates to me that what we hear this morning is a lot of practical advice and down to earth information. So without further ado, I'd like to introduce Vessa Palmo. Please welcome him. Good morning everybody. So thank you for the introduction. So my name is Vessa Palmo, that's the proper way to pronounce it. It was pretty close. The name is Finnish, so I'm originally from Finland. Today I'm living in London though, but my accent, I tried to stick with the Finnish accent a bit to not to feel like to UK person. So on top of what was already said about me, I have quite a bit of experience in doing Agile both in the world of Drupal and before Drupal, outside of Drupal in different kind of software projects. I've also done a fair share of teaching Agile to different organizations and it's one part of my job today is to teach Agile to our customers. So basically everything that I'm talking about today, I've told the same stories to quite a few customers before, so I might get a bit, you know, get into the details easily here. My basic background is in computer sciences originally. I never went around to actually graduate from there, did my executive MBAs later and ended up basically running companies. So the typical story for the computer science students around the world. A few more words about Wunderkraut, so Wunder what? You might ask. We are a professional services company for web basically. So we do end-to-end services starting from developing business of our customers, especially media customers for example. And we end in doing hosting and support services and basically do everything in between including development and so on. About 150 people and we are today physically have offices in nine European countries as you can see on the map. We actually have operations in quite a few other countries in Europe as well, but, you know, it's difficult to do the math on where you are physically in Europe and where you are not sometimes. You might have heard about some of the companies that we merged that were mentioned there, Crimson, Node-1, Merra and Wunderkraut. So we merged four companies. So basically trees was this morning talking about we need bigger triple shops we deliver. So we do our best and we intend to keep on growing a bit because a lot of our customers are really big enterprises that are asking for global services. So we are trying to meet the need for global basically triple implementations and triple projects. We do exclusively triple as far as technologies go. So we sort of are a bit different from many of our bigger competitors, the so-called elephants there. Okay. I'm going to be talking about a few things today starting with why Agile, why it's a good idea. I'm going to do a bit of introduction to Agile, but this is sort of a basic session. So I have to ask a few questions about your experience level before knowing on how deeply I'm going to go into that. And then I'm going to have a look at some of the basic problems most companies I've worked with are having with Agile, especially vendors working with the customer projects. It's really common for them to have issues while trying to do Agile. And then I'm going to go and have a look at what have we done with Drupal and Agile. We have quite a few years been modifying Agile to meet the special requirements that Drupal have. So in order to understand how much should I actually explain about what Agile is and so on, I would first like to ask how many of you have some hands-on experience in working in Agile projects? About half. Okay. What about how many of you do projects for external customers? About the same number of people. How many of you actually purchase services from external sources? Not that many. Quite a typical Drupal crowd, I would say so far. What about is somebody running your own internal projects with Agile or otherwise running your own internal projects? Okay. So quite a diverse bunch of people, really. All right. I'll try to spend a bit of time on introducing Agile and then move on to the rest of the things. Hopefully people with plenty of Agile experience get something out of the first part of this. So let's start with why Agile is a great idea. I'm going to move into this by describing the problem first, because I'm a consultant, so what consultants do, you describe the problem first. So I know many of you have probably seen this before, but again, it's funny because it's so true. And if you've been in software projects, especially complicated software projects, you've seen it before. So basically, I'm not going to go through all of this, but this is what was actually needed. And here you go, like customer explaining it, analyst designing it, business consultant describing it, of course, billing, usually like this, support, and documentation, you know, most of all. So it's only funny because it happens in IT projects quite often. And this is one of the problems that Agile tries to meet or solve. So basically, this is your traditional, what I call personally designed first approach or waterfall, if you will. It's quite pretty in pictures, and that's about it. It's the same thing in real life. It's really nice if you can do the professional looking gun charts and draw all of the schedules for the project and plan out like two years ahead of time in detail. It looks perfect. Everybody loves it. Unfortunately, it sort of fails usually. So it's mostly pretty in pictures. Let me do an example of that. Let's move into something a bit, I would say easier for most people. I would imagine everybody knows what this is like a blueprint of a house. Everybody has been in a house, at least in this room, because we are in a house right now. So everybody knows the concept of a house. What we have here, I don't think everybody sees it, but this is a kitchen, plan for a kitchen. So basically, everybody has been in a kitchen. I would assume most of you have been cooking in a kitchen as well. So you have an idea like based on the blueprint that, well, here we have an oven here and we have some sort of like working area here and cabinets and whatnot. So you get an idea, well, this is your kitchen and then somebody goes and builds it. But do you actually know how the kitchen is going to feel? Is it going to be a great place to work at when you are preparing food? Can you actually see the oven when you are preparing some food here? Can you see if the oven that your food is burning already or not? Like small things, but they do make a huge difference on the actual experience. And this is something that everybody knows very, very well, like houses. I'm not claiming I can build houses, but I do know houses pretty intimately. So I would imagine I could design it perfectly. But when I in real life go into the house, I'm going to be a bit confused and I'm most likely to actually want to make some changes. If you move into a new house, this is what happens. It's like, well, the bathroom should be a bit bigger. What if we could just move the wall a bit? There we go. Now it's like half a meter bigger. Perfect. We can do it in software. At least we should be able to do it. And if we can't do it with houses, we can't create perfect houses out of the plan to meet our expectations. How could we do it with something much more complicated, like software? We don't know software that well because we are not living in software all day. Well, most of us, at least. So that's one of the reasons. This is your project. Any project, basically. Basically, start of the project. We have minimum knowledge as a team on what the project is going to be, what the difficulties will be, and so on. At the end of the project, we know as much about the project as we ever will within the lifespan of the project. At which point do we make the important decisions? It's like this. Let's say, here we do a project agreement at some point. Quite a lot of these things, if you write them down in agreement and this can be an internal agreement or external agreement with the vendor, you will actually fix most of the really important stuff at that point with the minimal knowledge available. So that's the point when you do the important stuff. Then you might have some design phase where you still can do the details. What should we do with this and that detail on a project? And then we fix it, basically. Just go and implement it. So you're not really learning anything because you can't change anything anymore. It's fixed. You know what you're doing. And then you do your launch and you start learning by realizing well, it's not working really. It's not doing what it's supposed to do. And the users are not reacting as we expected. So that's sort of the problem. Then we have some additional first world problems here. We have developers that are fairly well paid in Europe and in Australia and US. And how do we treat these guys if we do everything designed first? They are these guys at that point. It's like, you know, don't ask, just implement. You know what you're supposed to do. There's the plan, you know, just go and code it. So these guys, they are end users for the similar kind of products if you are building websites. So they can actually give a lot of input into it. They use the product when they are building it. So basically, they learn at the same time. So they could propose all sorts of changes to the product and so on, and they should. But if you design all of it, they really can't. So that's the thing. And getting back to my house example, if you have somebody who builds houses for living and if they build a house personally for themselves, do you think they're going to specify everything in detail before they start working on anything or do they actually just make it up or at least some of it while they're doing it? Which way do you think is going to end up being a better house? At least on my experience, some of my friends who do that for living, their houses tend to be amazing because they know exactly what they're doing. Okay, if I didn't get the point through, one more example. Let's say we have a customer that makes a definition like on requirements and they say, okay, I need to have some sort of transportation device. It has to transport at least 20 bags of rice at the time and it has to transport it for 10 kilometers within 15 minutes or something. And based on this, you would imagine to have some sort of van or whatever truck and then you ask vendors to put in offers and there's some vendors that are cheaper and some that are more expensive and you just go with the cheap one because you are still going to get what you asked for, right? Expectation is a truck. Well, that's what you actually get. It meets your requirements. Every requirement has been met. Your expectations, not so much. And the lifetime value, you know, it's going to be a pretty expensive piece of... Yeah, so, same thing with software. Meeting the actual expectation, not so easy always. So basically, the design first paradigm or method or whatever you want to call it, it works perfectly fine on a simple and small project mostly because when you do it the wrong way, you can redo it within days. So failing is cheap in that case. So I'm saying the waterfall, everything perfect when you're talking about the project of some thousands of dollars or euros. Not the problem at all. When you move into more complex projects, it starts failing. It starts failing in spectacular ways often and in very expensive ways as well. So if you have a business environment that changes all the time, it's going to be really, really quite difficult to try to actually meet any requirements because the requirements have already changed before you get there. And, well, it's always about contracts. It's like, what do you have in a contract? And that's one of my favorite topics is how to do contracts because if you have a long list of requirements thinking that you're going to be sick here when you list all of those requirements, they're actually going to be really good for the vendor and really horrible for the customer because of the car example. They just check off all the requirements and they're done. They're out of there. That's it. So expectations or business goals not met, requirements met. So basically we have a problem here. Not going into a lot of detail here, but it's a lot of guesses and pretty high-risk process model and so on. So what we came up with eventually, and as we, I talk about like software community in this case, is mostly agile, but there's been all sorts of agile projects even before this. Like if you look at some of the products that have been done using agile methodology, they include everything from like sending people to the space and building vacuum cleaners and doing some small websites and doing physical products. So all sorts of products have been done using agile. And funnily enough, like in about three weeks, I'm going to be teaching agile to one of our customers who wants to use it in their business. And their business is building bridge season highways. They want to use agile in that. So you can do it and you can do it in like any kind of business. Probably I would not go and do scrum in building a bridge, like deliverables at the end of each print. I don't go there, but you can use some sort of agile methodology at least and that's going to be really interesting. And personally, I find a lot of like enjoyment even on actually teaching different companies how to become agile. And my personal view on this is like in 10 to 20 years we have like two kinds of companies. We have the ones that are agile and the ones that are dead. So, you know, you can pick the bunch. Agile in a nutshell shortly. Three basic principles pretty much in any agile methodology. Always deliver something visible within like fixed intervals. Fixed intervals they can be hours, days, weeks, months depending on your business and what you do. Typically we're talking about a few weeks in case of software. Always start with the highest priority items. Never start with the details first and never start with the favorite ones. Always start the ones with create most value. And value can be different things for different organizations but there always is some value in the work we do. They should be at least. And improve the process. Never stop learning. So basically you should always try to learn from your own mistakes and your successes. For example, in Wunderkraut what we do like other companies have an employee of the month. What we do is we celebrate failure. So we actually reward people from actually bringing up their failures and how to make sure that why it happened and how to make sure nobody else does the same failure in the entire organization. So we try to reward it because if you fail fast and fail cheaply, it's going to be good for the organization. If you fail slowly, it's going to become expensive and that's going to kill companies and you know people are going to be really pissed off. And we actually send this stuff to our customers as well. Look, we failed on your project. Some of them are first like, what? Well, it's okay. And they even pay for all the work that we do while failing. And as a CEO, you know, it's sort of a fun thing because I get to do the most expensive failures. The ones I do, they can have like six figures in them. So, you know, developers failing, it's cheaper usually. Agile is not the new thing as such. It's been done for ages. Then Agile we know today started from software. But if you think about what NASA was doing when they put man into moon, it's not like they designed everything perfectly and just pressed the button and launched and there we go. They actually did a lot of like small iterations, trial and error and so on. So it's sort of a similar approach even though they didn't actually call it Agile. There's a thing called Pareto principle. If you want to know who this guy Pareto Bosco and look at the Wikipedia page for that. But basic idea here is you get 80% of the value in typically any project within 20% of the total effort. Meaning most of your efforts are going to be more or less wasted if you just look at the value generation. Perfect example when building a Drupal website. I think something like 70 to up to 90% of your time is spent on tweaking the details and doing the theming and making sure that the corners are round and there's drop shadows. Who the hell cares? Like if you look at the business case. There are cases where it's important. But in many cases that's going to be exactly the long tail here. Yeah, it adds some value. But you know considering the effort. Does it really? And if you start by the most valuable tasks and get the 20% out of the way. At this point it's not up to you to decide if I'm assuming like customer vendor relationship here. But it's not up to you as a vendor to decide if something gets done. It's up to the customer and it's up to the business value. So if the drop shadows and rounded corners actually makes the site tick, fine. But the customer knows the actual expense. So it's no longer just a requirement. It's actually something that has a price tag to it. It's like am I willing to pay 25,000 euros to get this all over the site? It makes doing projects a bit different at that point. So this is really, really important to keep in mind. Agile in general. There's a lot of different methodologies. I'm not going to go into these in detail. I just left a slide for these here. So if you want to Google a bit around and get to know some other agile methodologies than Scrum that is most widely used in software development, please do. Because many of these are really, really applicable what many of us do. Like Kanban for maintenance, for example. Lean for running a company. It's a perfectly good example on how to run an agile company as such. So it's a good idea to take a look at some of these. And we as a Drupal community, I'm sorry to say we haven't been really all that great in many of the agile things traditionally. Mostly because the testing of Drupal, like testament development, all of these practices, Drupal as a platform has not really been ideal to do that. Like traditionally, if you compare it to Java or Ruby on Rails or many of the other platforms. So many people in Drupal community don't know all of these as well as they should. And it's a good idea to educate people because we are not always the cutting edge in any of these things. We can also learn from outside of Drupal community. So agile manifesto. Basically, this is the starting point for Scrum. And it's also like foundation of many other agile methodologies. It's like individuals and interactions instead of having a really, really nicely defined process and so on. So basically you have people working with people. And I hope I could, you know, one of these days push this message through to the schools as well because I'm sure all of you have realized that they are next to no female developers in open source because they think, you know, you're working alone in like room with no windows and no sunlight and all night just coding with bits and code. That's not exactly true anymore because this is really, really working with people and it's about interactions and being face to face with your customers and your end users and like everybody. And, you know, I would hope to have some female developers to hire because we have next to none. We have some, not that many. Working software is more important than documentation. Don't take it overboard. Don't forget to do any documentation because that also happens but it's more important to deliver something that's like functional, that adds value than to document everything in detail because especially in case of True Pool sometimes writing documentation takes just as long time as implementing something. So you don't want to redo both of them when you do changes. Customer collaboration over contract negotiation this is really important thing as well because it's much easier to do agile internally in an organization. I go to all of these agile events quite often and when I speak to other people eight out of ten or nine out of ten from like organizations to agile internally not like vendor-customer relationship but their own teams and they are always amazed like how do you manage to sell agile like externally to anyone? Is it even possible? And I'm always saying like well it's not simple and it takes a lot of time but you manage to do it and you end up actually making bigger impact on the customer organization than just doing a project for them because if you do it well it can actually spread within the customer organization. And this is really, really if I look at their own markets for example in Finland or Sweden we can do a contract for like one million euro project like by doing an email only that's done. In Germany they would die out of heart attack if somebody would try to do that for like ten thousand euro project it's like what no contract, no we can't work so this is really, really a cultural thing and how much stuff do you have to have in your contracts and I've had a lot of fun battles with like internal legal teams and different organizations like what's a proper contract and what do you have to have in there and those discussions are always fun. Responding to change is more important than following a plan we can't plan perfectly we have to plan we can't just do stuff we still have to plan but we don't have to have a perfect plan in the beginning we can respond to the changes instead. This is the traditional iron triangle of projects so basically contents, resources and time and then basically in the middle what we would have is quality one of them is going to be flexible and if we hide the quality behind them quality is the one that is going to be flexible in the end because if you try to push for somebody to do a lot of work for free for not enough resources you know they have to find shortcuts somehow instead of sacrificing the quality make the contents flexible it's much better to be flexible on the actual scope than to be flexible in resources or time so that's the real trick there then we have just in time planning where instead of doing this this is the traditional model and the problem in this is what if we run out of budget like in here we have a few options we can stop it there whatever decide you know we failed the project that's that we can invest more money into the project and go over budget and never know what the end result is exactly going to be or so on or we can just cut it back in the coding phase and decide well we planned all of this but we can't implement all of it because we don't have money for it so we spend extra time on planning and analyzing and designing stuff we never even do so basically this is the simple way of doing it plan a bit don't go into any details and then do all the detail planning in phases always just analyze the most important bit first implement it make sure it's already run ready to be run and so on move to the next one so we still do all of these same phases it's not like we are removing stuff this is what ends up happening if we do it right so basically same chart that earlier today we still do decisions in these points but we do very few decisions before doing an agreement one of my favorite customers like a really really big global company we were discussing like what do you want to do with us like next year this was like last year and they said well yeah we have a budget of like 300,000 euros like beginning of the year so what do you want to do we don't know it we just have budget allocated because there's always going to be some need so just book some people and we'll figure it out that's the way to do it and we do really amazing things with these people for this reason we don't have to plan ahead so much we just book people and based on trust well a bit of design first and then the decisions we know more and more when we do the decisions typically we do some sort of pre-launch we can still change a lot of things and so on so it starts to look quite different when you do it like this the benefits the red line is agile and the black line is more traditional so visibility we know all the time whereas we think we know everything with traditional in the beginning then we don't see anything and in the end we hopefully know where we are going adaptability is pretty obvious business value we deliver stuff right away and less and less value generated this is like complete the opposite everything is delivered in the end hopefully and the risk same thing risk goes down all the time but goes down slower in the end so it's quite beneficial so that's the basics what about like why don't all of the organizations do agile and exclusively agile this is the basic image that is this is your agile and this is what I described and it's beautiful and it's like sexy and it's what not then real life well sort of it's flexible but it's not always making everything like cool and sexy and that's the first thing you still have to do all of your work a bit more fun and flexible but a lot of the same stuff is still there this is one of my favorites because it's also true agile draining let's say scrum for example if you do a certified scrum master certification basically for yourself it's gonna take like full two days and a bit of rereading so that's a huge effort you know you get a fancy title of certified scrum master our office dog is actually certified scrum master at least he's been taking part of like four or five scrum master courses by now so I think he has to be but it's very easy to learn the basics it takes a few days but actually to learn how to do a scrum for example as an organization it takes years so I would say like within six months or somewhere within two years well then you know something already because it's like a cultural shift it's changing of your mindset and how do you think things and so on so it takes a long time to turn an organization and if you try to do agile and if there's no support from like the top level management it's always gonna fail at some point because then it comes down to the trust and all that gonna get back to that so the basic reasons of failure I've seen and I would say based on some of the customers I've been talking with they say that something like eight or nine out of ten shops that approach them and tell them they are agile they are really not they just claim they do agile I've seen all of the big IT companies do it they just slap a agile sticker on top of what they're already doing put up some fancy marketing materials and they call it agile I'm not saying all of them do it and this is obviously some of them might be excellent in it but I've seen it way too many times that they only use it as a marketing thing it's not gonna solve anything so basically if you don't have the trust in place internally or externally that's gonna mean the agile is likely to fail if you have the lawyers everybody likes lawyers always but they can actually block agile if they enforce the contracts in a bad way that happens unfortunately quite often one of my personal favorite it's not like it's an intuitive thing to do because what do you do by default is you plan for something and then you do it if you have to let's say move relocate to a new apartment what do you do? You plan for it how to do it, okay, book somebody to do it what not and then actually implement it this is what we do but if you look at how children behave they don't plan they just do it's not the intuitive way to do things but naturally it should be but it's not the case well, not the topic for today but we could have a very long discussion about that one cultural things it's easy to fall back to the old ways for the reason it's not intuitive easy to go there customer vendor always lack of trust makes it fail quite easily and no training and no support so this is what it actually looks like when you do agile in the beginning and one of the reasons why quite a few companies fail is that they get all of these fancy online tools and software for doing agile no, you have computer scientists in room you know what you do you do paper based process because it actually works the best way of starting to do agile is do it physically in one room use physical paper, physical evidence what you are doing it makes it so much easier to get started with agile this is lacking always or not always but quite often you don't have face-to-face contact you have distributed teams you don't meet with your customer enough in an ideal situation the entire team would be in the same room all the time including the customer or if it's internal thing including the business owner again when you are getting started it's going to be really really difficult to actually do anything else so try to stay in same room this is crumb as I'm sure you are aware myself not so much but in here I think you've seen this quite a few times so there's only one ball and quite a few guys so might be there's some overhead sometimes in case of triple so that might actually cause some agile projects to fail I'm going to get back to that in a minute so what's crumb requires and this is actually true to a lot of other agile but since most of us doing triple projects do them using scrum I'm talking only about crumb here development team has to stay the same if it keeps on changing you can't really learn it's really really difficult if it's always a new bunch of people team the same it requires trust I've said it like 10 times but I have to say it over and over again because that's I think the most common way of failing agile and content has to be optimized just in time meaning you don't fix the contents ahead of time you optimize it when needed and you have to re-prioritize and re-prioritize things all the time because you learn more some more things testing demonstration and feedback in every sprint or whatever your iterations are called and you have the total cost of ownership thinking not meaning if you save a bit of money here is it going to come back and invite you in the backside at the later point when you do like administration for the next three years so whatever the lifespan of the product is going to be and not saving the wrong places and well and product success has to be defined in general if you don't know what the success looks like it's quite difficult to actually succeed so you have to know the actual business goals surprisingly this is not always completely clear we talked a lot of customers and sometimes when you really ask them difficult questions on like what your business goals for this are they don't always know it in detail so it's like okay it's fine that you don't know any of the details but we have to know what we are aiming for here or define it at least it will fail if if the team can't solve the problems meaning if they don't have the authority to do so or the skills or whatever you need to solve the problems so the problems have to be solvable one way or another limited experience and this is especially true when talking about customer vendor kind of thing if the customer hasn't done Agile before and the vendor hasn't done Agile before it's not really a good starting point if you are in that kind of situation hire somebody with experience that's practically the only way of actually getting started with it if you have a vendor with a lot of experience or even a customer with a lot of experience it's going to be a lot easier because then somebody knows what's going on so at least somebody has to know it and the commitment issues is let's say it's a startup and customer doesn't know what to do next week they always change priorities completely and this happens in small startups a lot and Drupal is not really great at this either so if you can't commit for something like few months or so this is what we are going for it is going to be really difficult so Agile works but if it's a complete chaos it's going to continue to be complete chaos even if you use Agile and last but not least if you plan everything perfectly that's a sure way to fail with with Agile there's a bit of about project against product but I think I covered most of these so I'm just going to move into Drupal bit so what do we do with Drupal this is Captain Drupal by the way if you haven't seen him before he's one of our dear friends that appears in some conferences sometimes and there's all sorts of funny things we also do have a life size like this big Drupal icon with like man in it all sorts of stuff so a few words about Drupal basically if you think about what we used to do is we used to have only like frameworks that we used to build software and code it and this is where Agile was quite working really well because it's all coding then we ended up having some CMS products that were basically out of the box products that fulfilled your need or not but it was at least out of the box completely functional and we ended up having something in between I'm calling them here we are actually calling Drupal these days content management framework instead of CMS because it's a really crappy CMS you can build a CMS out of it but if you look at it like out of the box it's not really you know calling it a CMS it's sort of confusing so we decided to call it content management framework and this is sort of the differentiation there's a lot of stuff behind it but I'm not going to go there in detail so so basically this is where we are in like grand scheme of things and this this sort of has an impact on what we can do with Agile this is one of the primary things that actually makes a big difference what we have in Drupal is features are cheap and details are expensive you spend most of your time working on details because all of the features you know there's a module for that so at least in theory you get really complex functional Drupal site built in a day and then you really start working so that's the big thing makes estimation quite difficult and funnily enough with Drupal what you do is you start with the working product and you spend the development project breaking it so this happens in most projects it's sort of completely the opposite like okay let's deliver something of value like at the end of each spring meaning we broke views on this spring yeah some value this makes it a bit difficult because the way Drupal has been built and it's it's not really optimal for Agile always so but Drupal you know there's still coding required almost always not quite but in big professional cases at least always and we have to live with Drupal today so I'm talking about like typical programming projects for a while here so if you look at typical Drupal projects they tend to be rather small they are not like 2 year projects with like 20 person team working on them full time they are quite a bit smaller and for example Scrum was originally designed for teams of 7 to 9 people working together for like years doesn't happen in that many Drupal projects there are Drupal projects out there that do it but they are really the exception not the rule so we have tiny short projects high velocity we do stuff too quickly our biggest problem is that the product owner who's responsible on how to prioritize things and how to accept if something is done or not they can't keep up we are delivering stuff too quickly and we have to slow down so almost always when a customer comes and says can you deliver this within this time frame it's like yes we can but you can't and then we cut back the team and make it smaller and make it on a level that the customer can also sustain and add some consulting and so on so it's sort of a funny problem to have but it's absolutely a problem if you consider agile Drupal compared to other platforms Drupal is missing in action often there's no real standards on how to document Drupal site like the entire Drupal site there are some but we should have like a proper standard for it so at least internally it's a good idea to have some way of documenting Drupal Drupal estimation is a funny topic because in software when you misestimate something your estimate can be off by say 20% in Drupal it's off like 100 because you know you estimate it there's a module for it I'm going to use it and then you use it for like a week and realize it's complete crap and you have to rewrite it or there's like core issue that you have to really fix before you can actually use what you are supposed to do so your estimates when they are off they are really off so quite a bit more difficult than in traditional and yeah test coverage and continuous integration you can do all of it in Drupal but it's going to cost you more than the actual Drupal project in most cases again it's sort of a happy problem it's a problem of Drupal being so efficient to do that testing becomes more expensive than the actual project it's sort of happy problem but it's a problem where the customer sees like well how come the testing is like twice as expensive as the project sometimes that's the case well how do we fix this okay I'm going to try to leave a bit of yeah okay so I'm going to leave a bit of time for questions then so basically prototype driven development is the first thing we have a working product use it use the product out of the box see what you already have and start with that then you can start changing things and you can start giving options to the business owner you can say well we can do this in like 20 minutes and that's going to be 85% of your requirements are going to be done or we can spend like two weeks on it and then 100% is going to be done which one do you want to pay for it becomes a business decision it's no longer like this is the Drupal way of doing it it's a business decision it's like one of what makes sense in this case sometimes spending two weeks is a good idea sometimes 20 minutes is enough depends on what your business is alright moving on so this is the same basic model here where the important bit is build something first out of the box within minutes or within hours don't spend a lot of time on it because you are likely to modify it anyway have a look at the new works the business is it going to fulfill the business goals have a look at the technical implementation part create options options A, B, C if possible and basically implement it reiterate when needed so this is the same thing that I actually just said so basically we can have number of options and this happens a lot in Drupal projects you always have more than one way of doing stuff so let's have a look at flexible Scrum a bit so basically there's a few basic parts here and in order to leave a bit of time for questions I'm going to skip some of them but discovery this is your basic design of your project it's not actually designing anything it's like discovering most of the things listed here so create some sort of backlog do a bit of project planning because if you have to do integrations for example and if there's a lot of different parties involved you have to do some sort of timetables for them when do we expect this integration to be done if there's two parties and so on quality assurance and steering group kickoff so on but remember to stay on a high level and all of those one week sprints instead of two or three week we used to do three week sprints cut it down to two weeks and realize that's working better for Drupal then we cut it back to one week and realize that's working even better for most of the project at least this has to do with the high base of the project it's easier to cut it down in like every week and do really short reviews and planning and so on it just seems to work better not always but in most project this seems to be the case and small team few roles a typical team on doing a let's say 100,000 euro Drupal project a typical team would be I would say five people including the business owner from the customer side so they are tiny really really tiny as software teams and that works perfectly it's easier to split Drupal projects to multiple teams than to build a big Drupal team working around one project at least in my experience limited testing perhaps I'm not saying this is the way to go this is the unfortunate side effect of Drupal pricing meaning Drupal is so efficient that testing looks expensive and it depends if you have a disposable small project just trust on out of the box Drupal security and trust that the developers know what they're doing and skip on the security reviews not exactly a best practice sometimes you have to do it same goes for like scalability testing and so on if you have a long project that is going to be ongoing years different thing this is what we do to remove partially remove the bottleneck of product owner we add business consultants we add senior people who understand the business of the customer who can help them to prioritize and basically do a lot of like leg work for the customer so we basically not exactly double the bandwidth of the product owner but like 0.5 times or something like that bandwidth it helps quite a bit quality assurance this is another topic that we could spend like an hour on so basically remember to have business level quality assurance meaning a steering group in my mind quality assurance is not about technical quality assurance that's like one part of it like the business assurance making sure we do the right things that's the most important bit and the next important thing is like the like end to end is the user experience there is everything there the technical bit is actually surprisingly simple rest of it this is a bit more complicated often and yeah if you want to do agile contracting create a contract that says that the steering group can change basically anything within the contract and the steering group you know has to everybody has to agree it's no voting our steering groups typically have four people in them like basically the product owner from the customer side scrum master from outside and then we have like their bosses basically so if we have to add budget to the project or whatever we can do it in any steering group right away that makes it flexible also even if the contract is something we can do binding decisions on the spot right away and actually quite often that also do so I think I left like five minutes for questions as well okay so the question was what about basically what's the definition of dance or how do you get a sign up from the customer when some story is done basically when you're defining the story you should first of all have a definition of done that's always there like it's being tested and what not like the basics and then you have the actual definition of done of this story like if it's a checkout form for e-commerce site when it does these things then it's gonna be done and that's always done together together so basically customer agrees on definition of done but it's like everybody's working together on those yeah so if you have like a perfectionist there who wants to add everything on top of it yeah you have those people but that's why you have like planning poker and what not so you can do the same sort of principle on these like okay how many points do we need for this story and then the perfectionist is like there and everybody else is there so so basically he has to come down a more reasonable level and we have to remove some of the points of definition of done yeah well when you're doing the planning you should do that what was the follow up I already forgot the billing yeah well that's a long topic we typically build on sprint today I would like to yeah yeah no no it's billing is let's not go there it's a really long topic and we have only a few minutes it's agile billing we should do another session on that yeah so that's the question was about how do you when you have poor documentation you are not prioritizing that and you are handing the project off when it's done to some support team that is going to support it I don't think there's like a one silver bullet kind of answer for that one way of doing it is having the same team to actually support it as well we've tried it it works it has some problems a lot of benefits as well if it's like an ongoing project a lot of stuff is happening all the time it's really good if it's like really a site that is like one of it's done it's done and nothing is happening then obviously it's not a good model other ways is standardizing your like triple stack basically using the same bits for all of this what we've done with no stream for example we've also done that that also has a lot of problems and you know third way is having some sort of hand of procedures where you ensure certain documents are in place and so on I don't think there's we haven't at least found like one way of doing triple like development versus support and maintenance yeah so what do you do if you end the sprint where you have stories that are undone the stories will end up back to the backlog and they're gonna get re-prioritized and re-evaluate it as well so sometimes what happens is they're gonna end up like way down into the backlog because if we realized it's gonna be really an expensive story and the business value is not as great what we do in steering groups is we evaluate all the like epic stories like the really really big whale of a story that we have a look at the estimated business value and the estimated effort and we try to pick the ones that are like in a sweet spot like okay they might be really low on on the effort and then it's gonna be easy to do them even if they don't have that much value or they much be huge on business value in which case we can invest more work into them so it's like comes down to evaluating your stories basically yeah that's where the failing comes in if the customer goes and you know you just spend a week on doing something if it's for technical reasons then you have to come up with good reason or good excuse why that happened but usually there's a really good reason and quite often it's like also out of your hands because we don't really offer like warranty for third party modules as such so we don't go saying like any issue about you ever have in your project we are gonna fix it for free so you're about to grab this not literally but figuratively grab them afterwards anyway most expensive what were the most expensive or most common mistakes most common must be that the developers want to do stuff the triple way meaning spending three weeks instead of three minutes or something that has to be the most common it is good for like developing triple and moving it forward but it's not really great for customer project always most expensive ones I think they are like entirely outside of the realm of triple most expensive ones are probably like picking bad customers and not firing the customers in time we've managed to fire one customer three times and sometimes they always manage to come back to the organization and we always have to fire them again in a while and that gets expensive at some point we do fire customers yeah you should do it because sometimes you end up with bad customers so customers should fire us if they suck and the other way around as well so just on behalf of all of you fantastic and obviously you've got a lot more information than we had time for I'm sorry about the technical heat just to start with but Vesta will be around today and tomorrow sorry to dive in so please get hold of them if you have extra questions and please thank Vesta Palomo thank you