Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Microsoft

Microsoft Lauds Scrum 299

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?"
This discussion has been archived. No new comments can be posted.

Microsoft Lauds Scrum

Comments Filter:
  • A good example? (Score:5, Informative)

    by blowdart ( 31458 ) on Sunday November 13, 2005 @08:44AM (#14019742) Homepage
    So Scrum was used on SQL Server? The SQL Server product that's very late and has had to have features disabled [bink.nu]. 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 [microsoft-watch.com]?

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

  • by exaviger ( 928938 ) <nathantal@gOPENBSDmail.com minus bsd> on Sunday November 13, 2005 @08:47AM (#14019755)
    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 [controlchaos.com]
  • Combatting OSS (Score:3, Informative)

    by Kawahee ( 901497 ) on Sunday November 13, 2005 @08:55AM (#14019774) Homepage Journal
    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.
  • An XP Book Review... (Score:4, Informative)

    by mindpixel ( 154865 ) on Sunday November 13, 2005 @09:20AM (#14019827) Homepage Journal
    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.

  • by bwy ( 726112 ) on Sunday November 13, 2005 @09:50AM (#14019899)
    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.
  • 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 [agilemanifesto.org] and the agile work axioms [agileaxioms.com] to understand the underlying ideas behind the agile methods.
  • Re:A good example? (Score:3, Informative)

    by WhiteWolf666 ( 145211 ) <{sherwin} {at} {amiran.us}> on Sunday November 13, 2005 @12:17PM (#14020429) Homepage Journal
    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/ [blogspot.com]

    http://blogs.msdn.com/scottwil/archive/2005/11/07/ 490007.aspx [msdn.com]
  • by Zigurd ( 3528 ) on Sunday November 13, 2005 @12:22PM (#14020457) Homepage
    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:A good example? (Score:3, Informative)

    by Skim123 ( 3322 ) on Sunday November 13, 2005 @09:34PM (#14023205) Homepage
    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.

  • Fear of Steve? (Score:4, Informative)

    by Slur ( 61510 ) on Monday November 14, 2005 @05:16AM (#14024524) Homepage Journal
    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.
  • by SgtChaireBourne ( 457691 ) on Monday November 14, 2005 @09:31AM (#14025303) Homepage
    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 [gpo.gov] (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 [ft.com] of having anything to do with IT?

He has not acquired a fortune; the fortune has acquired him. -- Bion

Working...