The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
TechInterview.org
CityDesk
FogBugz
Fog Creek Copilot


The Old Forum


Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

What are the advantages & disadvantages of Agile ?

Here's a question for those who have worked with the Agile Methodology :


What are the advantages & disadvantages of Agile ?

I've just read Martim Fowler article called the New Methodology and I'm wondeing if I should give this methodology a try

Thank you for you inputs
Bummer
Monday, January 01, 2007
 
 
advantages:

1. notecards
2. group hug
3. ruby on rails
4. Object Oriented
5. gift-based society

disadvantages:
1. stupid managers wont understand
2. other programmers (Stupid Ones) won't understand
3. expensive, must attend training seminars to recieve certifications, flowcharts, mug. well worth it though
4. wiki not as good as EXTREME
5. you're having too much *Fun*!!, you'll never want to use rainstick or caddyshack methodology again
agile analyst
Monday, January 01, 2007
 
 
Another thing is that since only stupid people don't understand the benefits of agile, by working in agile, you preselect for smart, goodlooking coworkers.
Dirk Bentley
Monday, January 01, 2007
 
 
I wrote some material on the advantages here: http://www.agilekiwi.com/guide_to_agility.htm

I think its disadvantages are the disadvantages you will see in virtually anything which is still new enough to be trendy, but old enough to have been mis-understood, mis-interpreted, and publicly squabbled about.  In that context, you might also find this relevant: http://www.agilekiwi.com/scientific_experiments.htm
John Rusk Send private email
Monday, January 01, 2007
 
 
>>benefits of agile, by working in agile, you preselect for smart, goodlooking coworkers

I especially like the goodlooking coworker aspect to Agile. We only hire women developers; except for me of course :)
lemon obrien Send private email
Monday, January 01, 2007
 
 
Agile methodologies work exactly as well as other, traditional methodologies -- not at all.

No one really knows how great software is created, which is why every two years a new management fad sweeps the industry and changes the methodologies. Software projects don't succeed because of these management fads, they succeed in spite of the fads, through brute force, a few very creative people, and --all too often-- death marches.

10 years of experience at a variety of companies, and I've yet to see anything that makes more sense than "prioritize tasks, test early, test often".

But, I'm sure that the silly fad of 2008 will be the one that works!
A Lackey
Monday, January 01, 2007
 
 
"10 years of experience at a variety of companies, and I've yet to see anything that makes more sense than "prioritize tasks, test early, test often".

But, I'm sure that the silly fad of 2008 will be the one that works!"

is that the same as "Getting real"?
.
Monday, January 01, 2007
 
 
> not at all.

Total drivel. There are many many successful agile/scrum deployments. For info take a look at this group: http://groups.yahoo.com/group/scrumdevelopment/
son of parnas
Tuesday, January 02, 2007
 
 
A Lackey,

Like you, most of us have to rely on our own personal history of projects as a guide to what works on what doesn't.  I only know of one person who's conducted rigourous research into what works and what doesn't.  The end result is consistent with your suggestions above, and with a broad interpreation of Agile (as opposed to using a rigid interpretation of XP as "the" definition).

I've posted a brief summary of the results, with links, here: http://www.agilekiwi.com/crystal_clear.htm

You can find links about the original research under the second of the two links I posted above.

Yes, I know this is research by only one guy.  But that's one more guy than anyone else has been able to come up with ;-)
John Rusk Send private email
Tuesday, January 02, 2007
 
 
>> There are many many successful agile/scrum deployments. <<

I've been in the business for nearly 28 years, and have seen many successful projects using all sorts of methodologies (both big M and little m).

The only characteristic unique to all of the successful projects has been the use of clever and experienced people. But even that doesn't always work.

So I'm skeptical about all methodologies, including agile.
Mark Pearce Send private email
Tuesday, January 02, 2007
 
 
The only methodology that works is Correct Code. Clear and Concise both help.

