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

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?

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.

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.

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.

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.

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.