Microsoft Lauds Scrum

under_score writes "According to eWeek.com Microsoft is adopting the agile methodology called Scrum to get software built faster. Is it working? They seem to be claiming that Scrum and Extreme Programming have helped them get recent releases such as SQLServer out the door faster with better quality. Many other large organizations are also adopting agile methods including Yahoo, and Google. Are agile methods the next big thing in software development?"

Comments

So let's get this straight

[Anonymous Coward]

Microsoft is lauding scrum for assisting them in delivering a product late and with a smaller featureset than originally planned? Ok, that's certainly an interesting approach. Now we can hear about how scrum is responsible for bringing Longhorn out earlier and with more features than ever expected.

Re:So let's get this straight

[DigiShaman]

Hey...so Duke Nukem Forever will come out after all?!

Re:So let's get this straight

[ergo98]

Microsoft is lauding scrum for assisting them in delivering a product late and with a smaller featureset than originally planned? Ok, that's certainly an interesting approach.

I've noticed a tremendous correlation between organizations, groups, and individuals in trouble (late projects, lack of talent and capability, a feeling of being overwhelmed by the capabilities of competing groups) and an acceptance and evangelizing of silver-bullet methodologies. It's like the long-time alcoholic giving speeches on how great it is to sober, or the homeless guy talking about the importance of going to school: It's the wrong person to be talking about it. Maybe serving as a ominous warning, but not as a credible source of advice about the right course of action.

Personally I'd like to hear what "methodology" Apple uses - They seem to continually manage to release great software. They don't seem to be buzzword laden, or full of ridiculous concepts like pair programming, but seem to use "traditional" programming models on reasonable plans with involved, motivated employees.

Re:So let's get this straight

[An Onerous Coward]

But what is wrong with it?

You've given us a rocking-horse analogy, and you've given us a purported example of a failed project that used it. But software projects go massively over budget all the time, and they get cancelled all the time. Given that people often learn the wrong lessons from failures, the negative opinions of the methodologies by GM executives may not be a compelling indictment of the methodologies themselves.

Or, to put it in a more Slashdot-friendly way: Who cares what a bunch of incompetent blowhards in suits think?

Seriously, though. What specific problems have you had using these methodologies?

I've tried XP, though in an academic setting on a small project (about two months), and I thought it was the most fun I'd ever had programming.

Re:So let's get this straight

[Anonymous Coward]

Apple software has plenty of bugs too. The system update that would hose disk partitions if they were labeled with spaces in their names. Airport failures if you have > 1GB of RAM in the current series of PBs. iTunes5 trashing filelists. ibook logic board problems that killed their video.

Re:So let's get this straight

[Reality Master 101]

Apple's methodology is basically "fear of Steve". Jobs is notorious for berating employees and insisting on things being done the way he thinks they should be done. Now, personality-driven development can be relatively successful. Apple has some nice stuff, but other stuff that Steve doesn't care about are absolutely atrocious (perfect example: Quicktime for Windows).

Also look at Apple's software before Steve came. MacOS was absolute crap. Copland, which was supposed to make MacOS a modern operating system, was a late, dismal failure that was eventually killed because Apple was too incompetent.

Apple is not a good example of what to do. Not every company can be a personality cult.

Re:So let's get this straight

[NetRAVEN5000]

"Also look at Apple's software before Steve came."

Might wanna check up on your historical facts - there was no Apple "before Steve came", Jobs was one of Apple's co-founders. If you're speaking of the time he took away from the company. . . well, what'd you expect - the company lost one of its best programmers. If you want a comparison, look at the time where Bill Gates was CEO and wasn't doing any programming - we had wonderful products such as Office 97 with its "features" and its virus named after a stripper, we had Windows 98 which even crashed at the demo and really wasn't much better as a completed product - and which was so crappy they had to make a "Second Edition" to fix all the bugs, and even SE wasn't that much better. . .

Plus, there were plenty who liked Macs - they were well-known as being the best for video and graphics editing, and for being easy to learn to use.

Also, from the Bill Gates bio I've been reading, it sounds like he also was fairly well-known around the office for insisting things be done his way and berating employees.

Ob. The Office Quote

[chman]

"Whaddya say? Let's gangbang this thing and go home."

A good example?

[blowdart]

So Scrum was used on SQL Server? The SQL Server product that's very late and has had to have features disabled. Or was it used on Visual Studio 2005 perhaps? The one where they've already announced a service pack before the official launch date because people are so unhappy?

These are scrum successes? I'd hate to see the failures.

Re:A good example?

[zullnero]

Ahh, typical XP newbies. The problem with most companies new to XP is they still want to do things the traditional way, ie., do it before a specified cutoff date. However, XP requires continuous releases, and Scrum is all about timeboxing each release. Soo...they probably tried to get too much done in too little time, went over the limit, realized that what they had wasn't acceptable, broke the XP rules, made some hasty fixes, disabled some harder to fix features, and got it out the door late anyway. The only reason I know that is because I've been through that.

XP isn't a magical cookie cutter solution you can just apply and expect instant $$, you pretty much have to build your team around it from the ground up, have experienced XP people around, etc. In fact, it really only works if the top level management really buys into it.

Re:A good example?

[WhiteWolf666]

Ummm... Actually, if you go read so MS employee blogs, or go read some VS2005 articles, you'll find that a great many customers are unhappy with the state of the product at lunch, and those "won't fix" bugs were the reason MS announced a service pack at the same time.

Go take a look:
http://minimsft.blogspot.com/

http://blogs.msdn.com/scottwil/archive/2005/11/07/ 490007.aspx

Re:A good example?

[Skim123]

Or was it used on Visual Studio 2005 perhaps? The one where they've already announced a service pack before the official launch date because people are so unhappy?

The sad thing is even with the moaning from some customers, they'll likely agree that VS2005 is still head and shoulders above VS.NET 2002/2003.

Doubtful about the speed

[dnoyeb]

I find methodologies are like other tools. If they buy you time, and your dilligent, that time will be spent on quality. So its not likely to both buy you time & quality. If you seem to have more time its only because you have not spent it on quality.

Re:Doubtful about the speed

[aussie_a]

With Microsoft's virtual monopoly, they have a guranteed market for a program and would have to cock it up REALLY, REALLY bad for that market to shrink to a noteworthy degree. So they need to get programs out there to rake in the cash. Quality isn't really an issue for them.

However hopefully if they continue to use this flawed business plan, they'll continue to slowly lose customers. Well, I can dream, can't I?

This is a new thing?

[sparkhead]

From the article: So Scrum is one process--the idea that teams meet once a day for half an hour, figure out what they're going to do then go off and do their work very quickly.

Well, yeah, we call that a daily team meeting. Been going on since, oh, forever.

As far as XP goes, don't think that's going to be a hot methodology for too much longer.

Re:This is a new thing?

[Spit]

No, Scrum is different. Scrum is a daily meeting that is EXTREME TO THE MAXX!!

Re:This is a new thing?

[bwy]

Well, yeah, we call that a daily team meeting. Been going on since, oh, forever.

