 Welcome. I'm fairly honored to be in the stage. I've been on some Drupalcon stages earlier. Perhaps some people have seen me in Prague singing the opera at the pre-node. Maybe some people have seen me unproposed to my boyfriend and Amsterdam last year. And actually, I'm more nervous right now at the last couple of times I was on a Drupalcon stage. I'm a first-time speaker. So I'm very happy that I have an audience to tell you something more about large scale agile and Drupal development. So this is what was on the, this is the subject, how to hurt a flock of product owners. And I talked to some people already prior to this talk about that it's also sort of like how to make an elephant dance the cha-cha. We started out, I started out doing some projects for some small NGOs and some small companies who needed something more than just a digital flyer. And it grew and it grew and it grew. And my customers became bigger and bigger and bigger. And sometimes you work for customers with a million budget and 3,000 employees. And well, it feels like making an elephant dance the cha-cha-cha sometimes. So that's why I wanted to talk about these problems and challenges that you face when you work with large clients. A little bit about myself. No nick needed to get the frequently asked questions started already. Yes, I do like beer. You can't really read it, but on the t-shirt Ruben is wearing there, it says, calm down and get the beers in. It really is my last name. And no, I will not marry you or anybody else for that matter. There are 1,559 beers in the Netherlands. So if you really want to marry one, just go there and find one. Probably somewhere above the area of Amsterdam. You will find a lot of people called beers actually. And I would love to get my hands on the t-shirt. Ruben, have you found it yet? You lost it in Prague, right? Yeah, I found it. You found it? Yeah. OK, if someone can get me one of these, I really would appreciate it. OK, I'll pick you. Awesome. Who am I? Why this presentation? I told you something already about this because I think a lot of Drupal shops around Europe and the world cope with the same kind of challenges when meeting with larger companies. So oh, small commercial break. Thank you to my employer, Sennetig, which makes sure I could get on the stage here today. So thank you, Rene Rizziers. Thank you, Rene. So this was made possible by them. OK, a little bit more about myself than just my surname. I've been active in open source for about 13 years now. I started out at a small company doing open source CRM, open source voice-over IP using Asterix and also open source CMSs, home broom. But it takes a while before you get smarter than that. I've been a Drupalista for about five years now. You can find me on Drupal.org, Nancy Beers. And I've been a product owner for two years. I started out Waterfall, he brings two stuff like that. And then I saw the light and became Scrum Master and a Scrum Product Owner. So I'm fairly new, actually, to the whole product owner thing. I'm working at Sennetig. And I'm loving Skits in Drupal, London. So that's about four years now. And next to that, my biggest passion or even, yeah, I love Skits and Handball more than Drupal, I'm sorry. I'm a Handball player and referee and the biggest fact about the refereeing is that I revered the Dutch championships last summer. So I'm pretty proud of that. Sorry? You can count. Great. I'm not a programmer, but I'm a storyteller. So let me take you away to a little story called Scrumtopia. A long, long time ago in a kingdom far, far away, there was a little town called Scrumtopia. There were a lot of villages there, like the Customer Village, the Scrum Master Village, and the Developer Village. In the, oh, I'm sorry, I wanted to scroll. In the Customer Village, there were customers with limitless budgets. The only thing they needed to be happy was working software in short sprints so they could adjust what they wanted at any given time. They simply loved change and changes and change some more and think out of the box and stepping out of their comfort zone. The customers knew exactly what they wanted and their leader, the product owner, had the ultimate mandate and overview of all their wishes to communicate it with the Developer Village. CPI prioritized, knew all the processes, did it again? Sorry. CPI prioritized, knew all the processes within the Village, handled politics very well, and was always available to the developers, which was great, since the developers were always working on one project at a time, all week. Once a project was finished, they simply started a new one because the product and the sprint back loss block was perfectly managed by the product owner. Every once in a while, two Princess came down, peddling the nearby waterfall to tell the developers, sorry, to tell the developers to write extensive reports for the change advisory board, which is or the great CFO wizard up the mountain. We need more paper, they demanded. It or it's off with your heads. Luckily, the Scrum Masters from Scrum Master Town came to their aid and told the Prince two Princess to bugger off and stop wasting the developer's valuable time and resources. Every time you want an extra report, the waste pile grows and it grows bigger and the trees will die and we are less productive, the Scrum Master said. Please, let us be working in peace and deliver products. The Princess came to their senses, started the buff session on the Village Square and told everybody how they had come to understand that making reports can be just a way of window dressing instead of being completely transparent on what's going on in the project. In a nearby forest, there also lived two giants. One was called Fix Scope, who seems to be as mythical as unicorns or the monster of Loch Ness, by the way. Next to Fix Scope, there was another giant called Fixed Budget. They were friendly giants when you meet them. The developers lived in harmony with them and when they were encountering them, they just followed their rules and they'd be okay. For instance, when Fix Scope came along, who doesn't really exist? When Fix Scope came along, the developers started building, using modules from the Drupal Tree of Wisdom so they could meet the requirements needed to keep the giant happy. Some other times, encountering Fixed Budget, they kept a keen eye on the business value, they offered building their software so the giant would acquire the most for his golden coins. On a dark, windy night, Fix Scope and Fixed Budget met and went to the developers together. You can imagine what a horrible sight that must have been. The developers all got worn out by having to build more within the Fixed Budget's limits because somehow, Fix Scope wasn't so fixed at all. Now he knew they would charge him not any more money anyways. The developer asked for the aid of the Scrum Masters, but they weren't empowered to change anything about the giants. So they moved on and asked the product owners for help. Together, they waited until the giants were asleep, carried them into a forest and with a big fence, they made sure they were never able to bug the developers together again. Everything just worked perfectly well in this little software building kingdom and everyone lived happily ever after, simply living by a simple set of rules. I call this a fairy tale for a reason. I think most of you, can I have a show of hands who are familiar with the Airtel Manifesto? Why, basically, a lot of you, the biggest part of it. I love this, I really, really love this and I would really want this to work all the time everywhere. But as I laid out in the little fairy tale, I just told you, we don't live in a perfect world. So sometimes you do have a fixed budget and a fixed scope and sometimes they do want to have prints to excessive reports. So, I've got a bunch of tips to break the fairy tale down a bit. This is my first tip. Know the stakeholders and culture and use an Airtel approach to keep it that way, actually. Know the customer village. Know who they are, know where they live, know what they love. Ask questions. I'm blissfully living in Holland and the Dutch are known to be fairly blunt and honest and that helps a lot, actually. So the first question I always ask when at a kickoff with customers is what problem are we solving for you building this application? And ask it all of the stakeholders. Ask all of them because there might be someone sabotaging. There might be someone who's not that keen of change. There might be someone who is very keen of change and you will really help him or her to solve the problems they encounter. Also, by asking these questions at your stakeholders, you can also figure out the culture of a company. A good question to ask to find out whether a company is agile or not or has some agility is, how long did it take you to start this project? I have had customers who have been working for five years to start a new project. You know they won't be agile. But some companies are like, oh yeah, we just made a plan and three months later we asked you to build it and then you're fairly sure that the whole scrum methodology will work. Knowing the stakeholders is a continuous project. You do have to check them during every sprint because stakeholders change. Not only in person, but also they change their minds about the project and how it's going. So keep on checking on your stakeholders what their view is of your project, of what you're building. Make sure the team also understands the stakeholders and the client. What I usually do, I draw it on a board, I draw a couple of hats, just hats or some with curls and I keep track of how the stakeholders are feeling about the project by scribbling pluses or minuses on the board so everyone can visually see, it's visualized how the stakeholders are feeling about your project. And it changes through time, so keep on challenging that. Also, I got some examples, for instance, about culture, cultural stuff. I've been working for the Ministry of Finance in the Netherlands and it took them two years to start a new project and it was a type of three migration to Drupal. And one of the stakeholders was the type of three content manager. I hear some, you know, for sure that in this case she wasn't happy with this change because she loved typo. She was, but in typo three, it does, maker, what I did was making her the new queen of Drupal. So I call her every day, how is it going? Do you have some questions? Can I help you? Can I please are there some things you miss about Drupal? Can we find a module for you to make it closer to typo three? So that actually turned out to work great because she came a Drupal ambassador within the company and that's a way to keep on challenging your stakeholders and keeping them enthusiastic about the project. The wrong thing we did there was a fixed budget migration. Never do that. Don't ever. I have to look at what I tell because my boss in the audience but this was at a former company that helps. Another good example of what I encountered was I thought I knew all the stakeholders I thought I had them all and I was fairly certain my backlog was okay, my sprint backlog was okay and okay, we're going to build this. So we had the first sprint, we had the second sprint, we had the third sprint and then I went to the demo and a colleague of mine, I always let the developers demo of course and I type out what happens in the demo. And then a woman came barging in 15 minutes late or 15 minutes late, all sweaty and yeah, I'm sorry it wasn't a meeting and she sat down and I said okay, well welcome, who are you? Sprint three, I'm the project manager. I'm sorry, come again. I'm the project manager. So I gave the demo and then afterwards she said, well this is wrong and this is wrong and this is wrong and this is wrong and this is wrong and I said well, I'm sorry to be blunt but I'm Dutch like that. Why are you arriving here at the end of sprint three? And she was like, well I'm just project managing stuff. So other people are doing this for me, right? Yeah but you weren't here for the last couple of months to make this project so it's an example to stress out even more, know your stakeholders. It happens. I also have some good examples about the culture part. We work for a company that makes seeds, vegetable seeds and now it's not the big bad company from America but a tiny, cute Dutch one which does biological, organic and good stuff. They have 15 companies around the world, 15 organizations and they are innovative in core. They have been around for 100 years just innovating seeds, make it better, making better cabbage, making better broccoli and they are very agile in the core because they have machinery that is very blinking and new and just the latest of the latest technologies but they also have an old sort of seed shaking thing standing there in a corner which is about 50 years old but it works so don't fix it because it works. And they look at innovation like that, we just okay, they're so lean, where can we make things better? Where can we make small changes and keep on plan, do, act, check and make this better so they understand how agile work from the core from like 100 years ago. That helps a lot when you're at the table building their new website because they understand that change doesn't come in a split second and that sometimes you fail at things and sometimes innovation, you cannot innovate without failure and so I was there sitting down with a product owner. We wanted to make a link with the product database and we had thought out the whole plan, how to do it and what was the best technical solution to do that and later as we found out the third company, third party software worked differently than we had assumed and the customers I see department had assumed. So we were like okay, now we have to start over again or at least change this view of how to find a solution for this problem so that'll take us time. Okay, so the project owner says that's too bad because now I won't have as much icing on the cake at the end of my website than I used to have because my budget is getting smaller and I was like yes, you get it and that's exactly how it works. We need more time here so you won't have enough budgets left over at the end of the project for new spiffy thingies. So there are companies who actually understand how this works but it takes a while. Then a big problem is more than one PO is basically what my subtitle of my presentation is, how to heard a flock of product owners. In big companies there never is one person, the one product owner who knows all the business processes, who knows, who has all the mandate about the budgets, who knows everything. It's basically about a little bit like the giant fixed scope. I don't think they exist. That's fairly dangerous standpoint because a lot of people say there must be a product owner. I don't think in a bigger company that they exist. But maybe they do because when you work with a product owner team, we're building a website for a big city in the north of Holland and they have two product owners which I actually kind of like in this case because one product owner is from the IST department and one product owner is from the customer side department and they work together to make the backlog. So you have the business and the technical department combined together in a PO team. So I said, okay, this will work out fine. But at the first meeting kickoff on how to just to make some appointments about who's calling who, when, where and when, sure day off because product owners tend to work part time somehow. I was like, okay, so you want a multi-lingual thing, right? Yes, the IST guy, yes, we want a multi-lingual thing and we want to have it in Drupal because Drupal's created that and we would like to have that build in Drupal. Okay, so the customer-facing guy was like, oh no, no, no, no, no, no. We're not gonna do that because in our current website which is the Drupal 6 site, we have a little tool called LiveWords and we can translate on the fly. So if someone goes to our website, clicks on the link to go to the English part of the site, it will just translate on the fly through a third-party component and it works just perfectly fine for us. But it's expensive. So I had a problem there because there were two product owners telling me something different and I was glad that it happened at an early stage because at that point I could say, fine, so you both think someone else, who's going to tell me who's right? And in came the project manager. Hi, I'm going to tell you who's right. Fine, then you're the product owner now because you're the one who's telling me what to do. So these guys are the stakeholders now and you're the product owner. And he was like, oh, okay, because project managers are lazy by standard. So he was, hmm, I don't know if I liked that role. No, but he just took it. So live with it. But I also worked for an NGO a while ago and they had basically not really a product owner. There were a lot of stakeholders but they were worrying about sick children and not about websites. And they knew a lot about sick children and how to make them happy and that's what they did all day. And yeah, of course we need a website because we need sponsors and we need it, but we don't know what we need. And they were completely blindfolded about who's going to be the product owner. We don't know. And I think at that point with customers like that, it's the best way to find a product owner on the supplier side and put them in the company. You must have trust for that. That's because the customer must trust you not to make choices based on the idea to make more money. Well, it's an NGO. You must be a real bastard to screw them over. But you have to have a lot of trust but sometimes it's just the best way to have a product owner on the supplier side, I guess. Okay. Did I forget anything? Oh yeah, I checked with a lot of my peers before I made this presentation. And one of the things I heard and I think it's a very good point that a good product owner needs about a year to grow into his role. The problem is that projects are not that long, most of the time, but it's good to know that it takes a good year to become a good product owner. So maybe that is also why it's a good idea to have them on the supplier side because they got trained to do it. Okay. I'm gonna say another dangerous thing now for the Scrum lovers, under you. Prince II can't be all bad. It has been working for ages. So you could try and embed some old systems things. I know there are a lot of purists around who were like, no, what are you telling? But I think it might be a good plan, especially to have, for instance, I make sprint reports. That's so not Scrum, that's so waste, but the sprint reports I make are about five pages, so it's not extensive reports. And it says, when the sprint was what we delivered, if there are known defects, I know in Scrum there are no known defects, but in the real world there are known defects and also a report of the demo. That's not really waste because I type the report while being in the demo. So actually I have the report ready. The only thing that's missing is hours, an hour report and the sprint demo report. So I type them when I'm at the demo. And it helps me a lot, actually, especially when you have large projects like 10 to 20 sprints to look back at one of the sprint reports. I thought we talked about this earlier that you can just go back to the reports and find, okay, we made the choice on that particular time a couple of months ago. Why did we do that? What was the discussion about? So you have some legacy you can fall back on just to check why you made the choices you made. So I think that's a good idea. One thing that every large customer has is changed advisory board. And I know it's kind of prissy, but I think it's kind of needed to cope with the politics within an organization because it helps, because people can have their say in a sort of official way because we're changed advisory board and we can say something about it. And that helps to bring the scrumming is my point of view. And another great tip I got is when you have a risk log, visualize it. I heard of a former colleague of mine who had this risk log plotted on a radar. So they had a big radar screen on the wall with impediments, a pint on them and other risks within the company. And when the impediments grew or got bigger or got more problematic, they moved it to the center of the big radar. So everyone could see in just one overview, okay, these are the risks and this is how big they are. And I really liked it. I think I'm going to use that. So a free tip. This also helps a lot to have an ambassador at the clients. Also have that from a colleague of mine which might not be the PO by the way, but you want to have someone within the company who has lunches with the CEO at that corporate level who explains agile and the agile way of working. You need an ambassador. If you don't have it, it's very, very hard to keep explaining it and it takes a lot of effort to explain everything to the whole team within the company. And especially if the CEO is like, but there's my report and when is it ready and can you deliver me a planning and because I have to allocate budget, it can be quite hard to bring the whole scrum thing in. So have someone to talk to upper management and to make them understand what agility means. Okay, I think it's not only project management. I think it's change management because if you want a customer to be really agile and really work with you and really have the bonding and really have all the big issues within the agile manifesto, the whole company has to change. And this is a big thing. This is not just, okay, we're building a website and we're doing it with scrum. Now you have to change the whole mindset of a company. And that's hard. And that's maybe sometimes even, I think some clients just won't change. And it's not a very happy ending of this fairytale, but I think some companies will work for air traffic controllers in the Netherlands. They are so strict and so strict for a reason, of course. That is very hard to bring in the whole scrum thing. And maybe then it's just not the best way to go. And maybe you just have to let them be or say, okay, maybe we're not a company to build a website for you. Which brings me to the, I don't know if you know it, the manifesto for half-assed agile software development. This is basically what happens if the clients won't move. You can find it online. It's not for me, but I would just take a sip of water. It really made me laugh, yeah. My sheets will be online. So if you want to read it later, that's fine. Sometimes it just won't work. Okay. So my recap. Know the stakeholders and the culture of your clients. No, no, no them and keep, this is not, this is an ongoing process. It's not standing still. You have to have an ongoing process to know your stakeholders, know your villagers. Work with the PO team and then define the real one that could be at the customer side or at the supplier side. Embed old systems, at least that's what I do. Have an ambassador at the client at the highest level in the organization. I think HL development isn't project management, it's change management. And some clients just won't change. Well, that was basically my talk. I'm gonna do some aftermaths. Sprints are on Fridays. Please do so. Because we need it. All of you get Drupal 8 out of the door. I'll do my part. And this is a picture of Drupal Camp, Spain, in Geres de la Frontera. I really, really, really, really love the Spanish Drupal community. I'm standing over here in case you missed it. And they asked me if I could promote their next Drupal camp in 2016 in Granada. So I especially wore the Granada t-shirts if you want to know anything about Drupal, Spain camps, I can tell you because I've been there. And please go, go, go to Granada. These are my contacts. I also do geocaching, so I'm hanging in the tree sometimes. So if you want to reach out for me, you can use this contact information. And I'd like to thank you for your attention. And have a good talk. I don't know if there are any questions. Yeah, or I will repeat it for you, that's fine too. Do you have any tips or tricks for us? You are there with a team of product owners. They all have their ones, I believe. How do you make them change, how do you make them tell them what the business value is? So how do you make them prioritize? That's the question. Okay, well, you can do a couple of things. Once you have your backlog ready, and you can size them with your team, so give them story points. That doesn't say too much. What it says is how long will it take to build. And then you can say, okay, can the website go live without this feature or not? And based on that, you score them. So you give them an extra score between 100 and 3,000 or something. And then you can just say, okay, so you really want your Twitter feed on your website? Please don't. But you really want your Twitter? Can we go live without it? Yes, we can go live without it. Fine, I will give it 10 points. And when it takes 50 story points to build and it's a 10 points business value, and I have another user story which has, it takes 10 story points to build, and it has 2,000 business value because it's the contact form, then you can prioritize like that with the scoring. But how do you make them agree on the value? Or they don't? The business, because you are making the business value. The idea is that they are making the business value, right? One feature has 10 story points to build, the other one 20. The one product owner wants really hard that one feature, but the nine others don't. So what value will you give it in your backlog? Do you give it 100 points? What I've heard is what you can do is let them pitch for their own value. So you have 10 product owners, they all do their pitch. I want this feature because I think my site needs a Twitter feed. After that, you will make a swarm thing, let them put all the 10 user stories on a board and let them swarm around giving priorities on the, and it will level out itself. That's also a practice I used to, when I have 10 product owners to prioritize. Okay, thank you. Okay, you're welcome. Any other questions? Okay, well, you can reach me anytime, so, oh, sorry. I thought you were leaving, I'm sorry. Come on. Go ahead, go ahead. Okay, what do you do when you have somebody that goes on sick leave or something happen? It's like how you do change management or this kind of stuff, use tools to document or? That are two questions, right? Okay, let's start with the first one. Let's start with the first. What do you do when someone goes on sick leave? Well, actually we're having the problem right now. One of the customers, the main product owner is on a long leave at the moment. Yeah, it's a bit of an open door, but find a new one. And you have to, and you have to make them, otherwise, I'm sorry, but we really need someone who can tell us what to do, otherwise we have to stop the project right now. And maybe you just have to say it like that. Okay, we're going to stop now and start later on. In another project we're doing, we're also missing some information to start a new sprint, and we're like, okay, fine. Then we just won't start the sprint right now. And that basically helps to motivate people to find someone else to do it, because the deadline also goes further away in time, of course, yeah. And your second question was, I'm sorry. Yeah, how do you do the change management? So do you use tools for documenting when you just? No, we use as much as needed. And it depends on the clients, how much, how excessive you document things. For instance, the seed supplier I was talking about, they're okay if you just have a three-page report about the things you've walked through in a conversation, but we also have a customer who wants their sprints officially, how do you say it, accepted by all of the stakeholders. So they have a real big form with all names on it and they all have to give their checkboxes. It depends a lot about, it depends on the customer. How excessive you do that. Yeah, it depends. Sometimes they have their own tools or sometimes you just suggest something, they don't like it and then you just change it. Yeah, right. Thank you and congratulations for the talk. Thank you. I have a question, it might be quite a silly question and maybe a lot of you will be able to answer. So you said that you can get, say lots of product owners to do a swarm and let them fight for what's more valuable and what should be done first. Yeah, basically do all the bitching. But I've noticed a lot of times what happens is that they do the bitching, then someone agrees, okay, fine, yeah, yeah, your stuff can go first, whatever. And the next thing you do is what happens is that they will walk away off the meeting and then next day they'll come to you specifically and be like, yeah, no, I think my stuff needs to be done because of that and none of other product owners are there whilst they're talking to you. How do you handle that? Because do you say, okay, let's go have another meeting? Because that means I'm spending basically every time dragging them into a meeting to fight and still have to handle them all the time? Waste, yeah. This sounds a lot like the famous OC layer eight politics. Um, you have to find the one product owner, basically, I think. I'm not quite sure. I've never been in this situation exactly, so. Yeah, it's more like. Maybe there's someone else in the room that has a better answer than I do, but. Well, if anyone does, I'm just there, so. Let me know. Thank you. Thank you. Anyone else because I'm up for a beer now. Yes, go ahead. Well, I kind of know that situation, so what you have, I'm gonna lower it. I'm only 160. And the problem was even worse. There were three or some product owners and they had all different view. They agreed in the meeting and afterwards they all separately went to a higher level to escalate it and then you had this higher level coming in. You couldn't make them product owner because they don't have time to be product owner. The only way is go to that higher level and say and ask who will be the product owner. And they have to escalate it yourself, basically. Going up and asking them who will have the last word and who will you believe? And the only thing you can do. You can't solve it on your level. You have to solve it on higher. I'm afraid. Sounds good. Yeah. Yeah, thanks. Okay. Well, I'll be in here for a couple of more days. So if you want to have beer with me or ask me any questions, please feel free to address me. Thank you very much.