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.
"Whaddya say? Let's gangbang this thing and go home."
This comment was formatted for readability, but I forgot the line break tags
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.
Don't do meetings all day and get coding instead! D'uh!
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.
- I work for a company that adopts new trends at least 5 years late - that's about when they're being phased out elsewhere. For example, we're now deeply committed (or should I say sentenced?) to J2EE, RUP and outsourcing;
- Our company works on a contract basis, with complete and "firm" specifications (BDUF, anybody?) going in and deliverables coming out, with no wiggle room, no negotiation (at least from our side), no onsite customer.
Given such an environment, which I'm sure will sound familiar to others, do we stand a chance of ever being able to work this way too?When one person suffers from a delusion, it is called insanity. When many people suffer from a delusion it is called Rel
Had no idea what Scrum is so found this
0 69a2710abef27d02c851f&SID=7da824062baf60b8e78ec5f9 9836f092
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=8ef7eb5b2a
It's not a silver bullet but a very useful tool. Even if you don't adopt them wholesale, you should take a "survey course" to see what it's all about. Pick a few of the practices and try them out. See what works for you.
At the risk of sounding like a shill, check out my book (or one like it) to a quick intro some agile methods.
http://www.pragmaticprogrammer.com/titles/prj/
Agile Artisans
How many people are going to read this as Microsoft lauds Scum?
So... does that make Microsoft a hive of scrum and villainy?
First to go is scoping (deliver less) then documentation and Testing,the success criteria. The patient has died, but the operation a success.
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.
For my part, I hate having someone sit at my desk and debug with me for 10 minutes; XP sounds like torture that would cancel out any advantages it might have.
An awful lot of these things (from "methodologies" to the latest fads in "design patterns" and C++ template overusage) sound to me like coders who saw the writing on the wall when the first shop opened in Bangalore and started looking for something that would get them published / get them tenure / give them an "expert in" edge in the consulting market. I can't fault people for going into business for themselves (I have a family too) but it sure is annoying to deal with the consequences.
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.
.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.
And I'm not talking upgrading software, like VS
I'll subscribe to Slashdot when I see a month without a dupe, a typo, or an article the "editors" didn't read.
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
Any word on whether Debian plans to adopt this development method?
They are the last big thing. They were the next big thing five years ago. Under which rock did the article's author live?. They have gone the way of the hype. They are as much the next big thing as FORTRAN.
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.
"Scrum" means ASH... I guess... perhaps they refer to burning their products to the ground? Or what will be left of M$ once this latest FAD fails?
Please God let it be so!!
~D
PS - don't you love being well traveled, and multilingual? Makes the world shine in new colors. (Now I need to learn french since they have really hot women.)
" What luck for rulers that men do not think" - Adolf Hitler
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.
Short answer: Yes
Long answer: Hell, yes.
Start trying one of the recent linux distros, they're very good. I'm using Ubuntu, if that helps.
I'll do the stupid thing first and then you shy people follow...
They must be doing something right - ie,
if they can leave eXtremeProgramming.org
untouched (& feel it's just fine) since
early 2004, eh?
There is no silver bullet!
If you still don't understand it, go to step one.
Mea navis aericumbens anguillis abundat
So how do you write tests for ..
- applications that are a constantly moving target "this would be cool to have"
- applications where the moving-targetness lies in the presentation, while at the same time some customers bitch about any change in presentation
- applications with changing data sets - you can run your tests fine on the standardized data set, but then when it hits the real-world data, all you can say is "Sorry my application is perfect, it just doesn't work with with that data.".
I'm still trying to figure out what people mean by 'social skills' here.
And yes, VERY easy... and at least I didn't have to hunt for drivers to have my brand new, Athlon X2 board running on Linux... I spent a whole day troubleshooting the issue with my nvidia motherboard drivers in XP (the gaming side for this rig, I have a few games that DONT run in linux... and as I've said many times before, the only reason I keep XP on this rig is to game, Starcraft, all the Warcraft games, Doom 1 2 3, Quake 1 2 3 4, Unreal, UT, Half Life, Hexen 1 2, Heretic 1 2, all run in Linux without issues using Wine or native clients (Q4 and D3). I haven't checked Half life 2.
Overall I'd say that since I do NOT trust Windows with my business and only do my banking and important email from my linux box.
~D
" What luck for rulers that men do not think" - Adolf Hitler
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."
And I might have either drop in alternatives or something that does the job... A lot of your apps will run absolutely fine in Wine. Even internet explorer runs in wine (it actually runs better because spyware you will invariably incur using that Piece of Crap (tm)(c)(R) will not bork up the entire system, just the fake windows install that your apps think they're using.
/home/familymemberinquestion directory :) I'm not being mean here, I'm simply curious what makes for such vehement denial (my mom's not a geek but she prefers solaris at work, linux at home, and hates being stuck on "such a slow system" (her 2.2 ghz windows box, vs the Solaris Ultrasparcs she occasionally logs onto at work, if she can adapt, heh heh, my father made the excuse that he doesn't know anything except windows, but since all he does is surf the web and check email/orders he has little reason to complain once I put a firefox/evolution link on his desktop, I run a fully patched version of Xine with the matroska codec pack on his rig as well, he likes to rip movies to the file server and then watch them on his comp... all doable).
~D
PS - "why" does your family refuse to use linux? It isn't as if the "my computer" button can't be created to point to
" What luck for rulers that men do not think" - Adolf Hitler
rumor has it that the dev guys at 3drealms are also adopting scrum.
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!
Having a product that is always shippable is NOT new. In fact I've been doing this since the early 90's and I am sure that it's how it was done decades before that.
I mean this is the core concept of source control. What you have under source control is shippable, and ideally QAed enough to know for sure that it hasn't been badly broken. If you can't acheive that, you have absolutely no control over your sources and I seriously doubt you have any idea about what your schedule will be 4 weeks down the road.
I just want to know why your family is so against migration, (and I'm still curious about the apps you can't get replaced in *nix, I know there's a couple that are hell to get working and some that don't exist, but the number is getting extremely small as of late).
~D
" What luck for rulers that men do not think" - Adolf Hitler
This might be more than some pop superficial rehashing of programming methodology. This is an example of arbitrarily changing the rules to reduce competition. After all, they could have dragged out the old papers and books on formal programming process by Fred Brooks et all and used those. But by making up new rules (actually a subset of the old rules with new names) you can exclude competition from the programmers who know the old rules since they won't be familiar with the new names and will commit faux pas like asking for a formal specification or code reviews which aren't things in the current subset du jour.
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.
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
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.
Rugby's had scrum for years.
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
anywhere in the article where it says they used SCRUM or Agile Programming on SQL 2005. It says they are unhappy with the length of their release cycles and are going to try XP as a way of speeding them up.
Only trouble with scrum... it attracts sharks with friggin' lasers on their heads.
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.
So Scrum is the idea that teams meet once a day for half an hour, figure out what they're going to do then go off and do their work very quickly.
Wow, genius.
(from what little I know) Extreme programming is testing constantly and having people work side by side? Well I Am Not A Professional but I figured this out after my first project got too big. Am I missing something here?
I've got a new methodology: It's called: "Inning". Your programming team works for an 8 - 14 hour period and then takes a break when they sleep. I like to combine it with "Lunch" where the team, either together or seperately, eats food periodically during the day. My book is available to preorder.
Physics is like sex: sure, it may give some practical results, but that's not why we do it.
On how it's implemented within the company. The daily meetings can become a huge waste of time if:
a) There are unnecessary participants
b) The (necessary) particpants don't listen to the progress of others and add their input where it would be useful
In all, it's like pretty much any other methodology - it's only as useful as the particpants are able/willing to follow it. It is no silver bullet that will magically make your code better.
I am the maverick of Slashdot
"Treadwell said. "We have realized inside Microsoft over the years that software practices we used in the mid-90s don't scale to the size of problems that we're tackling today."
You're tackling much smaller problems today than in the 80's and 90's. You already have all the base components, in the 90's all those had to be written. If you want to print things now, the OS handles it, no longer any need to write complete printer device drivers. Indexing algos? Already written, Sort? What type, all off the shelf. Need a lot of memory? No problem, no need to squeeze huge database access into 1Mb of ram these days, machines come with hundreds of MB, yet a sales order is still only 1k of data, the colour "red" is still 3 letters long.
In reality it's a damn site easier to develop software today than it was in the 80's and 90's. The JOB GOT SMALLER!
My view is these methodologies are just disempowerment. Before the team leader would call meetings when there was something to discuss, now with the methodologies he calls them based on some arbitrary rule, it disempowers him. They come with new naming conventions, because if you give a new name to an old concept you disempower the people who don't know the new name. They come with sparkly new procedures, before the team leader would choose an approach based on the problem, now he has to choose an approach according to the 'methodology' written without any knowledge of the problem he's tackling.
As a result, a huge complex product that was delivered by 10 people in the 80's and 90's now takes 5 times longer and 20 times as many people, and ends up 10 times the size with hundreds of times more bugs.
"Steve Ballmer, chief executive of Microsoft acknowledged during his keynote address at the Microsoft launch event that the company needed to get more agile and to produce software faster, to the tune of delivering technology every 18 to 24 months."
No. No one wants such a short release cycle but you and your shareholders. If I may borrow one of your favorite words, there is not enough "innovation" in most of the technologies you purvey to justify an 18 month release cycle. You managed to pull it off for Windows XP and did nothing but piss off those of us who bought your line about Windows 2000. To us, it was clear that XP was nothing more than the finished version of Windows 2000. We had just spent a fortune on upgrading to the future only to be told 18 months later that we weren't worthy of free utilities, functionality upgrades, or even comprehensive service packs since we weren't on the latest release. As far as I'm concerned, you can keep your interim versions to yourself. Anything shorter than 3-4 years for operating systems and server products is lunacy.
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 did pair programming in an XP environment at one company for six months before leaving. It's actually a hell of a lot easier to slack off. If a company hires good programmers the one doing the typing does almost all the work while the other person tries desperately to keep awake. After a while it's easier staying awake and waiting for a point to look over code by reading slashdot or whatever.
Oh yeah I forgot, I'm a screaming freaking retard.
"see you in HELL, candy boys."
*Dell.com
Autonomous Retard -- Is your camp safe? UnsafeCamp.com
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.
"Previously management just did whatever felt right."
You make it sound like they pulled decisions from their ass. They presumably had knowledge of the product and the market your product addresses, something the makers of the methodology don't have. At worst they were as ignorant of your products as the methodology makers are.
Why would you choose a blind person with a good sales patter over someone with sight of the product and market? If methodologies are good, then why are there so many of them? Wouldn't we gradually refine to just one instead of inventing a new one every few months? Isn't this just Guru following, a new Guru comes along with new names and a new sales patter and managers with little confidence worried about their projects follow the Guru.
"Posting as AC, as my coworkers AND management read slashdot and will recognize me."
Or you're part of the sales patter, you've said nothing controversial that warrants an AC.
A second problem with code is avoiding the exponential growth of relatioships between data and the proliferation of rules that must be painstakingly reconciled. The is discussed in another grandaddy, Composite Structured Design
During the 90's many people, including MS did much work and wrote many books to explore solutions to these problems. Models that seperated data, controllers, and views. Models that isolated functionality into descrete well known funcions. Assertions that made sure inputs and outputs were within specification. Hiding data structure. I have written a significant amount of code using these techniques, code that seems to work well. The basis seems to be lmit the relationships in the system, and as a consequence the proliferation of knowledge.
I think that 40+ years of experience in computers has taught us this is the way to write good code. MS, Apple, IBM, all the big players work on this model to some degree. About the only new thing is tools to represent the entire system without intimate detail, and other tools to translate these representations into data types.
So this is what troubles me. Writing code is only a small part of the process. Defining boundries and interconnects, and bebugging, tend to the larger part. Once I know what the window manager will act like, I don't need to know anything else. The higher level code I write, the less I need to know and should know about the subsystems.
And I am not sure how XP fits into this. A group needs to meet to define functions and interconnects. Everything else should be handled through assertions and regression testing. We, as the engineers we want to emulate, need to code to the design. The problem seems to be that many are still living in a world where computer resources are limited, a world many never experienced. Or perhaps MS is just trying to keep an advantage by continuing to sacrifice speed over reliability. It might be useful to have meeting to gain authorization to link deeply into the subsystem, but hardly smart.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
But like any process, scrum won't work unless you have buy-in from every level. I think it took us almost a year before we really got into a groove with scrum and started getting really big benefits out of it.
Developers now work without meddling from management for at least the duration of a sprint (a month). We can focus and get lots of work done.
Transparency has built trust between the developers and the other stakeholders, like testers, usage experts, and management. There's far, far less tension between these groups. And whatever tension that does exist is kept off the shoulders of the developers.
We were a small company, bought out by a very large one, and now our group and our process is starting to be viewed as a model for other groups in the company to emulate, because we're (apparently) far more efficient, and we're getting a lot more work done.
We don't use XP (although we do have a lightweight code review process). The benefits of XP weren't quite as evident to us, so it's not something we mandate - developers can do it sometimes at their discretion.
Accountability on the heads of the powerful.
Power in the hands of the accountable.
On yesterday's evidence, we should hope that Microsoft have been modelling themselves on an English scrum rather than an Australian one.
Suck figs.
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.
Well, maybe instead of rushing software out the door, they should be taking their time to ensure that their software passes higher quality control standards. One of the major reasons that the Microsoft Corporation is losing its users to other operating systems is that the quality of Microsoft products has greatly declined over the years. I have noticed more and more people and businesses switching from Microsoft Windows to Linux, which is a more stable and secure operating system, and that can only mean one thing: there are other operating systems out there which outperform Microsoft Windows operating systems. It's too bad that Microsoft seems to feel that quantity is more important than quality, I have a feeling that Microsoft is paying for it in the long run.
MacGregor Despite Them!
My major objection to these "methodologies" is that they tend to be applied like fundamentalist religion: Rigidly, absolutely, and with great fervor. Blindly following any ideology requires turning off one's brain — which seems a tad unproductive when doing something intellectual, like computer programming.
Agile development presents some compelling ideas, but it needs to be applied judiciously and wisely.
All about me
Well done. You managed to get first post, and write two or three sentences just cynical and anti-corporate enough to paper over the fact that your post doesn't even demonstrate any understanding of what Scrum, Agile, or XP actually are.
Seriously, read the summary, then read the post, and you'll notice that there isn't any specific information there that couldn't be gleaned from the summary.
Well trolled, sir! Well trolled!
Personally I find it amusing that management places so much emphasis on buzzwords like RAD, Scrum, and Extreme Programming. All most of these methodologies really do is emphasize what was known back in the sixties: a few skilled developers can code rings around a large team bogged down by communications and paperwork.
I do not fail; I succeed at finding out what does not work.
They don't know it, and if something goes wrong with Windows they can get relatives to come in and fix it. If something goes wrong with Linux, they've got me. My fixing record isn't that crash hot (I haven't lost anything on the computer yet, although I have come close a few times). It's also inertia. They know how to use Windows and the apps it has, while there are comparable apps for Linux, they don't want to have to work at learning them. Hell, my family doesn't use Firefox (and I've offered a few times now).
As for the apps, well the only one I can't find an alternative for is Flash. Everyone always says "Gimp" but ignoring it's difficult user interface (although I have heard this has improved) it isn't scalar. I love Flash's scalar environment. Know of any open source apps that are comparable to Flash (if I only use Flash for drawing pictures that is. I doubt anything but flash creates flash movies)?
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 and the agile work axioms to understand the underlying ideas behind the agile methods.
Helping with organizational effectiveness is our job.
... 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
It's the Hawthorne Effect that is doing the heavy lifting here.
... or maybe not. Joke all you want, the description quoted above is about one small features. It's like joking about programming because "they use if's". If that was all there was to it, of course it'd be rediulous.
.
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
Small release cycles and having a working software most of the time.
Isn't there a huge loss in testing efforts to avoid regressions?
Or is automated testing mandatory for this?
will MS really change their processes or will it become nothing more than mindless corporate a paper chase? Will they embrace the culture and beliefs of the new methodology, or will it become just another 'flavor of the month'?
From my experience in corporate culture I suspect the latter. What often happens is a group with in a company adopts a methodology which works for them. They then become the poster children for 'organizational change'. The processes are then rammed down the throats of other departments who may be resistant to change, or for whom the processes are inappropriate.
Managers will go to be trained in the new metods and learn the form but not the true spirit of the reform. 1/2 hour scrums will begin to creep up to 2-3 hour daily meetings. In order to take advantage of the accelerated release cycle, products will be scheduled for release sooner, and testing/QA will suffer. Quick fixes will be prefered over true fixes and, inevitably, release will slip. That is my prediction.
Truly changing an organizaqtion takes years. Everyone originally working under the old system essentially has to be fired, quit, transferred, retire or die (one article I read, though I cannot find the reference, said it takes about 20 years for a large company to change).
This might be interesting to watch, in a morbid sort of way. MS is looking for a magic bullet, and we all know how well that works.
putting the 'B' in LGBTQ+
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.
As a manager, my preference is the "scrotum" method. That is, each developer is assigned his work and a deadline, and anyone who doesn't deliver gets kicked in the balls.
It works.
Agile methods are great, but as a contractor at Kaiser Permanente a couple years ago, I saw how it was tried for about 6 months, the managers freaked out because they were clearly made redundant, and old skool process binders and management were clamped on with the force of a grizzly bear trap. So agile methods are everything they are advertised to be, but if those in power are threatened, they won't be adopted. After all, the managers and executives have big mortgages to pay;)
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.
And for those of you who choose to gather more information before they start judging something they obviously know nothing about, here are some links that might get you started into the right direction:
www.controlchaos.com
www.scrumalliance.com
www.scrumeducation.com
www.xprogramming.com
www.extremeprogramming.org
www.agilemanifesto.org
I am sure a google search will also point you into the right direction. As someone who has been doing this Scrum thing for a while now, some of the comments I had to read here just make me cringe. They seem to be full of prejudice and plain nescience. Everything needs to be applied with wisodm and I think teh agile community has understood that. IN German there is a saying "Was der bauer ned kennt, des frißt a ned" Which means as much as: What the farmer does not know, he will not eat. Some of you that post your comments here, are a bit like that.
Putting a name onto the procedure half the world has been using already...tsk Besides, the problem isn't mostly not inefficiency in the programming, the problem is management that thinks they know how to code and are changing the recepie or demanding new "hot features" before having let the programmers ensure that the existing features work 100% If janitors worked the way programming teams work, there would be a manager that turns up every 10 minutes asking if it's gonna work out, putting people up for overtime for no reason, pointless brainwashing company events, mandatory changes in the cleaning procedure every 2 weeks. very little quality cleaning would be get done, but in a hip and buzzwordy manner.
on talk like a pirate day...
arrRRR. scrum.
It's true no man is an island, but if you take a bunch of dead guys and tie 'em together, they make a good raft.
Apple's "methodology" seems to be "first make it work, then deal with the consequences. or not"
The consequences being poorly optimized code, code that's hard to refactor, and plenty of bugs that the normal user will never encounter, but that I stumble over every day.
Lately they've also become fans of unit testing, code profiling, and ignoring their own user interface guidelines.
... 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
What I like about Linux and other F/OSS projects is that they deliver in what I'd call a "tactical" mode. Find the biggest annoyance and address that first. Deliver a good but not perfect feature. Then as you're starting work on new stuff, polish up the old. Deliver frequently, get the code in front of your customers, and let them tell you whether or not it works.
In the old model of software delivery, if a feature didn't work then you had to market the crap out of it or risk losing your investment. That's why we have so much crappy code out there.
If you don't want crime to pay, let the government run it.
almost all projects that use it are colossal failures by every reasonable metric including the famed Chrysler project that pioneered the whole process. XP projects are often late and full of bugs and defects. And then you have the maintenance problems from the lack of documentation created as well as unstructured and unmanaged architecture that emerges. There are a lot good individual practices in XP and Scrums, but the whole is much weaker than the sum of its parts.
I think the lack of meaningful design and analysis is the real killer of XP. XP relies on a methodology called continuous integration to overcome this deficiency. Continuous integration is simply a way of saying continuously change the design of the architecture to meet the needs of the day. And so you end up continuously rewriting the same code to meet new usages. XP has another concept called test driving development which dictates unit tests are written before the actual functionality. So when you continuously integrate, not only do you have to continuously update objects that use your code that you're changing all the time, but you also have change and maintain the unit tests already created. This whole series of chasing your tail can be avoided with a little forethought (aka design and analysis) to what you're doing.
XP can be a useful methodology in environments where the requirements are changing daily, there are a lot of unknowns and risks in the project such a dependency that doesn't exist yet or that is unstable and so changing a lot or projects whose future from a business perspective is questionable. But overall, XP is as big of a joke on the development community as scientology is to religion. Both are pushed by zealots detached from reality and neither has any evidence to back its dogma.
Since I bashed XP above, I'll enumerate some of the good things about it.
1. Continuous integration if done in a more sane manner like coming up with a design before hand, but not being afraid of changing it when needed and having tools to manage changes (like a continuous integration server)
2. quicker release cycles
3. continuous input from the project champion and business users.
4. having unit tests
5. daily meetings on the issues of the day
6. making a business case for refactoring code instead of doing so because it's cool or technically correct.
7. building only what you need and nothing more
Why should be anyone be surprised Microsoft uses a SCUM methodology???
... religious fundamentalist XP. XP, applied sanely is a set of engineering practices that can highly charge a team's productivity. If the "xp" team is delivering crap every week, then it's not xp, it's bad customer relations wearing an XP skin. Typically, however, I see a scrum wrapper around an XP team, where scrum is the main s
i - This sig provided by
... describing religious fundamentalist XP. XP, applied sanely is a set of engineering practices that can highly charge a team's productivity. If the "xp" team is delivering crap every week, then it's not xp, it's bad customer relations wearing an XP skin. Typically, however, I see a scrum wrapper around an XP team, where scrum is the main process control and xp activates the team itself.
i - This sig provided by
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.
A lot of very good programmers, some of them with vast experience, swear by (not at) Agile methods, XP, and techniques like Scrum. Myself, I was trained to use "waterfall" techniques, and still believe they have a lot to offer - there is much to be said for freezing requirements and specifications (at least while you deliver the current release - there is nothing to stop you working on two or more releases at the same time, as long as you use different teams for them).
9 851_1,00.html
As many posters have pointed out, there are too many PHBs - especially on the client side - who refuse to learn the fundamental axioms of software engineering. E.g. they don't know Brooks' Law, and they think they can keep changing requirements as much as they like, right up to (and beyond) the delivery date. Consider this recent glaring example (the UK National Health Service's $10 billion patient booking system). According to today's Sunday Times, a senior civil servant called Richard Granger criticized a less senior official for delaying the project by continually piling on new requirements or change requests:
"Granger censures Margaret Edwards, the department's director for access and patient choice, for adding numerous new specifications to the booking programme, known as Choose and Book.
"Granger writes: "Choose and Book's £20m IT build contract is now in grave danger of derailing (not just destabilising) a £6.2 billion programme."
"He concludes: "Unfortunately, your consistently late requests will not enable us to rescue the missed opportunities and targets." "
http://www.timesonline.co.uk/newspaper/0,,176-186
As I see it, Agile techniques like Scrum are a response to the insistence by non-technical PHBs (who unfortunately hold the purse strings) that they be allowed to go on changing their minds right up to delivery date. They're not perfect, but under the circumstances it is amazing they work at all - which they do.
I am sure that there are many other solipsists out there.
Unfortunately, only too true.
Speaking as a manager, I think there are certain minimum things the manager must be able to do:
1) Run the scripts that create the build environment on his workstation. S/He should wipe that workspace and rebuild it on a random basis, weekly or so. What??? You don't have hands-off scripts to create the build environment? -> good management question #1 has just been asked.
2) the manager should be able to kick off a nightly in the build environment he created in step 1. Are those nightly build scripts up to date?
3) The manager should be able to run the check-in requirements test script. You do have one, right?
4) The manager should be able to create a test case and check it into the testing framework. S/he should do so on a random basis. A good manager probably brings more to the testing effort than to the coding effort.
Note that none of the above require extensive up-to-date coding ability, or massive amounts of time. But they all directly get at good process and quality in a very hands-on way. It is much harder to sneak BS past any manager that can do the above 4 things.
It doesn't work in every situation or in any organization. You can't just plug it in anywhere, because it's very dependent on how managers perceive their role. It did work well when, at the suggestion of one of the developers, I used it with a small team in a small organization with a relatively trusting client. I have no idea how well it would work on a larger project for a more hierarchy-oriented organization.
Read the EFF's Fair Use FAQ
First, software development, engineering, applied math, is basicly organized problem solving. The core primitive is the technical analysis and design (software implementation is just fine grained design). Any wrapper (organization/management) around these primitives is theoretically just glue to get the primitives to mesh and go in the 'right' direction. Necessary glue, but just glue.
Development processes do not amplify the inherent problem solving capabilities of your workforce. They can just minimize organizational and communication overhead. You need training and education to raise the inherent problem solving capacity...or hire more smart people. The work environment itself can raise effiency some by reducing burnout and increasing motivation. This includes free lunch (google, dreamworks, etc), frequent (rare is just insulting) company sponsored activities (camping, skiing, etc), and good benefits.
All of these processes, from old-school top-down waterfall, to spiral, to peer-oriented agile/XP, to bottom-up bazaar, impose overhead to the core problem-solving in order to achieve higher level objectives. Different processes are more efficient for particular types of objectives and different workforce cultures. Some scale better than others. Some are more nimble than others. However, a 'new' approach is rarely any better than its almost certainly pre-existing relatives.
A 'new' approach often does carry one short term advantage though. It can create a temporary excitement that can result in extracting more productive problem-solving hours out of employees (like the cited Scrum-month, or a game company's 'crunch' with late night pizza, etc, etc). This wears thin and eventually reduces to just more hours without increased problem solving. New processes can't make people better problem solvers. Bad ones just suppress and oppress them.
Because, of course, developers can't actually be responsible for any element of project failure - it has to be poor management. If they had good managers who were all developers, everything would be 100% OK.
It may be worth asking yourself, next time you're set a ridiculous deadline for a fixed-cost project that was sold way under budget, that maybe rather than being actively evil, your sales people are acting under misinformation.
I know from experience that many developers dislike any form of time management / booking systems, but are also largely incapable of saying how long something actually took to do, or might take to do - yet somehow expect that everyone else in the chain is going to get that right. So when the business loses the sale because they over-quoted - that's sales fault. When it goes bankrupt because the developers took twice as long as they said it would - it's managements fault.
'Capitalists of the world, unite! Oh
Rule number one of business: It's Always Management's Fault.
"Piter, too, is dead."
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.
Uhm, what are you saying? Agile development IS exactly what you say: work with the customer in a tight loop so you don't create something the customer doesn't want. XP is a type of Agile develpment method. They recommend X weeks in the XP books because that's a good balance for everybody. If you want to add the next feature in 2 days, go ahead (but you probably only have one customer, and an enthusiastic one). The point is to do it QUICKLY and don't let the project get off track.
... we use a process called MTCOADBAFM.
Measure Twice, Cut Once, And Don't Be A Fucking Moron.
It works really well. Our stuff gets done on time, at budget, and passes all quality control checks.
I know, I know - our process doesn't have a nice EXTREME TO THE MAX buzzword, but it works for us.
Since I can't tell them apart, I treat all ACs as the same person.
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
It's "one small team at Microsoft is adopting" SCRUM. There have been agile development crazy teams at Microsoft for quite a while. Guess what, they're no faster than the "regular" teams, and the quality of the output is no different in most cases. But folks in management feel good about themselves.
First, the scrum book, by its co-creator ken schwaber http://www.amazon.com/exec/obidos/tg/detail/-/0735 61993X/ref=pd_sim_b_4/103-6526029-2864653?_encodin g=UTF8&v=glance
interestingly enough, its published by MS Press
Second: what people seem to be missing in this thread is that scrum is essentially a anarchist/communist/utopian project management technique. there are no bosses telling you what to do. teams are self-organizing and autonomous. this is a _radically_ different project management technique -- no folks, its not about the daily meetings. it's about being bossless.
A buddy of mine went through scrum training with schwaber, and he had them do an interesting exercise. teams of two were instructed to walk exactly 300 paces in exactly 2 minutes. each team was composed of a boss and a walker. the walker was told by the boss to take a step, slow down, or go faster.
_none_ of the teams successfully walked the 300 paces in the time period. so they were broken up such that each person had no boss, and simply had to walk the 300 paces. _every_ person completed the task.
lesson: micro-managing bosses just slow you down.
third: a very interesting practical example of this sort of project management technique is the GE jet engine plant in durham, NC.
http://www.fastcompany.com/online/28/ge.html
This shop is organized around a bossless culture. They are the most successful and productive jet engine manufacturer in the world. A great example of how this sort of technique isn't just for pot smoking hippies.
Finally: the essential thing that binds all of these agile/xp/scrum-ish like techniques together is TESTING. No code can be written without unit tests. All requirements have a direct mapping to a suite of acceptance tests (written, say, using fitnesse -- www.fitnesse.org).
There are three types of developers in this world: those that test first (the ones I want to work with), those that have never tested at all, and don't want to (stay away from these ones), and those that have read/heard about test first and want to try it out (these can be saved).
--sozin
Couldn't it be true for them to deliver fewer features than originaly planned AND more features than ever expected? It's a perfect tautology.
XP is exactly what I described. Agile development whores have tried to adopt XP and pretend its an agile methodology since PHBs have heard of XP. Agile development means working with the customer. XP means making the customer come up with a spec that they can't possibly create, doing it, and then blaming the customer for it being wrong. XP is where you create stories for each iteration. Agile development doesn't do iterations, the project is always evolving as the customer is involved and providing feedback.
There is no kinda doing XP, the creators of XP have always been very clear that you either blindly follow all their arbitrary rules, or you are not doing XP, and your bad results are your own fault for not doing XP. Again, its all about laying blame, that's what they created it for, shifting the blame off of themselves as programmers, and onto their percieved enemies (customers).
I am not always surprised when I see the trolls out on slashdot (it is one of my fav sites - not a total bash). In this case - I am somewhat surprised to see how many nay sayers are posting. I have been an agile advocate and user for some time now. I can say that while it is 'nothing new' - neither is anything entirely new. Putting together old ideas into a newer unification is what is usually happening with most things. In any case - the end of the story is - "DO WHAT WORKS FOR YOUR BUSINESS". I believe - as do many other practicioners that Scrum specifically has enabled me and my groups to stay closer to the business needs and to meet what the business needs more adeptly. This is really the crux of the matter. So - I would also gather that all the nay-sayers are waterfallers for the last N years. All I can say is - nay say what you know - be skeptical, but do not show yourself until you have some real experience in something. So - DO a Scrum based project for a few sprints - then come back and post about how useless it is.
" I have no tag line. "
This is exactly what Scrum does which is why it is used on some open source projects. "What I like about Linux and other F/OSS projects is that they deliver in what I'd call a "tactical" mode. Find the biggest annoyance and address that first. Deliver a good but not perfect feature. Then as you're starting work on new stuff, polish up the old. Deliver frequently, get the code in front of your customers, and let them tell you whether or not it works."
That's what I thought it said at first. :P
It is also a vector one, like flash. (I believe you meant to say 'vector')
Runs under windows, linux; opensource, mature, and easy to use..
http://www.inkscape.org/
Mod it up.
I always felt that Miscrosoft released Scrummy software.
"Hex, Bugs, and Rockn'Roll"
Come again? Isn't an iteration a set time where a project "evolves"? Every Agile project I've been involved, even back when they were called "Iterative & Incremental" or "Evoluationary" methods, had ... iterations.
"Agile" is an umbrella term. XP fits within it. It means working with a customer just as much as scrum or DSDM or "create your own agile method"... though with different priorities, focus & responsibilities than other methods.
Beck's main book (Embrace change) and the Beck/Fowler book (Planning) both make this clear. As do the C2 archives from circa 1998-1999 when XP was first created. Perhaps you've spoken to people that have gone way too far down a path (customer is responsible for specs "period") without being reasonable (customers are responsible but need collaboration & guidance).
-Stu
Three popular posts are emerging:
1. what's new IN scrum?
2. why is there "yet another buzzword" with Scrum?
3. methodologies don't matter, people do
4. I hate XP
Well the answer is, there's nothing new, and it's not a new buzzword. It's been around since at least 1996-1997. And it contains a lot of "common sense" to certain classes of hackers, which is far from "common sense" to managers used to treating software development like a manufacturing process.
As for methodologies mattering, the real problem is that many times you'll have talented developers and talented business people, but they don't speak the same language. So there is misunderstanding. And management also has its own language and techniques. Smart people will work through these problems, though it certainly can be nerve wracking and inconsistent. A method really is a way of codifying behaviours and interactions that have worked well for others. It should be tailored to your situation with care, and shouldn't be swallowed as a statement of religion.
Finally, XP is a way of looking at things from a particular vantage point. That's a strength and a weakness. It ignores larger concerns in favour of smaller concerns. Having said that, most of Its practises are spot on, even though they're very "programming in the small" practices. Pair programming is an acquired taste, of course, but it is very effective with certain team dynamics and individuals.
-Stu
I meant "four" popular posts... alas.
-Stu
No matter how great Scrum/agile methodologies are, the problem is in the programming languages used. Fix the programming languages, and most of the problems will go away. We should have been programming requirements by now and not implementations.
Most major companies, and open source projects use some agile methods already.
I've been leading programming teams for quite awhile now. I've used several different development methodologies, and had them all fail and succeed at some point. Every success or failure came down to one thing... PEOPLE. If you have a good team, that team can accomplish anything using pretty much any development methodology. Crappy teams will yield crappy results. Good teams will yield good results.
Good people know how to make a process work for them, whether its XP, Scrum, Waterfall, or RUP. Bad people become a slave to the process and end up failing. I'm not saying process isn't important. I think process is very important. But process will never replace good people and good synergy.
I first saw the title and thought well, it's good to see Microsoft agree that the All Blacks' scrums were pretty bloody good in the spanking they gave the Irish over the weekend.
/. branched out into sports now?
Then I thought - What!?! has
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".)
I always find it a bit funny every time I read an article promoting the programming paradigm d'jour. The reason is that nearly every programming paradigm that I've run across seems to take some fundamentally good idea that I and most of the programmers I know use regularly anyway, and try to create a complete programming methodology around it. A lot of the concepts in agile programming and eXtreme programming are things that I think most developers realize very early on.
OO always seemed like the best example of this to me. Before I'd really learned much about OO proper I used a lot of the ideas behind it when developing software. Of course the problem is that people seem to have a tendancy to take these concepts and run too far with them. A couple of semesters ago I was helping to tutor a student in his first Object Oriented Development class. The program the student has been asigned was supposed to allow the user to enter a series of names and birthdates and then print the list back onto the screen. The program wasn't working so I asked him to give me a printout of the source code. He had used 11 classes to write the program.
Anyway, I know berating OOP is a little off topic, but my point is that I really have a hard time understanding companies deciding to implement a specific programming paradigm when doing so in general seems to often lead to absurdist levels of whatever the particular paradim espouses, and when it would often be much more efficient to simply allow teams to program in a way that feels most natural to them.
This can be particularly important it seems the more people that you have working on a project, simply because different developers are comfortable using different styles of programming. A friend and ex-coworker of mine and I for example found ourselves much more productive when using a variant of the buddy method of programming. This seemed to be largely because we both are about the same skill level but have different background when it comes to coding (his first lanuage was Java and he works mainly with Java and PHP, whereas I started with C and work mainly with C++) so we tend to counter-balance eachother well (he tends to be better at noticing when the general design of the program is going astray, whereas I tend to be better with catching more local problems like buffer overflows. He also has a good eye for catching random syntax errors that I often overlook, while I tend to be better at knowing various CS algorithms off hand- or at least knowing of them and knowing when they'd be useful to look up. He tends to have a good mind for what constitutes readable code, whereas I tend to be good at knowing good shortcuts and optimizations to save memory or cycles (we were both CIS majors at the same school incidentally, but while he really got into the CIS side of things I tend to spend a lot of my time reading about pure computer science and doing things to learn more about CS via MITs Open Courseware, having realized too late into my education that CS was really what I wanted to do,as opposed to CIS)). Other developers at the place I used to work however hated having anyone else around while they worked. Similarly, some developers were very much into doing all of the design work, then writing all the code, then doing all the testing. I on the other hand always found myself more efficient when I could work on a small chunk of the program, test it well, and then move onto the next one.
Granted, I never worked on a project team larger than a half-dozen developers, so my experience may be skewed. I realize that it can be difficult if a group of programmers is working together and half want to develop the program in small chunks, while others want to do all the design, then all of the coding, etc. I think that there is still room for individual preference and compromize from within the group, rather than a mandate for a specific development method coming down from management who rarely understand the methods they are implementing, and even more rarely the code they are mandating the method be used on (not that this is necessarily bad, managers need to be good managers, not necessarily good developers).
Famous Last Words: "hmm...wikipedia says it's edible"
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.
-- thinkyhead software and media
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 of having anything to do with IT?
Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.
Determining whether something is "Agile" depends on the etymology of the term. In a general sense, anyone can come up with their own fitting description, though the colloquial use of the term refers to any method that adheres to the direction in the Agile Manifesto, and follows the principles behind the manifesto, all of which was crafted by the Agile Alliance (of which Beck is a founding member).
You'll note one of the principles is "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." It doesn't really matter if those intervals are "every day" or "every 2 weeks", so long as there is some kind of rhythm. You say XP was not designed in this way, and I strongly disagree. Kent had 3 day iterations on one of his Swiss projects circa 1999-2000, and was working on moving it to 1 day iterations. There is nothing inherent in XP to mandate a period for iterations, other than there must be a period. If you do it "whenever there's stuff to show the customer", you lose rigor in your ability to measure and control the process. The latter could work, of course, but it's just less repeatable.
And as for whether something is "Agile" or not, the person I usually turn to is Alistair Cockburn, probably the most experienced software project anthropologist out there. While he's critical of XP, it certainly is considered agile. So I must disagree on your point. Judging by the vehemenance of your claims, I doubt I'll be able to argue further, thus we'll have to leave it at that.
-Stu
...because their Charisma sucks.
Oh, say does that Star-Spangled Banner entwine / The myrtle of Venus with Bacchus's vine?
*shrug* We tried XP here. We're on a modified variant currently. Interesting idea but I agree with the guy who said that XP is like sticking your hands in a box of poisonous snakes and hoping that they're all too busy biting each other to pay attention to you.
This sig has absolutely no significance and serves only to take up screen space and waste the time of the reader.
Scrum is like communism, with all the benefits and curses of it. It encourages contributions from all, but also limits the authority of those who are good. Problem with communism, is mostly tho, that strong personalities can abuse the system and take power, without checks and balances. You end up with a system dominated by those who are the loudest, and not necessarily the best. Clean architecture is secondary to temporary velocity. And where multiple scrum teams exists, parallel silos are common.
When I learned to row at college, we were fortunate to have eight big blokes all show up for try-outs. After a few weeks, we were doing well, but our coach felt we needed some expert tuition. A professional trainer spent a day with us and taught us how to alter our strokes to be more efficient. At the end of the day, we still put as much effort in, but we went twice as fast.
Ah, but I'm not a novice! I've been doing this for years! Well, the blue boat (which is usually full of olympic athletes doing, er, agriculture degrees) still requires a coach because putting a group of brilliant, experienced athletes together requires that they form a team that works together.
There is no question in my mind that Scrum is extremely effective. It is also quite a different mind-set. If you are interested in it, I suggest getting a coach. You will learn to move twice as fast for the same effort. I am speaking as someone who has been doing Scrum for 18 months now with a combined team of over 60. I have been programming professionally for 17 years.
We've used XP-like techniques for some time. We don't call it XP any longer, but we continue to enforce two of the cornerstones;
- Unit tests. Preferably even before the feature exists. It forces the developer to see how his object/feature may be used by others. It gives us a good smoke test evaluation of functionality, incredibly useful in such cases as switching compilers, supporting a new os.
- Code reviews. We don't do Pair Programming, but code reviews are required for checkins. We use codestriker for that.
Called by any name, these are good guiding principles.
http://superconfigure-supergroove.appspot.com/
I was fortunate to attend a two day seminar on this methodology. Overall, I found it very interesting and it demonstrated an alternative to the traditional waterfall approach. We've managed to use concepts from this methodology on the team, but it is very hard to follow all the principals when there isn't complete buy in from everyone. The best parts I am able to take into the real world with me are:
Daily stand up meetings. These are usually no longer than 15 minutes and very rapidly give a view of the current project status.
A living backlog. The backlog of tasks with estimates to complete each task is updated every day and is a fantastic tool to allow the developers to select what they will work on next rather than relying on someone else to plot out what a developer will be doing in several months.
Burndown chart. The burndown is derrived straight from the backlog and shows very clearly how closely on track the project is within a given sprint.
That all being said - the one thing was not able to figure out is how to judge how clost the entire project is to being on track with its deadlines. As far as I can tell, the project is only planned as far ahead as a given sprint (roughly a month).