 Tervetuloa katsomaan jälkeen. Tämä on semmoinen ympäristösessi, johon olen tullut ihmisiä. Tämä on semmoinen beta-verso. Täällä pitäisi olla erilainen, joten ei ole mitään. Täällä on hienoa informaattia. Hei, minä olen Fesappalmu. Olen CEO Wunderkraut. Olen myös kappalassa lisäksi. Olen myös ympäristösyksessi. So I'm quite involved in all of this triple and related stuff. I've been doing IT and web projects for quite a while. I've been selling agile for ten-ish years. And I've been failing to do so quite a bit. And also succeeding from time to time. So I'm here to share you some of my lessons learned around this journey. We have quite a lot of stuff to cover for today. I don't think we'll manage to cover all of it because I'm trying to take questions from you guys during this, but we'll see how far we get. So a couple of words about Wunderkraut. If some of you were at the keynote this morning, you may have heard something about Wunderkraut. We are a large-ish company that does triple, but our main job is really improving the business of our customers using online tools. We are one of the largest triple shops, if you will, in the world in nine different countries. And we are quite international. We have 17 native languages spoken and quite a few nationalities and so on. Enough about us. So the format today. I will have some guests. Some of them are only recorded. So I did interviews for this because I didn't want to only show my point of view. I wanted to share also the customer point of view and a professional buyer point of view. So I have guys that I have short video interview clips here. Do you want to introduce yourself? So my name is Dick Olsson. I currently work for Pfizer, one of the world's biggest pharmaceutical companies. I am a senior manager in digital engineering. So I manage a lot of internal engineering projects all related to Drupal and Pfizer. And he will be mostly answering your questions here if you want to ask something about like how does the customer see this thing. I also have my colleague Hekki there in the end just helping me to take questions because I decided I'm going to use Twitter to take your questions because otherwise it may be impossible. So I'll get you on hashtags selling agile and we'll start getting some questions in very soon. But let's get started with the show by how do vendors sell agile. This is Petto Tolvainen. He's a CMS expert buyer if you will. So what he does for living is writes RFPs for different companies, chooses vendors, runs the RFP process and so on. So his views on like how do you choose vendors I think are quite valuable. So let's see if I get the video thing working. I think selling agile is a really actually dangerous style of selling the projects. We see it a lot like too much and I think many agencies should more focus to the benefits of what the agile method offers for the client. In many situations when I'm on client side I see that when the client says that they want agile project what they actually want. They want just visibility for the project and they want a really structured and easy change control mechanism. And that's the two things what the clients are actually expecting and that's what the agencies should convince the client that they have this kind of visible process and a lot of change control possibilities. And the agile should be a secondary thing in their pitch. To repeat the key message because I don't think we can crank up the volume more unless we get somebody from the technical staff here. So basically he said don't sell agile at all, sell the benefits of agile which I think is right on the money. That's what you really should do and that's one of the key focus points in here. So three things really for today. First of all agile is as such it's not difficult to sell everybody wants to buy agile but it is still difficult to sell real agile. So that's going to be the first topic. Then I have a couple of case studies situations that you will run into when you are trying to sell agile projects to your customers stuff that happens in real life. And I'll examine a bit like each one of them like how to deal with these situations. In the end it's not always appropriate to sell agile and there's not only like one way of selling agile or one flavor of agile if you will. So I'll cover that just a bit as well. So first of all I would like to hear from the audience. So now it's okay to twiddle all of these things. I would like to hear like how large percentage of your projects are agile or what you would consider agile. So if you could tweet this and use the hashtag selling agile we will get some statistics by the end of the session on this. So please do tweet it. Also the same hashtag selling agile we will use for all the questions. So if you have any question feel free to tweet it and Heki will choose some of the most interesting ones and bring them up to my attention. So first of all why is agile like real agile difficult to sell. Well really it really comes down to trust. It's really lack of trust that is like built into the relationship between customer and vendor like way too often. The customer thinks you are there to steal their money. The vendor thinks that the customer is just trying to get free work in the end. So that's the core thing. But still you know I haven't really had any real problems selling agile as such. And I had a discussion around this topic in a global scrum gathering a week ago with a room full of people like is selling agile difficult. How you do it. Everybody was saying like well it used to be difficult like five years ago or even ten years ago. These days it's really not all that difficult. It's just the problem of like yeah they would love to do agile but they really don't understand it. They don't understand the benefits and they don't understand what it actually requires. That's why I'm going to start by talking just a bit about this topic because I personally run into this all the time. We do quite a bit of agile training and agile coaching and we do see the issue of like people really don't understand what it means. So to set the basic scene on this first of all agile is not about software at all. You happen to do software with agile. But the real change in agile is not about software as such. It's not implementation or sprints or time and materials. It's really none of these. It's really a different way of approaching how do we do cooperation between organizations and how do we do product development as such. So that's the first misconception. To consider your projects like web projects. If you consider they are only like IT projects and nothing else. Fine. You really can't go all that agile because agile means quite heavy business involvement in any sort of project. So the business owner who owns the project they have to be involved. If they're not you can forget about it. So what we say always is agile is simple but it's not easy. Any organization starting to adopt agile you can do it. You can learn it in a couple of days quite easily. Adopting it really and using it that takes years. Years of practice. So you're sort of like getting the hang of it after a year or two. And then you really start seeing more and more benefits when you start adopting it. And to make the situation a bit more difficult. We as vendors we are working with customers who don't understand agile. So another half of your agile like entity changes all the time when your customers are different. So let's look at the basics. I think who of you has not seen this ever. I should have asked the other way around who has seen it and you know. Oh well. So this is the manifesto for agile software development. Which all of we know and love and all that. Then you know it sounds great doesn't it. And then there's the but. And the real core of the problem is actually here. This is what happens. It's it's not a proper agile. It's it's the half asked version of agile. So basically to give you an example from here. We we of course it's better to have customer collaboration than contract negotiation. As long as you have strict contracts in place. So so you sort of get all of these comments from the customers often say like. Yeah sure we can do sprints but it has to be fixed everything. We have to have a fixed scope and we have to be very strict on what to do. So they kind of adopt agile but they really don't because they break it in process by doing a half asked job on doing it. And this is this is what I see very very often with the customers. They kind of love it but not really. So this is what what I call fake agile. And to get a bit more examples on this again. I'm asking a bit of your your participation first of all. So to get the rest of the session. More fitting to to your questions. What's stopping you from selling agile today. Why don't you know first of all why are you here. Because if you are selling all agile and you don't have any problems. I don't think you would be here. So if you can help me out a bit and let me know like what's stopping you from selling agile today. To tweet it and we'll get back to these questions fairly soon. And we'll also do a very nice pie chart on like what are the biggest problems. So please help me out of it. So I want to bring in another angle to this topic. So I'm going to ask to help us a bit on like from your point of view. What's stopping us from doing agile. It's it is a difficult question. I think you're touching on many good points here. It's people they think that they know agile. But they have difficulty seeing the benefits of it. And that's really because many people they sell agile the wrong way to companies like Pfizer. I am in touch with a lot of vendors that approach us and they sell agile the wrong way. They don't lift up the benefits of agile. They say we do sprints. We do we standing up when we have our meetings and instead of sitting down and these kind of things. They don't sell the benefits. They don't sell the benefits of doing product development with agile. You know how you can how you can test and measure your progress and continuously improve and these kind of things. It's not about sprints as you touched on. And it's not about standing up instead of sitting down. So really selling it the wrong way. That's educating organizations like Pfizer the wrong way. It's I think that's the simple answer to quite a complex question really. Yeah, and I think that's exactly what it is about. And let's have another view that I think probably can reinforce this. You need to be really quiet for in order to hear this, but I hope you can be. Did anyone hear the previous video still? Okay, fine. So let's let's try if this one works. I think the single biggest problem is related to decision making structure of large organizations. So they have pretty slow decision making processes and they are not used to having these projects which do constant demands to other to other parts of the organization. And that's the biggest single problem the current leadership style decision making process in large organizations. So basically basically the way they run their business, which is not very agile. And again, this we see as a vendor over and over again. Everything has to be pre approved, which makes it pretty difficult to be really agile. So let's move on to some real life examples and case studies on this. So the first one. Sure, we can do that agile as long as you deliver to into your scope and everything within the budget and timeline and nothing changes. How many times have you seen it? Who's seen this in an RFP? There are some people who haven't. I'm surprised. So this is this is the typical argument you get. And this happens really quite often. So how to deal with it? First of all, in order to sell any of these, you should have a bit of like storytelling skills. So ideally you should try to know something about the customer business and you should tell them a story they can relate to. Like why did you fail on a previous project? You don't have to know the facts. It's quite easy to guess based on the RFPs often. It's like, well, let's imagine you have this kind of a project in your business. And then you do this and you know what happens and then the end result is kind of poor, isn't it? And then you have them like, yeah, yeah, that's just what happened. That's what happened the previous time. So that's sort of the foundation for it. Make stories out of this stuff. Try to try to tell stories that are like specific for the customer and their business. And don't make them about your business if you can. I know it's sometimes difficult. If the customer is a company, let's say they are doing cat food, maybe it's slightly difficult to think about what's important for them and what's their process like. So that's the first point. Second thing is approach it with some facts. Have a look at why is so, what's beneficial and so on. So for example, in fixed bid or agile, you can have a look at different things that are very different in this. And I did this for a real customer some time ago because they were just like, why should we do this agile thing? Isn't it only time and materials and so on? No, not really. Let me get through all the points. It's like what's really different in this. So there's a couple of things here. Project focus, of course. The biggest problem with fixed bid, the short term I use for fixed everything. So it's not only fixed price, it's fixed everything. It's like it's all about checking boxes really. So you have a number of requirements for your project and those boxes need to be checked. And who cares about the quality or anything. The vendor is motivated in trying to check all the boxes with minimum amount of effort. Because the faster you are, the more profit you make basically. So the incentives for the vendor are not very healthy. And it's quite different from when you're doing agile because in a good way agile is time and materials. So as a customer you are paying for results and great quality can be one of them. And the vendor is not incentivized in actually cutting quality or trying to cut corners in just going somewhere. So it's very different. Change is pretty evident what happens there. And scope in agile is actually improved. It's not that it's only a different scope, it's actually an improved scope. Because you learn during a project. So the final scope ends up being better than the original one you started with. Some more stuff. Transparency is one of the key reasons why agile is so popular. It approaches to become really transparent when you are doing agile. And in fixed bit if you are doing a waterfall process what happens is this thing is like 95% complete. But nobody knows what the remaining 5% takes. And that's the traditional problem you have. Whereas in agile you have a real tangible progress where stuff that is actually ready to be deployed is delivered all the time. So it's much easier to track. Time to market is kind of self-evident because if you do all of the design first before you start implementing anything. It is going to be slower that way than delivering the highest value items first and starting from there. Quality, I think I touched on that already. So I'm just going to move forward. Customer involvement also is very different profile wise. Because you couldn't really do an agile project where the customer is on vacation all the time. So in more traditional way it's like big push to do like a big piece of documentation and then you know it's easier. In agile it's more like distributed all over the project. Which one do you prefer? I don't know. You get better results anyway with the agile approach in this case. Risks are a bit different and pricing. Pricing is an interesting thing because fixed bit is anything but fixed. Because you have this. And this is a real picture. So if you can't read them. The small boat is original contract. And the bigger yacht is change order. And this I think this is from some person from construction industry that actually owns the boats. But this is true for the IT industry as well. The IT vendors are highly motivated on getting change orders. And their business depends on getting as many change orders as possible. Because the profit margin is way higher on change orders than in the original contract. And this is in your traditional contract. So really the fixed bit it's anything but in real life. It's just a good way for vendors to lie to the customer. And say like yeah we'll do it for this money. And in the end everything ends up being a change request. So on the other hand as a vendor if you want to get a bigger boat. You may want to consider doing fixed bit and just being evil. That may work as well. So basically the difference being here. What are the benefits? You create value faster. So you can see the highest value items coming out of it soon. And you have higher quality by default. Because cutting quality is no longer beneficial for the vendor in agile process. So you will by default you will get higher quality. And in the end the customer usually saves money as well. I'll get back to that topic a bit later like why that is. Another case. We have no product owner. I'm kind of assuming all of you know basics on agile process. So I'm not going to explain any of these terms. You may have to Google them if you don't. So this is typical for some companies. Well we delivered all of the like layouts for you already. And we delivered like this like brick of paper. Isn't that enough to just implement it just you know go and implement. That may or may not work. But one of the core things how we work with customers is it looks like this. So basically the customer has their business competence. And they can of course you know they're experts in their own business. We have competence on how to do great projects that are on track and reach their goals and so on. We can help them in that. We also have a lot of like digital competence. We have this funny tool that is like true something that we use quite a bit. And we do know a lot about how to do like digital services. When you combine all of these skills we really like to believe that the end result is much better than just the sum of its parts. So basically when we can give feedback for the product owner during the project on how could you do this and are there different ways of doing it and so on. The end result is usually better. We don't if we just do it based on a paper. We don't really know what's what's the thinking behind of all of all of these specifications the customer did. We can ask the product owner we can propose better solutions and so on. So that's that's the first part of this. So sort of having like one team with shared goals. It's probably probably a good idea for most projects. So sort of like leaving your badges when you go in just leave your badges on the table and forget about who works for which company. Just create a team that works together for for shared goal. The second thing. This would be your your traditional project where you do of course planning first and so on and so on. This would be a agile project. So in theory exactly the same amount of planning is still there. We don't really save on on doing less planning or anything like that. It's just done in different places of a project. And it's most of the planning is actually done with quite a bit more information about the project topic itself. This becomes really useful is this if this happens. And this may be you running out of time you running out of budget whatever have you. I don't know if this ever has happened to somebody that you run out of time or budget in a project. But if it would if it happens at this point in an agile project we've delivered the most valuable bits already. So more than half of the project is ready to be actually launched or maybe already launched at this point. Well the lower value stuff is not done. It started but it's not done. Not a very nice place to be but it may not be a disaster in a traditional project. We haven't delivered anything. We have some code. We don't know if it works it hasn't been tested. And it's not ready to be deployed and it hasn't been at this point. So this makes a very very big difference between like traditional and agile. Again these are some of the tools you hopefully can use to convince the customer that this is a good idea. So basically we lower the risk quite a bit. What if we are late? Much less of an impact with agile. It generates new ideas. You only have one team of people working closely together during the Intaya project. So they will come up with new ideas. Because for example all people of course they move from project to project and customer to customer. So they see multiple industries. So they will have new fresh ideas quite often. And in the end it's saving money. Let's say if you haven't designed something and you decided well I'm not going to implement it. I'm not going to have any cost from it. But if you already designed it. You have a sunken cost for the design bit. You're just not going to implement it. So before we move to case three. Heikki, do we have any questions? Well one about do you think a mix of agile and waterfall is a good route to take? Oh I wouldn't go there. The reason being agile is a big shift in a mindset. And if your teams are working like in a traditional mindset where all the work is pushed to the team. So you have a product manager assigning tasks all the time. And you are pushing the work to the people. And on the other day they are supposed to pull the work. So they are supposed to take responsibility. They are supposed to take ownership of the work. It's a very difficult thing to mix between these two mindsets. They are quite different. So on all levels the actual mindset difference is the key. So I wouldn't actually mix both of these. Any experience on mixing these from your organization? Because I know you've been moving. Dick, any? I would agree. A mix is rarely a very good idea. You can't really take the big benefits from agile if you try to mix it with something like waterfall. At Pfizer one of the sort of eye-openers when I've been trying to push agile within the organization is this. Ah it's actually working like we develop drugs. We come up with an idea. We build it, we test it, we measure it. And then we learn from it. It makes sense to build websites or web projects the same way. That was a little bit of an eye-opener, this learning and the iteration of it. You can't really develop drugs in a waterfall way. And mixing the two, then you will just miss the point really. Any other questions at this point? We have a new one. How do you manage projects with a large set of critical must-have functionality? This is a deep rabbit hole. The question is are there really must-haves? If you're using like Moscow prioritization, like must-haves should have, could have, won't, however you want to use it. The must-haves should be something that you absolutely cannot launch the product without. So if that thing doesn't exist, you don't get any value out of the project. Could-haves should be something that it's really going to hurt, but you can still launch it with could-haves and so on. So it depends on your definition of must-haves. It's a fairly large topic area, but basically I would just be really strict on what is a must-have. Yeah, so the comment was it could be when you're migrating from one platform to another. Yes, if you want to do a lift and shift project, but if you want to improve it a bit, and perhaps on an old site, not everything is actually absolutely needed to launch the new site. Like say full content migration, if you have 10 million pieces of content and some of them don't get any traffic every month. But yeah. All right. Okay, so moving on. Let's have a look at the feedback a bit. This is also quite often the case that the actual testing and acceptance and everything is at the end of the project only, and there's limited testing and discussion and test users and everything during the project. So this is what it looks like. Basically you have a goal in the middle, and then you have a timeline, and the top line being a waterfall project where all the testing and all of the real feedback comes from the end. So basically we do some sort of internal launch or whatever launch at the end. We may actually end up getting a bit different product that we were aiming for, but we don't really know it before it meets the real life or meets the internal stakeholders or whatever. Whereas in agile we do multiple deliveries. So we actually get the internal stakeholders. We can get like beta testers or whatever you may have really early working on parts of the product. And you get the feedback earlier. You are still going to be off. You are still not going to do a perfect product on a first try, but you know it much earlier. So you get really, really quick feedback. So testing everything and getting pilot users and so on, that's very important. And you can only do it if you have something for them to use. Makes sense. This is one of my favorite examples actually. Let's imagine for a while the product we are trying to do is like lottery with three numbers. And we can play the lottery in a way that we pay a three euro lottery ticket. Then we see if we win or not. That's the first way of doing it. So our average investment for the lottery ticket is always three euros, right? And that's always the same. And the possibility of winning is naturally always the same. The second way of playing the same game is you invest one euro for one number. And you only need to commit to buying the second number after you know if the first number is a winning number or not. Then you do the same thing for the second number and then for the third number. Well, I don't think anyone would use the three euro ticket at this point. But yet the projects are done this way in companies. Because on average your investment for the second case for successful case is going to be like 1.11 euros. And for the first case for successful lottery ticket is going to be three euros. And this is based on like real options theory. So if you want to learn about the science behind all of this, you can actually refer to the science and not just your gut feeling. And that's what's behind it. It is kind of common sense. But companies, they don't usually think like this. It's like, no, no, I need to have this fixed bit where everything is in. Instead of let's do a smaller bit first and see if it works. If it doesn't, it's a sunken cost and we will just forget it. If it doesn't, let's build on top of it and let's do more stuff. So making them understand that doing one big investment on one go may not be the best idea. Maybe eye opening for some customers. So we get higher quality this way. We get faster learning. We save money again. So the benefits are definitely there. So just remember to get always back to the why is it good for you. What are the benefits? One of my favorites, Photoshop. I just read a tweet about like Photoshop is the best way to show your customer what your site is never going to look like. Something along these lines. I think that was a perfect quote. So basically if you do design first, we are dealing with Truppel here. Truppel has existing functionality. It has existing user interfaces. Yet many people just, you know, you have your Photoshop cowboys and they just go and do something and then it gets approved and you're supposed to implement it as is. Well, the fact is this is any project. You have knowledge going up and you have time going horizontally. So instead of any project, the team doing the project has minimum amount of knowledge they will ever have on that topic. At the end of the project, they have maximum knowledge on this specific project, right? This is why hindsight is such a beautiful thing. It's so easy to be smart at the end of any project when, you know, you already wrapped up everything and then you know. So when do we do all of the important decisions in a project? Minimum available information, right? So we fixed everything before we know what the project is going to be all about. And in a real project, if we deliver frequently during the project, we would learn all the time and the team would learn more and more of the project. So actually we would do better decisions because we know more. So of course we can't make all of the decisions at the end of the project because it's kind of done at that point. But what we can do is we can do all of the decisions at the latest responsible moment. So, you know, sometimes not doing decision is much worse than doing a bad one. So at some point you have to decide. But we can postpone them, learn more first. So that we can't do if it's a fixed everything bit. So how do we approach this? This is loosely the process model we use at Wunderkraut. So basically what we do is, Trupul is a very good prototyping tool. It's like, I like to say that the Trupul features are cheap and details are expensive. You can build a fairly complicated site like within days functionality wise and then it's going to look horrible but it still works. And you know, with Trupul you start the project with the fully functional product and you spend most of your time breaking the product. That's the way Trupul projects go. So what we do is we have options on implementing something for the product owner. Like there's the quick and dirty way. I can do this in 15 minutes. And you know, it's sort of going to be what you wanted but not exactly. Then you have the perfect way. This is exactly like you envisioned. But it's going to take us three weeks to do. And you may have something in between as well. And all of these being different technical implementation options. So then what happens is the product owner is the one who will make the decision which one of these we should do. Because if one of them would be like visually brilliant or one of them would be technically just like fantastic to implement. It's so much fun for the developers. The downside of this is like the money is not. It's not the developers or designers money. It's the customers money. So we actually make it visible for the customer. Like look, do you want to make it perfect and spend a lot of money? Or do you want to do a quick and dirty hack and do it very cheaply? And depending on a case, they will pick either one. Quite often they go with the quick and dirty because they're well this is not so important thing. Let's just do it the cheap way first and then see what happens. But if it's like the core feature of the entire site or whatever, they are more likely to go with the expensive way. The case being here having options and getting the customer to decide because they own the budget. In fixed everything, they wouldn't. You would just go with the minimum whatever works solution or you may have to go with the expensive way because that's the way somebody drew it in Photoshop. And you can't do anything about it. And it's stupid for the customer to spend so much money on something just to make it pixel perfect instead of going, well this is actually almost good enough and it's way cheaper to do. There's a principle behind this. Again, there's some kind of science. I think this is economics. I don't know if it's a science or not. But part of the principle which has nothing to do with software. So it's just 80% of the results are often, you get it for 20% effort. So the initial bits you do are very valuable if you start from the highest value items and then the value goes slowly, slowly up. So it's just a question of which point do we want to stop working. At 20% may be not good enough. 30-40% maybe it's good enough. And quite often this I think in Drupal this may be even like 95-5% principle sometimes because the last stuff you do with the details it's something like well our marketing manager did spot a one small mistake there. Can we please fix it? Nobody else ever in the world would have noticed and you spent like two days fixing it. May not be the best solution cost wise. So we end up with improved product. Much lower risk if you approach it like this and again new ideas. Last case, unfair relationships. So basically let's do another show of hands. How many RFPs have you seen where the contract terms are completely unreasonable? Oh if you have yeah, okay. So this is what it looks like. This is especially with large organizations this has to do with procurement departments and procurement departments often they like playing a game called win-lose. So they think in a good relationship one party wins and one loses. So they try to squeeze like as much of chews out of the vendor as they can basically. They try to negotiate the prices. They try to negotiate warranties. They try to push you as hard as they can. And that's not really a healthy thing because that's not a stable like sustainable relationship. Because in any good healthy relationship both parties have to be happy. And if it's a win-lose game that's never going to happen. So what you should do instead is like you can do different pricing and contract models. For example in Agile you could do say this one which is target price. And if you manage to be under the target price you get 20% of the remaining amount for free as a bonus. So you get money for free. Customers saved money and you get money for not working. Pretty sweet. If you go over some defined target or some defined maximum price then you actually work for like say minus 40% discount which is really going to hurt you. But the customer is still paying for you to work because it shouldn't be for free for them either because it's like both parties have failed in this way. So figuring out ways where you can share risk and share penalties like most stable relationship between the parties some of these are easy to sell to the customer because it's like hey look you know you'll save money if we are faster and if we are way over the maximum price we will share your pain. It's going to help your sales as well. There's a bit of stuff but we don't really have time to go into detail but it's worth googling the terminal 5 contract model may sound funny but the software industry may have something to learn from construction industry at times. This is Hitro terminal 5 and they built it and it was a massive success because they had a completely different contract models in place and yeah just go online there's plenty of material read it it's well worth spending a bit of time on that. So again quite a nice benefits potentially out of this. So I have another guest speaker here I would have used more of James's stuff so he's James Cutts he's a director for product implementation product implementation being American for building websites in this case and he works for NBC universal he's basically he brought them from waterfall to agile like the entire organization and he does it for living unfortunately I had to do this only over Skype so the quality was so bad I couldn't use more of his stuff but let's see what he says about what do you ask when looking for an agile vendor so if you want an agile what should you do I think the volume is hopefully a bit higher on this one Sure yeah I think well I don't have a real list that I know through but what I try to do is really get the vendor to share what their experience is and I find any vendor who is using some form of agile has that experience they're very passionate about it and willing to share and they have some type of presentation that they're sort of really excited to share so that's one of the first things I do is just get them to share ask them what is your experience with agile tell me about your processes give me examples how have you done this and usually organizations or vendors that are have experience with agile that are good are passionate and they're really willing to share that information so when that conversation is quiet the response is quiet and it becomes uncomfortable then you know that that vendor probably doesn't have the best experience there but I find when you're interviewing vendors and talking to them those that have the experience are usually pretty excited to share it when you ask so I always say just ask so be excited about your own stuff I did ask the same question from Pertu as well and he has a different point of view on this a bit I think for me the biggest problem what we see more most often when we evaluate agencies is that there are a lot of agencies who just say that we are happy to adapt to any style what the customer wants to do and then we have a lot of we already have started to have these agencies which have a lot of experience from agile already and many of them have already developed their own way of doing agile and that's what we like to hear and we like to listen to them and hear their experiences why they have chosen this certain style of doing agile whether it's internally or whether it's with the clients always I think finding finding your own way with agile that's one thing what we look for when we evaluate agencies and we highly value those agencies that have found their own way of doing agile and are really promoting that way and saying to the client that this is how we work and that's really important so find your own way stick to it don't do whatever customer asks because if you do whatever process the customer asks first of all the customer is sort of silly to do it because they are trying to tell somebody what tools to use why don't they hire somebody who actually meets their process instead so it makes no sense for anybody really to do it and I can add some perspective to this as well sitting in the engineering department at Pfizer I often evaluate vendors that build websites for us from a technical point of view and what I like to do is looking at their processes and their tools that they have in place to make sure that the vendor have a process in place and have tools and continuous integration tools in place to actually release code or code frequently and that's paramount I found that paramount to learn and measure the success many vendors they come to us and say yeah we do sprints but then we don't learn anything we don't try we don't measure our results along the way having tools in place to release your code continuously after every sprint or what it be is of paramount from a technical point of view so looking at vendors making sure that they have those tools in place practices in place to support that is of paramount because otherwise we lose the whole learning process which is so important great let's have a look at the results a bit from the questions so basically I'm going to start with the other diagram so this is how the room looks like so how large percentage of your projects are agile it's like a surprising actually I was expecting more like companies who do exclusively agile and not so much but most people seem to be in the middle right okay this is going to be an interesting thing to analyze afterwards so what about the issues what we have in the room today so demanding fixed everything yes not being enough projects fair enough I'll cover that as well not understanding agile actually surprising a large percentage customers not willing to engage all other agencies offer fixed prices we have quite a few triple agencies in the room can we please stop doing that like tomorrow I'm not trying to do price fixing or anything I'm trying to get rid of this like waterfall nonsense yeah yeah I know it's been recorded that's why I said I'm not doing any price fixing okay yeah exactly the opposite no fixed price indeed alright couple more things before we move into the questions so what about when should you sell agile I think the most important question was already up there so really what's the size of a project and this may be bad news for any small shops in here where your average project size is tiny agile doesn't work well on very small projects you can use some aspects of agile you can perfectly well use something like Kanban in small stuff as well but if you look at like anything that has to do with iterations and sprints you may notice one thing if you look at Scrum for example one iteration in Scrum is a waterfall I'm sorry to break it to you but that's the case so if it's small enough it doesn't have any room to actually start working as it's intended so don't try to force Scrum for example on projects of all sizes you need to have big enough project Scrum is designed for like 7-ish people team all of them being developers and a project that runs for a year or more we have plenty of these projects for a triple but I know the biggest part of triple projects are not like this they are way smaller so that's where we get to this so tiny, I'm using mandates here instead of money because I know money varies quite a bit from market to market so if for example we are doing a project in Latvia or in the UK the day rate is likely different so that's why I'm using mandates so tiny projects in my books are like 30 days or less mandates or woman days whatever you want to have and that would be like waterfall thing anyway it's fixed everything because you have to design it first and then do it it's a tiny tiny thing and just get it over with small sites, let's say less than 100 days Scrum ban works nicely Scrum ban adopts some of the traits of Scrum into Scrum ban that may work as well then medium to large sites Scrum ban or even simplified Scrum trying to keep the overhead minimum like if it's less than 300 mandates and then the sweet spot of Scrum being with triple being like 300 to 1500 mandates this is triple specific in my opinion and if it's bigger than that I would split it into multiple teams you get better results with multiple teams in that point otherwise it's going to take forever for one triple team to get through it because they are stepping on each other's toes all the time and getting in a way so split it just get on with it so couple of requirements for selling agile you need to see and know the benefits you need to know the process and you need to have experience in it it's a chicken and egg problem of course if you want to move to agile but you don't have the experience how do you sell it and that's where I recommend try getting a customer that already trusts you and knows you and start with them and agree with some sort of terms like look you know we are practising and we are sharing the risk and you'll get big discounts and whatever we just want to get started with this because we know it's good for us and it would be good for you as well so doing something like that even internal projects but that's a bit different dynamic and the key thing here is like your sales force has to be quite integrated in all of your operations because if they have no idea what this is about there's no way they can sell it absolutely no way as you heard from all of the people I had in this thing everybody was saying like look if you're not convincing if you don't know your stuff you will not be able to sell it right so last but not least before we move to questions so how do you deal with it when you get a fixed everything RFP first of all a fixed budget is not a problem that's fine I actually like having a fixed budget because fixed budget forces priorities you need to set your priorities you have to move stuff out of the project you have to get like the least important stuff and forget about it and that's healthy for any project there's always some extra stuff that shouldn't ever be done in any project so it's a good thing fixed schedule you can also have that if you have a deadline just fine completely fine but fixed scope never and even if like even if your budget and your timeline is flexible fixed scope is not a good idea why? because you lose most of the benefits I was talking about you can definitely do it and you can use Trum to deliver a product with fixed like everything else and you know the scope everything else being flexible being fixed but you don't get most of the benefits of Agile at that point so yeah go ahead you can do it and you probably succeed because you have like infinite resources so you know you became a government right now but other than that it's not a good idea so how to deal with this is like we do three different things when we see it sometimes we just decline say like no sorry not interested this is mostly mostly if the customer wouldn't fit our profile anyway and we just send our apologies and say like yeah look sorry we are not gonna take part in this mostly we take the middle one we decline we explain why we tell the customer look we are not gonna propose for your project because it's gonna fail and we explain why it's gonna fail and it's specific for the project so it's a bit of effort it takes like some hours so to actually explain it like because you are doing this and this and it's for these reasons it's not gonna work and this is what we would recommend you do instead and you know no hard feelings and that's it it cost a bit of time customer may learn something for example I mostly work with our UK office because I'm based in London helping Steve and my other colleagues there and most of our UK projects last year or within the last 12 months we've actually won by declining funny enough so we say no and for example one of these like large media companies we told them like no we are not gonna do this because you know it that's not gonna work the response was like congratulations you have been shortlisted it happens but you really need to justify them why it's not a good idea and if all of the vendors would do this that would be beneficial and that's one of my own motivations on actually talking about the topic I hope more vendors would do this because then we would fix this like really broken way of procuring IT projects well then the last solution being and this is what many companies do they still do a proposal and they just say like yeah yeah it's you know we can make it agile later and we have time and they will see the light and then you know just fingers crossed and you can sometimes do this but it's a very high risk thing because the customer doesn't really understand that child and yeah I would really advise caution if you choose this one you can do it sometimes but be aware it is gonna fail from time to time and it can be really expensive when it fails so as long as you are very aware of that that's fine so basically now we should have some more questions and some time for that do we have any twitter questions yeah first one what if a customer doesn't have the resources or skills required for a good product ownership well then you train the customer first of all you provide training big part of our business not volume wise but meaning full less wise is providing agile training and coaching just because we couldn't do a project without it so you support your customer on it first of all if they don't have enough time to do it then you provide them with a product owner body somebody who's like an experienced consultant who understands the customer's business and can actually help them in setting the priorities and creating a great product so this person is not gonna be a product owner it's gonna be a body or whatever you wanna call it it's just gonna help the product owner and make the job of the product owner so much easier so that's the approach I would take then we have a couple of questions maybe generally from sales or agile methodology but we want to take them they can fit in here how do you sell work that is not immediately visible or beneficial to the client e.g. refactoring or API modules oh hidden work it's always interesting you have to make a business case for it so if you need to do refactoring why? you need to explain me why if I'm the customer you have to tell me like okay this is gonna reduce your maintenance cost later by this and this much but you need to have a business reason for all of this if you need to do an API thing let's say you are building an e-commerce site then you need to do spend two sprints doing integration to logistics well if I don't do this your packets will be delivered so just always start with the why start with the benefit what do they get from it and also when your devs come back to you and say look we have to refactor the entire thing why and if there's no reason if they can't explain it perhaps it's not worth refactoring it sometimes so you know you have to justify the money spent how do you estimate the budget of the project when selling a job officially like for real officially what you do is you take a book like agile estimation and go through like all the functionality and it's a very long process unofficially for most projects that are like six figures you know you use the stretching thing and you just based on your experience you come up with like well that's what it's likely to be and since the scope is flexible and you know what their business goals are it's quite accurate to say like look this is going to be 400,000 pounds and you know that you can deliver these benefits for that money you are uncertain what the exact scope will be but that's fine because the scope is not fixed so frankly when you have experienced enough people on board and couple of them like do the same sort of estimates on roughly on same number it's going to be the same one so I had my team in one large project doing like they were like they want to do proper estimates for this and I'm like well I'm just going to put a number here and you do your job and have a look at the number after you are done I ended up at 960,000 they ended up at 940,000 and they spent two days I spent two minutes so you know if you don't have the experience behind you it may be difficult and then you have to do the difficult way and do proper estimates for everything but after you've seen it like 25 times similar kind of case same kind of a customer frankly I quite often just do educated guesses anything else? the last one moment is how do you determine the amount of hours per sprint and the number of sprints it depends on your team size so if the team is bigger basically the basic formula there is the bigger the team the less productive it will be per hour spent because you are spending more time on communications so ideally you would use as small team as possible because then your productivity is higher and this is especially true with troupool where you know stepping on others toes and all that stuff so just first of all look at how small team you can get away with and then do your math okay we need if our sprint is two weeks and we have this many days on the sprint and this is our budget then you just estimate it but it can vary quite a bit for example we use one week sprint and two week sprint and both of them work just fine it's just a different kind of project where we use the math and usually the team is fixed for the entire project so agile actually from the vendor point of view you can also make your resourcing quite a bit easier even though I don't like the word resource but still your resourcing is going to be easier because people are going to be in a project for like months and they are full time there and nothing else so our resourcing spreadsheet is really like one like google spreadsheet where we have only weeks and people and nothing else and we don't need a resourcing manager for to actually run that that's very simple I don't know if that answered the question at all but I hope are there any other we have like 20 seconds left one last question we have time for it and then we're done can you please walk to the microphone so the recording actually captures it as well how should the contract be done like post sprint then the client is not happy and then he can cut the contract but it's like 10 sprints take it or leave it ideally what I would do is for like any reason so they commit only for one sprint but you can also do what I showed earlier where if you are ready early for one reason or another the customer pays you a bonus and then you walk away we typically have very flexible contract terms because it's based on trust and we tell the customer upfront we expect a bit of notification if you want to terminate the project because we need to sell the team to somewhere else so I would be really flexible on contract terms so we are out of time I thank you all for your time and I hope it was your space it was great