The daily stand-up is only a small component of Scrum. And the purpose of the meeting is strictly related to which tasks from the sprint backlog you were working yesterday, which ones you'll be working today, and whether or not you have any impediments. Only pigs are allowed to speak in the daily stand-up. This means that chickens (product owners, business folks, etc.) are only observers and can't butt in and introduce scope creep. How many times in a traditional waterfall methodology have you had someone add to your scope in a daily meeting? Every day they want to change a page, add a column to the database, change the way something works, etc. This goes on to the point where the product never gets delivered. Under scrum you deliver something every 30 days and at that point the product owner can decide if he really wants to change something- and he does this by adding it to the product backlog- not by grabbing someone in the hallway.

Re:This is a new thing?

[sparkhead]

I checked out the Wikipedia entry on Scrum, and if you'd like to fill in the missing details, please do so. What it says is in bold, what I would call it is not:

Characteristics of scrum

* A living backlog of prioritised work to be done;
An updated prioritized bug and feature list.
* Completion of a largely fixed set of backlog items in a series of short iterations or sprints;
Picking a set of items and fixing them quickly.
A brief daily meeting or scrum, at which progress is explained, upcoming work is described and impediments are raised.
Progress and issue review.
A brief planning session in which the backlog items for the sprint will be defined.
Planning.
A brief heartbeat retrospective, at which all team members reflect about the past sprint.
Post mortem review.

What's truly new here? I'm not asking to be a wiseass, I genuinely would like to know what this is apart from relabelled standard practices.

I went to the Control Chaos site on Scrum and the header states "It's about common sense". OK, so why give it a stupid label with overblown descriptions? The "what is scrum" section on that site reads like a Dilbert strip.

Re:This is a new thing?

[Anonymous Coward]

The news is (or was when Agile first came about) was packaging these practices into a methodology. And giving it a name - a name, as we all know, is the most important part of a project.

Ten years ago, and often still today, a mainstream software engineering textbook started with "design errors are expensive to fix while programming". Which is a slippery slope that inevitably leads to the Waterfall Model.

So most companies (not all!) took the Waterfall Model as an unquestionable law of nature. Monolithic upfront requirements specifications carved to stone, etc.

Agile methodologies _think_ about the "obvious to any hacker" process and _measure_ it. They take what looks like chaotic uncontrolled hacking and, by thoughtfully selecting the right parts of the chaos, make something that can be directed to achieve the desired result.

Sure there have always been programmers who used bits and pieces of Agile tricks. But rarely in a controlled, designed, documented, measurable way. Not in a way that is taught to every new employee, which is what you'd do with a systematically applied methodology.

If you have for decades systematically used a well-thought-out collection of Agile principles you should have written a well-argued book that proves how your methodology kicks Waterfall Model's butt. If you aren't a book-writing kind of guy you could have ghosted the book. It's too late now to say "I always used a provably better methodology than the Waterfall Model, I just never bothered to tell anyone" :-)

Re:This is a new thing?

[ScrewMaster]

There is a fundamental flaw in any such methodology, though ... it's called "discipline." I've worked in too many places where there was always a reason why established procedure had to be bypassed. Oh sure, it was always a "good" reason, but nevertheless if management itself is unwilling to live by its own rules I can guarantee you the programming staff won't either. Generally speaking, things like Scrum will only work in larger organizations where a top-down policy can be enforced. At least initially: you have to work past the resistance that most teams have to changing the way they do things. Once they see the benefits to them (always assuming that there are any) then the new processes may become more self-maintaining. But that's not so easy to achieve, because there will be a period of reduced productivity while everyone is trying to get rid of the old and figure out the new. And, depending upon how it is handled, that can easily evolve into active resistance. That's the point where, I think, a lot of these schemes fail: "See? We tried it for a month and now look how screwed up everything is. Let's go back to the old way."

Re:This is a new thing?

[Zigurd]

Scrum is the upshot of the fact that standard project tracking tools don't adapt well to software projects. You can't see the difference between 30% or 70% of the coding on a large task being complete, so Scrum tells you not to have tasks that large and to only count something complete when it is 100% complete. Even the XP rule of thumb that tasks should not take more than a week to complete is too coarse-grained.

Scrum admonishes the manager to ask "What got completed today?" If the answer is "Nothing." then you don't really know if project completion is closer or not.

That is common sense, but it is uncommon in projects that have misapplied project management tools.

Re:This is a new thing?

[Scurrilous Knave]

I've been in the software biz for a long time, and I've come to believe that the salient point is not what the "next big new thing" is in software development methodologies, but that there always is a next big new thing, every few years. To me, this means they haven't found one yet, at least one that works. Oh sure, most of them have contributed some new ideas and some benefits, but all fall short of the elusive goal, and more importantly, of their own promises.

Here's the way I envisioned it: A software manager and a hardware manager are playing golf. The HW manager says, "Man, my shop just started using CAD/CAM/CAE, and our productivity went up by a factor of three, and our error rate went down by the same amount!" The SW manager says, "Man, I gotta get me some of that."

The first time I heard about it, it was called CASE, for Computer-Aided Software Engineering. It had some interesting ideas, but wasn't the silver bullet for software development that CAD/CAM was for hardware.

And with CASE, as with every other silver-bullet attempt they've made since then, a flock of entrepreneurs showed up with products to hawk, promising to fix all the software manager's woes. I can't remember all the products and methodologies that have been foisted onto me by eager but underinformed managers, but they have been legion. Logiscope, CMM, Six Sigma, XP ... I've tried to block them from my memory. This Scrum sounds interesting, though as you and others are pointing out, not shockingly novel. But by the time it gets filtered through my company's Bogosity Injector, it'll be an embarrassment.

