Does The Software Development Edge use a specific process ?

[Eusebio Floriano]

Hi Joe,

I would like to know if your book references a specific process, like RUP or XP ? And does your book explain anything about agile development ?

Regards,

[Ilja Preuss]

As far as I can say from skimming over the table of contents and the example chapter, it looks like the book doesn't mention any specific process or directly speaks about Agility. It also looks to me like the world view presented in the book could be quite compatible with Agile development, though.

[Joe Marasco]

We come out strongly in favor of iterative development.

At Rational, this was instantiated using RUP, the Rational Unified Process. This worked on a wide variety of large projects across many different application domains.

The book talks some about the RUP, but the general principles described therein go beyond it.

We don't focus on Agile methods, although much of what is in the book also applies to those using Agile. In general, Agile seems to work much better on smaller projects, although I am sure there are counterexamples as well.

I tried to be as methodology independent as possible in the book, although there is no doubt that my 16+ years at Rational colored my view of things.

In any case, I stand behind what I suggest in the book.

Thanks.

Joe

[Ilja Preuss]

Originally posted by Joe Marasco:
We don't focus on Agile methods, although much of what is in the book also applies to those using Agile.

I didn't yet fully read it, but the "Getting It Out the Door" example chapter sounds quite similar to the very first Principle of Agile Software Development: "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."

In general, Agile seems to work much better on smaller projects, although I am sure there are counterexamples as well.

Well, I suspect that smaller projects work much better than the bigger ones.

You might want to take a look at the works of Jutta Eckstein: http://www.jeckstein.de/agilebook/index.html

She is known for stating that *especially* for big projects being Agile is important.

[Joe Marasco]

Originally posted by Ilja Preuss:


I didn't yet fully read it, but the "Getting It Out the Door" example chapter sounds quite similar to the very first Principle of Agile Software Development: "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."

I've got no bone to pick with the Agile folks, but "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software" should be the objective of EVERY team, independent of methodology. How can we argue with that?

What Agile, or RUP, or any other methodology is all about is HOW you achieve this objective. Just saying it's the highest priority is not particularly useful.

Thanks.

Joe

[Ilja Preuss]

Originally posted by Joe Marasco:
I've got no bone to pick with the Agile folks, but "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software" should be the objective of EVERY team, independent of methodology. How can we argue with that?

I agree that it *should*, but apparently it *isn't*.

We just joined a project that used the last two years for gathering and analyzing requirements. "User focus groups" phantasize about features they might possibly get in five years. Until recently they didn't even install the product that will be customized in the future, although that already would have been of significant value to the users.

In this project, delivering value early and often definitely *wasn't* of highest priority. And I fear that this isn't the exception in our profession.

Of course that doesn't mean that people from those projects would argue with the Agile Manifesto. In fact, the above mentioned project is "officially Agile", if you believe the project handbook. It's just that they don't really focus on it.

[Lasse Koskela]

Originally posted by Ilja Preuss:
She is known for stating that *especially* for big projects being Agile is important.

1959. NASA. Project Mercury. 4-hour iterations.

Can't get more XP than that (seriously speaking, Gerald Weinberg has been quoted to having said that what they did in Project Mercury back then was almost identical to what XP is today)

[Joe Marasco]

Originally posted by Ilja Preuss:

Of course that doesn't mean that people from those projects would argue with the Agile Manifesto. In fact, the above mentioned project is "officially Agile", if you believe the project handbook. It's just that they don't really focus on it.

Actually, it's worse than that. By hiding behind a "Manifesto" -- declaring themselves to be Agile -- and then doing everything in sort of a "business as usual" way, they (1) do not improve their chances of success in any way and (2) later give Agile a bad name because it was "an Agile project that failed."

The lesson is to pay less attention to what people SAY and more attention to what they DO. Saying that you practice the "foobar method" is meaningless if in fact you are doing something else. I fear that many projects "adopt a methodology" to satisfy some management requirement, but then blithely ignore it for most of the project. This gives process in general a really bad name.

Thanks.

Joe

[Eusebio Floriano]

Originally posted by Joe Marasco:


The lesson is to pay less attention to what people SAY and more attention to what they DO. Saying that you practice the "foobar method" is meaningless if in fact you are doing something else. I fear that many projects "adopt a methodology" to satisfy some management requirement, but then blithely ignore it for most of the project. This gives process in general a really bad name.

Joe,

In XP, the coach is the one designated for guarantee that the XP�s practices should the applied. Is there this person in RUP ?

Regards,

[Joe Marasco]

Originally posted by Vinicius Boson:


Joe,

In XP, the coach is the one designated for guarantee that the XP�s practices should the applied. Is there this person in RUP ?

Regards,

I call that person the Project Manager.

Thanks.

Joe
[ April 29, 2005: Message edited by: Joe Marasco ]

[Ilja Preuss]

Originally posted by Joe Marasco:
Actually, it's worse than that. By hiding behind a "Manifesto" -- declaring themselves to be Agile -- and then doing everything in sort of a "business as usual" way, they (1) do not improve their chances of success in any way and (2) later give Agile a bad name because it was "an Agile project that failed."

