I don’t intend to use anyone’s rules of thumb “just because” they worked for them. I do intend to use practices that have been demonstrated effective generally, and I intend to understand how and why those practices work so I will know when to apply them and how to keep things on track when they aren’t working well.

I also want to understand how various development practices affect the financials of a project and the cost of ownership of the resulting product, as well as how to introduce process improvement in traditional organizations to help them adopt better practices. I have to go beyond “it worked for me” to reach that stage.

No, I don’t want to “copy” you. I invite you to explain how, why, and under what circumstances your methods work so I can learn from that.

Meanwhile, I apologize for misunderstanding your point of view. I still think we’re generally in agreement about most of this.

And BTW, here’s a post I made earlier today in followup to a different thread on the site, tongue-in-cheek.

But I’m a reductionist who believes that all knowledge can be easily codified! I know in my heart that there must be a laminated placard somewhere that offers three simple steps that solve problems in all situations! My fully-aware AI robot insists this is true!

Then you say this:

Your approach to software development appears to be similar. You seem to want to avoid identifying practices that might produce better results on project after project. If something worked once, that’s nice, but you can’t or won’t take any useful message forward from that success.

Are you serious? That’s so not me or how I do things that I am honestly flabbergasted. I learn from my experience and make new rules of thumb and build new processes and set new standards and apply lessons learned every day. That’s how our shop independently ended up coming up with a very agile-looking mode of building software all without ever having heard of it before. We found it after the fact and went “huh, these guys do a lot of the same things we do”.

But I do not think that you should use my rules of thumb and my processes that I built from my experience just because they worked for me.

I just don’t understand.  I’m yelling “don’t copy me” from the rooftops and you keep yelling back “but I want to”.  I guess I should yell ”learn from my stories and decide for yourself so you can be a strong and independent developer”.

And we certainly aren’t going to go around telling people what they should do without any knowledge of their project, their people, their company culture, their goals, and their definition of ‘success’.

Fine. The point (and I think you know this perfectly well) is to choose an appropriate tool and then to use it properly. Be careful not to drill through your hand. And should the drill or screwdriver actually work “for you” (as opposed to “for screws”), be sure not to be so arrogant as to suggest the same tool might work for a different screw, or in the hands of a different person.

Re: Show people what has worked for you.

Sometimes its just a question of what has worked “for you,” and sometimes there’s more to it. Certain development practices have been proven effective on many projects. They don’t just randomly work sometimes and not other times. They work “for software development,” in the same sense as screwdrivers (and similar) work “for screws,” not just “for me.”

Flexibility is great. It means you can recognize that not every software development practice fits every situation. But once you’ve determined a practice fits a given situation, it fits just like a screwdriver fits a screw. It fits the same “for me” as it does “for you.” And if it doesn’t fit, it’s for some objective reason, and not just because it didn’t happen to work “for me.”

Re: Evangelizing.

No. Just explaining objectively. If a practice tends to be useful for software development, then there are reasons why and there are ways to understand and discuss those reasons. Similarly, any given practice will have its limitations and there are ways to understand and discuss those limitations objectively.

Otherwise, one would be surprised time and again by every outcome, because one could not correlate effect with cause based on experience, like one of those unfortunates who has no medium-term memory function (they can remember their childhoods and they can remember new information for a few minutes, but then they forget the new information, and every time they hear it it’s new to them again). It isn’t evangelism to explain how something works.

I’m reminded of deconstructionism. When I was in college, it was fashionable among literature professors. An unfriendly summary of deconstructionism might be to say it reduces any and all texts to the same level. The best works of Shakespeare or Dostoyevsky would be seen as no better than a grocery list. You could analyze the grocery list and discover just as much satisfaction and personal growth from it as from any other text. It’s an approach to literary analysis that totally misses the point of any given work of literature by reducing it to a string of words with no context and no relationship to past or future.