So why is that? Why haven't software developers gotten the same sort of help from automation and rigorous methodology that hardware designers have gotten? Here's where I lose my score: Because software is hard. It is, in many important ways, more difficult than hardware design. I believe that software design and development is the single most complex and difficult human endeavor ever undertaken. (Of course, as a programmer, I would think that, now wouldn't I?)

Let the flames begin!

Re:This is a new thing?

[Cederic]

Waterfall make work in theory.

In practice I've yet to work for a business willing to wait 2 years for their product. Where the business environment, aims, markets don't change for that period of time.

Pragmatically Waterfall doesn't work. It often almost works, and most developments muddle through. But my customers want new functionality next week, not next year. They'll wait until next month, but any longer and they start complaining.

Since I know of ways of successfully delivering next month, I'd be failing them to force them to wait until next year while I kick off a full waterfall process. Especially since they wouldn't give it the support it needs to work properly.

I can deliver every 2 months. I can deliver approximately bug-free code in that timeframe. I can deliver genuine business advantage, meeting actual business need and keeping customers happy. And I can repeat it.

Other engineers don't write software the way they build bridges, design power stations, construct roads. Oddly enough some of them have tried - and if they'd succeeded they'd be winning ALL the business. Different environment, different constraints, and therefore different approaches needed.

Incidentally, "every step must be done in order" is very wrong. Test before you build - how else do you know you built the right thing. (And test again after.)

You also forgot various steps, but that's a whole other discussion..

Deadlines

[aussie_a]

Looks more like developers are being pressured to achieve ridiculous deadlines, with a fancy name tacked onto the pressure. I also wonder what sort of security is being done to programs developed via the scrum method. Is the scrum JUST for the programming (and/or the preceeding stages)? Or is it the whole thing, testing included, in this "quick, quick" method? If it's the latter, I can't see how testers are going to be able to truly secure the software, so we'll continue to get unsecure software from Microsoft. Thanks a lot, you just made my wish to migrate to Linux increase.

But will our management buy it?

[Elrac]

I'm happy to hear that XP practices are helping some high-profile companies. Alas,

• I work for a company that adopts new trends at least 5 years late - that's about when they're being phased out elsewhere. For example, we're now deeply committed (or should I say sentenced?) to J2EE, RUP and outsourcing;
• Our company works on a contract basis, with complete and "firm" specifications (BDUF, anybody?) going in and deliverables coming out, with no wiggle room, no negotiation (at least from our side), no onsite customer.

Given such an environment, which I'm sure will sound familiar to others, do we stand a chance of ever being able to work this way too?

Thought this could help

[exaviger]

Had no idea what Scrum is so found this

What is Scrum? Scrum is an iterative, incremental process for developing any product or managing any work. It produces a potentially shippable set of functionality at the end of every iteration. It's attributes are:
* Scrum is an agile process to manage and control development work.
* Scrum is a wrapper for existing engineering practices.
* Scrum is a team-based approach to iteratively, incrementally develop systems and products when requirements are rapidly changing * Scrum is a process that controls the chaos of conflicting interests and needs.
* Scrum is a way to improve communications and maximize co-operation.
* Scrum is a way to detect and cause the removal of anything that gets in the way of developing and delivering products.
* Scrum is a way to maximize productivity.
* Scrum is scalable from single projects to entire organizations. Scrum has controlled and organized development and implementation for multiple interrelated products and projects with over a thousand developers and implementers.
* Scrum is a way for everyone to feel good about their job, their contributions, and that they have done the very best they possibly could.


Original article can be found: http://www.controlchaos.com/about/?SID=8ef7eb5b2a0 69a2710abef27d02c851f&SID=7da824062baf60b8e78ec5f9 9836f092

Microsoft lauds Scum

[Frankie70]

How many people are going to read this as Microsoft lauds Scum?

"Scrum", eh?

[__aagctu1952]

So... does that make Microsoft a hive of scrum and villainy?

New Big Thing

[alnya]

This is something else to be looked at and might well be a good approach. Of course, in reality, the best thing to do is to cherry pick parts of methodologies you like and that work for you. We tend to use test-driven development in conjunction with agile techniques and that works for us - everyone is different. I've yet ot see a fully agile approach be successful however (in an "on time on budget fully featured sort os definition). Of course, YMMV.

Combatting OSS

[Kawahee]

I think it's a new method to combat OSS. It's been long known that OSS is fairly slow to come around, and so far, Windows and that has taken a long time, too. But if Microsoft can push out the next version of Windows/Office/VS .NET faster and with a higher quality of code, potentially they can take on OSS faster and harder than ever before.

And I'm not talking upgrading software, like VS .NET 2007 or Office 13 (lucky), but also new software, if not new software from codebases such as Microsoft Tool X or Tool Y, like the Speech SDK that they've got out there, - or any other Microsoft Research project.

Could be....

[Steven Reddie]

There isn't enough information to determine whether or not use of scrum was a success of failure. You're leaning toward failure, but it's just as possible that they switched methodologies toward the end in an attempt to get a late product out the door.

big things

[famebait]

Are agile methods the next big thing in software development?

No, they are the current/i> big thing. No doubt the hype will pass, but I do hope and believe and they bring some things to the table that deserve to last.

The focus on the way people actually work, on optimising that in a realistic way, on work satisfaction, on recognising and handling uncertainty in stead of ignoring it, and on pulling the curtain on a lot of practices that everyone knows don't really work but kept pretending anyway. All long overdue lessons for a methodology-field too long too dominated by good-on-paper theory and wishful thinking for managers rather than real experience with what works.

Re:big things

[marcosdumay]

My guess is that XP is working only because it banished the "good on paper" metodologies and because of the refactoring formalism. All the other points you cite are a description of "good management", and as so, don't change just because the company adopted another metodology. But getting ride of a lot of useless paper (by letting the programers decide what is usefull) is the way to go.

Debian?

[Commander Spock]

Any word on whether Debian plans to adopt this development method?

Why XP works when it works.

[ankarbass]

When XP works, at least in some cases, it works not because it's the best methodology. But because it is the one that people will do. It is "A" methodology where there either wasn't one, or there was something in name only which people paid lip-service too. For the programmer and manager alike, XP is easy to grasp and start implementing right away. Compared to more traditional methods, it's a simple method that eschews excess paperwork and you can explain the basic idea over lunch.

I also think there is something to the transparancy of the work environment. It's a lot harder to read slashdot when you are "pair-programming" or all of your peers are sitting in the center of a large room. It might just be that you get more done because it is harder to slack.

Re:Why XP works when it works.

[AndroidCat]

Have you considered adopting eXtreme Posting methodology? ;)

In certain languages, such as Romanian.

[DaedalusHKX]

"Scrum" means ASH... I guess... perhaps they refer to burning their products to the ground? Or what will be left of M$ once this latest FAD fails?

Please God let it be so!!

~D

PS - don't you love being well traveled, and multilingual? Makes the world shine in new colors. (Now I need to learn french since they have really hot women.)

An XP Book Review...

[mindpixel]

This is a very timely posting for me...Monday I have a meeting to get the budget to make create an XP team to build Ajax internal systems. Good to see the large entities are thinking the same way.

Here is my review of Ron Jeffries, Extreme Programming Installed from April 25, 2001:

People are starting to take XP very seriously simply because it delivers quality code instead of just documents about code. The core philosophy can be summed up: "A feature does not exist unless there is a test for it." (P.83) This means that coders (pairs of programmers in XP) first construct unit tests of product features before the attempt to code the features. What this means in practice, is that the code that XP delivers (continuously in 3 week long iterations) can never be broken! I'll say that again just to make sure you read it: XP code can never be broken! I really think XP's adaptive, test-first philosophy is the best thing that has happened to software engineering since Dijkstra told us that the "Goto Statement is Considered Harmful" in 1968.

This book is the best of the XP series if you've actually made the decision to use XP. If you're not sure about what XP is or what it's limitations are, go to google and do your homework. When you're ready to actually install an XP project, get this book.

So how do you write tests for ..

[RedLaggedTeut]

So how do you write tests for ..

- applications that are a constantly moving target "this would be cool to have"

- applications where the moving-targetness lies in the presentation, while at the same time some customers bitch about any change in presentation

- applications with changing data sets - you can run your tests fine on the standardized data set, but then when it hits the real-world data, all you can say is "Sorry my application is perfect, it just doesn't work with with that data.".

Re:So how do you write tests for ..

[matvei]

applications that are a constantly moving target "this would be cool to have"

How can you write any code for an application if you don't know what it's supposed to do? When you have a functional specification, you can write tests that test the specified features. When the spec changes you change the tests accordingly to help you make sure that you don't introduce new bugs when changing your code.

