In my previous posts, I briefly described the stakeholders. However, they are not Lean nor Agile themselves. What is really important, for Lean and Agile, is how they work together: Everybody, all together, from early on.
In traditional software development, the process mimics the industry assembly line models of Henry Ford. However, the end product is quite different and involves a set of skills (such as domain knowledge, programming skills, design and interaction design) and knowledge that build on each other and depend on each other. Therefore we can not build one part of a feature and move on to the next part as in a production line: all of the feature parts must be developed at the same time.
Communication
To work in such a way, communication is key. We need fast, easy, clear communication so that no team member is left in a wait state
Lightweight communication
Physical distance is one of the factors that hinders communication in a team. The team members, and even the stakeholders, need to be colocated or, at least, in permanent direct contact with each other so they can respond to questions in seconds, rather than hours, days or weeks.
It isn’t that architecture takes so much work; it’s that everybody spends so much time waiting while E-mails sit languishing in in-boxes, while architects write architecture documents, or unread memos sit awaiting review
Pg. 63
Trust
Another major factor that hinders communication is the lack of trust. If team members do not trust each other, if there isn’t a “safe to fail environment”, people will not easily ask questions for fear of looking like an idiot, fear of embarassment. All team men=mbers need to embrace the idea that ” there are no stupid questions”, and should strive to put their personal egos aside, especially the team lead (if there is one).
Continuous improvement
Finally, one major factor that improves the team communication, the ability to work together and therefore performance, is the focus on continuous improvement. Nevertheless, to reap the benefits of continuous improvement, we need to give time to a team, and that means stability. Every time we change a team, it will inevitably go through the stages of forming, storming and norming before reaching the performing stage. Therefore, keep the team together over time.
The architecture guild
As a final note, the authors alert that the architecture team should not really be a formal team on its own. It must be an informal team composed by members of the feature teams. It should, in fact, be a Guild in the format expressed by the Spotify videos:
@hgraca 