That last point--the key role of intuition--is one of the biggest reasons you can't package up effective coding as a book, a manifesto, or a training session. Which implies something managers may find distressing: There is no silver bullet; a coding team's only salvation is smart coders.
80% of agile can be summed up as: limit work in progress, and (almost as a necessary consequence of this) ensure any given piece of work can go from initial requirement to deployed to customer very quickly. My "in the trenches" experience is that whether or not a company follows this is the most accurate single predictor of whether it succeeds. So methodologies do, in fact, get projects done.
Good question. If you mean: "Why do you choose to ship code?" then I suppose it's my desire to please my clients and stay employed. If you mean: "How do you manage it?" then it's what I hinted at earlier: Good intuition, experience, a precise and logical mind, and thoughtful use of tools.
About tools: My tools are important to me, but I don't see them as a silver bullet. It's like if you asked a carpenter about a "hammer-centric methodology." She would laugh. She'd say yeah, she uses a hammer all the time, but her hammer use doesn't amount to a methodology or a philosophy. Hammer use just comes about naturally as a consequence of recognizing nails that must be driven in.
Similarly for software: I don't use to-do lists because they're "agile." I use them because I need to remember the 20 different requests my client made yesterday. Could I live without Asana, Basecamp, or what have you? Sure. I'd just write my tasks in a text file. What if I couldn't use a text file? Then I'd put sticky notes on my wall. I need tools (everyone does), but I don't deify them.
> 80% of agile can be summed up as: limit work in progress, and (almost as a necessary consequence of this) ensure any given piece of work can go from initial requirement to deployed to customer very quickly. My "in the trenches" experience is that whether or not a company follows this is the most accurate single predictor of whether it succeeds. So methodologies do, in fact, get projects done.
I agree with all of the above except for the statement that "methodologies do, in fact, get projects done." I think the reason we disagree is that we mean different things by "methodology." I take "methodology" to mean a formalized process, like a recipe, that you can follow mechanically. By that definition, agility is the explicit rejection of methodologies.
But then, I'm not the god of word definitions. I don't get to say my definition of "methodology" is right and yours is wrong. So perhaps it's fair to say that we're each right insofar as we're permitted our respective definitions of "methodology."
Then I remembered one I saw just the other day:
> We offer a highly configurable Agile and tools-based software development methodology
They also have an "execution-focused leadership team" and "offer a number of flexible outcome-oriented engagement models assuring the success of our projects"
The whole page is like that!
So many companies write this way. I could believe they do so only because their staff never learned how to write good sales copy. Or is there some actual merit to it? Do they know something I don't--namely, that buzzwords sell?
> We are an innovation focused services firm with 100% focus in the emerging technologies. This razor sharp focus has allowed us to differentiate from our competitors in many different ways:
Smart coders who understand that they're part of a team.
I've seen at least as many problems caused by people not working with those around them (whether they be other developers, users, testers or whoever) as caused by rank stupidity.
That's not to say there needs to be a massively formalised way of working together, just the fact that other people are involved needs to be a central part of everyone's thinking.
EDIT: A central and constructive part of their thinking I should say - thinking "I need to steer clear of all these other bozos" I guess qualifies as a central part of someone's thinking but isn't what I was getting at.
None of them are prescriptive methodologies, though. They are all things like incrementalism, automation, and high quality code.
In that metaphor, traditional waterfall is a land mine filled with plutonium shrapnel and anthrax spores.
Some times you have a clear and well understood problem, and failures are very expensive. You'd be crazy to work on such kinds of environments with anything but waterfall.
Some people have to do underwater welding, but the methodologies there aren't appropriate for building cabinets, even though they are both types of construction.
Good craftsmanship is usually correlated with a good end product, but craftsmanship for its own sake is a hobby, not a career.
The larger team definitely produces more intermediate artifacts than the smaller team. You could say there's more process in that team. But it's still not formalized as a methodology. The larger team mostly just muddles along. I'd actually prefer to organize the larger team's tools a little better, e.g. maintaining a single, sane VCS. Even if we did that, I wouldn't claim we're following a methodology. (By my definition, artifacts and tools do not a methodology make.)