Architecture is a business asset that deserves explicit investment and care to generate long term benefits. Let me explain.
Software architecture is as important as functionality, at least in the long run. Sounds reasonable. I asked more than 1000 technical people in the last year if they agree with this statement, and they overwhelmingly do so. But, what does this actually mean?
As the functionality of a system is recognized as a business asset, it follows that architecture of that system is a business asset as well. And they both should be approached with the same rigor.
We all communicate and we all know it’s important. And culture is important. So important, in fact, that without the right one a company runs the risk of not achieving any of its goals. One of Larman's Laws of Organisation Behaviour also painfully shows the importance of culture and how difficult it is to nurture: Culture follows structure. Or, Culture/behavior/mindset follows system & organizational design.
I recently attended some events where talks on different subjects brought the audience to specific puzzle pieces of understanding on how complex adaptive systems perform best, especially taking into consideration the human factor.
The first talk was at an event hosted by Lego®, where Pedro De Bruyckere did a talk about "How play changed the world (and vice versa)".
A few months ago I was on an assignment where there was a clear request to use physical cards for their stories. It helped to give an overview by laying them on a large table. Always good to hear that people are thinking out of the box when searching for ways to visualize their work.
Introducing the Co-Learning achievement unlocked app
It can be hard to explicitly appreciate someone for their behaviour. And it can be even harder to accept appreciation. And yet appreciation is something that can have such a big impact on people's motivation. Achievement cards use the gamification element of achievements, getting recognition for a certain behaviour or perseverance.
It is frequently seen that even though people are working on the same delivery there still is misalignment on the way of working, with what degree of finish (D.O.D. interpretations), etc.
This especially happens with different skills and contexts that imply different perspectives on how to look at software.
Either way you place it: knowledge sharing is lacking.