Smart programmers, smart managers and smart prioritising all tend to help as well but they are not methodologies, only bonuses. Neither are they guarantees.
less is more
Tuesday, January 02, 2007
 
 
>> Smart programmers, smart managers and smart prioritising all tend to help as well but they are not methodologies, only bonuses. <<

Correct Code isn't a methodology either.

>> Neither are they guarantees. <<

Correct Code isn't a guarantee either, for nearly every value of "Correct" that makes any sense in the real world.
Mark Pearce Send private email
Tuesday, January 02, 2007
 
 
A few months back I wrote an article titled "Perils and Pitfalls of Agile Adoption":

http://www.informit.com/articles/article.asp?p=441115&rl=1

Nine months and a few war-stories later, I think there is more to it than that. 

In some ways, there is a sort of meta-physics to software development.  There are a *lot* of variables that interact to get you the final product. If you understand most of the variables and how they interact, you can make an informed decision about *this* project, in the moment.

If you don't, and just try to use someone else's pre-formed solution ... well, it doesn't really matter if you're waterfall, CMMI, scrum, XP, DSDM, or Crystal, you are pretty much hosed.

So I make the focus of my writing and speaking in helping people grok those system effects, to solve problems themselves.

Regards,
Matthew Heusser Send private email
Tuesday, January 02, 2007
 
 
You can't start doing real Agile development at a company without a whole fresh batch of people in most cases.  If you have to "consider" Agile at your workplace then it's NOT GOING TO HAPPEN with the current set of people.

If you get a bunch of bleeding-edge intelligent people together to develop software, they will most likely all be ready to do Agile at the drop of a hat.  Programmers who don't already know what it is and aren't pushing for it likely aren't smart/driven enough to keep it up.

Agile = great
Agile adoption at a non-agile workplace = painful
John Cromartie Send private email
Tuesday, January 02, 2007
 
 
Can't remember who said this, but:

"We tend to seek easy, single-factor explanations of success. For most important things, though, success actually requires avoiding many separate causes of failure."
Mark Pearce Send private email
Tuesday, January 02, 2007
 
 
>If you get a bunch of bleeding-edge intelligent people together to develop software, they will most likely all be ready to do Agile at the drop of a hat. Programmers who don't already know what it is and aren't pushing for it likely aren't smart/driven enough to keep it up.<

What a load of horse hockey. I've seen (and been a part of) many bunches of bleeding-edge intelligent people develop software and fail miserably with any number of methodologies, including Agile. And most of what I've learned in my career that has been really helpful has not been from the bleeding edge, but from people that have been doing this for quite some time. They could pick up the bleeding edge stuff when necessary and have enough experience not to cut themselves and bleed all over the project and drown it in a pool of their own blood.

That being said, here's my experience.

Advantages:

- Encourages getting to working software quickly. We all like working software. It's hard waiting a long time to see if something might work.

- Fosters more flexible software. Getting to working software more quickly usually means smaller components and reusing libraries.

- Empahasizes testing. I've never experienced more pain than when writing for a long time and then testing at the end of a cycle and crossing my fingers, sacrificing chickens, etc. hoping it would work. I now test everything I write as I go (before in some cases, TDD can be your friend...) no matter what kind of project/team/methodology I'm working with.

- Encourages refactoring. Since the goal is usually working software as quickly as possible, you aren't inclined to overarchitect a system as often. This means you usually get to revisit code you already wrote to fit more general cases and in the process come up with a more natural modeling of the problem than if you designed the whole jalopy up front.

Disadvantages:

- Encourages laziness. YAGNI and "document only what you need" seem to be translated into "I'll do what I feel like." by new developers or those that have lived in the ivory towers of R&D or academia.

- Doesn't scale well. Agile encourages small, smart teams.  Brooks encouraged the same thing in 1975. He also recognized some systems require large teams and that this is a whole different kettle of fish. Agile seems to ignore this for the most part.

- Many agile practitioners contradict the agile manifesto. "Individuals and interactions over processes and tools " yet different people are more than happy to push scrum/XP/TDD/(pick your favorite) as THE way to develop software.

