No concern is carved in stone

The daily assessment process ensures that engineers have a space in which to communicate technical issues and make technical decisions. They do this by making their concerns explicit and by crafting checkers that expose violations.

One key ingredient in this exercise is that every concern has an associated stakeholder. The stakeholder is the one that is able to go beyond what the checker reports and offer details about the meaning and value of the concern. And he is the one that has an interest to make the checker green.

For example, one day, Angie, a developer, sees that somewhere in the code someone is using his component by working with an internal interface, rather than using the intended public API. She then makes this concern explicit and sees that a checker exposes for these violations. After running the checker, it turns out that there are some six violations. During the assessment standup, Smoother, the facilitator, brings the concern into discussion. Angie describes the concern and why it is a problem. The violations turn out to be all introduced by Engelbert, and he has a question as to why is this an issue. Angie than argues that by using the private interface, she cannot properly control and refactor her component. They quickly go over the violations and see that it is easily possible to use the public API. The team decides that indeed the concern bares value and they go for it. Engelbert is joined by Angie and they fix the violations.

A month goes by, and another violation is introduced in the code. During the daily assessment standup, Smoother brings the concern into the spotlight. This time, it was Archie that introduced the violation. Angie says it's a known issue. But, Archie argues that he has to use that interface because of a performance issue. He has a special requirement that cannot cope with the overhead induced by the public API. Angie thinks for a second and then they agree that they have to set aside some 15 minutes to take a deeper look.

And they do. Angie gets to look into the special unforeseen situation of Archie. She agrees with his statement that the public API does induce extra performance costs. However, changing the public API to make it more efficient would incur a significant cost that would have to be planned for sometime in the future by the product owner. In the meantime, using directly the private interface is not a good thing either. So, they agree that a good enough solution for now is to expose a part of the private interface but only for the use of Archie's case. To ensure this, they add an exception to the checker to document exactly this allowed case, and everything gets green again.

Making concerns explicit is a means to drive the conversation. The goal is to find a good solution, not to satisfy concerns.