I'll check that book out, thanks. We'll see if it can re-calibrate me ;)
In my view optimizing productivity isn't necessarily mutually exclusive with other things you're trying to achieve. If productivity is very low then most other measures will tend to fall too though that may lag. The problem is that productivity tends to have poor visibility and is difficult to measure.
What I object to with all my heart is the "feature team" as the assembly line model of software "features". I.e. the software factory where features come in one end, get assigned to a random team, and product gets delivered on the other end. This model results in low quality, expensive, bloatware at best. It may or may not at any given time make some money. It's also not the model used, AFAIK, in most successful software companies.
Re:Working remotely with 150+ people
by TheCoelacanth on Friday January 06, 2017 @09:18AM
(#13336304)
I've worked on teams like that before, and my biggest gripe is that it is next to impossible to get a good code review. People on your team don't have the specialized knowledge necessary for effective reviews and the people on other teams who do aren't invested enough to do it thoroughly and in a timely manner and usually won't be familiar enough with the details of the feature you are working on to do it well.
For large complex software systems every team member can't be an expert on everything. That's why within the overall program you set up separate small agile feature teams composed of team members who each bring some specialized skills and experience. Plus you should also layer on a matrix of component stewards who help maintain technical integrity for individual components. For a detailed explanation of how that works please see Ken Rubin's presentation "Scaling with Feature vs. Component Teams". http://www.innolution.com/resources/presentations/svaln-2015...
No one ever claimed that a feature team organization is a silver bullet. But if implemented right it will usually deliver at least a minor boost.