- The "over" in the agile manifesto seems to be de-emphasized, if it is regarded at all. 'Responding to change over following a plan' is much different than 'Responding to change, don't plan', which seems to be what a lot of people do.

- Like all new shiny things, people in love with it will call you names if you don't like or criticize their methodology. It doesn't matter if your opinion is founded on, say, a decade and a half of successfully delivering real, working software to real, paying customers. You're obviously an idiot for doing what works for you instead of adopting the newest shiny dohicky.

The last disadvantage I'll list is simply a matter of my own personal taste and it especially applies to Extreme Programming. I HATE PAIR PROGRAMMING. Your mileage may vary, but I like it when it's just me and the keyboard. I've done both. I'm generally more productive without a second pair of eyes over my shoulder. I'm all for peer review of code, just not while I'm in the middle of writing it. I realize some people think pair programming is fantastic. That's fine. I'm just not one of them.

No matter your opinion on agile methodologies (love 'em or leave 'em) I would suggest looking at this http://www.softwarereality.com/ExtremeProgrammingRefactored.jsp as well as all the good (http://agilemanifesto.org/, http://www.martinfowler.com/) agile information out there.

At the end of the day, writing software is creative and you gotta do what works for you. My suggestion is to keep asking questions like this, take all the answers you get with a huge grain of salt (mine included!) and cherry pick what works for you. Nobody out there has THE answer. It's not like any of us changing water to wine as we're doing this. Software Engineering is still a very young field. We're all still trying to figure this thing out together.
Bart Park
Tuesday, January 02, 2007
 
 
> I've been in the business for nearly 28 years, and
> have seen many successful projects using all sorts
> of methodologies (both big M and little m).

Very true, Agile isn't necessary for success, it just improves your odds. Much like knowing some engineering principles helps you build better buildings but they can still fall down.

Scrum works IMHO because it encourages you to adapt and continually improve. This intersection of Scrum/XP/Lean is a process for both creating things while creating a better process.

Some interesting resources:
* http://video.google.com/videoplay?docid=-5105910452864283694 - Lean Movie by Marry Poppendieck

* http://www.infoq.com/presentations/The-Roots-of-Scrum - The roots of scrum by Jeff Sutherland.

* http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf - A very nice paper on a real life Scrum deployment.

* http://www.infoq.com/news/2006/11/ken-schwaber-code-quality  - Canary in the Coalmine talk.

* http://video.google.com/videoplay?docid=-7230144396191025011  - Google Ken Schwaber Talk
son of parnas
Tuesday, January 02, 2007
 
 
+++Bart!
Doug Send private email
Tuesday, January 02, 2007
 
 
> I HATE PAIR PROGRAMMING.

I do too, but that's XP, it's not Agile. Baby with the bath water and all that. Scrum separates programming practices from development process. You can adopt the practices your team and organization think make sense. The XP practices are a good place to start though.
son of parnas
Tuesday, January 02, 2007
 
 
>> I HATE PAIR PROGRAMMING.

>I do too, but that's XP, it's not Agile. Baby with the bath water and all that. Scrum separates programming practices from development process. You can adopt the practices your team and organization think make sense. The XP practices are a good place to start though.<

I'll assume that you missed the parts of my post where I said that it applies to extreme programming (I know it was hard to find. It was right before that comment.), that you should read a variety of sources and that you should cherry pick what you find useful.

I don't think I said anything about throwing any babies out with the bath water. I don't remember saying anything like 'run away from agile methodologies'.

By your reasoning "There are many many successful agile/scrum deployments.", we could use just about any methodology since there have been many, many successful X deplyoments where X is your methodology of choice. No Methodology, CMMI, scrum, XP, waterfall, have all had successful deployments. Waterfall might have the most successful deployments of all in terms of number and size of projects delivered, yet it is universally loathed, so it would appear that number of successful deployments isn't really much of a criteria.
Bart Park
Tuesday, January 02, 2007
 
 
> I'll assume that you missed the parts of my post

