Producers and Processes
Production methodologies are overrated. It sounds silly to say it because it's repeated so commonly. Everybody knows it. "Scrum is not a silver bullet" say the supporters AND critics of scrum.
Then producers apply it to every problem anyway. Those of us who know the history of software development can cite examples of massive projects using a "waterfall" methodology of being extremely successful. There's also examples of agile projects that have done great, met deadlines, and exceeded expectations. Two, three, and four week sprints have worked. With and without retrospectives. With weekly one on ones and with one on ones only on request. With remote and local teams. Test driven or feature driven development. I've heard every variable tweak result in success or failure, depending on the project, and have experienced it on my teams. Vastly different production strategies can work, even for similar endeavors.
My impression now is that production strategy is highly contextual to a team. The most critical contexts are company culture, team dynamics, and individuals. Those contexts can make or break a methodology, and most notably to me, can render practices obsolete for a certain group of people. For example, getting feature estimates is a big deal at a lot of places. The team, or some subset of it, needs to meet and produce detailed estimates, breaking up tasks into manageable chunks, play planning poker to assign a numerical value to it, and then a producer must track the team's real work versus their estimates over the lifecycle of the project. Graphs must be drawn and expectations managed over time as the team becomes more and more predictable with their timelines, as error is accounted for and risk reduced over time.
Some teams just don't need to do this. Why not? For example, individual contributors may be very accurate in their estimates and not need a meeting. A producer may be pretty good at picking up on risks and accounting for them in a timeline. A corporate culture may allow for more flexibility on deadlines or may encourage experimentation such that working on the wrong things then correcting isn't as big of a deal. I think any of these points could be shocking to certain producers.
"How can data not be tracked?" development philosopher A says. "How can an inflexible process be able to respond to changing requirements?" philosopher B says. And the other philosophers say their own points. To the philosopher, truth is singular and fundamental.
I don't see the truths of agile, TDD, or some other popular methodology as resembling the axioms of development. They are a level above, and suitable for certain problems, a problem being a team tasked with a project at a company. Methodologies can produce acceptable solutions to a variety of problems. But they are not the fundamental truths. Just like software architecture/construction, a production process involves a complex set of variables that cannot be graphed out and min-maxed to an optimal result, at least not prior to actually doing the work. You can't put all the team variables into a deep learning system and get a printout of step-by-step instructions on how to run your project. We task individuals to solve complex problems because they are complex and need a smart heuristic approach that produces a reasonable but imperfect solution. That means that any process can end up on the cutting block.
Getting individuals who are very competent at solving this class of problem is critical, and in an interview they won't be the ones who say "my experience has shown that an X week sprint/release cycle/check-up is optimal". Those individuals aren't suited to solving hard problems, they may be suitable to follow instructions or a check list that you hand them.
Every team is a different problem, and treating software development as a franchise business doesn't work. Franchise models work for businesses where you can address highly repeatable problems with a known, good solution on top of teams of low skilled workers. Franchises do not solve the problem of how to gain the maximum benefit from each worker's unique and incredibly powerful skill-set, they solve how to get an equal and uniform level of output from each employee type. At McDonalds maybe it could be argued that the common uniform output is 85-90% of their employees' total skills. In software, I highly doubt it's more than 20%.
The power of highly skilled workers is in their uniqueness, not their consistency or uniformness, and as I mentioned before, software has sets of problems that make each project unique and require individual solutions. The upper bound to optimizing to your specific problem is MUCH higher than in a franchise.
Strong critical thinking is still the winner in developing a production strategy that will drive a team to success. Tools and methodologies can compensate for the complexity that obscures a clear plan of action, but those gifted with the raw ability to see through that complexity are the ones I really want on my team.
