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.
‘Agile’, the mind-set expressed in the Manifesto for Agile Software Development (2001) and its underlying principles, introduced very different ways of thinking about software and product development:
Recently we came to hear that Dr Christopher Avery would come around to present his new book.
Without hesitation from within Co-Learning we took the opportunity to organize a workshop given by Christopher himself.
I guess you might be wondering why I’m that enthousiast about a person coming over to Belgium.
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.
In a previous article, I’ve talked about an elegant experiment from 1962 we’ve re-done.
At the moment of writing this article, we’ve completed 2 dry runs: One with a small group of students, and one bigger group of agile coaches, managers and scrum masters.
We got plenty of feedback, and improvement is on its way.
Lately I discovered an interesting experiment described in a book about transparency by Warren Bennis. It was not that much in detail, but the references -as in all good reads- were well mentioned.
The experiment we’re talking about was done in 1962 at the Massachusetts Institute of Technology.
