Slashdot Mirror
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?"
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.
These are scrum successes? I'd hate to see the failures.
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.
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.
So... does that make Microsoft a hive of scrum and villainy?
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.
Wanted: Clever sig, top $ paid, all offers considered.
No, Scrum is different. Scrum is a daily meeting that is EXTREME TO THE MAXX!!
POKE 36879,8
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.
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."
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.
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.
In soviet russia stale jokes recycle you!
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.
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.
Ian Ameline
Lots of buzzwords, little information. So let's Learn more:
At this point, my head exploded. This note is a post-mortem plea to press murder charges against the person who wrote that crap.
Please correct me if I got my facts wrong.
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"
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.
Please correct me if I got my facts wrong.
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.
Please correct me if I got my facts wrong.
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.
I wrote parts of this stuff