 Hi. Thanks for coming. Welcome to my talk, Lean Web Operations Planning for the Unpredictable. I'm Johan. I'm the founder and CEO, which in my case probably means chief everything officer of Friestil IT, a team of managed hosting experts based in Ireland and Germany. And actually this Sunday our hosting platform Friestil Box is going to be five years old. Happy birthday to us. However, in these five years, if I'm completely honest and this talk will be pretty honest, we haven't come as far as we should have, at least from my perspective. And the reason for that is not that we are a small bootstrapped business with constrained resources. The reason is that we didn't use these resources effectively. And in my talk I'm going to tell you about the things we've learned over the last 12 months and how we turned the ship around from course to complete burnout to productivity. But first, let me take a minute for a quick aside. We speakers live off your feedback. And in order to incentivize this a bit, I've brought this comic book, which I give away to the author of a random tweet about this talk that I'll select after the talk. So if you have any questions or feedback, tweet it to my handle, that is jeevis. And you might have this book later. Who needs project management? If you are a project manager, please don't be offended by the answer I gave myself every time when I asked myself this over recent years. So it turns out, boy, I was totally wrong. And I thought that project management was only for bigger teams and our whole company is only six people. Each of which I picked myself and I wouldn't hire someone who needs to be told what to do, would I? We are all professionals and adults, so everyone should know what to do. And anyway, we are working in an agile way where we can course correct regularly. And it's not as if we had much of a choice because we are doing web operations, not web development. And web operations, well, there's no use in planning anyway, or is there? If you ask a web operations engineer what they do, you might get a description that resembles the job description of a pastry chef. The infrastructure they create is delicate and inspired, like a souffle. They create it with well-honed skills, the finest open source ingredients, and surgical attention to detail. The reality is that web operations is more like dodgeball. Boy, do we envy the software developers among you. You can work in a focused way for hours on end, maybe interrupted once a day by that project manager asking for a progress update. For us, it's phones beeping day and night. It's either PagerDuty telling us that some hosting component needs urgent attention, or it's Zendesk telling us that a customer is asking for some TLC. And we seriously started to ask ourselves, is there any way to get something done at all? And last year, things turned so bad that it turned into kind of an emergency. We realized that our hosting platform was behind in features, so we started a few projects to catch up. We also had accumulated quite a bit of technical debt, so we started cleanup initiatives. But any time we wanted to work on that, we had an incident or an outage, so we had to drop everything and make sure that we were keeping our uptime promises. And due to all this firefighting, we realized that people urgently needed to take more time off. Some people on our team had postponed their vacations to the breaking point. That again led to even less capacity to get these projects from the back burner again, causing even more delays. And I could tell from the feedback that we got from our customers that they noticed too that we were struggling. You can probably imagine the impact that had on T-moral. Everyone was busting their ass and had nothing to show for it. Everyone faced the same dilemma. Should I tell my wife that I'll have to put in even more time at work? And what if even that doesn't work? Or should I say, okay, let's kick back, take some rest and let the whole team down? Maybe even damage the business? We were really in a bad place. Back then I read an article by Martin Micas of MySQL fame. And one sentence stood out for me. The success of a CEO is measured by the results delivered, period. And that made me realize that all my efforts as a leader are moot. If we don't deliver the things that our customers expect from us. And I also realized that the root cause of our problems wasn't that my team members didn't know urgent from important, that they kept succumbing to scope creep, that they got lost in the details, or that they simply didn't take enough time off. The reason was that I was failing in leading them. I had to do something and the first thing I did was get out a book. When I read the Phoenix project for the first time back in 2013 when it came out, I found it quite amusing seeing all the similarities between the story and my former corporate home. But this time I saw that this novel described exactly the same problems we were facing. Team members were taking on too much work. Everyone was motivated, driven, but couldn't quite figure out what their real capacity was. And the person that had the most know-how on a certain issue instantly became the bottleneck. Everyone had to wait until he or she was able to fix an issue, resolve an incident, things like that. Unplanned work, which is frequent in web operations, kept disrupting the flow of our work. We started things and never got them finished. We didn't even see what was going on. We knew we did a lot, we were busy, but at the end of the day you couldn't quite tell what you had accomplished. And when it came to deciding what we'd do next, we had no clear way to do that. So there were lots of discussions and second guessing and stuff. Luckily the book also describes a few approaches that can resolve these situations. I made up a plan to achieve three things. We needed a method for visualizing and especially limiting our work in progress. We needed a way to easily prioritize both the things we wanted to improve on our hosting platform and the things that needed to be done behind the scenes. And we needed an approach to limit the impact of unplanned work. Turns out we already knew a method for visualizing and limiting work in progress. And as soon as we started putting cards on a Kanban board, things got much easier. Now we could tell who's working on what and we could tell who's stuck with an issue. Embarrassingly I even had given talks about that. But every time we tried it, we dropped it again because we felt that the effort was greater than the yield. By normalizing the size of our cards to, I think I can finish this until tomorrow night, we not only leveled the flow of our work, thanks Mike, but also we got the satisfaction of moving a card into the completed lane much more frequently. And this time I decided to not use the build-in things that our Kanban like in Trello or in Asana, which we are using to manage our tasks. I decided to use Linkit because it gives you a much more sophisticated way of building such a board. And as you can see we have lots of different lanes for the different types of work that we have. We have even a little software development pipeline in the middle there for the infra coding we are doing. And it is easy to spot if there's a new support request or a customer order, or if there are incidents that need to be taken care of. That improved a lot, but we still had a problem with filling the backlog. In other words, how do we decide which important project is more important than all the other important projects? Again, I read the right thing at the right time. In this case it was a blog post from Intercom titled Rice Simple Prioritization for Product Managers. They had invented a smart little formula that made ranking projects between each other easy. And having an actual algorithm that didn't require expert knowledge or time-consuming valuations, estimations and things like that was important for us because we wanted to use the little capacity we have for executing work, not for planning it. Before we had a convoluted process with lots of discussions and second guessing if a project was really more important than others. And now we had a way to easily do that with an investment of, say, 90 minutes a month. Over the recent months we adapted the original formula presented by Intercom. It changed a bit, but it still fits the Rice acronym, in which R stands now for relevance, I for impact, C for confidence and E for effort. Effort simply is the number of days we think will be required to ship a feature or to finish a project. And to keep the ranking algorithm simple, we decided to only use a few discrete values for the other variables. Relevance can have five values, ranking from absolute game changer down to small improvement. So five is business critical, four means this project eliminates a high risk. Three, it creates a new opportunity, maybe a new customer segment or something like that. Two means it eliminates a medium risk and one, well at least it improves efficiency, either internal or for our customers. Impact has even only three values, from one incremental to two major to three fundamental. So a completely new feature will probably be at least major if not fundamental. And even though confidence is a percentage, we only allow three values. Fifty percent means you haven't thought it through quite well. Eighty percent, yeah, it's in the ballpark and 100 percent means, yeah, I really made an effort of thinking this through. And in the final formula, each of these three former values gets weighted in a way that lets us optimize for effectiveness. That means a project with a higher relevance will probably rank above a project with a lower relevance, except if either low confidence or very high effort apply a malice that pushes it down. So sometimes a project that is more relevant will rank lower because there are other more low hanging fruit. Did that make my life easier? Simply deciding these few values, seeing what Google Sheets would give me as a final rice score and then do sort by score. If only there weren't these terrible interruptions. I guess most of you are familiar with the Eisenhower model where you put tasks in four different buckets. The x-axis is important, the y-axis is urgency, and you drop everything that's not important and not urgent, and you focus on the important stuff, especially of course the stuff that's important and urgent. There are a few types of work that fall into the latter category for us. Mainly support requests, customer orders, incidents and outages, and security updates. We can't postpone these things more than I guess 24 hours if we want to be good. Up until this point tackling these tasks had been a team effort. Everyone agreed to take care of these things as soon as they surfaced. Because we thought if we spread it over the whole team no one needs to suffer too much. Well, it turned out sharing the pain was multiplying the pain because no one got anything done. So now we are taking the opposite approach. We created a new role that we call the Libero because the main job of this role is to take care of all unexpected things. So if a support request comes in he or she tackles it. If an incident happens and it's not during off time where we have an extra on-call shift, it's the Libero who takes care of that. And we rotate this role on a regular basis. So far we had done it in one week schedules and now we've extended it to two weeks. So for two weeks one person of the team gets to do all this unexpected stuff. And then it's weeks of focus work. Two weeks times the number of the rest of the team. This worked out greatly and gave us another challenge. What to do during slower times when there aren't as many tickets coming in if our hosting infrastructure is actually holding up? Well we decided to apply one of our core company values which is freedom. So the person doing the Libero can decide for themselves what to do if there isn't a ticket to answer our incident to resolve. They are not supposed to do project work during that time because eventually they will be interrupted. So there might be a DrupalCon video to watch. They might want to finish a book and we don't even mind if they do the laundry or watch Netflix. Even though the Libero role is quite new, it has already changed our perspective on it. Initially we thought well Libero is the poor chap who has to take a bullet for the team. Now after about nine months we start realizing this role is essential for us to achieve our desired service quality. This role is probably the most important role in the whole operations team. That's why we are currently discussing of renaming it from the Libero who is just the last line of defence against these pesky customers into the concierge. With our WIP board we feel we are now finally in control of our work, not the other way around. And since there's a person taking care of all the unexpected stuff there are no excuses anymore. It frustrated me on end when we did our weekly planning round and I asked okay this has been on the plan for weeks now why hasn't it been finished yet? And the person responsible told me well on Monday I worked on it and then came that incident and I tried to get back on it but then I had to take the support request which turned out to take more than a day. On Thursday I took the day off and well on Friday nothing much did happen anymore. What should you do about that? There's nothing that's actionable. Now it's clear if something has not been done there is a reason that we need to discuss. And weeks in which we don't make any significant progress are now the exception not the rule anymore. Our project ranking algorithm gives us certainty that we invest the capacity we have at the right places and adding things to our backlog is much easier now. There's no second guessing wait a minute is this really so important shouldn't we rather do this or that? We simply pick from the top of the list because that's the single source of truth. Let me be perfectly honest again we are not in a position yet where we are constantly shipping new product features and that's because over time we had accumulated a lot of technical debt that we need to tackle first. But we already see the results of our efforts because turns out eliminating technical debt reduces the amount of unplanned work which creates a virtual cycle and this is and that's the most important thing confirmed both by the feedback we get from our customers and the feedback I get from my team during our one-on-ones so if everyone's happy I can be happy and if you wanted me to distill everything I've told you into a single sentence it will probably be our new motto with that I'm finished. If you have any questions I'd be happy to answer them please use the microphone. One thing I think I noticed in such situations is that support requests tend to happen in batches all at the same time meaning that your libero can handle them all. Does he stack them in order or dispatch them to the other workers? So most of the support requests we get are either pretty trivial and can be answered right away maybe even with a pointer to our FAQ or there's a real issue that someone needs to tackle and that's when the libero simply tells the customer whoa that's a biggie we'll have to look into that and then he or she delegates it to the rest of the team it goes on our WIP board might not be tackled right away because planned work but then someone will take the time to get this resolved once and for all so our aim is that the libero responds quickly if possible with a solution and if that's not possible it becomes kind of a second level support thing. I'll be around until tomorrow night so if there's anything tweet me catch me in the hallway and thanks.