Episode transcript The transcript is generated automatically by Podscribe, Sonix, Otter and other electronic transcription services.
Hello, everyone, welcome to the Five Minutes Podcast. Today, I like to talk about cadence and why this concept is so important for you to understand the deliverable of your project. The first thing I need to start by explaining why should we care about cadence and why is cadence? Cadence is a rhythm. It's the rhythm of your project. For example, when you have, for example, your heart, beating the heart beats in a frequency, and this frequency gives us some kind of predictability. For example, if your heart beats once every second, you know that in the next second you should expect one heartbeat. And the following second another heartbeat. If I tell that you give two heartbeats every second, I should expect that your heart will be twice in the next second. It's like, for example, true marching. And there is a marching cadence when you see, for example, parade and you see that the foods they all the time, every single people on the troop they hit in the floor, the same food at the same time. And this gives some kind of rhythm. And this is the cadence and the cadence provides what? Provides predictability and reliability on what we produce. Of course, there are basically four types of cadence. Many people don't believe that the two first ones could be considered cadence. I prefer to say that it doesn't matter if between one event and the next one that provides your cadence. It's one second like the heart, or if it's six months, like, for example, construction project. These is cadence. Ok. Of course, there are cadence that are more suitable for one type of project than for the other.
So the first one, it's called the single delivery and this single delivery, it does not look like cadence because it's like, imagine you have a heartbeat at the beginning, and then it comes to an end of the project. So it's something like zero or one hundred percent. You have just a single delivery. Of course, in this kind of project, the concept of cadence, it's not extremely valid because you need to wait maybe five years, maybe three years, maybe 10 years, or even, for example, on James Webb Telescope. Twenty five years plus something like six months after the launch to know, OK, did it delivery? Of course, we are talking about deliverables like the launch of the telescope. We're talking about opening the mirrors and this. But what is the actual value delivered, the value delivered when scientific images comes to the Earth, and scientists can make discoveries using that kind of photo, right? This is where the deliverable will happen. For example, I don't care as a scientist if the mirror is open or not. And please, I'm not saying this is an absolutely spectacular project, but I'm saying that this kind of project is extremely complex for you to create multiple value deliverables. Because how do you say, OK, let's release the mirror and let's start taking photos on the journey? Maybe this will not add anything in terms of scientific approach. The second type is multiple deliverables. And what's the difference between this second, multiple deliverables and periodic deliverables? Because it seems the same like several deliverables that you are delivering between the beginning and the end of your project.
However, multiple deliverables, they are not respecting a fixed cadence. For example, you may have one deliverable on month one and not a one a month eight another one a month twenty one, another one a month thirty eight another one a month sixty. So they don't respect, I would say, a periodic pattern. And this is why so many people say that this is not cadence, OK? And I don't want to discuss that and go into this discussion. But one of the approaches is to do that. So you create deliverables, milestones in your projects and based on these milestones, you create these deliverables. The third one, this is on the heart of the agile methods. For example, scrum or lean is the concept of periodic deliverable. For example, every two weeks, every week or every three weeks, you produce something. This is extremely used in software. For example, every two weeks you produce something. There is a cadence and a sets of expectations that every two weeks you will deliver something. And this is the core of what we call agile cadence. Or agile delivery cadence that you can see in safe and several other methods. And there is one that is even more extreme than periodic deliverables is the continuous deliverable is that instead of waiting two weeks, let's suppose you have a cadence of every two weeks to deliver your products. But at the end of the second day, you already produce something that could benefit the client.
What do you do? You just release it. You just release it. You don't wait the end of your sprint to release it. You release in a continuous mode. Of course, it adds a lot of complexity. But these, for example, is one of the routes that the Spotify model, the Spotify model, works a lot on this concept of making continuous deliverables. Of course, when I present this single, multiple, periodic and continuous, I would love that all of us, all companies or projects they deliver on a continuous basis, right? Imagine you're building a house where you put the floor and people start putting the sofa and join the TV on it. But it's not simple like that, right? So some projects you need to have, for example, two weeks. It may be a good time frame for deliverables in a software environment, but if you are working, for example, in oil or mining, two weeks is nothing. Two weeks is maybe what you need just to train the people to use protection devices and protection equipment to go in the mining inside the mine. So it's tricky to say that, OK? You should always try to short because in some kind of projects there are limits. There are even physical limits for you to deliver faster. And what is my advice to you and what do I do in many complex projects that I work that relate pieces of technology, pieces of infrastructure, pieces of Lego, pieces of, I would say, technical requirements. I create different cadences for different types of work. For example, on the technology side, I can use agile and create a cadence or using a sprint that every two weeks will deliver something in the other areas.
For example, like regulatory, I create an aspect of multiple deliveries. Why? Because I don't have the control over the conception of the public authority. It may take one week or it may take half an year. So I need to understand that every two weeks will not make sense on that specific case. This is why it's so important for you when you frame your project and when you plan how you want to accomplish and transform that idea into reality that you know exactly which kind of cadence, which kind of approach for you to deliver the value to your customer you will use? Of course, I would love to avoid single delivery at all costs. Sometimes you can do that. Sometimes it's extremely challenging to do that. Like the James Webb, I don't see anther possibility of using a different cadence on that kind of project because it's so technological, advanced and it's so complex and it's so risky that it's very hard for you to deliver, for example, all let send shots from Earth. And then when we move, we take another shot so scientists can start using. It doesn't make too much sense. So this is why it's so important for us to understand how will be the heartbeat of our project in order to deliver the value to our customer. Let's think about that. I hope you enjoy this podcast.
See you next week with another Five Minutes podcast.
