Sam Gentile's Blog

As all of you know, I am a big time Extreme Programmer. My team runs under a full XP process. I have written hundreds of posts on it, blah, blah, blah. I call myself an Agile Architect. But lately, I find myself getting increasingly annoyed with my "own" community, even some on this site sometimes. The incident that broke the camel's back is the reaction to Roy's post on TFS of which he listed several features, that I myself have considered, even though we are a "pure" XP shop:

• The ability to associate a work item with a check-in action is very powerful in determining and reporting “delta” between failing builds
• Builds are also connected to checkin, and build history allows you to ‘drill down” to see all the source differences between the last success build and the current failing one
• The ability to use “workspaces”, which map current source control into local directories is powerful because it allows you to work concurrently on multiple versions of the same product, and switching between them in a couple of clicks from the IDE
• Powerful automated reporting
• Distributed and extensible build capabilities
• Task and bug management

So I have considered TFS for pretty much the same list that I feel is not happening with Subversion/Wiki. Does that make me now not an "official" Agilist? Frankly, I think certain people in the Agile community are becoming Agile Correctness people and turning into it into a religion. The thing that seems to get my goat is that they weren't there when we came up with XP. But many in the community now feel that they can become the spokespeople for something and judge the degree of agile correctness. I have done it myself and I'm tired of it.

Before I get on to a main point of Agile Architecture, I want to say with 100% conviction that Oren has every right to pursue a "friction-free" toolset and I have often worried about TFS getting in the way of my development team's momentum (dig up the dozens of my posts on this,I don't feel like it right now). This post isn't really aimed at him but I do find a post by him seeming to suggest that you only can use OSS tools to be "Agile" to be, well, quite disappointing. The main point when we came up with XP was to emphasize Individuals and Interactions over Processes and Tools. And it still is that. But what some Agilist's get tripped up in the zealotry is that not every project is the same and not every team is the same. An Agile team should feel completely empowered to define their OWN agile process and do what they need to encourage teamwork and collaboration including picking their toolsets. And there is no law that I know of that which says only OSS tools can do that. Of course, the best thing is sit everyone in one room but that's not always possible. We have three Business people in London. You can bet your butt that we put tools in place when we need them. Agile is about delivering business software and you do anything to accelerate that process. If some team outgrows White Boards or cards, and think they need Rally or Jim Shore's former electronic card tool, does that make them less Agile? Or is TFS provides a degree of collaboration that enables more rapid software, they aren't Agile? By the way, that's all I want to say on that. I have zero desire to get in a war about TFS vs. OSS or whatever. I want to stick to a general point.

Now, on to the Agile Architecture stuff. I said in this post:

It was a rhetorical question because I already know the answer having been there when we came up Extreme Programming in the 90's. As someone pointed out in my comments, that dogmatic answer is the canonical "Infrastructure Phase" at the "beginning" of the XP project and to a lesser extent, the mystical "System Metaphor" that we deempasize these days. My experience in the 90's with the XP community was that they were not the world's biggest fans of Architecture and most notably Software Architects. These topics realize perhaps a bias especially with topics like ArchitectsDontCode. At first glance, we got that right. You have to remember that a lot of us were reacting strongly against debacles like CMM and ISO9000 that threatened to take down further software projects in a sea of bindered documentation and hierarchical organizations with the uber ChiefArchitect. For the most part, we were all right about this as, after all, The Source Code Is the Design, not those huge UML Rational Rose diagrams that we churning out that produced zero value but were check-off items in some big process list. Models have no use unless they are essentially are Code Is Model. I learned, kicking and screaming at first, to let go of all those useless things I could not explain why I was doing and focusing on delivering business value not process. Architects were just another big process bump in the road in a lot of places.

In both cases, biases were developed because of bad experiences people had because of process rather than worth skilled and trained Architects brought to the table. I want to take on my Agile community though because you get this misguided "infrastructure phase" nonsense whenever you raise the issues. Since we don't have very much knowledge at the beginning of a project, Agile, rightfully says, we don't do Big Design Up Front. And we do a great job of that in code. But then we're saying, wait, we are omniscient up front in that architecture stuff and we can just make a platform and then go. Don't get me wrong, we preach the values of Refactoring, Continuous Design and by extension Continuous Architecture and JIT Architecture. I agree with my good friend James Shore with his thoughts on Continuous Design and there is a world of things we can do to keep a design simple, refactored and adaptable to change. That's what we do on our team to a very good level of success.

But it's not enough. We found that a year down the road that there was still a lot missing. Too many "infrastructure" or "framework" things were blowing by in this delirious rush to crunch out 100% business functionality every week no matter what. Someone with Architecture experience needs to perform explicitly the role of Agile Architect and restore these capabilities to a team. It's kind of foolish to say that it was supposed to have been done in the "Infrastructure" phase. I wasn't even at the company then and the infrastructure laid was, well, far from complete to base a real world-class scalable product architecture on. What had we as a team missed in the last 39 week rush? Oh just tiny things like Exceptions, Logging, Security, Service-Oriented Design, Workflow, Scaling to server farms, fail-over, etc. You get the idea. A lot of "cross-cutting" concerns that are like totally essential. The answer is NOT a BDUF Architect coming down from the mount with the stone tablets!! The answer is an Agile Architect. "What's that Jethro? Is that like that X-M-L thang I hear about and all?" Well, Scott Ambler, as well as people like myself, have been trying to educate people on the very real differences with being an Agile Architect. These are our Principles. Look at number one; "Deliver Working Solutions." And if most of that is code, well that means that us Agile Architects CODE ALL THE TIME and SIT WITH THE WHOLE TEAM and not on the mount. We use Agile Modeling. We use Simple Models with Sketches, Whiteboards, Pair Programming rather than Rational Rose UML models because the value-add is the business value we generate in code (Software Is Your Primary Goal) not some UML diagram. I am an Agile Architect.

So why am I mentioning this again? Because this Agile Correctness and Political people are drowning out any discussion of Agile Architecture in many places and experiences that I have been in. And guess what? One reason (it isn't the main reason) I am not going to speak on Agile Architecture at DevTeach in Montreal next month is that I am sick of all these politics and I don't even want to get in the arguments. Yes, I have said it. Its that irritating to me at the moment. This community, and myself included, need to figure out how to make our points in a non-religious way and realize that there are all shapes and sizes of projects and teams.