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?"
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.
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.
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.
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.
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.
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.
sudo ergo sum
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.
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.
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.
db4o - open source object database for Java and
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.
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.
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.
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.
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.
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.
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.
... 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.
i - This sig provided by
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.
i - This sig provided by
... 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.
i - This sig provided by
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.
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
" What luck for rulers that men do not think" - Adolf Hitler
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.
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.
... 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.
i - This sig provided by
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.
A Government Is a Body of People, Usually Notably Ungoverned
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.
www.linuxpenguin.net
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.
If the hard drives on a Dell laptop series had a problem, we would say that Dell has quality problems. Apple is no different.
Furthermore, like Apple gets credit for the "just works" because they restrict the hardware that their software runs on. Similarly, it has to take at least some blame for the quality of the hardware they restrict us to run them on.
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".)