applications with changing data sets - you can run your tests fine on the standardized data set, but then when it hits the real-world data, all you can say is "Sorry my application is perfect, it just doesn't work with with that data."

Are you suggesting that having no tests would make that particular application work with real-world data? The point of testing is not to prove the customer that your application is flawless (that's impossible) but to help the programmers catch errors like the one you describe.

When you're writing a test, you are making sure that your application works in one particular case. If you don't know what the possible cases are, not only will that prevent you from writing tests - it will also prevent you from writing working code.

"But you can't test everything!" is a dumb excuse for not testing at all. It's like refusing to wear a bullet proof vest because it's useless if you get shot in the head.

Re:Of course...

[Anonymous Coward]

The problem is that most managers have absolutlely no clue how to program or organize code. They can't really do anything useful in the design process. Each time something is built the programmers design and build everything without much more than stupidity raining down from the management team. Since managers don't know anything about the craft they're "managing," they don't recognize who is actually writting good code or designing robust systems and they tend to rely too heavily on the people who do nothing more than sit in the bosses office brown-nosing. As a result, many projects fail miserably or are badly designed, bug-ridden crap when they fianaly get called a "final" release. Since these managers are always having their own performance reviews tied to a process that they totally do not understand, they invent new "management" schemes to make it appear they are adding something to the process in an attempt to make themselves seem different from their peers. Until managers understand the craft they pretend to manage, we will all be subjected to feeble management fads.

But that's typical.

[blowdart]

That's certainly true, but having read a lot about scrum et al you tend to find that most, if not all of the examples used to justify the selling of a new methodology don't have a lot of detail.

Take a look at one of the Agile Poster Children and his proof that it works.

Quote: "Because of the newness of agile methods there simply hasn't been sufficient time to prove that they work in a wide variety of situations."

Thats a wonderful way to dismiss anyone saying bad things, and it's rubbish, because the burden of proof for any claim is independent of its age.

Quote: "the question "where is the proof" is typically asked by organizations that fit the late majority or even laggard profiles ... Because agile techniques clearly aren't at that stage in their lifecycle yet I believe that this question simply isn't a fair one at this time."

So the act of asking for proof these things work means you're not ready? Ad hominem alert.

Quote: "Are they really interested in finding an effective process or are [they] merely looking for a reason to disparage an approach that they aren't comfortable with? Are they realistic enough to recognize that no software process is perfect, that there is no silver bullet to be found? Are they really interested in proof that something works, or simply an assurance of perceived safety?"

Ad hominem again.

Then you look at the project that started Agile, the Chrysler Comprehensive Compensation (C3) project. It was lauded as the first agile program and a success, however by February 2000 with the system was failing when paying 76,000 of the company's 86,000 employees. It was cancelled. Apparently this failure is now the new success.

Every methodology has rapid followers who will hear not evil said of it, but when looking at these things you have to remember "He's NOT the Messiah ... he's just a very naughty boy."

Re:But that's typical.

[arivanov]

Well, it tends to work in the areas where UML (in any of its incarnations) and the Unified Process reigns supreme. Now, the important thing before putting any claims about UML, object oriented programming and Agile is to understand the background behind their origins.

The Unified Process precursors were initially developed by consultants helping improve the code quality at Ericsson. The work was mostly in the area of voice switches and network management equipment. These consitute a specific field of software design which is quite different from the rest of the industry.

The most important difference is that there is an existing specification to which the software must comply. The specification already defines what the software is supposed to do for each allowed input, what are the error conditions, how to handle errors and this is usually defined as a set of simple and very strict rules. This type of task can be very easily expressed as a flow chart. The data objects are mostly defined in the protocol spec so there is no data design work to wrestle with. The spec rules are trivial to map to elementary state machines and are usually very small and well defined. They can be easily written with test cases and unit tested. And most importantly there is plenty of system resource to implement them.

While the methodology behind this type of work can be applicable to other fields there is no justification whatsoever to state that it is the only correct methodology.

It is not applicable to systems whose behaviour is mostly determined by a resource constraint.

In order to apply it to a system you have to define the specification first and express it in terms which are suspiciously similar to a Telecom switch spec - trivial actions with well defined input and output.

It is not applicable to systems where the conditions determining the change of execution are complex and cannot be expressed in terms of simple rules. Best example is possibly heavy duty math. It is nearly invincible to UML, UP and Agile attacks.

So on, so fourth.

duke4

[yaiba]

rumor has it that the dev guys at 3drealms are also adopting scrum.

I prefer this definition

[ColourlessGreenIdeas]

http://www.scrum.com/rugby_guide/scrums.asp

Do that every time you need to make a decision. Clear all furniture out of the way first.

Developer's opinion of scrum

[Anonymous Coward]

I'm a developer at a smallish company (~25 developers) which started using scrum in August. I was very skeptical at first but really like it now. The short version:
Previously management just did whatever felt right.
Sometimes this was very good, sometimes it was very bad. Sometimes it was just inconsistent.

Now management has a defined methodology that they follow. There are some rules. The rules need not be particularly great ones (although I don't mean to suggest scrum isn't good), just so long as management is thinking about them and makes a concious decision to be consistent and let develoeprs know what to expect.

Specifically, scrum has helped us overcome the "holy shit, its a big customer bug!" panic that happened occasionally. We still panic, but its not the entire organization jumping onto one bug, its just a single scrum team.

Posting as AC, as my coworkers AND management read slashdot and will recognize me.

Remote pair programming is the "next big thing"

[Carl Rosenberger]

Agile methods have been around for a long time, they are not new, it's only new that big companies like MS find out that they work indeed.

In the meanwhile globalisation has advanced, there is a more efficient way to build software than to pile people up in cubicles. It's pretty much like an open source project:
- Get the best experts from all over the world for the theme where they are good at.
- Let them work from home.
- Let the team work in remote pairs, using VNC and Skype and change pairs frequently.

In this setup half-hour meetings every day do not work, because of the different timezones. A weekly meeting is good enough, Asterisk works fine for VoIP conferences, CVS email notifications about all checked-in work keeps everyone up-to-date.

This is how our company works. We are very happy with the cost and the quality of the work we get and with the lifestyle to work at home when you want and how you want.

scrum experience

[AgentPhunk]

I used to work in a scrum-based web development shop.

Meetings went something like this:
Go around the room, and say #1 - what am i going to do today, #2 - whats in my way of getting #1 done. One two people were allowed to talk, the person who's turn it was, and the manager in charge of the meeting. If another person in the meeting was the cause of someone's #2, the manager would turn to them, give them (and only them) them the chance to respond. Lather rinse repeat.

There was no "I did this yesterday" because a) we supposedly heard about that the day before, b) the assumption was that you got it done.

Even with at least three different projects going on, and maybe 15-20 people in the room, we were out of there in 30-45 minutes. Any major issues were taken offline so that the rest of us could get back to work.

We usually had only one meeting a day, sometimes two. I found it worked extremely well with a minimal amount of thrashing. We might have been using a modified version of scrum; can't remember - those were dotcom days, everything's still a blur.

