Just enough up-front design (visual & architectural)

Doing too much upfront design doesn’t go well with the agile way of working. It usually produces a lot of waste: design work that turns out not to be needed later on. Regarding visual design, we have good experience with having the global style designed upfront, and designing details one sprint (or less) ahead of development. Regarding architectural design, there is good experience with the approach of emergent design (which requires continuous refactoring). However, if the team identifies a number of aspects for which they prefer some upfront design, this will be part of the co-preparation phase. In all cases, it is up to the team to choose the preferred approach, and also to change it along the way, based on experience.

Proof of Concept

Certain technical uncertainties identified during co-preparation can prevent a team from giving estimations, or give too much uncertainty on time and budget for the customer. In those cases, we choose to execute a proof of concept. The purpose of a proof of concept is to gain the knowledge necessary to reduce the risk of a technical approach, better understand a requirement, or increase the reliability of a story estimate.