So I shouldn't respond with my reaction which took off from that point but was not limited to it?

> we could use just about any methodology

Certainly you could. When selecting a methodology however what might you use in making a decision? Successful deployments might be among them. And by successful I would mean something like the customer is happy with results. In that sense Scrum works. Yet it's not the only thing that can work.
son of parnas
Tuesday, January 02, 2007
 
 
+1 Bart Park

The one difference I have is not a disagreement, but with the taste issue of pair programming.  I've tried it with about a half-dozen different people.  All but one were dismal failures.  The one that worked was great.

In every case I was the more experienced coder, and all the ones that failed spent half their keyboard time questioning my design choices instead of writing code.  The one that worked wrote the code I wanted when he was on the keyboard, and told me what he wanted (but not how) when I was on the keyboard.

I think it's like driver and navigator in a rally: the navigator tells the driver where to go, the driver gets there without flipping the car.  If the driver questions which way to turn, or the navigator keeps pointing out every rock in the road, they'll get nowhere fast.
Drew K
Tuesday, January 02, 2007
 
 
>> Very true, Agile isn't necessary for success, it just improves your odds. <<

My experience is that Agile doesn't improve the odds as much as having the right people. By "right", I mean a good combination of domain experience, software development experience, and brainpower.

But of course YMMV - every project is different, and there are several different types of software development.
Mark Pearce Send private email
Tuesday, January 02, 2007
 
 
> My experience is that Agile doesn't improve the odds
> as much as having the right people.

Toyota manages to make quality products from local labor pools wherever they are located. They hire a certain kind of person but then then put them in a process that drives success. The kind of person they hire is one who will work well in the process, they don't have to be super genius. It's like in sports, a team with only the best players won't win because that's not what a team is.

If the only way a project can succeed is to have exactly the right people then only 10 projects will be able to succeed simultaneously on a world wide basis.
son of parnas
Tuesday, January 02, 2007
 
 
>> I'll assume that you missed the parts of my post

>So I shouldn't respond with my reaction which took off from that point but was not limited to it?<

Respond all you want. Just don't put words in my mouth like I'm throwing the baby out with the bath water. I say enough idiotic things on my own. I don't need help. :-)

>> we could use just about any methodology

>Certainly you could. When selecting a methodology however what might you use in making a decision? Successful deployments might be among them. And by successful I would mean something like the customer is happy with results. In that sense Scrum works. Yet it's not the only thing that can work.<

And so do a lot of other things. Up until this post your response was Scrum, Scrum, Scrum. Most of the evidence to date would suggest that having A process is more important than which process you have. I agree that saying it matters "not at all" is total drivel.

Scrum sounds like good common sense. Makes me wonder how they sell any books on it at all. Look at what you have to do, prioritize it, do what you need to get done in X timeframe and then see if it is good enough. Repeat. I've always wondered how things like that turn into consulting sessions, high priced seminars and the like.
Bart Park
Tuesday, January 02, 2007
 
 
>> Toyota manages to make quality products from local labor pools wherever they are located. <<

Making a car is very different to "making" a software product. The whole car process is much more mature, especially construction.

>> If the only way a project can succeed is to have exactly the right people then only 10 projects will be able to succeed simultaneously on a world wide basis. <<

I'm sorry if that's the impression I gave. What I meant was that you need some people on the team with the combination of attributes that I mentioned.
Mark Pearce Send private email
Tuesday, January 02, 2007
 
 
I've been an agile developer and coach for 5+ years now using XP and Scrum. That may make me experienced or brainwashed. You decide.

In that time I have worked on 5 different projects. One, a greenfield project, was a huge success. Two others, legacy projects, showed huge improvements in delivery reliability and defects. One turned a troubled legacy project into a stable legacy project. The last I consider a failure as we delivered late and with some reductions in scope.

The interesting point about the failure was that I knew we were in trouble very early. Much earlier than I would have using traditional project management thinking. Fortunately for me, our management was enlightened enough to notice that the techniques we used allowed us to provide that warning early and so they resisted the temptation to throw the baby out with the bath water.

