This article on iteration is part 7 of an 8 part series on the Agile Mindset. You can read the first part, about focus, here.
One of the common things to point to as “evidence” of an agile team, culture, or environment is the use of sprints. However, having sprints in the development cycle doesn’t yield business agility. In some cases, it doesn’t even mean you are following scrum. A sprint doesn’t equate to iterative development; it can, but often times, we miss the point of a sprint and how it rolls into iterative development.
Sprints, What Are They Good For?
In scrum, the center piece of time in development is the sprint. According to the scrum guide, the sprint can be a month or less. However, chunking out time throughout a span of a project is the easy part. Which is why anyone and everyone can refer to sprints in their work. However, the output at the end of the sprint is often what gets overlooked. It’s the output that determines whether or not you are using the concept of iteration to your advantage.
The scrum guide states that the sprint is used to create a ” ‘done’, useable, and potentially releasable product increment”. This is the harder part, but necessary for sprints to actually work. If you are following scrum and aren’t producing something that is useable, you’re just marking time off the calendar.
The Product Increment Explained
The key to making a sprint actually work toward incremental development is the product increment. The keyword in this term is “Useable”. If you are at the end of a sprint with something that doesn’t work, it isn’t a product increment. Your output at the end of the sprint only matters if you can get it in front of people. You should be getting the product increment in front of people pursuant to additional feedback, collaboration, validation of a working product i.e. the first three values of the agile manifesto. This is where the iterative nature of the scrum framework gets implemented. As you put your product out there for review, you should be finding ways in which the product can be iterated. Iteration fuels the entire process and brings value to sprints.
Now, just to be clear, the product you release at the end of the sprint is an increment. It’s a minimum viable product. It isn’t meant to be a fully functioning thing at this point. However, it is meant to be useful without being a fully-fledged product. That’s what you need to focus on in your iterative development. Your end product of your sprint needs to be useful to your user. If not, you are not iterating or haven’t given yourself room to iterate.
What About Non-Scrum Frameworks?
A lot of companies use scrum as their framework of choice. However, there are various companies that find Kanban more useful, or some other framework. In Kanban, for example, sprints don’t exist. Time is isn’t boxed up into manageable chucks. The expectation is that you should be continuously pushing out releases. So, the question the becomes: how do I iterate without sprints?
As covered earlier, sprints does not equal an iteration. Even if you are using a framework without a “sprint” you can still be iterative in your work. You can be iterative in the way requirements and acceptance criteria are elicited. You can be iterative in the way development is done. Iteration also can be applied to the way you test. However you work, you should take an iterative approach. This means, do something small, get it in front of people, then refine it based on that feedback. Do that with your requirements, your features, your test cases, yourself, and your team.
Why Iteration Matters
Being iterative in how you work allows you to learn more about the product in pieces rather than all up front. This means that you lower the risk of misunderstanding a requirement, or even missing a requirement all together. Additionally, being iterative in your work allows you react to change quicker and better — one of the key values of the Agile Manifesto. If you are doing complex work, with complex solutions, an iterative approach is always the better way to manage the scale and complexity. Often times, the work we are trying to accomplish can feel like trying to hit a moving target. Using iterations ensures that you can adjust with the moving target rather than missing altogether.