LikeLike

LikeLike

Doing incremental design doesn’t mean that you shouldn’t think of the whole design. The idea is that your design will evolve and change as you write your code and as the requirements change. Thus, you need to keep your design ready and easy to change.

Here is how we do it in our team:
1. Plan the requirements for the coming 3 months with our Product Owner during a Business Priorities meeting. In that meeting we agree on the epics to work on for the next period. This will make us focus our design on small parts of the big design
2. Another activity we do is an Architecture meeting every 6 months. During that meeting the team looks at the current whole design and plans the next steps, like whether we need to remove, edit or add pieces to it.
3. When faced with a complex story (micro-task), the pair working it suggests a design to the team before starting the coding phase.

With those 3 steps, we guarantee that our design is evolving as our product is growing and at the same time we are sure the pieces are well connected in the whole design.

I hope this answered your question!

Thanks,
Ahmad

LikeLike

I am a bit skeptical on the idea that “[design] should be assembled one bit at a time”. I think in this approach one is constantly rethinking the architecture of the solution, refactoring the parts of the solution, and might reach a point were the sub-solutions are optimal but the whole design is not and realize that maybe it was a good idea to think of the general design first.

My question is how do you think of the solution design for your micro-tasks when you follow an iterative TDD (“Don’t write more production code than is sufficient to pass the currently failing test”) approach, and the general solution architecture in an agile methodology? Those might be two different questions so you can address them separately.

LikeLike

LikeLike

LikeLike

LikeLike

LikeLike

LikeLike

Thanks
Gaetano

LikeLike