The Agile Thought Police soon descended on him. The arguments haven’t changed. they just sound more defensive and shrill :-)

BTW, your statement “But, if you are “Agile”, you will deliver valuable software to your customer. Period.” is not correct based on reality. I agree, that is what the manifesto says, but that’s not what some Agilists are doing. They instead are pushing a process on clients that may or may not work for the clients’ situation. Those consultants just want to be paid and whether through ignorance or malice are more concerned with selling there wares (i.e. “Agile expertise”) then actually helping their client produce valuable software.

Well, I have an idea! In this case you can stop saying you are “Agile” and start saying for instance that you follow ISO quality principles. Would that help you in your life?

But, if you are “Agile”, you will deliver valuable software to your customer. Period.

From the Agile Manifesto: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”. So, you may be following this.

If your coach is not focused on this, fire him! Are you not having a moment to look for a PDCA (Plan-Do-Check-Act) cycle for continuous improvement?

All these terms and principles are not new. Nothing in Agile is new. At all! Customer focus is something that comes not from software industry, but if you go back and start learning more about Toyota, there you have it. If you start reading more about Deming, there it is!

Now, if you are using Scrum you are helping your customers to have ROI faster. If you are using XP, you are tunning your engineering practices to help along the way. If you look at Lean, you will be focused on waste removal, improving culture mindset of the team, knowledge creation and looking for more profit, that can be read as ROI and also as customer satisfaction.

So, I really don’t understand why you care about being agile or not. Just drop it and start saying something that you like. No issue! Don’t like buzzwords? Don’t use them!

My favorite approach is to take the concepts that are relevant to the particular context (such as tight feedback loops, interpersonal outlook, focus on self-validating systems) and just use them, leaving all of the buzzwords and the baggage behind.

http://www.approach-alliance.nl/index.php?option=com_jd-wp&Itemid=2&cat=4

Share your thoughts with me: Need your red pencil?
Mary

I’m sure you’re aware already, but I highly recommend Steve Yegge’s “Good Agile, Bad Agile” piece that I linked to near the end. Where my post is on the angry side, his is very much witty.

Haven’t had time to read all of this site (but I will), although your ‘about’ page makes a lot of sense. It pretty much captures the way I like to think about software development; I might try and put that down in words in an upcoming post.

I fear that the term ‘pliant’ may be significantly less catchy than ‘Agile’, but I hope the ideas can catch on nevertheless.

One of the articles stated that while more systematic, less iterative and more up-front planned ways of doing things emphasize predictability, agile methods emphasize adaptability. I can understand this. Maybe 80% of all code written is contract-based. Customers always ask for predictability, and budget issues are usually quite important. You decide what works best, for these 80%. Agile methods can’t claim the remaining 20% either: there are other dealbreaker conditions to be met which are not met in most cases. For instance team structure: in order for agile methods to work, you need a team of quite skilled, more or less equally good programmers. Which is seldomly the case in real life.

Another argument for agile methods is everchanging requirements. IMO, this is shaky ground. On one hand, in my experience requirements don’t change often – it would mean that company change the way they are doing business similarly often. Only, some programmers/companies have trouble believing that requirements gathering is the most important phase in a software project. When it turns out they did a messy job at gathering requirements, they pretend requirements are changing, so agile methods are better suited for them than planned approaches. In other words, let’s fix the problem in some other place than where it is – instead of requiring the business analyst (or whoever is in charge of gathering requirements and agreeing on them with the customer) to do his job properly, let programmers iterate until they drop dead before something usable can be shipped.

The biggest problem I have with agile methods is documentation. Agile advocates argue that the code is what counts, and systematically downplay documentation. Clearly, they don’t live on the same planet as I do. It often happens that a team does maintenance on an application which was written by others. Programmers come and go. In spite of advocating weak code ownership, agile adovcates don’t account for such situations. It is IMO plain stupid to expect one team to get into foreign code without at least some documentation. While well written code might communicate intent on a low level, and structure on a higher level, it often does not communicate what’s essential for developers to get to do the right thing: the higher level intent of the application. Agile advocates will counter and say that agile methods don’t say not to do any documentation at all, but just to do the right amount. That might sound right, in their world, but what I could notice in my world is that what XP-ers usually see as just enough is nearly nothing. Furthermore, in agile methods documentation is not intended to be maintained. Writing it and not maintaining it is quite the same as not doing it at all, from the point of view of maintainability of the application across different generations of programmers.

The second biggest problem I have is the time box model. Heck, they pretend to empower people, yet they are more deadline-fascist than any planned approach I know of. Not only that, but they impose regular, multiple deadlines on people, some methods more than once a month. Someone told me this is a stupid view of agile methods, because the team decides what the length of a cycle is. Which is even worse: instead of doing your planning of milestones on a case by case basis, you are forced to decide up-front what the dates when you’ll break your neck will be, and don’t even get to blame it on management.

Somebody trashed me because I speak without first listening or reading, so I have read whatever I have found during the last few days on the topic of agile methods. I’m less interested in books or howto’s than in personal experience of people – this is what counts, IMO. What I found is that there are significantly less agile methods advocates than people who consider agile methods rightout dangerous. There must be a reason for that.

There are, however, may people who consider many of the individual techniques employed by agile methods to be useful. Which brings me back to start: agile methods are just hype. Iterative and incremental development was there before agile methods. Classical project management has integrated change management already for a long time. Starting from there, anybody should look for setting up its own processes, rather than buy into methodologies which, at least from what I could observe, work only for a small percentage of the industry.

Another thing that struck me is anecdotical. I was advised to have a look at what big agile methods evanghelists have to say. So just about the first thing I did was to go for Kent Beck’s wikipedia page. Funny things are two: the only achievment listed there is a failed project, and as I write Kent Beck focusses on design of software (states his homepage at the three rivers institute). Up-front software design isn’t written big in agile development. Is it just me spotting something that doesn’t match here?

I am a believer in XP: I think it’s an excellent set of rules to help people start thinking about how they produce software while still actually producing it. I have always believed XP to be, all things equal, a great place to start learning. Does that necessarily mean I believe XP to be a panacea? What else could it possibly mean?