Your approach to software development appears to be similar. You seem to want to avoid identifying practices that might produce better results on project after project. If something worked once, that’s nice, but you can’t or won’t take any useful message forward from that success. All development practices are seen as qualitatively equivalent, and their relative value is reset with the beginning of each project, as if no one had learned anything about how or why the practices worked well or didn’t work well on previous projects.

I agree with much of what you’ve written here, but not to that extent. That kind of thinking is just too extreme and too limiting for me.

Me: But it would be arrogant and presumptuous of me to imply to try to convince you that you should do the same thing and that you will get the same results.

You: I disagree. If you can provide objective arguments in favor of using any particular practice, then it behooves me to listen.

You’re arguing that I need to evangelize to you and try to get you to do things my way? I am confused.

Well, okay. Speaking of context, remember what prompted people to start exploring alternative approaches to software development in the first place. It was the low success rate of traditional practices, especially what we now call the linear waterfall approach, and all the stuff that goes along with that.

One of the core problems with traditional methods was the lack of collaboration. That, and other core problems, caused people to re-think what works (or doesn’t) and why it works (or doesn’t). Once you start discarding these core ideas, you’ve moved away from the original idea of agile development and (possibly) getting into a realm that has no definitions at all. Sort of an “anything goes, nothing really works better than anything else” mentality.

>But it would be arrogant and presumptuous of me to imply to try to convince you that you should do the same thing and that you will get the same results.

I disagree. If you can provide objective arguments in favor of using any particular practice, then it behooves me to listen. It’s not arrogant at all for you to explain why something works. We’re all building software, after all. If something adds value to that process in one situation, it’s very likely to add value in another. If not, then we need to understand exactly why not so we will know when to apply that particular practice and when not to. That’s a bit more solid than just saying, hey, this worked for me but it might not work for you.

Some of the principles and practices that underlie agile methods have come to be accepted through the collective experience of practitioners, based on what has worked on real-world projects. I submit the reason you can’t easily think of a concrete example of a case when collaboration would be a bad idea is simply that there is no such case. This is one of the foundational definitions of adaptive development, including agile, lean, and other variants. It’s a direct answer to one of the core problems we’re trying to solve in our profession.

I’m not so sure literally everything is totally open. I think there are certain basic concepts that differentiate agile development from other approaches, and if we set those aside then we’re left with, effectively, no definition or no framework at all.

I say this as someone who has a personal interest in understanding the hard value of agile practices, specifically in contrast to traditional (waterfall) practices. Sure, there are situations where agile methods don’t apply. But once you’ve identified a situation as appropriate for agile methods, then the next step is to apply those methods properly.

It’s the same idea with any other tool. To tighten a Phillips-head screw, you choose a Phillips-head screwdriver. It’s the right tool for the job. Once you’ve determined it’s the right tool, then you need to grasp it by the handle and fit the tip into the screw head. Otherwise you’ll fail to tighten the screw, and probably hurt yourself as well.

Similarly, once you’ve determined agile is the right approach to a given project, I think it’s best to get as close as you can to the most rigorous agile practices, given the realities of the project and the people you’re working with. That way you can achieve the best results.

I understand and appreciate your reaction to the overselling of capital-A agile, but I hope you won’t go too far and throw out the baby with the bathwater.

As far as when collaboration may be a bad idea, I don’t know when that would be, but I’m willing to accept that such a context may exist. That’s the whole point! We don’t presume to know what’s best for you! So, sorry, I can’t offer you a checklist of when you should avoid collaboration. That’s precisely the kind of prescription we are saying doesn’t work.

What I can offer is past examples of things I have done, why I have done them, and what the result was.  But it would be arrogant and presumptuous of me to imply to try to convince you that you should do the same thing and that you will get the same results.  I may recommend that you try something, but I won’t tell you that it will definitely work.  I’m glad you’re asking these questions, though, because it’s forced me to think more about the aspect of giving advice and sharing experiences.  For me, I always trust someone who’s relaying experience over someone who’s evangelizing or selling a cure-all, and maybe that’s what bothers me the most about today’s Agile.