David Cliquot
Transcript
I'm very, very happy to be here. I think we've seen some pretty brilliant people, very inspiring people as well.
I'm thinking about Alexander we've just seen before and also Carl and David Anderson and Claudio with the popcorn. I loved it. So today I'm going to talk to you about our journey using Kanban in multiple contexts, from large companies to startups.
So first of all, I will introduce myself. My name is David Clicquot. I founded two companies. The first one is Reactive and we offer some lean startup and agile consulting to corporates. And the second one is MVP Stars. It's a startup studio where we help entrepreneurs bring their ideas to life. And we will be talking about this activity in the speech. So as you see, we're hiring people in both these companies, so if you're interested, please feel free to connect. Either you're agile and want to help corporates, or we're looking also for iOS developers to help us, help our startups.
One more thing, I would like to thank my partner, Nicolas Morin, and he's also the co-author of this presentation, couldn't be here today, so thanks him.
And now we're ready to start.
So I will share with you our story with CanVan. It all started when I launched it. We launched it in our old large financial company. So we've discovered a whole new way of working and we started to challenge more and more the status quo. Then I will share with you how we try to implement the lean startup principles and how we try to build our first startup, the things that we've learned, the techniques that we've used. And finally, I will share with you
Our current way of working, it mixes lean startup principles and Kanban. And this is what I call the lean Kanban startup. I hope nobody coined this term. It's not a trademark.
So basically this is what we will go through.
So, how did I discover Kanban? I have to thank again the organizer of this conference because I've discovered Kanban three years ago at the first Lean Kanban France 2012. My partner, the guy that you've seen with the beard, he was already a speaker there because he already had implemented Kanban in our company. So he invited me and I got the chance to see, this time, very inspiring people too. So David Anderson, Don Reinstein and Stephen Parry. And I discovered the concept. On the afternoon, I played with the Kanban Zine. It's a serious game where you can practice Kanban. And I knew there were some stuff I could pick and it was going to help me as an IT project manager. So I bought the book, the David Anderson book. I took the little booklet.
Stop starting, start finishing. Took this home, read it, and I was ready to start implementing Kanban in my teams.
So I will not go through all this implementation, transformation. I know Claudio doesn't like this term. We're talking more about an evolution because there's no end point. But I will share a few stories with you that I think are interesting.
Just to provide you with a little bit more of context, I was leading a team of about 15 people working on software development. We were already doing Scrum since a couple of years and we already gone through also a lean IT transformation wave. That's why I materialized successful evolution. So the Kanban would have been the next one. I don't know what's the next after that.
So the team was pretty agile already, if I may say, or at least they were really open for continuous improvements. So that was a very good point to start. So to provide some role modeling, I've started my personal Kanban to raise some curiosity. So I just drew my Kanban board behind my desk. We were working in an open space and I was putting in my Kanban system, my project manager tasks. And I got to practice myself before going with the team. I also let the start finishing, stop starting, start finishing, sorry, booklet on my desk, so the people will sit next to me, will just see it, read it maybe, ask some questions about it. So the curiosity started raising the team and around.
Then I organized a Get Kanban game with the team with the help of internal coaches. So they explained to the team, explained the methodology, explained the theory, and then we split the team in two. And they would compete at the Get Kanban game. Do you know Get Kanban? It's a very famous, serious game. You get to practice Kanban as well. It's on IT development context.
So at this time I left. I didn't play with the team. It's very important. So I let them play and everything. So I just came back at the end of the afternoon for the wrap-up. So I offered the candies or chocolates for the team who won. And discussing with the team, I realized that most of the people are really, really understood the benefits that we could get from Kanban. Some of them were really, really excited. And one developer asked me, okay, but when are we going to do that? And I think he thought we were just playing around and we will not do it. So when I answered him, we're starting tomorrow, was very...
was very happy.
So this is how it started.
Then I would like to share the story of the white-white board. So just after that, all the team left. And I erased the board that we had. So it was a scrum board or lean IT board or whatever you call it. But it was important for our team because we were using it every day. We had indicators, we had a lot of stuff in it. So it was nothing to erase it. So I erased it totally. And when the guy, I came early to the office the next day, so when the guy came, the guys came in the office, they were really proud. And at morning meeting, I asked them, okay, now,
You've decided to go with Kanban, so go ahead, create our own Kanban, do what's working.
And the whole team discussed one day, an entire day. They didn't work, they just discussed, debated about value stream mapping, everything, the whips, what we're going to do.
I couldn't not get into the discussion, so I had to force myself to step away, to leave again, not to guide too much discussion. And at the end of the day, we had our first Kanban system, our first Kanban board. It was pretty nice. And it took us a few more weeks with continuous improvements to get something working within the team pretty nice.
So then I started to work on the demand side of our system. So I started to discuss with our clients about what we were doing one floor up.
So it took a little bit of time to get them on board, but they understood pretty well the link type improvements. And they were very happy with live prioritization. We got rid of prioritization committee. So anytime we had room in our cabinet system, they would just prioritize what's the next thing. Best to do now. But somehow I was always stuck with the release cycle, release date planning and everything. And one day my client asked me again, so when is your next release? And then everything became clear and I just answered it's Basically, when you want. Just come upstairs, look at our board, and look at the value we have in the done column, and just tell us when do you want us to deliver. Just take into account, consider that we have like three days of workload of manual testing. to perform the release in production. So if you consider you have enough value, go ahead and tell us. And to visualize this, we've used a special sticky note that we've called a broom wagon, a voiture balai, I don't know if you can say this in English. So everyone in the team knew which was the latest feature or the latest user story of the release. And the clients could come up every day and just move it around, depending on new priorities or new things.
So at the end we were in a position where the client was driving our priorities live, our backlog, continuously, and he was deciding exactly when we would release. So I almost had no job left as a product manager.
So I started to help more and more people around.
This is when we started to work on the right side of our carbon system, meaning the delivery process. So at this time I've read the great continuous delivery book by Jason Bull and David Frehley. And I've passed it around to the team, same way I've done with the Kanban first. And now that we have Slack time, thanks to Kanban, everybody know what Slack time is? Sure.
Since we have slack time, we decided as a team to put all our slack time efforts on the continuous delivery process.
So we had a great, great time doing technical stuff. It was very challenging. The guys in the team loved it. But we were less successful at the politics side of it because we had to convince the architecture team and the operation teams to use what we've built. So we've done in-house stuff, we've benchmarked vendor solutions and stuff. And at the end, we got a lot of improvements, but we couldn't get to the point where we were releasing like every day constantly as soon as the ticket is ready. But I think nowadays maybe it's different because DevOps is a very trendy buzzword nowadays. So maybe you would get much more better than us at this part of your process.
And then what about the other teammates, the other teams around how we coordinate the management?
So it was pretty difficult to coordinate with the other teams, with my pairs, project program or project manager, because they had always the same questions of when are you going to release the next month, what's your release date, when we put in there and everything. So my answers did not really sound well for them. They were not really well understood when I said, but just tell me when you need it and I will put it. We can deliver anytime you want. Just give a phone call to my clients and they will push the release. So it was quite difficult. For the management side, they were quite confused, but at least the clients were happy, so they were happy. And like I said, we already ran into a couple of transformations again, so nobody wanted to take the responsibility of scaling this stuff, even though it was working well.
So this is when I began to become more and more challenging with the client requests. I had the feeling that we were not creating enough value, we were doing things right, but was it the right thing to do? I strongly believe that in such organizations you tend to do local optimization because of the split of the value chain.
So this is our conclusion for that part.
Doing things right is quite easy if you follow the Kanban methodology. It's easy to implement at team level, but very difficult to scale for multiple reasons. So I'm curious about what David Anderson is working on today with the enterprise service planning. I think it's very good to try to present Kanban to senior executives. things right, but was it the right thing to do? I strongly believe that in such organization you tend to do local optimization because of the split of the value chain.
So this is our conclusion for that part. Doing things right is quite easy if you follow the Kanban methodology. It's easy to implement at team level, but very difficult to scale for multiple reasons. So I'm curious about what David Anderson is working on today with the enterprise service planning. I think it's very good to try to present Kanban to senior executives.
So Kanban definitely does not tell you what to do. So this is when we introduce the lean startup thing.
So how did I discover Lean Startup? One day, I always wanted to launch my own company. And one day I was discussing about it with a friend of mine. And I was saying how difficult it would be to leave my comfortable job. And he told me that some guys in the Silicon Valley have written a book and it's about a technique to bootstart companies and that I could even do it, keeping my job, eliminating risk and everything. So I went home, ordered a book on Amazon.
And I was so excited that I also downloaded the book in PDF, sorry about that. And before the book came in by the post mail, I already read it through the PDF and it was terrific. It was exactly what I was looking for, techniques to boot start.
And it was at the same time we were doing this Kanban implementation. So I already felt that the lean startup plus the Kanban thing that we were doing, They sounded like a very nice combo, but didn't know very well how to manage that.
So then I went into all the startup literature, business model generation, of course, and all the Eric Rice series, Running Lean, Lean Analytics and everything. So all of these readings plus our recent success with Kaman gave me a lot of energy to start something.
Since I like to do stuff, I say, okay, now let's try it. So let's find a problem and let's try to solve it.
At this time, our offices of that company just have moved out of town, not out of Paris, but out of central Paris. And in this place, there were very few restaurants. And they were pretty far away. So at noon, lunchtime, everybody in the open space kept on asking, where do we eat today? And the guys say, no, this place, no, I don't like it, or this place, no, the service is too long. And we started to think about this problem. One idea we had was to publish the daily specials of the restaurants around.
Why daily specials? Because usually in France, this is what people order at lunchtime because usually it's cheaper. The service is faster and most of the time it's homemade.
So we wanted to test that. So of course, all what I've said, we've tested it with the lean startup principle afterward. And the bigger vision of the thing I had is that I wanted to gather and maybe later monetize all the ephemeral data that sits out there.
Google, Wikipedia and everything, they're very good to index human knowledge right away, but it's still very difficult to get data that are only relevant for a few hours. So let's say what's the menu, what's the special in the restaurants around? How many, is there any room left in my theater for this movie? This kind of stuff. This was the bigger vision and starting with the daily special was a way to practice.
So let's go. So we had to build a platform. So it's very common. So in a platform you have two sides. The first side for us was the restaurant who would have to post their daily specials. And on the other side it was the hungry visitors who wanted to choose their restaurants for lunch.
So, time to get out of the building. So, at this stage, we thought we needed to start by the selling side of the platform. So, every day, we would go to restaurants and take pictures of their daily specials. So the daily special, either they are outside the restaurants or they're inside. So we had to discuss with all the restaurant owners in this area, about 20 restaurants.
And after a few days, some of them asked us, but you're not going to come every day to take pictures of my board, are you? And I said, yes, we have to. And they just tell us, but how can I help you? How can I send you this picture? And this is where the ID came and they were just sending an email with the picture of their daily specials. And on our side, we would just index that email to a particular restaurant. And this is... What we call nowadays a transparent app, it's very trendy, means that you don't have any user interface and your user is using something he already has. And it was working perfectly for restaurants because these guys do not want to use any specific application. They don't want to use a form on your website. So they were just using the smartphone, take a photo and sending it. So with this, we developed this, like it took us less than two weeks to figure this out. So it's very, very powerful what you can get when you get out of the building.
And then it started to go crazy because at that Lean Startup Conference, sorry, Lean Kanban Conference, we heard the speech of Stephen Parry, who was presenting Sense and Respond. Basically, he was telling that you have to listen to what your customer wants. And maybe we did not understand that very well. So we started to sell to people a whole bunch of stuff. Because we were friends with all the restaurant owners, they started to ask us crazy things. First thing, they were okay, they asked us for websites. So we sold them websites. Then they asked us for social media marketing. So we sold them social media marketing. Then some asked us for paper print of their menu. So we partnered with a printer and we sold them paper print menu. And at one stage, one restaurant wanted to decorate his car, promote his restaurant with a car sticker. And we were about to do it. I was learning in YouTube on how to put a sticker on a car. And then we said, no, we have to choose. We cannot sell just everything to people. And after that, we started saying, no, we had even more weird. Demand. Some clients ask us to fix their curtains and they were ready to pay for that. Some others wanted us to decorate their restaurants.
I have to thank Stephen Parry because it's very crazy when you build a good relationship with your customers and you actually listen to them, you can sell them a lot of things.
It's incredible.
So afterward, we started to work on the demand side of our platform, meaning the visitors. And we started to use more lean startup principles and techniques. So first of all, we run some interviews to gather what we call qualitative feedbacks. And we verified that quantitatively with surveys, for example. We've discovered pirate metrics at that time. We've heard about it during the conference. You know, acquisition, activation, retention, revenue, referral. You have to pick the one metric corresponding to your business model and your stage.
And we start to work with experiments as well. So, for example, we would test if we would get more visitors if we put stickers in the board of the restaurants. So we just go with 20 stickers and figure out, okay, that would work if we have 20% more visitors. So we started to run this type of experiments. One other experiment, for example, we figured out, okay, it's easy to go to rest. restaurants and ask the people and index them and have them to post their menu, but it will never scale. What about if we do it by phone? So we just say, okay, what would be a validation criteria? If, I don't know what it was at that time, but if 40% of the restaurants are okay to go on a platform after a phone call or only by phone calls, this would be a success. So I would just pick 20 or 30 restaurant numbers in Les Pages Jaunes and call them and try to have them on the platform. And so on and so on. This was very cool. We were using really this lean startup thing and we were learning a lot.
The downside of it is inside the building, because we were developing like anything we had to run these experiments, sometimes we needed developments, plus we were developing, improving our product. And at this stage we were very bad organizing our work. And one of us was already full-time, but the two of us, because we had another person joining the project, a UX designer, we still had a daytime job.
And we forgot everything that we've learned and we've done with Kanban and Agile and everything. We were just doing stuff. As fast as we can. And one day, an experiment got us stuck for a very long time. We were expecting more visitors if we had a neat design. So we started to revamp our website. And it took us weeks working at night. And I have to say that this took us a lot of energy. And it was important to the rest of the story. And at this time, when we were doing things, we stopped learning from our customers. We stopped selling crazy stuff and we stopped seeing people. It was very, very bad.
So during this journey, we've realized that building such platform requires a lot more than IT development. Operations and business developments are really time consuming and if you can code at night, you cannot call your customers or index new restaurants or sell stuff at night, it's very difficult. We've also realized that reaching the scale that was required by our business model would be very difficult. We'll still have to solve a lot of issues through experiments. One opportunity that we've had was to maybe close down the website and just offer a service for restaurants to promote their activity online, basically. But one competitor, a French competitor, was already doing it pretty well and it was very well funded. So we decided not to go at this battle and we stopped the project. But at the end we've learned a lot. We had a team, we had an IT infrastructure, and we had already coded some generic components that we would be able to reuse.
So our conclusion for the lean startup part is that
Doing the right thing is very hard. It's very fun, but it's still very hard. Fortunately, along the way, we found something more interesting.
So during the year where we built this website called Near and Fresh, we started to get into the Paris startup ecosystem and we've identified that there is a real lack of technical founders or CTOs. Almost every month one of us got a proposition to join a startup as a founder to help them launch their thing.
So we've launched what we call the Startup Studio to solve this problem and help talented people build their company. So how does it work? We partner with entrepreneurs. So basically they come to us with an idea. And if we like the idea, we partner with them and we act as a founder. So we take equity stake and we launch the product. And as soon as there's some activity, some clients, or ideally as soon as we raise funds, as a founder, we start to get paid for the new features. So this is what we do. we do now.
And also we go further than regular CTO because we offer lean startup advice from what we learn. We offer UX, design and of course mobile and web development.
So the first step of that was about one year ago, was de-risking our business model again.
So we have identified three main risks. First of all, we had this feeling, but we had to verify that the demand was high. So how did we manage to do that? We just went to events where people are supposed to meet co-founders. And we've identified, so there's one in Paris called Adopt a CTO, for example, but there's many. And in such meetings, there's like a ratio of one CTO for three business ideas, basically. So we were pretty confident that the demand was okay. Secondly, since we were going to require a fair amount of funding, either for us or for our startups, we went to the investors to present our idea and to see if it was appealing.
So I went to pitch the 20 business angel networks present in Paris, and we've got some interest. Some of them rejected us. And the most important question we had for the one who rejected us is, okay, you don't want to invest in my startup studio, I understand, it's not your business, but if one of our startups will get any traction, will you invest in it? And the guys who rejected me really violently, they say, yeah, okay, no problem, I will. So this was a very important green light for us as well.
And then the third thing we had to verify is the legal setup. Because we had to contractualize the equity and plus we have to solve all the intellectual property issues. So we went to a lawyer, we took a good lawyer in startups and after one or two meetings we had many options to run this setup. So with all these green lights, I was really confident and I quit my job.
So again, stop talking, let's go to action. Let's do the first project. So we partnered with a doctor. He wanted to launch an app in order to improve the well-being of people. We liked it because he really had what we call an unfair advantage because he was pretty famous in this area. And on the other part, the business model was a bit tricky, but we went for it. We liked it. And we helped him with his partner to define their minimum viable product, their MVP, and we started to implement it. So again, stop talking, let's go to action, let's do the first project. So we partnered with a doctor, he wanted to launch an app in order to improve the well-being of people. We liked it because he really had what we call an unfair advantage, because he was pretty famous in this area. And on the other part, the business model was a bit tricky, but we went for it. We liked it. And we helped him with his partner to define their minimum viable product, their MVP, and we started to implement it.
And we had to go through mobile app development. So we had to learn everything about it in a few weeks. It was very exciting.
It was part of a plan because we needed that to launch startups because nowadays everything is about mobile and data.
And again, doing that, we forgot most what we knew about Kanban, Agile and everything. And mobile app development, I'm not even talking about continuous delivery and everything because it's very difficult to industrialize and you have to be there the first day. If anyone put a bad comment on the app store the first day you launch, you're dead. No one is going to download your app. So you cannot iterate. As often as on a website, you can start with really crappy, you have to launch, so it's a totally different approach.
But at the end, we managed to launch our first app within a few months. It's called Smile Life. It's available on the French App Store and Red Store. And we got some pretty good feedback, so we were happy with this.
But now, what about Kanban?
Celine Kanban Conference. And now I admitted that on both of these previous projects, we were just doing stuff. Maybe we had a trail board and that's it. But now things have changed. We have two more startups to launch very quickly. And we need to be very consistent and organized. So based on everything that I've shared with you, all of our learnings, all our previous experience, all the things that we've did wrong,
we've built the version one of our operating system. And this is what I call the Lean Kanban Startup. And I'm going to share with you now.
So this framework is our answer to the question how to bridge the gap between vision, strategy and daily operations while staying really, really focused. And we know And we've learned it the hard way that it is very difficult to achieve in a small team. Because in a small team, you're a CTO, you're a coder, but you're a founder, so you participate in the strategy of the company. And when you're a CEO, you're a founder, but you also do a lot of stuff. And it's very difficult to think about the strategy and then to get things done on a daily basis. Either you get lost on either side.
So we did not invent anything at all, we're just using, combining and adapting principles and techniques that are very well documented in the startup and agile community. So what you will find in this framework is documents that will help you define your strategy mainly, Kanban systems to help you test and execute your strategy, techniques that will help you to focus on what needs to be done now, it's very important, and also the meetings that will set the cadence that will also help you to stay focused.
So, on the top, the four first boxes on the top, it's what we call the strategy layer. It's composed of a lean canvas. This is your business model, basically. Your vision. This is something big and appealing. And this is where you want to go. And a plan. It's very important. You need to have a plan. How do you get from now to that vision?
Then, on the bottom side, we have what we call the execution layer. And it's composed of three Kanban systems. The first Kanban system is for experiment. Either they are risk reducing experiment or learning experiment. The second Kanban system is for product development.
So basically we'll put your software in there. And the third Kanban system is for all other operations, for getting things done. And the technique that we have is the thing in yellow where you need to stay focused. So we're using things such as unique value proposition, one metric that matters, and so on. So let's go through this.
So in the strategy layer, you will get your lean canvas that describes your business model. I'm not going to describe all the lean canvas now. It's very well documented and I'm sure most of you know already about it. But what's important for us is to stay focused throughout your journey. And to do that, you need to define very well your unique value proposition and the associated customer segments. For example, at MVP Star, we have three customer segments. The first one is graduates from business school. The second one is experts in their field, like the doctor, which I partner with. And the third one is serial entrepreneur. And the unique value proposition will be different for these segments. So for graduates,
Our proposition would be launch your startup without money, for example. For experts, it will be launch your startup without IT skills. And for serial entrepreneurs, our proposition would be launch your next startup within three months.
And you're not going to work on all these segments in parallel. So you have to put in this document what you are working on now.
You also need to have a vision.
Everybody talks about vision. Why do you need to have a vision? It's required if you want to attract anyone. And when I say anyone, I mean any partner, any employee or any investor. If you don't have a vision appealing enough,
No one will get on your goal.
We don't have a template for that. Usually it's just a pitch. You can pitch that vision. For us, for example, we just want to help entrepreneurs across the globe to launch hundreds of successful companies and create thousands of jobs.
And then you need a plan. So this is the part that usually people don't have. They're really good at having a very big vision. But if you have a big vision but not even a clue on how you get from now to that point, it's useless. So maybe you need to stick to a smaller vision, but to really have a plan. So this plan can be a business plan. For example, you can put financial in that, but it's not necessary. It just needs to be a plan on where you go from now to your vision.
must be ambitious and realistic too. And you need that as well if you want to onboard people.
So what we suggest as a cadence is to review this monthly with your advisors, your board members, or your investors.
And you will also, in this monthly meeting, get some results back from the execution layer.
Execution layer is where you get things done. So, strict and bound system. First of all, we've talked about it, experiments. So, it's derived from your strategy, basically. And depending on the phase of your project, you will either run risk reduction, let's say at the very beginning you have to reduce risk, and then you will focus on learnings. So we discussed about the one metric that matters. So for example, if you're really early stage, you want to focus maybe on activation or maybe on retention. So what we propose is just to stick that on your board to help you prioritize
the correct experiments that you have to launch because you have a limited capacity.
And what you do is that you review these experiments. on a weekly basis, for example. Some experiments will take you a longer time to gather data. And then you have a more traditional Kanban system for product development. So at the beginning, you will focus on your MVP. So this is important. You get your value proposition in your Lean Canvas. And this helps you define your MVP. So this helps you prioritize in your product development.
Kanban. And then when the MVP is out, you follow the traditional value-driven or cost-of-delay-driven prioritization in this board.
And we've launched another Kanban system, might be confusing, but for all the other stuff that needs to be done. And it's more GTD oriented, so it's very basic, where you have to-do progress done, and for there to stay focused, you're going to use WIP limits. So why we've separated the operation from the software? It's because it's more and more trendy, for example, to communicate to your customer your progress, meaning that you can share your product development board.
And you can keep your day-to-day tasks on the other board. And sometimes also if you're in continuous delivery thing, you want to automate some stuff. So it's a good reason to keep the software development apart and to have the tickets like I need to go and sign this contract apart from that. You don't need to continuous deliver. And what's important is that you're going to review these daily with the team.
So with this, it gets you a good thing to
Have your strategy, define your strategy, and execute it.
So you're supposed to be equipped to do the right thing right.
So it's the end of my speech. In conclusion, what I can say is that from my experience, Kanban, large companies, great result at team level, but difficult to scale.
Lean startup, it's great for customer discovery, customer development, but it's definitely not an operating system. And maybe with this lean Kanban startup, combining lean startup principles for strategy and focus, and the Kanban execution, you get a very, very nice combo. Thank you very much.