My position on architecture is different from most peoples’. My view works really well at scale (much better than the traditional view, in my experience), but it is very different.
I start with one traditional definition of architecture: any decision that would be costly to change. However, I also know that I (and those on my teams) learn quickly. Every problem that I found difficult at some point has later been found to be easy…once we learned more. This gets me to my final definition.
Architecture is any decision you make that you are not yet smart enough to be able to change on a whim.
The best large systems have no architecture, under my definition, at all. Continue reading “Architecture – Scaling Design”
I hear a lot about Scaling Agile these days. Every time I hear it I have to shake my head. The fact that people are asking how to scale Agile means that they don’t know how to do Agile. The fact that people are designing frameworks for scaling Agile means that they don’t know how to do Agile either. Agile done right (beyond the 1-star level) consists of two steps:
- Change the rules of the game (by changing the details of how software is created moment-by-moment).
- Adapt everything else to take advantage of the new reality.
This is why when you ask “how do I scale Agile?” to someone who can ship at will, they look at you with a blank stare. If you’re thinking about “scaling Agile,” then you probably haven’t really benefitted from your agile implementation. If you had, then the question wouldn’t make sense to you either. You would just scale your business in a few obvious ways, look around, and repeat.
There isn’t a special method to scale Agile. The team just does whatever it was doing before, only it stops doing whichever parts it doesn’t need anymore. Continue reading “Scaling Agile – the Easy Way”