An Agile Thought Experiment

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)?

3 thoughts on “An Agile Thought Experiment

  1. I’d be more interested in the cause of the breakdown than whether or not they were “agile” enough. If this is a hypothetical situation, there’ll be no answering these, but some of the questions I’d be interested in having answered include:

    – Why did it take 2/3 of the schedule to discover that a component/engineer is (supposedly) in trouble?
    – Did Adam’s code suck or was he not confident enough to stick up for it or was Charlie being overly domineering or …? In other words, what was *really* going on, not just how were the actors playing it.
    – If Charlie was given the use of Adam’s code as a hard constraint, how would he refactor/extend it to do what’s needed?
    – Could Charlie’s domain knowledge and Adam’s knowledge of the code that he wrote be exploited in tandem by having them work with each other?

    Even in non-agile settings, it is (or should be) the responsibility of senior engineers to help grow junior engineers and for the development manager to keep the group working as a team.

    If part of the root cause of the situation was a power imbalance dynamic, it’s just going to be worse now. Charlie will be harder to reel in and Adam is going to need even more ego building to help him step up. On the other hand, if Adam’s code did suck, it’s time to come up with a plan to improve it (and cut him loose if that can’t be done). You already wasted (at least) 8 weeks on him.

  2. I’d say the _project_ was a success – customer was satisfied, and original schedule was kept, even after a major re-direction.

    However, the team’s process seems very suspect. As Tom Morris notes – how did they manage to let poor Adam flounder for 2 months? It’s also hard for me to imagine that all his efforts would need to be scrapped – surely some of it could have been salvaged.

    In a political sense, Charlie is the clear winner here – he’s the hero who saved the day. Maybe he thinks an agile process does not give him the glory he deserves.

    At the very least, this team needs to do some serious thinking about their review process, so problems are caught earlier.

    Maybe they just got lucky this time…

Comments are closed.