Bah. That's nothing new

[Anonymous Coward]

Rugby's had scrum for years.

Agile & Scrum work for us

[ameline]

At Alias, we use Agile and Scrum very extensively. The Sketchbook team was among the first at Alias to adopt it at our company -- Jim Highsmith even gave us a little write up in one of his books.

We don't, however, do that much pair programming. And the whole completely open office space works for some, and definitely not for others. For myself, I'm way too easily distracted -- so I need a nice quiet and private cubicle in order to achieve the state of "flow" where I can write code. In my experience, pair programming works for debugging and integrating code -- and not so well for creating it. YMMV.

Sketchbook has come in on time and on budget, and with extremely high quality. Agile and Scrum had something to do with it. I think the fact that we had a clear vision, a small and very experienced team, a really good working relationship with our usability team and research team, great QA, and excellent management had at least as much to do with it.

As a process, its the only one I've seen in 20 years of doing this that actually makes the life of a programmer better, not worse.

Re:Agile & Scrum work for us

[ScrewMaster]

I think the fact that we had a clear vision, a small and very experienced team, a really good working relationship with our usability team and research team, great QA, and excellent management had at least as much to do with it.

No, I would submit that those qualities had everything to do with it, and probably a lot more than anything that implementing Scrum could ever do. Consider yourself very fortunate to work with such people, in such an environment. I know I do.

Scrum and other such overarching methodologies are simply ways to enforce standardized positive behaviors upon otherwise mundane workers, or good workers lorded over by second-rate managers who themselves need some kind of framework to tell them how to handle their particular herd of cats. Managed-incompetence, you might say.

On the other hand, compact, tight-knit development groups (like the one you mentioned) have usually already worked out highly efficient methods of getting their jobs done, methods that directly apply to the type of products under development. That happens almost naturally when you have intelligent, motivated people with good communication skills who truly want to cooperate with each other. The group I work in is one such: after working together for years we all know each others strengths and weaknesses, and when given a directive we automatically assign the best person to the job, and if it requires more than one of us, the person best suited to take the lead just assumes the role. And that happens because our manager trusts our judgment and doesn't treat us like children, as some do. Granted, most of my coworkers have at least twenty years in software development. A team composed of fresh-out-of-school programmers would be a different matter entirely.

I guess what I'm saying is that if a company is fortunate enough to have a development group that is already fast, efficient, produces quality work and has that certain esprit de corps that is the hallmark of a good team, don't mess with it. That kind of team is a corporate Golden Goose, and it is surprisingly easy to kill. I'm not saying that there isn't always room for improvement ... there is. But it's wise to be careful about making sweeping changes if you already have something that is working well.

We don't, however, do that much pair programming. And the whole completely open office space works for some, and definitely not for others. For myself, I'm way too easily distracted -- so I need a nice quiet and private cubicle in order to achieve the state of "flow" where I can write code. In my experience, pair programming works for debugging and integrating code -- and not so well for creating it. YMMV.

If I had mod points I'd give you a +5 Right on the Money for that one. Actual programming is a solitary effort, and a work environment should reflect that.

Death by Buzzword

[RAMMS EIN]

Ok, so what's this scrum thing? According to Control Chaos (the first related hit I got on Google):

Scrum is an agile, lightweight process that can be used to manage and control software and product development using iterative, incremental practices. Wrapping existing engineering practices, including Extreme Programming and RUP, Scrum generates the benefits of agile development with the advantages of a simple implementation. Scrum significantly increases productivity and reduces time to benefits while facilitating adaptive, empirical systems development.

Lots of buzzwords, little information. So let's Learn more:

- Scrum is an agile process to manage and control development work.

  - Scrum is a wrapper for existing engineering practices.

  - Scrum is a team-based approach to iteratively, incrementally develop systems and products when requirements are rapidly changing

  - Scrum is a process that controls the chaos of conflicting interests and needs.
Scrum is a way to improve communications and maximize co-operation.

  - Scrum is a way to detect and cause the removal of anything that gets in the way of developing and delivering products.

  - Scrum is a way to maximize productivity.

  - Scrum is scalable from single projects to entire organizations. Scrum has controlled and organized development and implementation for multiple interrelated products and projects with over a thousand developers and implementers.

  - Scrum is a way for everyone to feel good about their job, their contributions, and that they have done the very best they possibly could.

At this point, my head exploded. This note is a post-mortem plea to press murder charges against the person who wrote that crap.

Re:Death by Buzzword

[Anonymous Coward]

Scrum is a way for making first level managers (aka team leads, section leaders) feel involved with the flow of what's happening in the group, even if they lack the skills to make a technical contribution themselves (which is, sadly, often the case).

It's a way to highlight the contribution of the more talkative members of the group, who are often correspondingly week in hard technical skills, while slowing down the thoroughbreds who might otherwise put the organization at risk with some pie-in-the-sky, breakthrough innovation.

It's an excellent source of book and consulting revenues for trainers, usually the same people who taught XP before that, RUP and/or formal code inspection methods before that, etc.

vapor style

[opencity]

So Scrum is the idea that teams meet once a day for half an hour, figure out what they're going to do then go off and do their work very quickly.

Wow, genius.

(from what little I know) Extreme programming is testing constantly and having people work side by side? Well I Am Not A Professional but I figured this out after my first project got too big. Am I missing something here?

I've got a new methodology: It's called: "Inning". Your programming team works for an 8 - 14 hour period and then takes a break when they sleep. I like to combine it with "Lunch" where the team, either together or seperately, eats food periodically during the day. My book is available to preorder.

Shorter release cycle?

[rayd75]

"Steve Ballmer, chief executive of Microsoft acknowledged during his keynote address at the Microsoft launch event that the company needed to get more agile and to produce software faster, to the tune of delivering technology every 18 to 24 months."

  No. No one wants such a short release cycle but you and your shareholders. If I may borrow one of your favorite words, there is not enough "innovation" in most of the technologies you purvey to justify an 18 month release cycle. You managed to pull it off for Windows XP and did nothing but piss off those of us who bought your line about Windows 2000. To us, it was clear that XP was nothing more than the finished version of Windows 2000. We had just spent a fortune on upgrading to the future only to be told 18 months later that we weren't worthy of free utilities, functionality upgrades, or even comprehensive service packs since we weren't on the latest release. As far as I'm concerned, you can keep your interim versions to yourself. Anything shorter than 3-4 years for operating systems and server products is lunacy.

Insightful?!

[RAMMS EIN]

Sorry about whining about a post getting modded up, but what is this? Can't people calculate anymore? If Scrum buys you two months of time, and you spent half a month on improving quality, hasn't Scrum bought you both quality and time?

The above is just a simple counting argument. But if you actually look into the nature of things, it's entirely likely that a better process can increase development speed and improve quality. For example, if you improve the specification process, you could end up with a clearer specification that wouldn't be adapted so often while implementation is already going on. This reduces the time it takes to implement the specification, and causes it to be implemented better.

So, no, I don't think the parent is right that you can't have an improvement in both time and quality, or that if you've improved one, it's probably because you sacrificed the other. I do think that a lot of these methods are worse than worthless, but that's a completely different story.

