There has been some considerable debate in the agile community about the percentage of good people required to make agile methods work. Most recently this thread at the FDD site. The topic was also a common running theme in Boehm and Turner's Balancing Agility and Discipline where on page 185 (for example) they postulate that FDD requires a lot of good people in order to scale. Schwaber and Beedle's Agile Software Development with Scrum claims on page 121 that it needs 50% experienced people to work. As I state in the thread at the FDD site, my experience with FDD is that 1 in 6 is about sufficient. Why?
Simply put, I believe that this endeavor to define how many good people or how many experienced people are required for any given method, is a red herring. The real issue is one of leadership versus uncertainty. Uncertainty comes in many forms - change (see Satir's change model, see also Peopleware 2nd ed page 199), scope ambiguity, domain ambiguity, schedule uncertainty, job description and positional ambiguity, fear, difficulty, novelty of process, technique, tools and lack of experience therein, then there is variance both common and special cause. The greater the uncertainty in any project, the more leadership is needed (at all levels) in order to compensate for it. By loading too much uncertainty into a project, without sufficient leadership, there will be the chaos that Satir identifies but rather than recovering from the slump to show an improvement - the J-Curve effect - there is simply a slump and things remain worse than they were before.
FDD gets its leadership at many levels - the Chief Programmer (the shop floor foreman) is the first level of leadership, then there is the Development Manager and Chief Architect. All these roles must provide leadership on a day-to-day basis in order to overcome the uncertainty. When a project is happening in a new domain, with uncertain scope and schedule, and FDD is being introduced for the first time, along with color modeling and perhaps new middleware tools or development tools such as a JDO implementation and the Togethersoft Control Center, then everything is in flux. In such a situation, a team needs every CP, the Dev Man and the Chief Architect all to be great leaders, mentors and teachers. In simpler situations, where there is less ambiguity then less leadership is required.
In order to be a leader, an individual must be both good at software development and experienced in the software lifecycle (with a particular method). Hence, "good" and "experienced" are actually emergent properties of "leadership".
The amount of leadership required on a project is situational. Trying to measure it by method and define a scale of agile methods versus percentage required is futile!