I just learned today that the above mentioned project actually is the official "Agile" pilot project for the gobernment department that is our indirect customer. That is, the outcome of the project will determine wether "Agile" development will be perceived as a viable alternative.

Fortunately, we already found ways to "short circuit" some feedback loops, such as installing a new prototype every few weeks (instead of the originally planned two "iterations" this year). Seems like things are already going better than they expected/are used to, but it's still a tensing situation...

[Ilja Preuss]

Originally posted by Joe Marasco:
I call that person the Project Manager.

Having the Coach and the Project Manager be the same person is somewhat of a slippery slope. She easily can encounter conflicts of interests, for example between rigorously following a testing approach and getting something out of the door quickly. I have read many reports in different forums from teams observing that those conflicts are more effectively resolved if the conflicting interests are represented by different persons.

There are *also* reports of teams that did just well with one person filling both roles, but it seems to be kind of an advanced practice...

[Joe Marasco]

Originally posted by Ilja Preuss:


Having the Coach and the Project Manager be the same person is somewhat of a slippery slope. She easily can encounter conflicts of interests, for example between rigorously following a testing approach and getting something out of the door quickly. I have read many reports in different forums from teams observing that those conflicts are more effectively resolved if the conflicting interests are represented by different persons.

There are *also* reports of teams that did just well with one person filling both roles, but it seems to be kind of an advanced practice...

Dealing with conflicts of interest is what a project manager does all day, every day. PMs who can't do this well are not successful. On the other hand, a PM who does not get solidly behind whatever methodolgy is being used on the project will cause it to fail -- both the methodology and the project.

Another way to put this: if the coach says one thing and the PM another, we know who wins that battle. If you have a coach and a PM, they will have to get behind "the right thing to do" in any case.

I have found the PM/Architect collaboration to be the most useful one, and in that case they must work together. Setting anyone on the project as a "counterweight" to the PM just never makes much sense in the real world.

Thanks.

Joe

[Ilja Preuss]

Originally posted by Joe Marasco:
Another way to put this: if the coach says one thing and the PM another, we know who wins that battle. If you have a coach and a PM, they will have to get behind "the right thing to do" in any case.

I guess I didn't word that very well...

Of course the responsibility of the coach is not to "battle" the PM. Her responsibility is to observe the work of the team, to raise flags, to hint at problems and to help find solutions.

She doesn't have any real power, but she also doesn't have any emotional investment in what the team is doing (quite contrary to the PM). That makes her a good "mirror" for the team.

[Joe Marasco]

Originally posted by Ilja Preuss:


She doesn't have any real power, but she also doesn't have any emotional investment in what the team is doing (quite contrary to the PM). That makes her a good "mirror" for the team.

I'm still uncomfortable with this. How can anyone who has no power and no emotional investment in what the team is doing be a good mirror for the team? I find that people without a strong emotional investment are not particularly useful in providing guidance. Witness, for example, many external consultants. The provide high-level advice and guidance, then leave. As they never have to live with the results of their advice, there in not a good feedback loop for them. As they are not personally invested, they can opine without the risk of consequences. In my view, this dilutes the value of the advice they offer.

Thanks.

Joe

[Henry Wong]

Originally posted by Joe Marasco:

I'm still uncomfortable with this. How can anyone who has no power and no emotional investment in what the team is doing be a good mirror for the team? I find that people without a strong emotional investment are not particularly useful in providing guidance.

I am not sure there is actual disagreement here. In regards to the project itself, I notice in many cases, that the coach doesn't have much interest. In some cases, I even notice that the coach doesn't have a clue about the technology or even care. However, that does not mean she is not emotionally involved. She is interested in the measurement criteria of the project, as part of the process. And also in the adherence to the process itself. This is both to achieve success, and to work on ways of improvement.

I noticed in some really high-level processes, such as Six-Sigma, all that the coach is concerned with is measuring so that the PM, and other managers, can have a high level view.

Henry

[Ilja Preuss]

Originally posted by Joe Marasco:

I'm still uncomfortable with this. How can anyone who has no power and no emotional investment in what the team is doing be a good mirror for the team?

Of course she needs to be interested in the general *success* of the team. But she shouldn't care about the actual practices the team uses. She should only care about the fact that the team uses the practices that helps it most.

If the coach had power, how would she use it? As far as I can see, any attempt to *enforce* something can only distort the image she presents to the team.

To make good decisions, the team needs to see the whole picture. I think that is hard if you are in the thick of it; having someone who is committed to the success of the team, but can take the view of rather an outsider and can arbitrate between the parties involved doesn't sound useless to me.

Witness, for example, many external consultants. The provide high-level advice and guidance, then leave. As they never have to live with the results of their advice, there in not a good feedback loop for them. As they are not personally invested, they can opine without the risk of consequences. In my view, this dilutes the value of the advice they offer.

There is certainly a risk in this, yes. I don't have personal experience with external consultants, but I know some I'd be happy to have on the team for a week though, just to hear what they have to say. I'd say that can be valuable input for the team. I suspect that much bad experience with consultants actually comes from misuse of their advice - when management decides that "they said X, so we do X".

A coach is still different from this, though, as she is an integral part of the team and doesn't leave after a short period of time. She succeeds when the team succeeds.