Overall, I would say I have a favorable batting average. I've learned a lot about software development during the journey and I can safely say there will always be some "agile" thinking in anything I do from this point on.

Can you succeed without agile? Most certainly. Does it hurt to start thinking in a more agile way? Very likely not, unless you're working on very high risk projects and even then the concepts of postponing decisions until the last responsible moment is a sound practice.

While I cringe at the comments about "stupid" managers and developers, there may be an element of truth in the idea that agile works better with smarter people. But then, that's pretty much true of any system involving people, isn't it?
Bruce Rennie
Tuesday, January 02, 2007
 
 
> Making a car is very different to "making" a
> software product. The whole car process is much
> more mature, especially construction.

I think that's what people say when they want to dismiss the troubles of software development.

Toyota produced the Prius in record time because of how they do it (http://money.cnn.com/2006/02/17/news/companies/mostadmired_fortune_toyota/index.htm) . It's not a matter of maturity or Ford and GM would do it, and they don't: http://leaninsider.productivitypress.com/LeanInsider/tabid/36/EntryID/28/Default.aspx

Toyota's process can't be said to be mature because they are always changing it to be better.
son of parnas
Tuesday, January 02, 2007
 
 
<quote>
Making a car is very different to "making" a software product. The whole car process is much more mature, especially construction.
</quote>

And yet, agile methods are built on the foundations of lean. A lot of things have translated very well to the software world.

The famous index cards are nothing more than a simple kanban system, for example. Postponing decisions until the last responsible moment is also taken from lean manufacturing.
Bruce Rennie
Tuesday, January 02, 2007
 
 
"* http://video.google.com/videoplay?docid=-5105910452864283694 - Lean Movie by Marry Poppendieck "

Damn, I hope they didn't pay her for that lecture.
old.fart Send private email
Tuesday, January 02, 2007
 
 
A quick reaction to two SoP quotes:

Quote 1: "...that's XP, it's not Agile." Yay, I'm glad that was made explicit. Whether anyone here was confused over the two or not, it's a common mistake, and somewhat frustrating, because the Agile world is a big place with a lot of options. (Personally, I've got most out of Crystal Clear.)

Quote 2: "There are many many successful agile/scrum deployments." Yes, but that doesn't prove that it works. You'd have to show that there are *more* successes than in a situation where no methodology was followed (or a competing methodology was used), on an equivalent project with an equivalent team. As far as I know, there have been no proper experiments done for any methodology. One approach to getting past this dilemma is to do what Alistair Cockburn did, to visit teams that consistently perform well and look at their practices.

My 2 cents.
EKB Send private email
Tuesday, January 02, 2007
 
 
>> Toyota's process can't be said to be mature because they are always changing it to be better. <<

Yes, but car-making is a relatively mature business that lends itself very well to process automation and process improvement. My argument is that software development is 1) still in its infancy, and 2) is completely different to car design and construction.
Mark Pearce Send private email
Tuesday, January 02, 2007
 
 
>> And yet, agile methods are built on the foundations of lean. A lot of things have translated very well to the software world. <<

Of course software development as an industry can learn from many other disciplines. But its primary asset is brains, which is where my emphasis on people over process comes.

For me, the methodology (agile, or whatever) always comes secondary to the quality of the people involved.

Agile is not some type of panacea or solver bullet. It isn't superior to every other process that's been tried. It's just another brick in our wall of knowledge about software development. All we can do is try lots of "bricks", improve our knowledge, and pass this information on to the next generation of developers.
Mark Pearce Send private email
Tuesday, January 02, 2007
 
 
John Cromartie wrote: "You can't start doing real Agile development at a company without a whole fresh batch of people in most cases.  If you have to "consider" Agile at your workplace then it's NOT GOING TO HAPPEN with the current set of people."

So, it's a methodology that is typically unsuited for most development teams? HA!

