Process Justification

What is the reason to have processes in the first place. More exactly what is the reason to have a heavyweight process. [Perhaps 'formal process' might be a better term for this discussion since it should include XP and other 'lightweight processes']

I've added a lot of comments below, but I've concluded I don't know what you mean by process. Everyone follows a process. Doing things randomly is a process.

It's already said in NoProcess, that everything has a process. It just doesn't need to be a heavy process, and fully described by methodologists. Here by heavy I mean it imposes technical choices and/or technical constraints upon the software engineer.

From NoProcess

The benefit of formal process models is the sharing of information about things that work, and things that don't work. Everyone who decides to "buy in" to a process needs to accept the responsibility of evaluating that process in relation to their own work. It's certainly true that following the rules of a formal process without understanding it or thinking about it can lead to bad outcomes. But that is your fault (or your bosses' fault), not the fault of the authors or proponents of the process. There's only one thing you always gotta do, you gotta think.

-- KrisJohnson

I think that KrisJohnson and WaldenMathews, who expressed a similar idea in NoProcessDiscussion gave the best reasons for processes and I think they're right. Processes should be about learning from experience of others, being able to follow a trail and make rational decisions about the best paths to follow. For this to actually work, a process should possess some desired qualities. I think as a software engineer I am a bit disillusioned about current processes not being actually able to fulfil this task. -- CostinCozianu

Why does anybody need ExtremeProgramming, RationalUnifiedProcess and the likes?

I mean why do you need a DefinedProcess with all kinds of prescriptions, superstitions, discipline and myths and all the goodies? -- CostinCozianu

(Assuming that is a real question, there is a real answer, or six at least. From AgileSoftwareDevelopment, p 170: 1. Introducing new people to the way people work around here, 2. Substituting in new people for previous ones, 3. Delineating responsibilities, 4. Impressing sponsors, 5. Demonstrating visible progress, 6. Curriculum for ongoing education.)

Ok, let's see, please note that the question was not why anybody needs a process?, but it wa referring to the existing ones:

1. Introducing new people to the way people work around here.

For any non stupid, non anti-social software engineer this is but a trivial problem. Who really thinks we need processes and methodologists for that? -- CC

Hmm... I think that's complete nonsense. Which source code control system is in use? Where do I check source code in? What's the naming convention for branches so the automated buid picks up my changes? How do I tell the QA people what I've changed? How do I report a bug or problem with the code I've found? When do I have to have things complete so the release manager can pick up the changes? How do I alert project management when things are slipping? How do I know we have QA staff and ReleaseManagement? When any of the above change, how will I know what I have to do differently now?

I'm sure you can think of other questions. All these kinds of questions and answers are a process. Even if your non-stupid engineer asks someone about them all, and thinks of all the right ones, that's a process. It makes more sense that there's one answer to most of these questions, rather than every engineer having their own way of working.

In fact, I think it's pretty much impossible to have a non-trivial size team deliver anything without some process. I'd be interested in hearing about any counter-examples. That doesn't mean the process has to come from text books and methodologists - but ignoring what they have to say is probably not the best idea...

I think you don't need to study XP or RuP to learn how to ask a few questions, if the team doesn't already give you a presentation. Sending an email about bugs, or using a bug management tool , learning how to "check in"/"check out", that's pretty common and basic. Nobody learns that from either XP, RuP or any other process or methodologists. Both CVS and make and many other tools for doing these activities were invented and built by programmers, for their everyday activity, they didn't come with a process. -- CC

2. Substituting in new people for the previous one.

This ends up in being the point number 1 + the problem of how the knowledge of the guy who leaves gets transferred or otherwise recovered to the guy who comes. How does a process solve that?

By giving guidance to the new and old person about what they need to transfer. By giving templates for how to represent that information - that resemble ones both have seen before, so they don't have to relearn from scratch. By ensuring that some, at least, of the knowledge was captured during the previous guy's work (because the process has checkpoints for this...

PairProgramming

3. Delineating responsibilities. This sounds good in theory. But then this is all processes need to do. A responsibility is an what I am supposed to do on the team, not how. See the NoProcess argumentation.

For example, a responsibility is: I am the guy with the database design, and I need to do it till this Friday noon., but not: "Do the database design following the class model in UML, constructing the datamodel according to the myths and superstitions from the RUP chapter <<XXX>>, and following the guidelines ... Make sure your object model drives your data model, and not the other way around, blah, blah blah." -- CC

--- 4. Impressing sponsors. This can only be a side effect of a demonstrably good process and not a justification, unless we want to be a bit hypocritical with the sponsors.

It's both. If I'm engaging a new consultancy, I'd like to see some evidence they've got an idea how to go about doing the work, rather than waiting to see if they have a good process after they've delivered (or not)

Ask for references, talk to their people to evaluate their technical competence. It's much more important than asking if they use RuP or XP or something they invented ad-hoc and they might modify for the next project to suit their needs. -- CC

5. Demonstrating visible progress. Who needs processes for that? One needs intermediate builds, counting bugs removed, bugs introduced, function points and the likes. Tracking progress along a predetermined process line doesn't really count.

But that's a process! Saying there shall be intermediate builds, bugs removed must be tracked, bugs found must be documented, etc. _is_ a process

That should be like a process. I think it's kind of a proto process or something like that. Of course, everybody has builds and bug tracking, but tracking progress along a predetermined process line might be, in RuP for example: have you built your business object model? How about the object model? How about the data model? Have you done the XXX UML diagram?. Who needs that?

6. Curriculum for ongoing education. This is the worse of them all, if not vicious. The least any software engineer can to learn is from books on processes. There are books on coding, algorithms, database design, OO design, requirements, everything a software engineer needs to know.

as long as he or she doesn't actually need to work with other people

Be sure that a software engineer who knows how to do the required engineering task, and masters the different techniques, will manage with any process at all, and especially with NoProcess. But the most summary discussion, the least amount of knowledge, the most inflexible recipes are in the book on processes. And the books on process contain a little of everything. -- CC

Now let's compare these 6 raisons d'être with the reality of the current processes. And where is the fit between the process and the problem???

From ExtremeRules

The point of the rules isn't to control what we do, it is to inform us how to do it. It's to remind us of the best known way to do things, and to make us aware when we're out on a limb.

[[In lack of other better title]]

From NoProcess, NoProcessDiscussion