Joe Marasco

author
+ Follow
since Mar 23, 2005
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by 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

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

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 ]

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

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
This is what we might call a "target-rich environment".

Analogy is a way of trying to explain things without resorting to technical jargon. Sometimes it can be very useful in explaining things to people who are not skilled in the art, as the patent people say.

The problem is that sometime the analogy is just plain wrong, or misleading. In particular, construction analogies that have been used in software are only half-truths. The problem is deciding which half is true and which half is not.

There is an entire chapter in the book entitled "Bad Analogies".

I think that really good analogies can be extremely helpful. On the other hand, it is very easy to draw a bad analogy. Therein lies the problem: the non-expert reader cannot tell the difference. And that is exactly the reader for whom the analogy is intended.

Hope this helps.

Thanks.

Joe
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
I am unfamiliar with the certification you mention.

My experience is that "high ceremony" organizations that focus excessively on process and certification often miss the forest for the trees.

The most important thing on any project is to get great people. They may or may not be "certified". You need to interview them for skills, compentency, and character, none of which can be guaranteed by passing a test. On the other hand, sometimes "uncertified" people will have the mix you need. So I would focus more on what candidates can bring to the table, as opposed to rigid notions of certification.

UML is only one part of the total picture. It is useful and helpful, but not a panacea. I think the more important notions to assimilate have to do with iterative development. The RUP is one instantiation of this, an instantiation that has worked on large projects.

In the end projects are successful because of a conjunction of good process and great people. Overdependence on things like CMM levels will inevitably lead you astray.

Hope this helps.

Joe
Cool! What year? I'm BChemE class of '66.

Thanks.

Joe
Early reviews of the book can be found here.

Thanks.

Joe

[ April 27, 2005: Message edited by: Joe Marasco ]
[ April 27, 2005: Message edited by: Joe Marasco ]
Incidentally, Amazon is taking pre-orders, and we expect them to start shipping sometime in the first week of May.

On the other hand, Addison-Wesley has the book in stock, and you can order it directly from them at:

Addison-Wesley web page for The Software Development Edge

You can also read a sample chapter on the A-W site.

Thanks.

Joe
[ April 27, 2005: Message edited by: Joe Marasco ]
Glad to be on board.

One of the things I talk about in the book is checking out the culture and values of a company when looking for a job. Have a look at page 279.

I'll be glad to answer any questions you have on the book.

Thanks.

Joe