Because Agile is still fairly young, it attracts a lot of those "If you don't think it's great, you just don't get it (idiot)" boosters. These people generally end up being a problem in any decent sized organization.

Agile is a methodology. It's better than having no methodology, so long as you're willing to apply it intelligently and flexibly. Alot of the Agile cheer leaders aren't that flexible.

Next management fad: something with a spinning wheel of tasks!
A Lackey
Tuesday, January 02, 2007
 
 
<quote>
Of course software development as an industry can learn from many other disciplines. But its primary asset is brains, which is where my emphasis on people over process comes.
</quote>

I'm not following you. What is a process if not a set of rules for managing/organizing people with brains?

Btw, I agree with you that software is all about the people. Where I tend to disagree with you is the implied statement that the auto industry isn't. Is it possible that the only difference between Toyota and GM is the people they employ and the processes they use?
Bruce Rennie
Wednesday, January 03, 2007
 
 
>Next management fad: something with a spinning wheel of tasks!<

I think they might have done that at the last job I was at. Mind you I haven't actually seen the wheel, but I've been wondering....
Bart Park
Wednesday, January 03, 2007
 
 
>Btw, I agree with you that software is all about the people. Where I tend to disagree with you is the implied statement that the auto industry isn't.

The difference between making cars and making software is that the huge efficiency gains to be had with cars are in the build process.  In software, that's already a (mostly) automated process.

For a comparison to work, you have to compare writing software to the car *design* process.  No manufacturer tries to apply Six Sigma to the design team.  Any concept based on treating design as manufacturing is fundamentally flawed.
Drew K
Wednesday, January 03, 2007
 
 
>> What is a process if not a set of rules for managing/ organizing people with brains? <<

A process is usually designed to help you deliver X when you don't have people with large amounts of experience in delivering X. Process is often used as a way of dealing with  the inevitable fact that's it's difficult to find very good people.

But software development isn't like many other skills. It relies very heavily on big brains and lots of relevant experience. It's perhaps similar to research. IMX, putting a process in place doesn't usually help you as much as just having the right people.

>> Btw, I agree with you that software is all about the people. Where I tend to disagree with you is the implied statement that the auto industry isn't. <<

As I keep saying, the car industry is very different to software development. Any direct comparisons won't give you good results.
Mark Pearce Send private email
Wednesday, January 03, 2007
 
 
>A process is usually designed to help you deliver X when you don't have people with large amounts of experience in delivering X. Process is often used as a way of dealing with  the inevitable fact that's it's difficult to find very good people.

But software development isn't like many other skills. It relies very heavily on big brains and lots of relevant experience. It's perhaps similar to research. IMX, putting a process in place doesn't usually help you as much as just having the right people.<

I don't disagree that you need "the right people", but just having the right people and having them all run around doing their own thing isn't conducive to good results, either. I'll take good people with a good process over good people with no process any day, and I can't imagine running a truly large team without some process in place, anyway. As your team grows you are going to revert to the mean no matter what you do.

In The Mythical Man Month Brooks states that at its peak over 1,000 people were working on OS/360 and approximately 5000 man-years went into the project over 3 years. How on earth would you manage that number of people without having some sort of process in place?

I think both people and process are a sliding scale from horrible to brilliant and the size of your team and the kind of work you are trying to do dictates where on each spectrum you need to get to. Some projects won't do well with anything but brilliant people and can limp by with a poor or mediocre process. Some projects can do quite well with good process and average or slightly above average people.
Bart Park
Wednesday, January 03, 2007
 
 
<quote>
For a comparison to work, you have to compare writing software to the car *design* process.  No manufacturer tries to apply Six Sigma to the design team.  Any concept based on treating design as manufacturing is fundamentally flawed.
</quote>

I'm not sure how much I agree with this statement. There are design and construction steps in both manufacturing and software. I would also point out that Toyota most definitely DOES apply their process to design. In fact, it's one of the primary reasons they walk all over the north american companies.
Bruce Rennie
Wednesday, January 03, 2007
 
 
<quote>
As I keep saying, the car industry is very different to software development. Any direct comparisons won't give you good results.
</quote>

