There's bunch of questions that will probably never get answered ...who was behind killing JFK?is Elvis alive?why did your local football team suck that much in the yesterday game?... and ... what's the optimal work model for running software teams? ;PObviously the last one is much more thrilling than the previous ones (hehe), so lets stick to it today :) In fact it's not just a single question, but a ton of smaller ones that fit well together:cross-competence or competence-based teams?individual or team responsibility?what are the roles & their particular responsibilities?who's decisive in terms of priorities,…
All posts in software delivery
TL;DR Due to software's innate complexity & its ephemeral character it may not be easy to assess the "level of its completeness" (/readiness) - it's not only that opinions on that may vary, people are also reluctant to give final statements (due to high degree of uncertainty). In the end of X participants you may hear X different statements, not just misaligned, but sometimes even contradictory. This effect (similar to key plot construct in japanese movie classic - "Rashomon") can be combated in quite a simple way: by promoting radical transparency and consistently stressing for…
TL;DR Many engineering organizations postpone their most ambitious plans due to cost constraints for so long that they start to believe that it's only money that limits their capabilities. When they eventually get funds, they learn (in a painful way) that scaling up in an efficient manner is not really a matter of funding (actually it's one of LESS meaningful factors) -> software engineering is a very fragile process w/o a simple formula to define Ability to Deliver (Execute) in a period of time. Instead, there are several important components with lower than linear positive impact (above…