Having no shared understanding of what you are jointly aiming for is a recipe for disaster:
- Conceptual integrity will be broken.
- The discussion will slide to your code base.
- Which will eventually turn your code base into a battle ground.
- It’s not uncommon people will undo the changes of others, thinking it is not the right way - mind you, without a joined agreement on what constitutes ‘the right way’.
It applies on all levels of the IT organization, but most certainly to development teams.
There are a couple of things you can do to increase a shared understanding of the design objectives.
- Pair programming helps: even though it synchronizes between two people only, if you switch pairs frequently, and if you prevent your team members from getting too attached to a particular area of the code base, you will eventually get a shared design understanding.
- Joint design discussion: as soon as you notice blank stares when discussing a particular area of the code base, you should step up and demand allocating some time to discuss that part of the codebase.
- Plaster the walls: any material coming out of the design discussions should be on the wall. And it should be updated if it no longer reflects the current understanding.
A shared understanding of the design will help people understand the consequences of their actions. Not having a shared understanding of the design will quickly cause people to claim a certain portion of the code base they understand, which eventually will result in a fragmented code base without any conceptual integrity at all.
Having design meetings of course is expensive. Having some preparation might help, but pictures drawn during the meeting normally have a longer lasting effect. And you should keep in mind that ideas captured during preparation might turn out to be invalid during the discussion.
The advice is not to have design discussions during the stand-up, but perhaps right after it. Somebody should take the responsibility to make sure the results are captured on the wall.