[AnimalMuppet]

Extreme Programming is about the lightest "methodology". I've seen it used on a team of 30 (20 devs, 10 QA). It scaled that far, but we had a couple of exceptional "XP masters" on our team (just as devs, but they kind of owned the methodology as well).

That eventually fell apart, because upper management couldn't understand agile development, and so they killed it. Never mind that it delivered on time.

But on a small team (4-5 people), I have seen even less process. There was a manager who coded half-time. There was an overall direction, and discussions as needed. Each person had their area of specialty within the code. There were code reviews before checkin, but the code reviews were over-the-shoulder in someone's cube. There was a bug database, but there was no JIRA or other "ticket" system. (There eventually was, after the team grew. And there eventually was a quarterly planning meeting.)

There was a weekly standup for the larger team (20 people). But within the smaller team, each person kept their own to-do list. When your code needed to interface with someone else's, the two of you would hammer out what the interface was.

That won't scale too far. And it risks the mismatch with upper management that the XP team ran into. But for a small team, it can work.

[NumberCruncher]

I am happy to read this here. I manage a team of 3 and code half-time. We are heavy on XP, because I introduced it. At the beginning it felt strange for the team but in between the enjoy the empowerment it comes with.

[_phnd_]

yeh, the illusion of management control is a tricky beast to defeat.