XP level of testing leads to brittle code

[CarlBenda]

Have you done XP programming yourself? Evidently not. Did it for six months at one place. We had so many tests that whenever a refactoring was done it would break tons of tests. The tests would have to be redone thus decreasing their value. The tests weren't making sure new changes didn't break the code because whenever you added new code you changed the tests. Refactoring thus wasn't encouraged by all these tests and so eventually you have more and more spaghetti code. Our XP coach was telling us that every so often it's hard to move forward and someone has to go in and change things while others wait. Yeah we figured out what he meant. The code got so bad (even though all tests were passing) that someone had to go across the whole code base and spend a week fixing junk. This happened over and over.

Re:XP level of testing leads to brittle code

[aricusmaximus]

Considering you got fired after your XP experience you quitting the proejct, it's not suprising that you have a negative opinion.

I'd also have to say that you (self-admittedly) sabotaged the unit testing process automatically diqualifies you from providing an objective opinion on unit testing.

We use scrum, and it's working for us

[DeadVulcan]

But like any process, scrum won't work unless you have buy-in from every level. I think it took us almost a year before we really got into a groove with scrum and started getting really big benefits out of it.

Developers now work without meddling from management for at least the duration of a sprint (a month). We can focus and get lots of work done.

Transparency has built trust between the developers and the other stakeholders, like testers, usage experts, and management. There's far, far less tension between these groups. And whatever tension that does exist is kept off the shoulders of the developers.

We were a small company, bought out by a very large one, and now our group and our process is starting to be viewed as a model for other groups in the company to emulate, because we're (apparently) far more efficient, and we're getting a lot more work done.

We don't use XP (although we do have a lightweight code review process). The benefits of XP weren't quite as evident to us, so it's not something we mandate - developers can do it sometimes at their discretion.

Lucky You

[RAMMS EIN]

I say you're lucky. I'd much rather work for a company that watched what $new_thing is doing to others before adopting it, than one that jumped on every overhyped new thing that hit the press.

There is an unholy amount of crap being invented and hyped everywhere, and, in my experience, the things that are being hyped the most are never the best ones, or they aren't actually anything new.

