This blog concerns itself with organizations moving to business agility—the quick realization of value predictably and sustainably, and with high quality. It includes all aspects of this—from the business stakeholders through ops and support. Topics will be far-reaching but will mostly discuss FLEX, Flow, Lean-Thinking, Lean-Management, Theory of Constraints, Systems Thinking, Test-First and Agile.
I often hear people say as you scale things get exponentially more complicated. That state as unassailable truth that if you have 'n' people or teams and add one more you now have n times as many things to attend to. While I agree it is this way when you build around organizational layers or off of team relationships, it doesn't have to be this way.
Imagine, for a moment, you were responsible for a development group building a new product and every time a new feature was added it took longer than the one before. You decide to talk to the team coach and team lead. They respond that for every new feature added you have to attend to its relationship to all of the other features. As there were now more features there were more relationships to attend to.
I am sure your response would be "have you never heard of architecture?"
We need well thought out framework architectures as well. They need to have clear, visible relationships between the framework's components. We need to be able to see if a local change has an overall positive impact. It must be robust in the face of errors.
The architecture of a framework will determine if it gets simpler or more complex over time. And whether people stumble with its implementation.
Architecture of a company is quite different. but this is a great question.
Take a look at "The Value Stream of the Effective Organization"
there's a lot more thought that goes into this than meets the eye - but i've not written it up - only discussed it in the FLEX workshop.
I'll get around to writing up more on this in the next few weeks.