A few weeks ago, we (myself & my two friends - Tomek & Wojtek, as a part of a community called CTO Morning Coffee) hosted an online X Spaces session on Domain-Driven Design (DDD). To be clear, this wasn't supposed to be an intro session; quite the contrary....
Many people who've never seen high-performing teams in action (I mean genuinely high-performing, not just the ones who self-claim they are ...), assume that all that you need to form such a team is: * assign them a mission (they could identify with) * grant them a sufficient level of autonomy...
I've used many personality assessment methods & tools in the past. Gallup SF, Transactional Analysis, OCEAN - that sort of stuff (& more). I'm not a professional behavioral psychologist (of course), but I thought nothing would surprise me regarding the qualification of personality types. Yet, I&...
It's one of the lessons I've learned the hard way: there's no other resource valuable more than your own time. Why so? * it's hard-capped * it's not transferable (my time isn't directly exchangeable with your time, at least in...
I bet that nearly everyone in the software-crafting industry has heard about YAGNI [https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it] ("You Ain't Gonna Need It") principle. But what about TAGRI? TAGRI (which is nearly as old as YAGNI) stands for "They...
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...
There's one thing that freaks me about agile adoption in large enterprises. WAIT. NO. There's one thing that particularly freaks me about agile adoption in large enterprises: Full conviction that it can be done only in a top-down way It has to be a shift in...
