💡 Tips for Iterative Development

What makes iterative, incremental development tricky in practice?

You may not (and likely don't!) have the right answer initially, but you can:

This requires some tradeoffs:

Requires engaged stakeholders who are willing and able to be involved throughout the development process
Funders might require a detailed, long-term plan in order to get grant $

Iterative development doesn't mean we'll be done when we're done
We can still forecast timeline, but we do it in shorter increments (i.e. sprints)
This may be a big adjustment for some team members and stakeholders.
- You will re-frame the builder <> stakeholder relationship from transactional to collaborative. Their engagement in the development process will give them a nuanced understanding of progress via continuous delivery of value.

The goal of each cycle is to reduce ambiguity and make clear, measurable progress towards the ultimate solution.

This often looks like defining a concise hypothesis or evaluating an approach to solving one piece of the problem.

Cycles are short - weeks not months.

Purposefully and deliberately use "failure" to find success - perfect is the enemy of the good enough
Over time failing forward helps us get better at mitigating risk
- … BUT there will always need to be some tolerance for risk
- Re-evaluate after each iteration (eg 2-week sprint)
  - This keeps risks from growing like they might if the only evaluation happened at the end of the project

A key goal of iterative planning is to avoid over planning - since this is often based on 🔮"mythical certainty"
Each time you come to a decision point, consider:
- 'what is the best option given what we know at this point, which will minimally limit future options'
- This framing can help ensure iterations are thoughtful and well-engineered
- iterative != scrappy
Always consider what decisions must be made now, vs those that can wait
Eg:
- Choosing a newsletter's title text design doesn't need to block selecting the stories that will be included
BUT, always consider how each choice made might impact possibilities farther down the line
- AKA - don't build yourself into a corner by making hasty decisions

Sometimes you will scrap something you spent time on - that's ok❣️
Use what you learned in the process to come up with a better solution.
- See "Fail" forward ▶️👆

Be thoughtful, but don't dwell on having perfect data before making a decision
Capture why each decision is made and what information you used to come to the conclusion
- This is in service of your future selves and teammates
- Eg: We looked at both X and Y as database options - here are the pro/cons we found for each… We went with Y for A, B, C reasons.
Worst case, you commit to the decision for two weeks of work, then get more information which allows you to pivot to a better, more informed option

The best stakeholders are the ones that are the most continuously invested
- Feedback on each iteration is a must in order to generate the most valuable final solution
Consider scheduling a bi-weekly meeting that aligns with sprint cadence, where you give a demo of changes and progress made, receive feedback, and ask/answer questions
Consider ways to structure cross-team meetings to ensure you are showing progress and getting meaningful feedback from users.

The smaller the individual tasks, the better the effort estimation, the greater the chance of success

Thoughtful and responsible sprint planning should lead to meaningful progress and a sense of accomplishment (at least) every two weeks - celebrate that!
Even better if you can do this with your stakeholder partners.

Check out more resources on iterative development.