A team, unaccustomed to but enthusiastic about moving towards agile methodologies, begins an important project. The project has many facets and a number of strong developers, so it seems natural for the developers to concentrate on a single aspect: Adam is associated with the Widget feature, Barbara focuses on the Sprocket, Charlie with the Doohickey, etc. Charlie is the most familiar with the domain, the legacy codebase upon which the project is being built, etc.
The project is scheduled to last 36 weeks, divided into 12 3-week sprints. At the end of Sprint 8, Peter the Product Owner is satisfied with the feature set of the Sprocket, Doohickey, and other facets, but it has turned out that the Widget feature has been more complex and is clearly going to be the focus of the remaining sprints. Further, Peter has a number of additional features that he'd like to see in the finished project, if possible.
Charlie says "Well, I can add these new features as requested by Peter, but not using Adam's code, which doesn't capture several important domain concepts needed to rapidly develop them." Adam says "These new features are outside the domain I've worked in. I think my code is fine, but I cannot guarantee where it will be in the few remaining sprints." Adam's code is shelved, the team realigns into a more traditional lead programmer structure with Charlie "doing the hard parts." At the end of Sprint 12, the project moves across the finish line with an acceptable level of quality.
Would you say that this project was a success because "It delivered customer value on time; it discovered a problem and course-corrected, the switch into a non-agile mode for a short period is fine, like a 2-minute drill in football."? Or would you say that the project was a failure because "It relied on 'superhero' efforts from Charlie at the last minute; it didn't identify that the Widget feature was not coming together properly and 24 weeks of Adam's efforts did not go into production."?
What improvements to methodology and team structure could be made for future projects? Should the team structure themselves more along the lines of a Lead Programmer model (Charlie is clearly the most productive developer) or less (the argument being that the feature-focused structure distributes credit and blame unfairly)?