I know you keep saying that. I'm just not sure you're right.

I might also tend to disagree with your statement that process is mainly for people with little experience or who are of "low quality". The scientific method is a process and it isn't for the benefit of the stupid scientists only.

I stand by my original statement: a process is a set of collective rules designed to manage and organize a group of people, be they line workers in a Toyota plant or software developers. Processes are all about the brains. A good process helps get the most out of the brains. I don't think you can truly have an emphasis on people and ignore process.
Bruce Rennie
Wednesday, January 03, 2007
 
 
> In The Mythical Man Month Brooks states that at its peak over 1,000 people were working on OS/360 and approximately 5000 man-years went into the project over 3 years.

Can I get a math check on aisle 1?

(Okay, fine, I know that "over 1,000" could mean "nearly 2,000" and it would work.  But I did a double-take when I read it.)



> There are design and construction steps in both manufacturing and software. I would also point out that Toyota most definitely DOES apply their process to design.

I knew I should have been more specific. :-/

There are aspects of car design that strictly deal with measurable quality: performance of the electrical system, horsepower, fuel economy, reliability.  But the shape and style of the car are much more loosely coupled to hard-and-fast measurements.  That facet of the design -- the way it looks, the demographic it will appeal to -- was what I was referring to.

Granted, there are some cars that are strictly (or nearly so) utilitarian.  Some people only care about efficiency and reliability.  They buy Corollas by the boatload.  But the FJ Cruiser is not the result of a logical, statistical analysis, with high conformance to the mean and low variation of anything.

I think what I'm trying to say is that marketing design is building the right thing, while production design is building the thing right.  The auto industry is mature enough that you need both.  Success in the software industry still relies more on building the right thing.
Drew K
Wednesday, January 03, 2007
 
 
Drew, I'm just quoting page 31 of my copy (1982 edition) of the Mythical Man Month.

"At the peak over 1000 people were working on it-programmers, writers, machine operators, clerks, secretaries, managers, support groups, and so on. From 1963 through 1966 probably 5000 man-years went into its design, construction, and documentation."

So it's probably 4 years, not 3, depending on when they started in 63 and ended in 66.

If you want to write Brooks and get that math check, be my guest. If it was only half that, I would still defy you to manage a project of that size with absolutely no process in place. Hell, I'll be a project a 1/10th that size (500 man years) still blows up without any type of process in place.
Bart Park
Wednesday, January 03, 2007
 
 
>> If it was only half that, I would still defy you to manage a project of that size with absolutely no process in place. <<

Of course you need a process for any project. And the bigger the project, the more important the process becomes.

Incidentally, I would defy anybody to manage a project of that size using any type of agile process.
Mark Pearce Send private email
Wednesday, January 03, 2007
 
 
>> I don't disagree that you need "the right people", but just having the right people and having them all run around doing their own thing isn't conducive to good results, either. <<

Agreed.

>> I'll take good people with a good process over good people with no process any day, and I can't imagine running a truly large team without some process in place, anyway. <<

I would always take good people with a bad process over bad people with a good process. And with a truly large project, I certainly wouldn't use any standard flavour of agile.
Mark Pearce Send private email
Wednesday, January 03, 2007
 
 
>> I don't think you can truly have an emphasis on people and ignore process. <<

I never said that I ignore process. I said that IMX, the quality of the people is more important than the quality of the process.

Just read the agile manifesto. It makes almost the identical statement - people and interactions are valued over process.
Mark Pearce Send private email
Wednesday, January 03, 2007
 
 
> Drew, I'm just quoting page 31 of my copy (1982 edition) of the Mythical Man Month.

'Twas a joke, Bart.  I saw 1,000 developers x 3 years = 5,000 man-years and did a mental stumble, that's all.
Drew K
Wednesday, January 03, 2007
 
 
It's been a long day and I've been particularly grumpy most of the day. *sigh*
Bart Park
Wednesday, January 03, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz