#begin
Next up is chapter 4 ‘Working iteratively’ and it’s the first chapter of the second part of the book called optimize for learning.
David starts this chapter of with a definition of iteration: “a procedure in which repetition of a sequence of operations yields results successively closer to a desired result.” So iteration allows us to learn, react and adapt what we have learned.
This fits very nicely with agile right? I mean that’s the entire point of agile workflows. We work in small manageable steps towards solving a complex problem. Practical advantages of working iteratively is that we can measure finished things.
Back in the day, during waterfall, it was very difficult to measure units of completion. But when we move towards a more agile approach where we work in small steps we can cut these units of completion into smaller parts and then we do have a way to measure them. So the reduction in batch size is a big step forward.
One of the more subtle advantages of working iteratively is that it provides us with choice! We can choose to work on x, or maybe prioritize over y. We can steer the project towards the direction of higher-value outcomes based on feedback from customers. This is very powerful because, let’s face it; customers most often do not know what they want. But they will see the possibilities of what they are asking after a couple of iterations. So then you choose to switch direction a bit to support their vision. Now that’s powerful.
Another advantage of working iteratively is that it can be used as an defensive strategy. When working in iterations we can minimize the cost of change. Imagine back in the day during waterfall when big changes had to be done. Lots of the process would have to be reverted and redone. But when working in small steps, you can change in small steps too. And when you combine this with proper software development techniques you should be able to change important architectural choices.
Remember that surprises, misunderstandings and mistakes are normal in software engineering because it’s an exercise in exploration and discovery. We need to find learning in this and optimize for it.
So what can we do to work this way. Well first thing is to adopt some iterative work style. This could be SCRUM, eXtreme programming or some other agile process. The crux of the story is to work in smaller batches. We need to reduce scope and changes need to be made is smaller steps in order to reduce costs. We also need to set expectations and assumptions in regard to these small iterations. We need to be adaptive and agile to adjust direction based on feedback. So stubbornly working towards an end goal nobody wants is not the right way to go.
David then goes on to say that on a different scale; Continuous Delivery and Test Driven Development (TDD) are at the heart of any iterative process. In CI you are going to deliver changes multiple times a day which gives you a lot of feedback and opportunities. TDD on the other hand is truly an iterative process. The TDD cycle forces you to work in small steps. There’s just no way around it because it’s designed to be iterative. You write a test, make it pass with the smallest possible change to production code, refactor it to fit the application style and architecture and restart the cycle again. Combining these two practices will form the foundation to force you to work iteratively.
#end
01010010 01110101 01100010 01100101 01101110
Recent Comments