From the course: Azure for DevOps: Designing a Strategy

Setting timelines and goals - Azure Tutorial

From the course: Azure for DevOps: Designing a Strategy

Start my 1-month free trial

Setting timelines and goals

“

- [Instructor] Let's first start talking about setting goals. What exactly are goals? Goals are clearly defined measurable outcomes. These are things like reduce your defect count by 20%. Clearly defined, we want to reduce our defect account, but we also want to reduce it by 20%, again, a measurable outcome. Or increase the uptime by 10%. Or possibly even increase the release frequency by 20%. I think you get the idea here. We're clearly defining the measurable that we want, and then we're actually saying this is the measure that we want to have as the outcome. Now we'll talk about creating timelines. And what are some of the characteristics of a good timeline? For example, a good timeline should probably have a short duration, but nothing too short, okay? 'Cause all goals need timelines. You can't just have goals and have them open ended as to when they may be completed. You want to set timelines around those goals. So we want to have these short durations of timelines. We don't want to have a six-week timeline, but we don't want to have a one-week timeline. So keeping it between two to four weeks is a great start for setting your timelines for your goals. Again, that can be adjusted as you start to work with things, but you'll get the idea of how to set up your timeline correctly. They should be achievable. All timelines should be achievable. You shouldn't think so big that you know you're not going to make that goal. For example, you may say, "I want to complete this piece of software "in the next three months." It might be a nice want-to-have, but you may never be able to achieve that. But to say, "I want to complete this feature "in the next three weeks," now that's something that could be very achievable. So, again, you want to make these challenging, but they also need to be achievable timelines. Rapid feedback, again, rapid feedback is really important for the teams to be able to understand and get some actionable learnings back into the system so they can make course corrections as necessary. That feedback is vitally important in DevOps, and it's one of the pretenses in DevOps is to make sure you get rapid feedback so you can course correct or take actionable learnings and improve your system or your processes as you go through. So let's talk about some of the advantages of going with these shorter, achievable timelines. First off, it's going to allow you to make it easier to pivot your priorities. If you have to change direction very quickly, you'll have the ability to do that. You can also have a shorter timeline, which is going to give you the feedback loop is going to be a lot shorter, and your learning loop is going to be a lot shorter, which is what you're looking for. And you're going to be able to incorporate any of those learnings into any of those outcomes as you go. So, again, it's really to your benefit to keep these timelines short and achievable to get that rapid feedback. And last thing you should do at the end of each one of your timelines, especially if it's in a development timeline, is to retrospective on that timeline. And make sure, what did we do well in this particular timeline? What did we not do so well? Where could we improve, I'd like to say. What worked, what didn't work? And how can we get better, really? And that's what you want to do at the end of each one of these timelines, is make sure you take a retrospective, and see, how can we improve? Again, that's what DevOps is all about, is continually improving also.

Contents