A few examples:

  - Java, when new, was being hyped up the wazoo. This was the herald of object oriented programming and write once, run everywhere. Never mind that object oriented programming languages had existed for a long time, as had write once, run everywhere, and that Java isn't actually a particularly nice programming language (I get modded down every time I say something negative about Java, but this time I assume at least you will read it). With the advent of Java 5.0, it got a lot better, with things like generics and "foreach loops"; the performance problems have mostly been worked out, and stable and mature frameworks have been developed. And now your company has adopted it. Makes sense to me.

  - Ajax is the new hype of the website scene. All it is about is making websites more like regular applications through the use of existing technologies. I was doing this stuff in 1997, possibly earlier. It's still majorly broken in the exact same ways (you need to use a full HTTP request to get new data, and the server can't push data to you, except on some implementations). Maybe in five years these things will have been fixed (perhaps with the advent of XAML?) and your company will adopt them?

  - RSS feeds are all the hype. Basically, you can get news headlines from sites you subscribe to. It works just like regular HTTP, except that people have standardized on a, no, two, no, four formats to distribute headlines in, so that they are sort of compatible between implementations. Maybe in five years, when your company adopts the technology, there will be a single standard format? And maybe they will have solved the problems caused by the fact that data is being pulled (by clients who don't know when updates are available), instead of pushed (by providers who do know when content is available)? We shall see.

I could go on, but I think you get the idea.

Schedule, Quality and Scope in Agile

[under_score]

The big difference between agile methods like scrum and extreme programming as compared to other methods like RUP or waterfall is how they treat the "iron triangle" of schedule, quality and scope. Agile methods specifically say: sacrifice scope in favor of super-high quality and fixed very short schedules. Scrum, for example, recommends that teams produce potentially shippable software every month. Potentially shippable doesn't mean every feature under the sun, but it does mean that it should be production-quality. As for large organizations adopting agile methods, there is definitely a transition period where the focus is on getting used to the monthly cycle and gradually increasing quality from the organization's norm to a much higher standard. Sometimes this can take a couple of years. This type of schedule does cause a huge amount of pressure... but every agile method that I know also encourages a sustainable pace including very little overtime work. I have worked on many agile projects over the last nine years and every time the benefits have been clear and compelling. Nevertheless, it is possible, like with anything else, to screw it up and have a bad experience with an agile method. Pair programming from Extreme Programming is a great example of this. It is a fabulous way to increase quality without sacrificing productivity. Yet it is also such a huge change for many developers that it needs to be adopted with great sensitivity. If it is imposed, then people will rebel against it and cause it to fail. Same with agile methods in general. I've seen them work too many times to not be a believer, but if one's first experience with an agile method is a disaster, it can be pretty hard to see how they might help: be more effective, more humane and more fun. I strongly recommend that people check out the agile manifesto and the agile work axioms to understand the underlying ideas behind the agile methods.

Oh for pete's sake...

[israfil_kamana]

... Scrum/Agile isn't about "combatting OSS", it's about doing what any software dev shop, OR open source software project needs to do - improve team productivity, roll out features in a structured, efficient, and systematic way. More importantly, it's about not pretending that a large two-year effort can be completely understood in a three month requirements gathering phase. It's about admitting that the low-level tasks that some project manager assigns to a junior programmer 14 months before won't be valid when the rubber hits the road. It's about maximizing the capabilities of softawre teams, improving collaboration and effectiveness, clarifying priorities, eliminating waste.

I'm no huge fan of microsoft, and all my servers run OpenBSD, but jeez, this is fanatical trolling. For the record, some open-source projects use agile methods.

That's what people sayd about O/O in the eighties.

[israfil_kamana]

They're not the latest big thing - they are the software manifestation of the same practices/principles used to create the Toyota Production System - practices that then have been adopted across the whole car industry. Nay-say all you want, but if you haven't tried it, then you have nothing productive to say for or against. Talk talk talk.

Except that agile methods were developed...

[israfil_kamana]

... by developers, for the most part, based on what works, not on what management thought SHOULD work. It's not a management fad, it's a simple empirical process. The whole point of scrum is to get away from management-induced fantasy, and rather to go with plan-try-measure-reflect-try-measure. It applies the scientific method to software development control.

Mostly what's pissing me off about this slashdot crap is that people who have never tried it are weighing in with opinions on how it can't possibly work, or how it's obviously just a fad. Sheesh.

The real question is...

[plopez]

will MS really change their processes or will it become nothing more than mindless corporate a paper chase? Will they embrace the culture and beliefs of the new methodology, or will it become just another 'flavor of the month'?

From my experience in corporate culture I suspect the latter. What often happens is a group with in a company adopts a methodology which works for them. They then become the poster children for 'organizational change'. The processes are then rammed down the throats of other departments who may be resistant to change, or for whom the processes are inappropriate.

Managers will go to be trained in the new metods and learn the form but not the true spirit of the reform. 1/2 hour scrums will begin to creep up to 2-3 hour daily meetings. In order to take advantage of the accelerated release cycle, products will be scheduled for release sooner, and testing/QA will suffer. Quick fixes will be prefered over true fixes and, inevitably, release will slip. That is my prediction.

Truly changing an organizaqtion takes years. Everyone originally working under the old system essentially has to be fired, quit, transferred, retire or die (one article I read, though I cannot find the reference, said it takes about 20 years for a large company to change).

This might be interesting to watch, in a morbid sort of way. MS is looking for a magic bullet, and we all know how well that works.

Extreme programming is not agile.

[Some Random Username]

XP is designed to shift the blame off of the programmers and on to the customers. "You didn't properly define the spec". Of course, the customer never knows enough to be able to define a spec detailed enough, so it always results in the dev team making something the customer isn't happy with, the customer getting the blame for it, and then yet another iteration is done to "fix" it based on the new spec. Repeat this process until the customer gives up and accepts what they get, or they give up and go somewhere better.

Agile development is about working with the customer, giving them something to see and test and provide feedback on as quickly as possible. Instead of giving them crap they don't want in a week like XP, give them a basic test in 2 days, and then refine it to be what they want over the rest of the week.

That would make too much sense...

[DaedalusHKX]

its the same in every job field, when employees are only in it for the money and take no cares about their work, because the company they work for is run by a bunch of assholes that will shitcan them at the drop of a pin... the employees do not care, and to them it is just a job.

You hit it on the head... "motivated and involved"... what buzzwords those would be.

Corporations need to sell stock though, not produce quality goods, and we all know quality takes time, and stocks sell better if you sell on buzzwords, vaporware and crap items with quick time to market (of course in Microsoft terms, quick time to market means only 1 or 2 years of delay with significant reductions in feature set, security and quality, but hey, they're the epitome of the corporate american dream... sell shit, make moolah, repeat.)

You're still living in the 20's when people actually WANTED to buy american cars, and respected americans a lot more than they do now because we had quality in our products, and we took pride in a job well done. Something most of us aren't ALLOWED anymore at work, especially in the high tech sector where everything is about "buy the cheapest shit you can, because it'll be outdated before the 1 month it takes to blow up, that high quality stuff won't offer us the *wasteful company tax cut* from the republicans". I've sold plenty of execs when I was a tech, on "new microsoft technologies" and they swallowed it up hook line and sinker.

~D

agile isn't new anyway

[idlake]

These assertions are also wrong because agile methods are not new; they've been around for half a century. The fact that people only now have found a name for them doesn't change that.

Do they work? For the right team and project. But those teams and projects tend to discover agile methods for themselves anyway. If you organize your team around textbook methods, agile is probably not for you anyway.

This will be useful...

[merc]

on talk like a pirate day...

arrRRR. scrum.

Quality is mandatory...

[israfil_kamana]

... and automated testing is, while not mandated by scrum, a software best practice that helps make it function.

The thing about scrum is that scrum is the process control part. It shapes the team's interface with the customer, and with the workload. XP provides several practices that work well within the team itself. Things like test-driven-development and continuous integration and other such things are practices that can be used at the team's discretion to maximize their productivity. Scrum isolates the team from scope interference during the iteration.

that's the amazing thing about XP

[Anonymous Coward]

almost all projects that use it are colossal failures by every reasonable metric including the famed Chrysler project that pioneered the whole process. XP projects are often late and full of bugs and defects. And then you have the maintenance problems from the lack of documentation created as well as unstructured and unmanaged architecture that emerges. There are a lot good individual practices in XP and Scrums, but the whole is much weaker than the sum of its parts.

I think the lack of meaningful design and analysis is the real killer of XP. XP relies on a methodology called continuous integration to overcome this deficiency. Continuous integration is simply a way of saying continuously change the design of the architecture to meet the needs of the day. And so you end up continuously rewriting the same code to meet new usages. XP has another concept called test driving development which dictates unit tests are written before the actual functionality. So when you continuously integrate, not only do you have to continuously update objects that use your code that you're changing all the time, but you also have change and maintain the unit tests already created. This whole series of chasing your tail can be avoided with a little forethought (aka design and analysis) to what you're doing.

XP can be a useful methodology in environments where the requirements are changing daily, there are a lot of unknowns and risks in the project such a dependency that doesn't exist yet or that is unstable and so changing a lot or projects whose future from a business perspective is questionable. But overall, XP is as big of a joke on the development community as scientology is to religion. Both are pushed by zealots detached from reality and neither has any evidence to back its dogma.

Since I bashed XP above, I'll enumerate some of the good things about it.
1. Continuous integration if done in a more sane manner like coming up with a design before hand, but not being afraid of changing it when needed and having tools to manage changes (like a continuous integration server)
2. quicker release cycles
3. continuous input from the project champion and business users.
4. having unit tests
5. daily meetings on the issues of the day
6. making a business case for refactoring code instead of doing so because it's cool or technically correct.
7. building only what you need and nothing more

Re:that's the amazing thing about XP

[chromatic]

Continuous integration is simply a way of saying continuously change the design of the architecture to meet the needs of the day.

That's pretty much exactly not continuous integration. I have my doubts about your understanding of XP.

Scrum worked well for us, but not a cure-all

[BP9]

We used scrum in our development for about a year. Our ~25 developers were already arranged into several groups, each one with a technical lead, we turned each of these teams into a scrum and did the daily meeting. At first the meeting ran long and everyone was frustrated, but eventually we got it down to a short meeting that accomplished the main goals of having everyone in the same room: 1) where are we, 2) where are we going in the next day, and 3) who needs something from someone else.

For us the weakest part of the scrum process ended up being the time tracking (which is really cool in theory and draws pretty pictures for sr mgmt on progress). This isn't due to a fault in the concept, but the nature of our workload. Many of the groups were still heavily into the 'R' side of R&D at this stage, and its very hard to predict what you'll turn up and how much that will cost you when you're still in research and design work. From a mgmt point of view this looked like us slipping daily on the charts, which caused some bad feelings.

Once things moved to implementation and testing in a given group the scrum stuff worked brilliantly. As one of the team leads I generally dislike excessive meeting time (preferring instead more informal 1:1 or 1:n in the hallway or on IRC), but these got short enough and had enough value they were worthwhile.

It really does help to force everyone to think about what they've accomplished in the past day and 'promise' what they expect to accomplish in the next day to their team. We didn't have any real slackers, but just spending the couple of minutes planning out your day enough to tell everyone else what you'd be up to was very beneficial.

Generally the 'what help do I need' part of the meeting was the least useful, as most people would IRC or email around directly (perhaps at the cost of some NMI style distraction) and not really ever come to a meeting needing anything. It was still IMO worthwhile.

Scrum only worked when we could break down implementation into bite sized chunks (no more than 2 days I think is the guideline in the book); at the risk of repeating myself it really didn't work well going into a big problem and trying to work out a plan and design.

My experiences with Agile

[Arandir]

One of our divisions at work has been using Agile for a couple of years now. Recently I've had to be involved in their process.

Aaargh!

If they're using real Agile, and not just picking and choosing the parts they like, then I can only conclude that Agile sucks. For years I have been bitching about the stupid waterfall model I've had to use, but Agile seems to be the exact opposite, with opposite but just as existant disadvantages.

