Stakeholder engagement: Trimming wasted time

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.


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


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:

This post is part of a set of posts with my personal notes about all the chapters in the book “Lean Architecture for agile software development” by James Coplien and Gertrud Bjornvig. I will do this as I read through the book, and take notes on the concepts I personally find more relevant.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s