According to the book Extreme Programming Explained: Embrace Change by Kent Beck, “The basic problem of software development is risk.” One of these risks is that of the schedule slip. In this episode, we discuss how to use XP to prevent schedule slips when developing software. Tuning in, you’ll hear about how XP addresses the problem of schedule slips through short-release cycles, what a Big Bang release is and why you want to avoid this, and the value of prioritizing the most important features in your schedule first.
Key Points From This Episode:
[0:00:01] MM: Hello, and welcome to The Rabbit Hole, the definitive developers' podcast. Living large in New York, I'm your host, Michael Nunez. Today, we'll be talking about schedule slips. Is your schedule slipping, falling, can't get up? Use Extreme Programming to help you prevent that.
First and foremost, I want to apologize to any of the listeners who have made it this far. I've been – I'm having a couple of schedule slips myself. I haven't been able to release episodes in which you may have heard quite a few replays in the past. Both Dave and I are still in clients that are quite competitive. But now, I'm actually able to do some recording. Moving forward, we'll try and release a new episode every two weeks, enough that I can get a backlog to be able to provide y'all with some content.
During the time that I've been working, we have training that we do here at Stride Consulting, we call it that The Baseline Training. One of the books we actually read over is Extreme Programming Explained: Embrace Change by Kent Beck. That book just kind of gives you an overview on why XP is a preferred way of practicing agile. I think for the next couple episodes, I actually want to go through some of the basic problems, because that's a chapter that we read together, and I have conversations with folks. But I guess, I can just point people to these particular episodes if we need to.
If you haven't noticed, the title is a reference to the DMX song called Slippin', so rest in peace. Chapter One in this book talks about the basic problems and their multiple bullets. Today, we'll be talking about schedule slips. I'll start by reading: “The basic problem of software development is risk.
Here are some examples of this risk:” schedule slips being one of them. “The day for delivery comes and you have to tell the customer that the software won't be ready for another six months.”
Let's pretend that the customer isn't the government, I think government normally has requirements that are really, really strict, they don't move. And if you don't make a schedule, then your product cannot go live. I have some experience with that, especially in finance. Sometime after 2008, there were a lot of different requirements that were needed for some brokers, in which we had to ensure that those things that happened in 2008 won't happen again. They applied some really strict requirements that the piece of software needed to follow.
Let's pretend that it's not one of those kinds of situations. But instead, it's something where you're able to build something for a particular client. The day comes, they expect that day to hit. Suddenly, they find out that it's not going to be delivered at that time.
The solution, as mentioned in the book, “XP addresses this because it calls for short-release cycles, a few months at most so that the scope of any slip is limited. Within a release, XP uses one- to four-week iterations of customer-requested features for fine-grained feedback about progress. Within an iteration, XP plans with one- to three-day tasks so that teams can solve problems even during an iteration. Finally, XP calls for implementing the highest priority features first. Any features that slip past the release will be of lower value.”
The idea of the schedule slip, the average team who isn't practicing XP is probably thinking that every single piece of features are important and you try to tackle all of them at the same time. What's the phrase? How do you eat an elephant one piece at a time? You can't just go and eat a whole elephant at once. That will probably explode your stomach. The idea is that you have to break the work down. The way you do that is by prioritizing the highest feature first, ensuring that you deliver that, and get that out the door.
Schedule slips, also in XP, you ensure that you're not doing what's called the Big Bang release, as I call it. I'm sure that's what it's called in other places. I didn't make that up. But the idea is that the team will deliver a piece of software in one go, like the Big Bang. Before, there was nothing, and then the Big Bang happened. Very similar with your piece of code. Before, this feature didn't exist. Then all of a sudden, you have an entire rewrite of an application.
That's not usually the way that you want to deliver software because you want to give an opportunity for the customer to give you feedback about things. Now, would you rather have receive hundreds of feedback because you turned on a whole slew of features and then get bombarded with positive and negative feedback? That could be one way. The other way is, you priority have ties to things that you need, deliver that, and then show that to the user in which then you can get feedback. How do you know that the thing that you're building is the thing that they want? One way to address that is by simply getting it to them as fast as possible.
[0:05:16]
Something I want to call out in this particular passage, and I'll read again, “Within an iteration, XP plans with one- to three-day tasks so that teams can solve problems even during an iteration." You want to make sure that the work that you're doing is small enough that it can be completed for a given iteration. Whether that's one week or two weeks, that's up to your team's decision. If anything takes more than three days, you might want to cut that down a little bit so that you can still deliver some kind of value to your users.
Lastly, when you're delivering a particular set of features since you've been delivering incrementally. When that scheduled time comes and say you're not ready to deliver all the features since you've prioritized the highest ones first. By the end of that delivery date, the things that may not have gotten delivered would have been lower-priority work. It's like, you're less risky about having your schedule slip because if it does slip, you know that it's the thing that's of lease priority.
To address the schedule slips, make sure that you are breaking your work down into one- to three-day pieces of work. You prioritize them to make sure that the work can get completed of highest priority. You try to ensure you can demo this to your users and your stakeholders to make sure that they agree with the thing that you're building. Continue that work until the scheduled time comes. Hopefully, you get to deliver every piece of features and feature sets that were being requested. If you for whatever reason, cannot, you already know that you delivered the highest prioritized set of features.
XP is one of those ways to do that. I know there are other agile methodologies that also helps you with that. I might bounce around a bit in this particular list. But yes, hopefully, for those who are practicing agile and XP that you have less scheduled slips. For those who aren't, feel free to give this a try and let me know what you think.
[END OF EPISODE]
[0:07:33] MN: Follow us now on Twitter @radiofreerabbit so we can keep the conversation going. Like what you hear? Give us a five-star review and help developers just like you find their way into The Rabbit Hole. Never miss an episode. Subscribe now however you listen to your favorite podcast.
On behalf of our producer extraordinaire, William Jeffries, and my amazing co-host, Dave Anderson, and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.
[END]
Links and Resources:
Extreme Programming Explained: Embrace Change
“Slippin'"