First, where's the fricking specifications!?!? How the hell am I supposed to write code if I don't know what I am supposed to write? For a small team this informality may work, but for the fifty person team I'm on, it's maddening. "Just do it!" they tell me. So I do. And then throw it away because it isn't what they wanted.

Second, it's claimed that there are specifications, only that they're called "user stories". That's all well and good if you're writing a user interface, but most software is not a user interface. As a systems software developer, "user stories" don't do me much good because the user doesn't interact with the software I write. Heck, according to the user stories, my code doesn't even exist!

From what I can see of it, Agile is merely a reactionary response to old fashioned gated/waterfall processes. It's not better, it's not worse, it's just another damned unworkable process.

Read a little

[sozinsky]

First, the scrum book, by its co-creator ken schwaber http://www.amazon.com/exec/obidos/tg/detail/-/0735 61993X/ref=pd_sim_b_4/103-6526029-2864653?_encodin g=UTF8&v=glance interestingly enough, its published by MS Press Second: what people seem to be missing in this thread is that scrum is essentially a anarchist/communist/utopian project management technique. there are no bosses telling you what to do. teams are self-organizing and autonomous. this is a _radically_ different project management technique -- no folks, its not about the daily meetings. it's about being bossless. A buddy of mine went through scrum training with schwaber, and he had them do an interesting exercise. teams of two were instructed to walk exactly 300 paces in exactly 2 minutes. each team was composed of a boss and a walker. the walker was told by the boss to take a step, slow down, or go faster. _none_ of the teams successfully walked the 300 paces in the time period. so they were broken up such that each person had no boss, and simply had to walk the 300 paces. _every_ person completed the task. lesson: micro-managing bosses just slow you down. third: a very interesting practical example of this sort of project management technique is the GE jet engine plant in durham, NC. http://www.fastcompany.com/online/28/ge.html This shop is organized around a bossless culture. They are the most successful and productive jet engine manufacturer in the world. A great example of how this sort of technique isn't just for pot smoking hippies. Finally: the essential thing that binds all of these agile/xp/scrum-ish like techniques together is TESTING. No code can be written without unit tests. All requirements have a direct mapping to a suite of acceptance tests (written, say, using fitnesse -- www.fitnesse.org). There are three types of developers in this world: those that test first (the ones I want to work with), those that have never tested at all, and don't want to (stay away from these ones), and those that have read/heard about test first and want to try it out (these can be saved). --sozin

Re:agile doesn't do iterations?

[Some Random Username]

No, an iteration is where you leave the customer out of things, and develop. The stories do not change during the iteration, you come back to the customer after the iteration to have them redo their specs now that they can see how you did things (not the way they wanted). With a real agile development methodology, there is no iteration where you set requirements in stone and then go meet them. You do the least possible to show the customer, and then show them, and you keep working with them constantly. You could pretend that XP would qualify if you had 1 day or less long iterations I guess, but that's not how XP was designed.

Yes, the XP douches certainly do pretend that XP is agile. I am not saying they don't. I am saying they (Beck) are wrong. Calling something agile doesn't make it so. Agile means able to easily adapt to change, not able to blame the customer for changing the spec. XP is all about arbitrary rules, which you must follow even if they make no sense in your situation. The methodology itself isn't even flexible, nevermind using it.

Re:That's what people sayd about O/O in the eighti

[Peter La Casse]

Nay-say all you want, but if you haven't tried it, then you have nothing productive to say for or against.

Pardon the slight topic drift, but this is crap. Having tried something improves somebody's credibility, but insightful analysis of an activity is possible without engaging in that activity. A criticism of, say, XP doesn't become invalid because the person making it hasn't tried XP. If it's valid, it's valid on its own merit.

In other words, when evaluating ideas, don't weight the speaker too much. Don't weight them too little either, but there's little danger of that, while there's lots of danger of only weighting the speaker and not at all weighting what they're actually saying (which can lead to a "cult of personality".)

Fear of Steve?

[Slur]

Yeah, I saw that movie too. So is that how you imagine Steve still behaves? And do you really think that's what makes Apple successful? I think you're projecting your imagined view of Apple onto the real thing. If you have a look at their current roster, and their programming methodologies, I think you'll get a much more realistic picture of what makes Apple successful.

For one thing, they hire really talented people, and quite a lot of PhDs. And they use a far superior development environment than Visual Studio. and really well-designed APIs based on objective-c for most of their applications. Third, they build on top of a Unix-like kernel, and make excellent use of open source when they recognize something worthwhile (KHTML being a prime example).

You see, Steve's second coming brought all those brilliant folks over from NeXT, and it brought NextStep, Interface builder, and a huge mass of portable objective-c code along. And it brought Apple many years of lessons learned. Things like making sure you have a solid foundation before you start building on top of it. Steve and his NeXT entourage understood that you can often get a lot further by rebuilding the whole foundation from the ground up. The reason Copland failed was that frankly, it wasn't ambitious or courageous enough to start from scratch. They didn't have the experience and insight of NeXT. It was very smart of them to admit failure and get a hold of what NeXT had... (Apple's acquisition of NeXT is an event quite comparable to Apple's visit to Xerox PARC, and literally connected to that visit. Because what NeXT leveraged best was OOP, something Steve only after leaving Apple chose to revisit.

Microsoft has had many opportunities to go back to the foundation and start over, and to some degree NT was such an endeavor. But like Copland they didn't go far enough. Had Microsoft decided - as Apple did 7 years ago - to create a completely new Unix-based OS that would use the same interface paradigms, but run old applications in a sandbox, they might not have the mess of exploitable code that is Windows today.

Honestly, the difference between programming Apple's APIs versus Microsoft's is striking. And it's the same with the development tools. Apple's libraries are so much more elegantly designed than Microsoft's. And XCode blows away Visual Studio. If you ask me, I think the reason Apple's development goes so much more smoothly is that the programmers are just a lot happier, and waste a lot less time fighting with crappy technology.

To blithely label Apple as a big personality cult is kind of silly and outdated. The people who work at Apple are quite simply brilliant engineers who for the most part enjoy working with and building well-designed systems. They are not little children playing in Steve's pond just for the delight of being at Steve's feet. If that's what you believe, I think you've watched "Pirates of Silicon Valley" a few too many times, and forgotten that it refers to pretty ancient history at this point.

Quicktime for Windows

[SgtChaireBourne]

Apple has some nice stuff, but other stuff that Steve doesn't care about are absolutely atrocious (perfect example: Quicktime for Windows). ... Not every company can be a personality cult.

Bad example. Development for MS platforms is highly dependent on cooperation and support from MS. In the case of Apple, MS has been more obstreperous than usual. In the case of Quicktime for MS Windows in particular, MS has tried repeatedly to kill it off even as far back as 1997 and 1998 (warning: PDF). See page 52.

Sure Steve may be a problem, but the particulars around that specific example tend to indicate that the problem may be elsewhere...

And speaking of personality cult, or just plain cult, when's ol' Chairman Gates there going to drop the fascade of having anything to do with IT?