I have noticed some mixed comment by you about SCRUM (you like its people oriented approach and dislike that it may become too-defined and strict for your liking). I also have noticed on Forum that many Ontime customers are asking repeatedly about supporting Agile and SCRUM and other methodologies within Ontime.
You even have forums:
http://community.axosoft.com/forums/thread/11802.aspx (I have asked question in Sept.07 - no answer)
http://community.axosoft.com/forums/thread/13479.aspx
Quote: “but honestly Axosoft knows nothing of Scrum, and they are unwilling to tweak the product to support Scrum. I really doubt that many Scrum shops are using OnTime, but that would change quickly if Axosoft were willing to listen to their customer base.”

Does this mean that you will be unwilling to listen to this growing number of people using SCRUM and other methods, since you disagree with them? Most people comment that they like Ontime for simplicity, transparency and many other nice features, but it lacks few extra fields and reports (burn down chart :-) ) and there is not enough flexibility with custom fields. Please comment. On the positive side for Ontime, by adding support for such methods (without compromising core of Ontime) you could have expanded your customer base by a factor of 10.
Same question I have asked about supporting ITIL (or at least some of it) , and that is also not possible with Ontime, as Related Items doesn’t really do much and it is not possible to link Incidents to Defects and no ‘knowledge base’ exists at all.

The truth is, that we as a company suffer more often, not because we have a too-strict methodology , but quite the opposite, because we don’t have any fixed methodology at all. Having grown from small company to 25 people company. Ontime product , as great as it is off the shelf product, you can buy it or not , when you bought and you want to change it, Axosoft may do the change (in some new releases) or may not at all. Our customer base is different and we need to supply customer’s demand (estimate, quote, commit to a timeline, test and deliver, commission, provide user training and then get paid) and respond to incidents 24/7 as it is time critical applications that we build. So as much as I like your free-spirited approach and having to build PureChat in 60 days - which may sell well and become another winner for you. We may not always be able to take time off and turn off our phones for 2 months. Some requests that I have submitted to Ontime more than 6 months ago , may never be addressed as there is no way I as customer can leverage your decision (we even tried to pay) to build something. So for me as customer - reading that all your team worked on some new idea is a bit sad, as it means that no one worked on features that we require for our businness (and I hate to buy yet another tool just to address one need). Mind you, we may conside PureChat for some support applications :)
I agree with lighter approach, but having no methodology at all rarely helps. All the best.

Both English and American dictionaries agree on the definition of methodology (words vary slightly by dictionary, of course). Here is one from the dictionary.

“1. a set or system of methods, principles, and rules for regulating a given discipline, as in the arts or s
sciences.”

The premise of this article is that because your are writing software that has never been written before, a methodology, analogous to the McDonald’s methdology, cannot help you. But how much of our software is truly unique? How many of us has coded a system with data stored in a database and presented on the screen? Did we map fields in the tables to objects? Did we map them to UI widgets? Did we update the tables with values from the screen? How much of that code was truly unique? Not much, hence the inexerable march towards more value in the components we use. In the past, we all coded transaction processing code. Now we use application servers. We all coded workflow in our apps. Now we use workflow platforms. And portal tools. And communication libraries. And…

I’d argue that a more realistic metaphor is a recipie. Yes a person created the first version of some tasty dish. But, following their directions significantly increase your chances of creating the same tasty dish. There is still a chance you’ll miss-read “cinnamon” and use “cumin” instead like I did the first time I made hot chocolate, but your more likely going to end up with a masterpiece.

This is the promise of methodologies: quit this insane notion that what you are building is so unique that you can’t stand to learn from other people’s successes and failures. While your software may be unique, the issues you run into aren’t.

Thank You,
Mike H
http://www.tril0byte.com
Home of Crypt Guardian