S2E35 – Vacationcast – Iterate!

Show Notes

 Andy discusses the importance of iteration and feedback in the development process. He emphasizes the difference between iteration and incremental progress, sharing a story from Kent Beck’s ‘Extreme Programming Explained’ to illustrate the concept. Mon-Chaio returns next week when they will discuss the Peter Principle. Stay tuned!

References

• Extreme Programming Explained – https://archive.org/details/extremeprogrammi00beck

Transcript

Andy: Hello again, to another episode of the TTL podcast. This is a vacation cast. So what am I going to talk about today?

I think. I think I’m going to talk about iteration. And specifically, I’m going to talk about feedback and iteration. So, this is on my mind right now because the client that I’m working with. Really needs to work on iteration.

And the reason I say this is because we have long release cycles. We have a. A development process that lets things just kind of go down a waterfall approach. And you might think, oh, but we’re, we’re doing scrum. We’ve got the scrum board in JIRA. We’ve got weekly iterations, weekly sprints. Our, sorry, not weekly sprints.

We’ve got fortnightly sprints. So every two weeks.

But the thing is within this, there’s actually no iteration. There is incremental, but not iteration.

And I think the thing

that is missed about iteration, is that iteration, lets you go back and try again. Whereas incremental is building one thing on top of another, where you never going back to revisit.

And this is really important. Because iteration is what you, what you need to steer a project to steer a team to steer delivery effort.

Without the iteration, we have almost no opportunity to steer.

And I bring this up. I’m looking at the. At the first edition of extreme programming explained. And chapter six in that book. It’s it’s actually just about, um, Kent Beck. A story of him learning to drive.

He was being taught how to drive the car by his mother. And he nearly takes the car off the road. And then he says that his mother told him “driving is not about getting the car going in the right direction. Driving is about constantly paying attention, making a little correction this way, a little correction that way.”

And that’s what iteration is about.

That’s what feedback cycles of iteration are about and why we want so many cycles. So many fast cycles, so many, slightly longer cycles. So many even slightly longer cycles. Each one of those gives us that chance to steer.

And so this happens at the level of writing the code. The test driven approach or test last approach, but either way, doing very small iterations through your code.

This happens at the level of how you approach completing a story. A user story or something like that.

I know the term, uh, thin vertical slices. I believe others call it elephant carpaccio. But the idea is that rather than taking a complete user story and saying, oh, well, I’m just going to complete that whole thing and then in five or six days. It will be done and we’ll be able to test it. You actually do it in little tiny pieces where you might do it as much as first a link appears on the page and then that link takes you to a blank page. And then that blank page has a bit of nothing text show up, a lorem ipsum quote. And then you add a bit of data from the database of what you actually want to show on there one, one field at a time. And the thing is, is each one of these. Each one of these steps is visible, not just to you. But to your whole team.

And so you’ll, you’ll be sending through sometimes a feature that isn’t complete. And that’s that’s right. And in fact, that’s, that’s desired. If you’re, if you’re aiming for iterations. And this, this one particularly was on my mind because I asked a team that I’m working with. I said, yes, please work on that.

And they said, but but it’s blocked on this other work. And I said, well, what happens if you work on an it. And it’s blocked. They said, well, we won’t be able to finish the whole thing.

And I said, well, could you fake out, could you mock out, could you just return dummy data? Until that other work is complete. And they said, yeah, but that’s not good practice.

I would disagree. I think it’s. It is good practice because it, it lets us get that feedback. It lets us iterate long before this other piece that may be as much more complicated is complete. And in fact, if we sliced up our work differently, that that much more complicated piece that we’re blocked on would come through in multiple iterations a little bit here, a little bit there as we build it up. And each one of those passes, not only do we get to revisit all the stack, all the bit of code that’s being written. And fix up the design as we go, as we, as we come back and we learn like, oh yeah, I tried that way of connecting these components together it wasn’t all that nice. I’m going to try this way. Oh, that’s much nicer. Okay, cool. But it also lets us show that to the product managers, to the business and say, here’s what each part of this looks like. Did we have it right? And bugs might come back and we might be able to say, oh no, that that’s, that’s just not finished yet.

That was our next pass. Uh, look at the next build and there it is. Or you might find out. Oh, they didn’t want it to work in that way. They wanted it to work in this other way. Now, we’ve just learned that after maybe two hours. Rather than, uh, six days.

And so we have these multiple cycles of iteration. That are so important in us making progress.

But I think one of the reasons why we don’t do it all that often is it feels like going back and reworking something is wasteful. Or putting out something that’s knowingly half complete is unprofessional.

And I think that’s what we need to get over.

That we’re not looking for the highest utilization of our team. We’re looking for the highest effectiveness of our team. And effectiveness in reaching that outcome.

And to do that.

We need a lot of chances to get it right. So, how do we make more chances to get it right?

And that’s where I think we’re all leave you. How do you get more chances with your teams to get it right?

Mon-Chaio we’ll be back next week. Where our plan is to talk about the Peter Principle. So stick around. And until next time, be kind and stay curious.