Question: How can a team choose the right architecture, the right framework and the right way to build it?
Answer: By fulfilling a commitment!
Reading “Emergent Design” by Scott L. Bain, I found an interesting statement: “Professionals know that there are always a number of ways of solving any given problem, and they make a decision based on the cost versus benefit, or return on investment.” (p. 67)
Today I was asked the standard question #Q4711: Why shall the team commit themselves to a Sprint Goal, if they do create the technical design only after in Sprint planning 2? How can we know we will meet the goal, when we do the task break down only in the meeting later.
And suddenly – after 6 years of repeating the default answer #A4711: “It makes sense because you need to know what you shall consider in Sprint planning 2. You need to know how much you need to look at” – I had an insight:
You must develop a solution that fulfills your commitment that is doable in the time you have!
Your commitment is something that does not only bind you to the amount of functionality you will need to develop. It does also constrain your space of solution.
The commitment is the border you need to enable collaboration and self-organization. The commitment means much more than: “We want to build it!” It means: “We will develop everything we committed ourselves to, given the time we have, given the resources we have, given the skills and abilities we have and given the information about the features we have!”
Consequense: A team shall give its commitment always after Sprint Planning 1!