5

There are many software development methodologies - SCRUM, agile, XP, etc. - and they all have there advantages and disadvantages I suppose.

But when do we really need to apply them? Surely they are not necessary for small 1-man projects, but for large 50+ teams you can most certainly not go about ad-hoc:ing the whole thing.

So what's the line for when to use and when to not use such a methodology, if there indeed is one?

|improve this question
10

Even in a strictly 1-man project (you coding software for yourself with no schedule) you have to:

  1. Figure out what you actually want/need.
  2. Figure out how it can be done (various approaches).
  3. Implement it.
  4. See what you got and go back to 1), refining the requirements.

You could do it informally (cowboy), but given that the 1-man project is a special edge case (usually there's at least you and someone else you're working for), doing it with some well founded light formalism is virtually always preferable. Keep in mind that the core of the Agile Manifesto is really just a few principles. The formal methodologies (e.g. Scrum) aimed to reach those principles can and should be tailored according to the team size etc.

|improve this answer
2

Always

"no methodology" is still a methodology, just not a very good (repeatable, predictable, improvable) one

|improve this answer
1

The question really doesn't make sense. No matter what you do you are applying some form of SDLC approach. That approach might be cowboy coding or waterfall, but it is an approach. A better question is what projects and team sizes are better suited to what approaches.

|improve this answer
  • What I was aiming for was, when can we no longer rely on cowboy coding. Does that make more sense? If so I'll revise the question. – gablin Oct 31 '10 at 21:20
  • 1
    Please no waterfall... – Christopher Mahan Nov 1 '10 at 7:47
1

Software methodologies are purely a means to reduce project risk.

It's fairly well known that if you take a team of developers practising some methodology and tell them they don't have to follow it anymore and can work however they want, their productivity will increase, but the risk that they will build the wrong thing at the wrong price in the wrong amount of time will greatly increase.

Thus in order to choose an appropriate methodology you first need to determine what the risks are if the project fails.

If the only thing to lose is a couple of weeks of your evenings then a few sketches in a note book and no measurement of progress or deliverables is fine.

If the lives of seven astronauts and billions of dollars is the price of software failure then you better have world class planning, development process, project management and testing in place.

|improve this answer
0

The approach to the development you take must maximise the ROI of the project. Depending on the project nature and the resources available the right direction to take may be different.

There are two obvious rules though, common to designing any functioning system

  • the performance and delivarables must be quantatively measurable, metrics must be as simpe and as unambiguous as possible. (reflecting Graham Lee's comment:) As it is not always possible to set up adequate metrics at the very beginning, metrics should evolve as project goes on to reflect the growing expertise of the manangement in the problem domain
  • the risks assessement procedures (partially based on above metrics) must be set up before the project starts, and dynamically updated as project evolves. The mitigation plan must exist for every type of identified potential risk and shoud be triggered accordingly

The need in asource code version control, system backups, QA procedures, and many other essential bits is just another part of the project risk management.

One more consideration -- the bigger the company is and the more the departments like yours are the more desired it is to have some converged practices used globally to ensure minimum overhead on relocating resources from project to project and also minimum overhead on senior management required to understand the details of projects in departments they run.

|improve this answer
  • I disagree. If you're starting at cowboy coding, then you must be able to define the processes you currently perform, internalise them, measure them and identify deficiencies before you can work to "maximise the ROI of the project". That's the kind of progression identified in models like CMMI. – user4051 Nov 1 '10 at 9:59
  • @Graham Lee - The one and the only reason why projects ever start is a profit (or ROI maximisation). The profit must be measurable and risk protected (or, in other words, predictable). The details (like the formal process definitions, particular management practices and so on) are consequences of the above requirement. – bobah Nov 1 '10 at 10:07
  • @bobah: there are plenty of open source developers that disagree over the motivation for initiating software projects. But even in the commercial world, a project can be successful without a maximally-efficient project management system. The processes merely need to be good enough not to drag the project into the red. I've worked at companies that had processes with significant overhead, but were not at a mature enough state for changing the process to be achievable/desirable/possible. – user4051 Nov 1 '10 at 10:14
  • @Graham Lee - please treat my statements more generally, the profit is not necessarily cash income. A project, not generating measurable value (being cash, knowledge, expertise, brand promotion within a community, etc.) is worthless and can't be called a project. – bobah Nov 1 '10 at 10:44
  • 1
    Right, even so, my disagreements stand: you cannot reliably maximise income of any currency, knowledge or other commodity until you have the ability to measure the effect your work has on your holding of that commodity. Someone who is at the outset of defining their processes isn't in a position to make those measurements effectively. – user4051 Nov 1 '10 at 10:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.