Agile (SCRUM, XP, FDD, ...), Waterfall, RUP, ... Why would a small company bother adopting one in the first place. Why not just hack-away each project to completion (with a usual team size of 1~2).
I'm preparing a short presentation against the argument but would like to hear what everyone thinks.
"hacking away" is a development process, it's just not one that is easily tracked or predicted!
the point of the process is consistency and predictability
Consistency is the key. If you go from project to project just "hacking away", then it will take a coworker (or especially a new employee) a longer time to come up to speed on a project, than if there are standards and conventions in place. It really doesn't matter which standards/methodology you pick, just as long as you pick one that will work for your team, and use it consistently.
Ooh, my favorite type of question. Whenever SDLC comes up, the appropriate answer is always, "It depends!" :) I hate that answer as much as everyone, so let's dig deeper.
If your projects are manageable by a single person and very short (i.e. <3 months) then no formal process probably makes sense. PRINCIPLES of some of the processes are important, but most of the ceremony can safely be dropped. For example, in an Agile-y sort of way, I would still track cards that had technical stories (one sentence or so), user stories (a sentence or two), tasks, etc so I wouldn't drop the ball on anything. I wouldn't do iterations necessarily, just rolling-wave. If you know you have some hard date for a beta/preview/whatever, then you can plan your wave accordingly by choosing the priority of the cards you're working on week-to-week.
One benefit of having SOME process is that you will likely leave some planning/management artifacts (undone cards, backlog, etc) so if you or someone else needs to resume development on the project, you can pick it back up more easily.
A project 6mo and over with 2 or more people should definitely have some sort of process to keep things from getting too chaotic and out of sync between team members. Stand-ups are important here as are task cards and accountability.
All of this stuff, by the way, is project management/process. Even on a 1-man team, I would still use source control, Continuous Integration, TDD, etc. This is a necessity for quality software, regardless what process you're using for task assignment.
If the "hacking away" process allows the small company to deliver what their customer wants and for a cost the customer is happy with, the company should not bother to adopt any other process, obviously.
Of course the problem is that hacking away, even in a small company, makes producing these outcomes more difficult. Also, if the company or it's applications are looking to grow, hacking will rapidly become untenable.
You use a software process to manage time and resources on the project. 'Hacking away' is fine for a single person project where you don't care if what you produce is overbudget, delivered pasts all the deadlines and doesn't actually meet customer requirements*. For projects that do care about these then a software process is introduced as a layer of management. The managers can then more effectively monitor the development lifecycle, focus effort onto the tasks identified as critical, important, etc, provide feedback to the customer as to what stage they are in, and all the other stuff that seems unimportant to developers but managers and customers love because it shows that we are actually doing something they think is useful :)
*I'm not suggesting that these are always consequences for hacking away or that a more structured process will remove them. They are better called 'higher risk' areas of the hacking away method and hence a project that just hacks and hacks and hacks pretty much doesn't care if they occur or not :)
I guess the same reason as why there is a process for building cars, and building houses?
Adopting a development process can reduce how many times you say "Oh shit should have thought of that".
If a "hacking away" project fails this happens:
"lazy programmers, they should work harder""next time I will really do unit testing" or "we should have taken *this* tools or *that* language...""Bye everybody, I'm leaving"And if a running "hacking away" projects delays managers tend to add more people to the project. From there is the saying: "I need this baby in a month send me nine women!"
The tricky thing is to adapt an existing process to your company and team:
Whether or not you realize it, you already have a development process. The most salient point of looking into the wide world of processes is learn that others have found ways to make their work more productive. Maybe you can too!
Process improvement is the foundation of process. The point of adopting a process is learning how to improve systemically so that improvements don't shake the work to pieces.
The fact that you've only got two people on the team isn't the barrier to entry. I use Lean principles and kanban even on projects that I do as a one-man team. I can benefit from these because I've learned from them, and from that learning my mind was opened to ways to be more productive that I hadn't conceived of in the past.
If you already feel that you've got nothing left to improve, then you probably don't need to look into processes outside of what you're already doing. If you really feel that way, try to observe your emotional state in detail when you hold thoughts in your mind of exploring development processes. If you have even the tiniest moment of stress when you do this, you might be recoiling from the perception of the work involved rather than from the benefits of learning from the work and exploration of others. That kind of inherent psychological recoil isn't uncommon, but its rarely helpful when faced with a meaningful question.