Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

In a thirty-person team, you have smaller groups working on different things, all nominally coordinated by the manager who in practice heavily depends on capable developers to help manage the subgroups. Since every convenient method that exists in a large company will eventually be formalized and fetishized, it was inevitable that someone would seize on the idea of breaking up the larger team and formally replacing it with a set of small teams with fluid membership.

Now a large team is seen as grotesquely unwieldy, bureaucratic, and high-overhead, kind of a laughable concept compared to smaller teams, even though large teams were normally run as a set of fluid, informally organized smaller teams. With a single large team, a certain amount of mandatory overhead is incurred at the team level, and individual groups within the team can adopt as much or as little overhead as they think appropriate. One person can work alone, or all thirty people can work in concert. Informal groups within a team never have a formal existence, so they can form and unform at will. Everything depends on judgment and discipline, and the greatest risk is chaos. Sounds kind of lightweight and agile compared to an "agile" process like Scrum, where each small team has a formal existence, a minimum size, mandatory administrative overhead, and a prescribed methodology, doesn't it?



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: