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

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.

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.