 So, let's start. Welcome everybody, hope you all had well-earned coffee and are ready for the last day of DrupalCon. What we're gonna try here is a bit something new that we've never tried before in a DrupalCon and we're gonna see, so you're all part of an experiment, yay. What we're trying to do is, like Reddit-style AMA, or ask me anything, so for people who know we're just gonna do the same thing in real life. So, what we felt as one, I'm one of the content team members and we discussed about okay, we wanna have project management in or we wanna talk about more beside of the code, how do we do things? How do we run companies? How do we do a lot of things? And we feel a bit that there is not a lot of discussion going around how to organize a team, how to structure, how to handle specific situations and we felt okay, instead of just doing buffs where we talk about that, let's try to do an ask session. So, this should be it and we're gonna try how this works. So, basically, it's about we found some really great minds that are sitting over there really far away from me and they all have rather bigger Drupal shops in Europe and what we felt is a lot of smaller ones or other ones, they wanna know how you do things. Everybody wants to grow, everybody wants to try out new things, like which tools are you using and that's your chance to ask these people without haunting them down at their booths to ask them and the idea is really that it should be a discussion about how do we do things. So, if you have an additional question, raise your hand or walk up to the microphone, I can also repeat questions so there's no more walking around all the time and stuff like that. So, I'm Michael or people call me Schnitzel but more and more important are the three answers people that we have and I would like them to introduce themselves shortly who they are, who they work for and just a little bit about their company. All right, so me first. Hi, my name's Mike King. I'm the project manager with Anatec. We're based in Ireland. We're a reasonably small team of 10. So, for an agency point of view, we're agile, definitely. We focus quite a lot on the charity and public sector. From Amazing Labs based out of Zurich. I'm a project manager and we are a team of around 20 people in Zurich all over and I would say project management is a bit larger, defined at Amazing Labs so I'm helping in pictures. I'm doing business analysis for the client and handling the project. Good morning, I'm Steve Parks. I'm from Wunderkraut or Wunder as we know in the UK. We're in the beanbag business. So that's where our focus is comfy seating around Drupal Cons for all. But when we're not doing that, we run large scale projects, agile of course, methodology, scrum generally. Sometimes Kanban on particular areas and mostly Drupal. Cool, so does anybody already have a question to our people? Okay, no, that's perfectly fine, we're gonna come. And so I have one and what I would like to know is how much do you actually explain your clients about Drupal as a community? So for us talking about what we do for the community, is that maybe the question what we do in the community? I think more it's about, do you even explain them about the open source part, about the community that all these people exist? Yes, so I think first it's very important to explain the open source idea and the advantages of open source and the idea behind it, it's still not in everyone's head. And we strongly believe it's a selling point and it works really fine. And when I know this, it's also really important to talk about what you do in the community. And a lot of our clients really ask for that actively, say, hey, can you please prove what you do for the community? And as we are very involved, it helps us a lot. And I think also we get a lot of leads out of people that know us from the community. They know our names and they know our Drupal names. It's like, oh, I know this schnitzel work is working for amazing lab. So who is that? Can I meet this person? So yes, definitely talking about the community and talking about how Drupal works is very important. Thank you. Go for it, Steve. We actually include it from the very beginning in proposals. It depends, of course, whether that's appropriate but most of the time when it's a Drupal project, we're including in our proposals at the very beginning an explanation of the community are part in that and why that's a benefit for the client. And then we try and actively get them involved in the community. So we actually have clients here at DrupalCon but we also involve them in DrupalCamps and other events that are going on. But also trying to encourage their team members if they have internal teams to contribute as well and to either release some of the code back to community or to work on core issues and so on like that. So, yeah, we try and encourage, we educate and encourage a lot of community involvement. Thank you. As I'm going last, I can mainly reiterate what the others have said but I can also add that we identify specifically to all of our clients that we're coming to DrupalCon that as a business, we see this as a really important thing. So from a community perspective, yes, we absolutely encourage everybody to come and also promote that to our clients. Obviously, it means for a bit of an odd support system for a week but people seem to understand and they appreciate that. So, also I wanted to add something like thumbs up bringing your clients to a DrupalCon. So it's great team building event and last year I presented together with a client and we had great parties together and of course it helps. How does it help to make the client happy? Cool, does anybody has a, or maybe a question to the room, who of you thinks about the same? So do you all present or explain your clients what the Drupal community is or is there maybe somebody that says, okay, we didn't try that yet? Okay, maybe it's way too early for you but. Okay, one of the next question is how do you charge then that? So do you actually, let's say you work on a module and it has a patch that is broken and you fix it and is it then part of the bill or do you exclude that from actually charging to the client because he says, well, I'm not paying for the box that somebody else built and now you're fixing it. How do you, how do you handle maybe the discussions around that? Okay. Or do they don't even exist maybe? I think it's sometimes the discussions exist, sometimes people are made aware of that. It depends on their knowledge and their desire to be involved in that process. So if they're aware of modules and they're aware of the whole Drupal infrastructure, then maybe they will be aware that there are bugs and we tell them that there's a bug in a module and that we'll be fixing it and it will be fed back to the community. But a bit like Steve said, we include this in our responses and our tenders that code will go back if it's appropriate to do so. So I suppose it's being inclusive but sometimes people don't mind or don't care whether or not it happens but it's only appropriate code that will ever get pushed back. One of the things that's worth pointing out in discussions with client is that if they don't want to pay for that kind of work then perhaps they should just have a proprietary CMS with a license and full account for a million pounds a year. They're getting Drupal for free and a part of the price of that is some level of contribution to it and being part of that community. So there's a bit of an education process there around look at what you're getting and this is what you have to give for that and look really in the scheme of things how cheap that is. Yeah, for us sometimes we find solutions like 50-50 like sometimes we have the feeling it's harder for us to charge for really everything we do and sometimes we try really to go the extra mile. Like even if the client says or even if it would be really easy to do it only for the client we'd go the extra mile and do it for the client and then release it as a patch. So we actually actively approach the client and say to him or her, look we have this problem and if you would be ready to contribute to the community it would be great and we could find maybe an agreement. So we're not that maybe not that far as you are. We do also have sorry just the community time we have members of staff each week have community time so that also goes back and obviously isn't chargeable to the clients. Yeah but it's one of the things I think this is an interesting discussion because it's how do we make Drupal businesses sustainable and how do we make them grow and it's in the client's best interest that those two things happen. The clients do not want a situation where they hire a Drupal agency and it goes bust after a year. They don't want the situation either where the people running the Drupal agency are so crazily busy running around like mad doing crazy busy work rather than a focused clear plan and so therefore that's in their interests and it's also in the Drupal businesses interests and therefore it's really important that work that is done for the client is built for in my view and that includes part of the community work because if that's for their project and they need that but it can also be shared back to the community that's still for their project and you know what your clients build for everything they do. You know if your client is a big washing powder manufacturer or something then you go into the supermarket and say well actually if I buy that washing powder I don't really want to pay for that bit because it's the same as the other washing hands and you can't just say that they will charge you for that box of washing powder. So client businesses understand this and that's their language so we have to charge what we do. So the way we charge is I'm talking about the UK office mainly here around the Wondercraft Group we experiment in different ways each office has a lot of freedom to experiment with ways of working and the UK are approaches that we build for sprints and we say that these people are in the sprint for a certain period of time and therefore the cost of a sprint is this. Now within that time there is stuff that is directly on the project but there's also stuff that benefits the project but is for the community and that's still important for the success of the project so that does get built for me. Actually that maybe leads to the next question. Do you have a question in the audience? Oh, yes. Yay, thank you. So to repeat the question for the recording so how do you do the time logging and also if an employee or a developer works on a patch not specifically to the client that how this is time locked and how this is presented to the client at the end? I think there are two aspects to it like one is like how it is handled internally and how it is handled with the client. So what I would like to talk about from a basic point of view is how we handle it internally. So people in our company they are allowed to do community work as much as they would like but they have to do one half in their free time and one half in their work time. So if you would like to work on a two hour or a half a day community work you can do that two hours in your work time and two hours in your free time and we introduced this because it was for us really hard to get a system that works for everyone because we don't want to force people to do community work but we want to to a certain extent support those who do community work. And then additionally to what you do for the community you get contribution points which is a system that allows you to gather points to be able to go to conferences. And so if you gather a certain amount of points then you can go, you have a conference day. So because we don't only want people to go to conferences and not contribute back I think it's for us important that those who participate can contribute. So this is for the internal part. Well speaking again mainly for the UK office but it's an idea that's gradually spread it. Well every office has the principle we like to operate on the basis of transparency. Transparency is a really important thing for us. So in the same way of saying if we do some work we bill it and if it's something else we don't but one of the things is if it's general community work that gets done on Fridays. We have a concept Wunder Fridays across a number of our offices that's gradually spreading. And so the idea is that Monday to Thursday we do client billable work and we keep our focus there. Fridays that's where we do the work on improving the business on our community work and so on and professional development. So that means you've got real clarity Monday to Thursday that is billable work for the client. And we operate rather than time reporting in the UK office we operate on the basis of booked time. So the client when you're setting up the project you're booking people for a certain number of sprints working a certain number of ways Monday to Thursday and that's for a period of time. So they're then booked and that's the basis on which the billing is done. So we try and lift some of that burden of time reporting because again that's a context switching thing and we try and reduce that. So if you're very clear that Monday to Thursday is work that's focused on the client and Friday is work on the community that lifts a lot of that reporting burden that can otherwise be a bit of a pain. And it also gives you a kind of clear focus of when everyone can get together to work on a community issue. So we have a lot of core developers in the company and they can get together at a certain time and do kind of you know mini sprints on issues and managing the issue queues and so on. So people like Lewis Nyman and so on put a lot of time in on their Wunder Fridays and we find that's a system that works well and it's transparent. The client knows Monday to Thursday they have us, Friday they don't. Okay, I'll probably take it back and be a bit simpler on my response which is if the work is directly to do with a module used within a project then it's probably logged as part of the project. If it's not, if it's something that people are doing during their community time then it will be logged as community time. How do you handle the community time? Like how much do you allow your employees to do or how is it organized? Yeah, we normally allow, it's around 20%. Okay, okay. Is your question answered? Okay, we have a question. Hi, yeah, so my question is if, I've got a very small organization. There's only four of us. So we don't have like an isolated development team. So everyone kind of does get interrupted and does deal with clients and stuff. But, and I have read like the, is it the Agile Manifesto where it's like, you know, you have to do all of it. But I was just sort of wondering for a team like us that might wanna start adopting some of those principles without being able to do the whole thing what would be the bits that you would suggest that we focus on and how should we do that? The first thing is that concept that you have to do all of it. Agile rather than a religion is a toolbox. And you don't, you know, you take the tools that are useful to you and that work for you. Now it does work best. You know, they've all been proven to work many, many times on many large successful projects. And it works really well to use more. But it works also to gradually get that. So don't feel that you have to jump in and change everything 100%. Start experimenting and doing bits and build up and prove to the stakeholders in the organization, this is making a difference and this is working. So the things that I would adopt first in doing that, number one is visible communication. Use the walls, put things up, have everybody see stuff. Things like the scrum board, things like that where people can really see what's going on. And the other thing is in rather than requirements as they were traditionally listed, where it is, you know, install search module and then you've got the must Moscow prioritization and everything's an M, of course. And project managers have special keyboard that they take out, client project managers and it's only got the M key for doing Moscow prioritization. And so rather than doing that, start focusing on using that user story approach. And so you're really focusing on the who, you know, as a who, I want to what and the really key bit is so that and the why. So I want, as a I want to so that is the structure of user stories. And the why bit is the really key bit and that's not captured in most requirements documents. Really understanding that user need and treating that as a placeholder for conversation and have that as part of the visible communication. Have them on the wall, stand around the wall, talk about them and see them move across the board. That's where I would stand. I would like to add something to this. We're going also through a HL transformation, I would say. And I totally confirm what Steve says. Don't do everything at once, start small. And to identify what you focus on. It's very important just not to do agile because of the sake of agile. Ask yourself what your goal is. What you would like to improve on your process. And based off of your goal, you define which measures you would like to take. I think this is also important to get all your staff on board. Like otherwise they feel like the project manager or whoever is experimenting with their team and changing things all the time and no one knows anymore what should be done, how and why. So defining goals and getting the buying of your team is really important if you start this transformation. I think I'm probably only, again, speaking last, I'll say the same things in a different way. But in the same way that it's a bit of a misunderstanding that Prince II was never meant to be completely implemented on every project. You were supposed to take the bits that you needed. It's the same with the agile manifesto. Well, it is and it isn't. But the reality is that you can, as Steve has suggested, start with user stories. You could start with a stand-up daily, just to get the communication in the team going. You know, a lot of teams would have only one meeting a week, let's say. As soon as you start to get people talking amongst themselves for 15 minutes each day, you get a better flow of information and people know what's going on. Not necessarily just with each other, but within the business and there's a better awareness. And even without a scrum or an agile aspect, that's really important. So that would be my suggestion. Thank you. Yeah, can you walk to the mic as you're close? And now Mike has to answer first. I would like to add to that, to use also iterations that you work in iterations and you present to the client on a regular basis during the project. You will learn so much from what they actually want more than what they said in the beginning that they want. So use iterations. Yeah, the constant communication, it works with the client as well as within your team. Yeah, that's really important. Any more questions? Yes. So how do you implement UX and especially big projects? Like how do you incorporate that into the project workflow? And how do you do them within sprinting iterations? I think we talk about cards, we talk about user stories. If they are the only thing that's there for a requirement, then the requirement isn't enough. So there's no reason why you can't have a wireframe for a requirement, a process flow for a requirement, ideas about UX for a requirement. So I think sometimes people explain the idea of a card maybe as being a mini project. And if it's an isolated atomic piece of work, then it can be. But sometimes there's an easy way to write cards which have to rely on other cards. And then all of a sudden you don't have those atomic pieces of work. So if you keep it atomic, you can apply the UX to that card itself. So you keep going with design, you keep going with UX, you keep going with the whole process throughout the sprint and the whole project. I think it's important that it's almost never too early to start testing and test often and do it in a really simple way. We had amazing what we have as a process is that we do testing several times within the project and one test is just taking a day of work. So we really invite clients, we do it remotely so that we reach easily people to test and we test them on prototypes, really rough prototypes and we find out what is not right and we do maybe another iteration and retest. So I think the continuous testing is very important and don't do it too late. You don't have to have designs, finish designs to do testing. It's already too expensive to check it. And also we apply the concept of the export review. So the one, the person doing the wireframe, this person will always go to another expert in that field and get that prototype challenged. So this is also a very easy way to get immediate feedback on what you do and yeah, do that mutually. It makes people learn from each other. I would be kidding if I said there was a perfect way of doing this at the moment. It's a big discussion within the UX professionals trade and within our company we have a team that's got together with representatives from each of our offices that are working on adopting and experimenting with different ways of working and trying to find better ways of working all the time. The key words though are that it's got to be about dialogue throughout the process. So there's always been this traditional thing of and even within agile there's still a temptation for organizations to be asking for more design first approach. And it is this thing of as my two colleagues here have been saying is embedding it throughout the process and stories being the story cards involving the elements of the UX, the development and so on. So everybody has some contribution to make to all of those stories. And also with all of those stories there should be the really clear question all the time what is the real user need for this? Have we actually got evidence? Is there an actual user need? Has a user really asked for this? And would they ever? And where is the data coming from for that? So that that's then a start for conversation and okay well if we've got no evidence there how do we get some? What's the cheapest way of testing that and getting some feedback, getting some data points? And then we can make a decision to make more investment. So it's keeping it as a conversation as a dialogue throughout the process with everyone involved and focusing all the time on the user need and it's all too easy to say we're doing UX but not involving real users all the time. So as Dagmar was mentioning, testing all the time as often as possible, research. We've done projects where people will just sketch something out on a pad and go out into the street and chat to people about it in the street and just get instant feedback there. So just whatever you can, the cheapest way of getting some kind of real user feedback is really important in that process and then embedding it in everything throughout the project. Can I just ask, just to start briefly, that when you talk about UX, make sure you also include in your thinking accessibility because they're not distinct things. It should be an inclusive thing. Thank you. What I'd like to add is like, UX starts at the very beginning of your project. So a lot of times the client comes with fixed requirements, right? Happens to all of us. And important is going a step backwards, asking the client what is your goal and then going into creating personas and creating customer journeys and to truly understand how the potential user will interact with the website. And you will, a lot of the times, you feel find out things you didn't know or all of the team that has written the requirements didn't know before. And in this process, we oftentimes include salespeople or people from support because requirements are often written by marketing or by the technical department and they have assumptions. But these assumptions are sometimes not proved and including sales and support in this process will open a lot more discussions. He was first. Maybe you wanna walk around, it's actually easier on the microphone. Yeah. Thank you. Hi. So how long are you... Can you come and be closer to the microphone? Sorry. Yes, thank you. How long are you usually sprints in your companies? Also, how are you planning the sprint? I mean, like when you are doing the sprint planning, sprint planning, sprint grooming, sprint demo, yeah. So I think it was the question, how long are sprints? Yeah. Yeah, okay. Normally two weeks, pretty much always two weeks just because then it's predictable. I know some people change the length of the sprints but I'm a simple man so it kind of makes it easier for me. But as for planning the sprints, we would normally plan as we should as close to the start of the sprint as possible. And that would include maybe a few days before a backlog grooming process. So you normally have a Monday, Wednesday, Friday cycle for meetings that might be to do with particular sprints. So you'd have a retrospective on the Monday, grooming on the Wednesday, planning on the Friday, start the sprint on the Monday retrospective of maybe every two weeks. Yeah, totally agree. We do it the same way. Something I would like to highlight is the demo with the client. We have recently changed from including all the team into the demos, like all the technical teams and this has been to be very excellent. Like bringing clients and developers together is a great thing. Clients appreciate that their technical questions are answered right away. And our engineers like to feel how the client feels. Like to feel if it's good, what they delivered or if it needs improvements. And it improved a lot of our team dynamics. First of all, I would echo that. Having the whole team there in a sprint demo is vitally important because there's valuable feedback to be gained there. But there is also that reward for their work. They've worked damn hard in that sprint. And to see the client go, wow, that's done already. That's fantastic. So it's really important that they get that kind of direct feedback from the client. Don't have a project manager in between the team and the client. The project manager is just facilitating the communications and supporting the communications that happen directly between the team and the client. So in terms of the direct question, the length of sprints, that's always got to be up to the team to decide. And each team when they're starting the project may decide on a particular sprint length. I would say we generally have two week sprints which for when we have the one to Fridays that's eight days in a sprint. But some offices and some projects sometimes decide to have one week sprints. Certainly because the velocity of development that you can achieve with Drupal is actually really high. I mean, if you think what you get with the core and some modules and so on, some contrary, then you're very quickly getting functionality implemented and you want a fast feedback loop on that. So as quickly as possible you want to demo that to the client and get some feedback. So some projects adopt one week sprints where functionality is simple enough that the speed is so great to get that regular feedback loop. But the team can decide and in retrospective they may decide they want to change the sprint length. But it generally gets set at the beginning of the project and then stays the same. Thank you. And one additional question. It's about quality assurance, actually testing. Do you allocate time for regression testing during the sprint? Because yeah, we know QA is involved to test the backlog task during the sprint. But what about the functionalities that are in the past sprints and then can be broken? Because new functionalities. That's a first to me. Go for it. I'll happily pick a smile first. So the question was about QA and testing and how's that integrated within the sprints? The first thing is these days a modern development workflow automated testing very, very important. And so that's a key part of the process. But also we adopt a peer review approach. So with every commit, then you get a colleague to review it before merging it in and that process is really important. That constant peer review and the testing that happens as part of that process. But otherwise, a really comprehensive automated testing approach is a very valuable part. But then you'll also have it part of the role of the project manager many times to do the kind of the dumb user testing. Because often developers are too clever and they know what to do. And you sometimes need a dumb user to come in and go, well, what happens if I click here or there? And that's the more in the browser type testing rather than the regression testing which you may have automated, which is, you have an automated check that if, can I still log in? Can I still check out or whatever the functionality is? Nothing to add. Okay, yeah, I would only add that we include that in our definition of dumb. So when you're estimating a card you're always including the fact that you've got to have QA done on that work. It's not necessarily the full regression that you're including every time. But as Steve points out, automated testing you should get green lights across the code anyway. Thank you very much. Keeping up with tradition I'm gonna ask two questions again. Can you go closer to the microphone? I said keeping with the tradition I'm gonna ask two questions again. First is how many of your projects are in agile methodology? Because we've seen a hundred percent. Number two is at what point of time do you bring in a developer along with the UX guy because there has to be a word line. So how many projects do we do in an agile way? All our projects are agile. I would just say that some are more advanced than others. We are in a phase of transformation in this case. What is still a challenge for us is to include maintenance work into our sprints. So because in the past lines it really liked us to bring in work and we did it immediately. And if you do scrum, you have sprints and you plan in advance and you just don't put things in there just now and say it's someone go, go for it. So this process is still a challenge for us I have to say. And maybe someone of you has an idea but this is in terms of agile. And the second question was again... The developer getting in along with the usability guy and what point of time do you bring in? Okay, so we have our UX person here and they sit in the same room and important is that they talk before where you started because you have to validate the estimation. Was the prototype too complicated for what time we have allocated? Is it possible to do? So they speak on a regular basis and they have to understand each other to a certain extent. Again, we only do agile projects. So I think it's roughly about 200 a year that we do across the group and they're all agile projects. The next question kind of comes back to the earlier question about the integrating UX in the process and the key is that the proper agile team should have the talents that it needs within the team and collaborating completely together. So UX is not a separate part of the process that a brief gets sent to them, they do their bit and then they hand it over to Dev. They should be working closely together. Now they can be a distributed team but they are working as one and the same communications, the same meetings, they're taking part in the same sprint planning, same demos, everything is about that collaboration between a team that contains all the talents necessary to deliver the project. So they're completely involved together throughout. Okay, I think, I don't have too much more to add but yeah, all of our projects are agile after a fashion which sometimes means that we work in an agile way internally and not necessarily with the client in that way. So the client might see the calm swan swimming across the lake and we're pedaling away underneath in agile. So yeah, there are some smoke and mirrors sometimes and that's the honest truth. When the devs get involved as soon as possible but the reality is that they probably get involved around the first iteration of wireframes. So it'll be a case of talking the devs through making sure, they've already got all the documentation they've been involved in the meetings anyway but it's making sure that they can verify that A achievable and B can be done within budget. Thank you. Hi, I mainly work as a freelancer or a contractor and I often sense that when I'm contacting web agencies web agencies about work and I tell them that I do work remotely, I often get that sort of face that tells me to get out of there. So how do you manage that and if you don't manage people working remotely, why not? And how do you sell it to the client? Do you even have to explain it to the client that your people are working remotely and how are the clients affect to that? How do they react on this? Okay, I'll step in here. Hi Tommy, by the way. We're pretty upfront about the fact that we're distributed and people, there is some issue with acceptance in some cases where people would expect you to have an office or whatever but people are okay with it. As long as you're there at meetings and you're contactable, then you're okay. So I think we benefit from being distributed in that way. And so that was the answer to your second part, your question. So to answer the first part, we only work distributed so therefore it wouldn't be an issue at all. I wouldn't say we are distributed. We have a great office in Zurich and people love to come to the office and work from there. But it doesn't mean that you have to be there all the time. So people can work from home if they like and people can work at least three weeks in a year in one of our other offices in Austin on Cape Town. So there is a lot of, we are all virtual. There is no physical boards around. But still I think for us it's a good point to be not distributed. So a lot of times client come by our office and work from there. We encourage them to do so because we like them to be there when they enter their content for the first time. Because nothing more annoying than having to open 10 JIRA issues and you didn't manage to get your content in. You have to open a JIRA ticket and wait for hours until it's fixed. So better just walk over a developer, ask the question and get it solved. So working with a client in our office is for us a point and then the social aspect. We do, we go running over lunch, we go out for beers, we just are there. We see how people feel, we are there for them. So for us being in our office is more choice than an obligation and it works well for us. We have been experimenting with distributed working. So our entire UK team works in a distributed way. There is no London physical office. We all work in a distributed way. And it's an idea that we're starting to experiment with elsewhere as well. It's worked very well for us and it's worked very well for clients. We actually get clients saying sometimes that they have a better quality of communications with us than they do with their colleagues in the same building in their company. And you know, because within these organizations you end up with silos and or you've just got people in this big open plan office and they're just sort of zoned out focusing on their screen and checking Facebook or whatever. And so we actually, you know, because we put the effort in because we're distributed, there is a better quality of communication because you're focusing on what communication do we need to do. Part of that is having an open chat channel with the whole team and the client team all in one chat channel. And they're just constantly throughout the day little bits of updates and information. That's one of the information radiators. The other thing is, you know, sharing project management tool and everybody having access to that and having that report into the chat channel as well using the Hubot bot is a fantastic thing and connecting up GitHub and Jenkins and everything else. So everyone can see the commits, they can see the states of builds, they can see everything and a client doesn't need to know how to log in somewhere else to do that to just go straight into chat. And then having those sort of set meetings whether it's the daily stand up or the sprint demo and so on and having those very clearly planned and even ad hoc communications. We have a thing that was just, we just know as a tea break hangout where a member of the team will say, we're British. A member of the team will say, I really fancy a cup of tea. Does anyone else fancy a cup of tea? I'll go, yes. Okay, five minutes, let's have a hangout. And we'll just have a chat and have a cup of tea on a Google hangout. It's weird, but we're English and we like it. I love you. Tommy likes tea. First of all, thank you for mentioning the distributed teams topic because everybody else in the conference talked about remote teams and I think that's not the same. And the second thing I wanted to ask is actually, there was a talk earlier about testing and finding things that you didn't thought of before, the testing that are missing in the project. So if you miss something in the discovery phase and any other phases prior to testing, how do you go back to the clients and say, okay, you are missing a whole feature or whatever. So what is the point that makes you to go back to the clients and not cover that yourself? So how do you handle that, actually? You're missing a whole feature. I don't know, so something that's... Something's gone wrong. Yeah, exactly, exactly, exactly. I suppose let's say you have, you've missed something. The clients missed something, they haven't told you something. The answer to when do you go back is as soon as possible. And that immediate communication is paramount. And you squeeze it into the next sprint. You do something that's got to give. This is the classic why you use agile answer. You've got a list of 10 things that have got to be done. You've now got a list of 11. If you've only got enough budget to complete 10 of them, which one is the least important? It's kind of a short, pithy answer, but hopefully it will be the right one. I agree. Yeah, definitely communication as soon as possible. So say, for example, you've found out that perhaps they haven't, you know, someone was off sick and they haven't mentioned the right thing in discovery and this thing is really needed. And it comes up at a meeting about, you know, well, aren't you going to put the magic button in or whatever else it is? And it comes up as a request. And yes, it is that unique prioritization that's really important. We explained very early on, in fact, let me just go back a step. When we start a project with a client, if they don't have what we believe to be really solid agile experience, we give them a two day training course in agile for all of their key team and stakeholders. And then we do trickle downs for other people in the organization. We do an hour session for everyone that will be around the project vaguely. So they know what we're talking about when we say a user story and they know the format for it and they know why that's key and they know what this big board on the wall means. So that's a key thing. And so therefore, we help them write this new user story and we talk about it and then we help them figure out the prioritization and we explain that there is no such thing as magic time. There is none. So it's this thing as well, that you've got a backlog and you believe you can get this far down the backlog within a certain amount of time. So it is, where does this go in that stack and what else gets latched out? And that is exactly the right, I would agree with that, the right way to approach it. So Agile is actually your safety net. Exactly. And you can take the stakeholder that's raised this up to the wall and show them all the cards and say where would you put this new one? Where would that go? And they have to be part of that discussion, that conversation about prioritization. And you use the word safety net there or the phrase safety net. I think that may be the wrong way to look at it. And if you turn that around to say this is the solution to change management. Change, the only thing that we know that will happen is that requirements are incorrect and there will be change. So therefore Agile allows us to continue with that change and adapt to that change throughout the process. So rather than being the thing that we have to fall back on as the safety net, it is the thing that we're using through the project all the way. Thank you. I would echo that. Change is good. Yeah. Hey, I have a question about teams. Probably I know something how it's done in Wunderkraut but it would be interesting to hear from others as well. How you decide who is going to be in the team for a particular project? Like which they and AMAZ Labs has also more than one continent. So do you split teams between Europe and US or how you decide on these things? Of course, availability is like most probably number one but like skills primary and previous experience or? So there's a geographical and the expertise level, I would say. So on the geographical level, it is best that the office deals with the clients at that location. At least this is the case right now. So Austin has their own clients. Zurich has their clients and Cape Town as well. We could imagine to extend this model so that Zurich gets supported by other locations. Especially this case is really interesting because the rates abroad are lower than they are in Switzerland. So this is a case we will maybe build up in future. And then it is really nice to have this relocation and they can also help each other out. Like our two offices outside of Zurich are really small still. So if they have a big project to get started to grow, they need our support. They need the Zurich support. Otherwise they can never do really cool projects. They will stay with that little project they could do as a three people team basically. So the idea is that what we practice is that they get support from Zurich to handle their big project so that they can grow. Then on an expertise level, this is the other thing. So they are site building and they are steaming and they are back end. There are a lot of different things in Drupal and this is a challenge because people are in one thing very, very good maybe. But then you don't have to accept people for the two parallel projects. If you have too much of a specialization you will blocking each other. So you have to go away that is kind of combining the two. Like giving people a specialty. I strongly believe that specialty is something important. It motivates people to be really good in something. But at the same time they have to have something else they can do as well. They have to understand the cross functional work they do because as a site building you have to prepare for theming and you have to understand how that works. So that's why we try to keep a balance between expertise and this really scrum way of doing everyone can do everything. I would say that my favorite type of developer would be a generalist with a favorite specialism. But they're very rare. I think the answer to your question which is from my point of view, I would love that it's based on skill but it's mainly based on availability then skill. I want to add more to that. I know you already know this, but for everyone else I'll just mention briefly how we do this. We have 170 people across nine countries and we're more and more trying to get cross country teams, you know, multi-country teams because that encourages knowledge sharing, it encourages, it allows us to pick from a much wider pool of talent on each project. So within 170 people you have people with real specialisms in certain areas and we take on fairly large, fairly complex projects that often can have real business critical projects to our clients and so we therefore want to have people with that deep specialism. I like the phrase you used about sort of the generalist with a specialism as well and we kind of refer to this as T-shaped people. They've got a broad knowledge which is the top bar of the T and then they've got a deep knowledge which is their specialism and you want to build up a large number of those around the company and then be able to use them to their best scale all of the time but they know how they fit into the right place in the organization generally because they understand a broad range of things too. So having 170 people means that we can pick fairly widely. Working in a distributed way means we can pick fairly widely as well and it means that we don't arrogantly assume that the best people in the world for this project are the ones that happen to be sitting within arms reach within the office. We can find them anywhere they are and recruit them and bring them onto our projects. So that's a key thing. Scheduling is always difficult, really difficult because there are so many projects in place, so many moving parts, projects will get extended which is always a nice thing when clients go, hey, this is great, we want to do more on this. That's a good thing or projects will sometimes get delayed because large organizations can move quite slowly at times and so you've got all these projects moving around and we're figuring out at the moment what the best way of doing that is at the moment like most agencies we have this big unwieldy spreadsheet. There's got to be a better way. So we're looking at that at the moment and then yeah, the project manager, the consultant that's been putting together that project then looks around the group and talks to people about what the project is and whether they'd be a good fit for it and bring this together that team. We're about to do an experiment with the next projects coming up where the consultant will pitch the project internally to a wide audience and then team members will select themselves onto the project managing their own schedule. That's just an experiment for one bit of the company but it could be interesting and we're going to see what results that have. Okay, thanks. Do we have still time? No, sorry, no, we are over time. Yes, that was already an hour. Wow. Thanks for all of you for the questions. I think they were really important and really interesting ones and we definitely cannot fix everything in an hour because then we definitely would have fixed other things as well. But I really thank you. If you liked that, please go to the Drupal Con Barcelona website. There is an evaluate tab or a button and write in. If you like it, if you didn't like it, also write it in because it's definitely something that we want to know from the content team if you like these type of sessions and stuff. Yes, Steve. One thing I've mentioned as well is part of our policy of complete openness and transparency. We publish all our ways of working on something called the Wunder Way. So it's way.wunder, W-U-N-D-E-R, .io. And it contains all our ways of managing projects and we're doing a sales process. It's basically our intranet, but it's public. So feel free to go there and borrow materials. Cool, thank you.