Is Extreme Programming only for the experienced?

Question

I might be working with a team on a buisness workflow automation project, since it is a business workflow we are looking to have constant interaction with stakeholders and frequent releases. The team however, is pretty new and the average experience is around 3 years. Do you think the lack of experience could be a problem if the project was tackled in Extreme Programming way?? There doesnt seem enough Agile experience too. Would it be a good idea to let the developers talk to stakeholders or we need someone like a spokes person?

I would really appreciate your opinions on this.

Answer 1

One aspect of extreme programming that can help is pair programming. If you pair weak programmers with strong programmers, then the weak programmers should be able to get much more experience much quicker, and learn the proper way of doing things at a much faster pace. An inexperience programmer left on their own to program can be a very bad thing. An inexperienced programmer who has to be disciplined, create unit tests, pair program, and follow a string development methodology can be a lot more effective.

Answer 2

3 years is a good enough basis to start learning to (a) estimate, (b) talk to stakeholders (aka non-technical people), and (c) be held accountable for results.

Answer 3

Seriously, I despise the term "Extreme Programming". It's asinine. Agile is good, the implications are mature, and the process works. I swear, Extreme Programming (grunt?) was proposed as a way to simply shake up the software development community. Agile development, and the Scrum methodology, would be my suggestion.

I think you probably just need to get a book on Scrum (try "Agile Project Management with Scrum") and that'll be a good way to go. Specifically, no, the devs don't particularly talk with stakeholders; that way lies madness. But there is, in Scrum, a Stakeholder representative who mediates the communication with the Stakeholder and servers as a gatekeeper for information in both ways. It's pretty well laid out in the book.

Answer 4

I'd invest in some training for the team with a scheduled "tune up" after they have been running awhile to keep them on course. Agile development and XP, in particular, requires discipline to make it work properly. There is no sense in learning bad habits that will come back to haunt you. Check out the training available from Industrial Logic, I've spoken with these folks at industry events and they really seem to know their stuff. I'm trying to find a way to get an enterprise-wide ability to use their training materials locally.

EDIT: I'm not too fussed about the 3 years experience thing. I'd be more concerned about them learning a new methodology. The techniques are not particularly hard, but doing them right takes practice. With no experienced person on the team and little experience with Agile, the time and money spent on getting some expert advice would be well worth your effort.

EDIT 2: As far as developers talking with customers. I agree with some of the others here in that I think you need a "go to" person that the customer can identify as the person to talk to unless your customer is part of the team. This person could be a team lead or an actual project manager. I do think developers need to be involved in direct discussions with the customer. Having the customer on the team is the best way to do this. If this isn't possible, then involve them in meetings, etc.

Answer 5

I find that pair programming (and it's cousin pair debugging) is an excellent technique for sharing knowledge both between peers and people with different level of experience.

In my experience TDD is also suitable for less experienced developers.

Answer 6

Many people think "extreme programming" means wild west, no rules. XP is not undisciplined, it's just a different form of discipline than waterfall etc. Part of XP is writing lots of tests. How could it be bad for an inexperienced programmer to write lots of tests? Another part of XP is pair programming. What could be better for an inexperienced programmer than to pair program with someone else? (But some folks on the team need to be experienced.)

Answer 7

Extreme or not (I'd agree with others, that extreme programming should work in your case), but developers shouldn't talk with stakeholders on their own.

The flow of requirements and developer beliefs should be controlled. There should be some representative, so stakeholder won't need to ask 'whom should I ask if I want to know this?", and developers won't waste their time on doing things that are not discussed properly. There should be at least one person with some vision about what's currently being done and what are key features or problems.

EDIT: Developers should be aware of the discussions between stakeholders and teams representative, so they can react or respond if customer raises question, or propose some unusual/hard to implement feature.

Answer 8

That's how I learned C++ - with my only previous experience being BASIC on an old Tandy.

I think it's a great tool for beginners - both to a language, and to programming.

Answer 9

My experience with agile process is that it seems to work better with smaller teams working on smaller projects. Big teams and Big projects have trouble with achieving the quantity and quality of communication required for agile.

So the real question isn't so much how old your programmers are as it is how many you've got (and how many you think you need).

If you've got so many stakeholders and so many developers that you're thinking about providing a single point of contact, your project might be too big.

Answer 10

A couple of points.

First, I agree with tvanfosson, I would be more concerned about learning a new methodology than with the three years experience. I've observed a low correlation between experience and code quality/productivity.

Second, in my experience prescriptive ("Big-M") methodologies seem to be designed to prevent 'low quality' developers from screwing up a project. If that works is another question. I've only read a couple of books on XP, I haven't actually tried it, but it seems to me that it is a highly disciplined process. If you have a good team, you're more likely to succeed regardless of your methodology.

Answer 11

I see XP as an extremely disciplined approach. There's no silver bullet though regarding turning an inexperienced team into a highly productive one. Three years experience say nothing about their capabilities. If they've been micromanaged for this time, they'll most likely not succeed without some external help.

Starting an XP project - just like almost any agile project, sorry, just like any software project - will be slicker with a coach available to take care of the process.

Be careful for namedroppers though. Sometimes XP is an excuse for cowboy coding without documentation (we don't do documents, therefor we XP). Don't aim for XP, aim for a productive and efficient, value-delivering project.

Answer 12

A specific methodology will not determine the fate of project, it will only amplify it.

Answer 13

What less experienced developers need are basically:

• a lot of guidance on what to do, and
• a lot of feedback on how well they are doing

In my experience (in one project actually with developers coming directly from university), with it tight feedback loops and the very specific development practices, XP is just perfect for less experienced developers. They still will need a lot of coaching and mentoring, but that would be true in any case.

It's good to have the developers talk directly to stakeholders, because that will improve their understanding of what the system actually needs to do and why. Also, the direct contact can have a very motivating effect.

You will need to take care that those stakeholders don't override the decisions of the Customer (a role in XP), who has the final say on what gets developed when and decides on the acceptance criteria (probably in collaboration with the other stakeholders and the rest of the team). But that's true for experienced teams, too.

Answer 14

Given that XP is mainly composed of engineering practices, it is more difficult to learn than the agile management (SCRUM) practices. A team that just uses SCRUM will likely get itself into trouble. Development will become increasingly more difficult with each new iteration. A team that uses both SCRUM and XP, is much more likely to be able to sustain success.

XP, in particular, Test Driven Development (TDD) can be challenging for a team that is not familiar with XP. For a team new to XP, it is best to embed a technical coach. In addition, pairing will help developers learn the engineering practices at an accelerated rate.

If you are doing to do Agile, use both SCRUM and XP. The learning curve is higher for XP but the long term success will pay dividends.

Once you have a well functioning Agile team, you can add new developers to the team. By rotating the pairs on the team, the new members will come up to speed very quickly. From this point on, even junior developers will quickly become effective