Geek, agilista, blogger, codefella, serial reader. In the daylight - I navigate & lead software engineering. #lean #design #aws #elixir #analytics. I speak here for myself only.
Few days ago I've written a blog post about feature teams - I wasn't hiding that it was inspired by C. Larman's book about scaling Agile. Or rather by one of the chapters that I've found very interesting & thought-provoking. There'...
I've always had a clear vision of how code ownership should look alike: * each piece of code should be owner by 1 team * code should be divided domain-wise (not tier-wise, so no "component teams", please) * responsibility of the owner is not only for writing code, but...
> "Deadline." > "Commitment to the fixed scope." > "Requirements specification." Those three statements have made my flesh creep, did you get the same sensation? They are definitive, they are scrict, there are about formal responsibility & discipline. And they are the essence of...
Let's start with some bold statements: * Team that did shitty waterfall work will most likely do a shitty agile work too (you can freely substitute the word 'agile' with Lean Six Sigma, CMMI3+, XP or whatever) * Nice tools can make a noticeable impact (by improving morale,...
The idea of decomposing application into layers (logical vertical split) or tiers (physical vertical split) isn't new - it's bread'n'butter of systems architecture. Reasons for such a split are still the same (as they were in 90s, 80s & beyond): * to reduce...
The prose of life Test automation ain't trivial & there are several reasons for that, including: * need for scalable structure (hierarchy, naming, etc.) * dealing with dependencies (coupling) * insufficient speed of execution affecting dev agility * shared resources impairing isolation * inertia of data (incl. configuration, parameterization, etc.) But there are...
