×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Agile Software Development with Scrum

timothy posted more than 11 years ago | from the don't-break-your-nose dept.

Programming 168

bADlOGIN writes "Anyone and everyone on Slashdot probably knows that business-driven software development efforts all too often end up as a mess. After a number of years of observation, research, and fine tuning, Ken Schwaber and Mike Beedle have released a book that makes a subtle but vital revelation about the nature of software projects and how to better run them. Learning what Scrum is and how to practice it is not all that profound. However, sitting back and realizing why Scrum works and how it addresses the fundamental flaws of the last 20 years of software engineering is. This book could be viewed as the "why" component to all of Extreme Programming's "how."

What it's all about:

Books that claim to hold the keys to developing software the right way are most often: a) a dime a dozen, b) self-serving vendor drivel, or c) all of the above. While this book is fairly new on the shelf (Copyright October 2001), it has a level of research, professionalism, and effort towards being tool- and language-agnostic that may place it in a fourth category of being: d) none of the above. Agile Software Development with Scrum is a complete picture of the Scrum process from theory to practice in real life examples. The name Scrum was chosen because the process is similar in nature to rugby play where success is built upon being quick, adaptive, and self-organizing. The target audience for the book is "executives, software managers, project leaders, and programmers." While the authors make no assumptions directly, being familiar with Extreme Programming, "classic" waterfall methodology, and having hands-on experience with the chaos of software development is indeed helpful.

The primary theme of the book is simple, but the impact is profound: software development is an empirical rather than a defined process. That's a nice big sweeping claim to make: fortunately, the authors spends a lot of time making sure that you as the reader understand what they mean by the statement and that they're serious about it. Comparisons to other empirical processes are illustrated with examples of changing, complex problems. The authors seek out and provide unique insights from process dynamics experts on the nature of empirical versus defined processes, and cite profound supporting work regarding the limitations of algorithms in complex systems with external inputs (e.g. Wegner's Lemma).

Along with a good dose of theory, there is a generous helping of practice and how-to. Agile Software Development with Scrum covers the basic practices and concepts needed to manage software development in an empirical fashion. The authors do a good job of addressing the classic "but what about..." questions on the spot in a conversational manner and include anecdotes throughout to make specific points and include full process examples towards the end.

What's good about the book?

Scrum is the missing "why" to Extreme Programming's "how." By it's nature, Extreme Programming incorporates all of Scrum's spirit, and vice versa. This book has a foundation of ideas and an explanation of what it takes to seriously improve the state of the practice of software engineering. The order is reasonable, and the depth of information should give any determined individual the ammo they need to make a change in how software is developed in their current job or their next.

What could have been better?

There are only three things worth mentioning for improvement, all of which could be easily done. First, there were occasional typographical and formatting errors -- places where indentation, capitalization, or bullets were missing broke the flow. Second, the graphics in more than one section were blocky, low resolution circa 1987. And last, the $30.95 list price was a bit steep for 158 pages. It should be noted that the typographical and graphics issues were the only thing that prevented me from rating this 10 out of 10.

Summary

In my opinion, this book has been needed for a long time. The issues and failures of defined processes such as the "classic" waterfall methodology can't be set aside until there is an approach that can justify itself both in theory and in practice to replace it. Extreme Programming has gained much attention, but tends to depend too much on the fact that "it works because it works." Scrum gives you a way to fix your development efforts without as much culture shock or risk. It's worth considering implementing before your competition does.


You can purchase Agile Software Development with Scrum from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

168 comments

IN SOVIET RUSSIA (-1)

IN SOVIET RUSSIA (621411) | more than 11 years ago | (#5326072)

Agile Software Develops You!

Free Shoes Song (-1)

Want Some Shoes (640625) | more than 11 years ago | (#5326094)

Join us now and share the footwear;
You'll be free, cobblers, you'll be free.
x2

Hoarders may get piles of money,
That is true, cobblers, that is true.
But they cannot help their neighbors;
That's not good, cobblers, that's not good.

When we have enough free footwear
At our call, cobblers, at our call,
We'll throw out those dirty licenses
Ever more, cobblers, ever more.

Join us now and share the footwear;
You'll be free, cobblers, you'll be free.
x2

Re:Free Shoes Song (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5326226)

nice job! But...


1) instead of throwing away dirty licenses, throw away dirty socks.

2) ???

3) profit!

Confused (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5326121)

CmdrTaco, should I fear Google?

Buzzword alert!!!!!!! (-1)

Anonymous Coward | more than 11 years ago | (#5326127)

I read the title of the article. I got to the words agile software and the buzword alarm went off.

No need to waste any more time on this article.

sounds interesting... (3, Insightful)

f00zbll (526151) | more than 11 years ago | (#5326179)

might be worth a purchase, but still not completely sold. self-organizing is nice when engineers on the team understand the reality that organizing with other team members is good thing. It still doesn't help when one member of a team doesn't listen to anyone and ends up rewriting their code 5-6 times.

Re:sounds interesting... (4, Insightful)

PincheGab (640283) | more than 11 years ago | (#5326261)

It still doesn't help when one member of a team doesn't listen to anyone

In that case, no development methodology will work. The best methodology to follow is to send the team (non)member home.

Re:sounds interesting... (1)

Derkec (463377) | more than 11 years ago | (#5326398)

Exactly. If a member of your "team" isn't a team player, it becomes very difficult to justify paying his or her salary. Well said
.

Re:sounds interesting... (1)

killmenow (184444) | more than 11 years ago | (#5327475)

But sometimes that person is really tight with the CEO and it becomes very difficult to justify playing roullette with your own salary.

And I don't want to hear it about getting a better job where you don't have to deal with the politics...any sufficiently sized organization (say, more than three people) will develop office politics. It is human nature. I've worked in many organizations trying for years to find the mythical "no bullshit" company...the closest I ever got was when a business partner and I worked for ourselves as consultants...but even then, with just two people, bullshit happened.

Wait...maybe it's me!

lack of promotion, or lack of substance? (2, Interesting)

prgrmr (568806) | more than 11 years ago | (#5326182)

...While this book is fairly new on the shelf (Copyright October 2001)...

Since when is a year and a half "fairly new"? This makes me wonder if both this book in particular and extreme programming in general are really the Nirvana they appear to be? Is lack of promotion for or lack of substance with extreme programming the reason the Big Guns like IBM and Sun haven't promoted Extreme Programming Consulting services, or have they simply not found a way to co-opt the market yet?

Re:lack of promotion, or lack of substance? (5, Insightful)

PincheGab (640283) | more than 11 years ago | (#5326246)

Since when is a year and a half "fairly new"?

When you are learning principles, a year is nothing. Lemme see, your gcc book might be old in a year or two, but your algorithms book from ten years ago is still very useful.

Same thing here, books about development methodologies never age (refer to The Mythical Man-Month, rightfully, still required CS reading).

If you think a year is too old for principles, then you follow fads too much.

Re:lack of promotion, or lack of substance? (1)

prgrmr (568806) | more than 11 years ago | (#5326348)

Point taken. However, given that this is an after-the-implementation expository (after all, Extreme Programming is how old?) rather than new paradigm advocacy, it's obviously more than a fad.

Extreme Programming won't be labeled a fad until Microsoft gets ahold of it.

You Know What I Say? (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5326190)

"We got no food, we got no jobs, our pets HEADS ARE FALLING OFF!"

From: Dumb and Dumber

lame title (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5326197)

Agile Software Development with Scrotum.


Admit it -- that's what you're thinking!

CmdrTaco, the whiny little bitch. (0, Informative)

MondoMor (262881) | more than 11 years ago | (#5326202)

So today, CmdrTaco posts a duplicate article [slashdot.org]. Not out of the ordinary, since he can't be bothered to read his own site.

The twist this time, is that he posted the dupe an HOUR AND A HALF after the first one [slashdot.org]. Not a week. Not a day. 1.5 hours. There was only ONE story between them.

Amost every single post in the discussion attached to CmdrTaco's article says "OMG DUPE".

Of course, he didn't bother reading this (nor the other stories on the front page). Once he woke up and discovered that his idiocy was laid bare, he had the nerve to suggest that the readers should have emailed him:

CT: Yeah yeah. It's a dupe. Funny that not a single reader emailed me in almost 2 hours to tell me.


Listen up, shithead. YOU should be proofreading and checking up on your posted stories, NOT THE READERS. Some readers ACTUALLY PAY YOU, so the least you could do is not insult them by posting dupes and implying they should do your checking for you.

What a fucking worthless prick.

Re:CmdrTaco, the whiny little bitch. (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5326731)

Well Said!


Cmdr Taco has previously stated that slashdot runs the stories it runs (linux, legos, etc) because he wants slashdot to be stories that he wants to read.


Ok, so why isn't he reading? Eat your own dog food, bitch!

Scrum? (1, Insightful)

Masa (74401) | more than 11 years ago | (#5326208)

First I read "Software Development with Scum" and I thought that this must be something about those clients I have been working for.

It's not a secret, why business-driven software development so often turns to be a such a mess. The demanding part (management, customers) is just plain stupid. No, sorry, bone-headed whould be a better term.

Re:Scrum? (5, Interesting)

tobes (302057) | more than 11 years ago | (#5326284)

Not to be rude, but perhaps if you feel that way you should spend more time setting expectations. Developers always complain about management (I know I've dealt with some crappy managers), but I think that it's the fault of the industry as a whole for not setting expectations right.

Half the time the problem is the vendors telling management that their product will slash costs by 200% and be implemented in a week for a 10th the price of the competition.

If you're a consultant I'm sure you've seen the ever popular salesman screw job where your sales person doesn't have to guts to tell your client what their development is really going to cost them, so it ends up being done by the you (the developer). That always leads to some fun discussions.

Re:Scrum? (2, Interesting)

PincheGab (640283) | more than 11 years ago | (#5326315)

It's not a secret, why business-driven software development so often turns to be a such a mess. The demanding part (management, customers) is just plain stupid

I'd argue that it is our professional responsibility to make management and customers happy, we should drive the process and we should feel responsible for success. Having said that, I'll be the first to say that there are customers out there that you do not want to have (I'm sure we all have war stories about these!).

I just want to make the point that business requirements change, clients (or employers) do not know exactly what they want, and all of that is a part of life. We do not get clearly-defined programming assignments like we got math problems in school. That is why methodologies that embrace change (like SCRUM) are so exciting.

no, the managers aren't stupid (0)

Anonymous Coward | more than 11 years ago | (#5326897)

it's just that they never listen.

You're supposed to write the manual first, with the users, flesh out the help screens, write psuedo code, then code. Coding is 20% of billing.

No manager is going to tolerate that, s/he wants to see working code before the first payment is made, and lots of it. After the users complain that nobody asked them, you go back and modify it. You never get around to doing the manual, and help consists of your support contract soothing confused users.

This is why software sucks. Ask the lusers who are stuck with Results/Plus, Paradigm, or any other vertical market app.

Re:Scrum? (0)

Anonymous Coward | more than 11 years ago | (#5326974)

Yeah, if it weren't for those damn users and management, software development would be perfect...

You don't know Slashdot (-1, Flamebait)

Anonymous Coward | more than 11 years ago | (#5326217)

Anyone and everyone on Slashdot probably knows that business-driven software development efforts all too often end up as a mess.

Feh - who are you kidding? Slashdot is comprised of about 90% pock-faced, communist, unemployed teenagers with superiority complexes and about 10% normal tech workers. The only thing that "anyone and everyone on Slashdot" knows is that the MPAA and RIAA are "evil".

Axis of Evil? (-1, Flamebait)

bildstorm (129924) | more than 11 years ago | (#5326276)

So I guess maybe the MPAA and RIAA would be considered to be the Axis of Evil around here?

Of course, I don't know how many people on here are teenagers. Haven't many anyone pock-faced here, definitely no communists, but because of poor business models, I've met plenty of unemployed.

Methodologies (2, Insightful)

j_kenpo (571930) | more than 11 years ago | (#5326224)

Sounds like an interesting book. I'm always on the lookout for good books on program design methodologies and software development strategies. I've come across a few for OOAD and a using the Rational Unified Process that have caught my attention within the past three years (the titles of the two books escape me at the moment). Although neither are as heavily referenced as some of my programming books, they still had a good mind set for development life cycles and methodologies that I've used in projects that I'm working on, both large and small. Then I've read some total dogs that really sucked, such as System Analysis and Design Methods from McGraw-Hill. Although it had a few (and I mean very few) good points, most of the book was regurgitation of the garbage that they summarize in the first few chapters. The only thing that I'd give a plus is the follow along of a new analyst in a developing system and the interactions he has with the development team (which after about 3/4 of the book, I ended up just reading those, after all, it was kind of nostalgic to remember what it was like to be so eager to jump into a project that you'd spout out technologies and algorithms when you meet a customer for the first time, only to have them look at you real funny and have no clue what your talking about). Id be interested to hear what books the rest of the Slashdot community would recommend as real jewels on this subject.

other recommendations (was Re:Methodologies) (2, Informative)

grey1 (103890) | more than 11 years ago | (#5326391)

"The Mythical Man Month" is old, and isn't yet another methodology that washes whiter than white. But it's small, easy to read, and needs reading by most people involved with managing software development. Then they won't believe that getting more developers will lead to faster development.

Or maybe I'm making a mistake - maybe all of you have read this already...

[Fred Brooks, ISBN for my edition = 0-201-83595-9, details on amazon [amazon.com]]

Re:other recommendations (was Re:Methodologies) (1)

j_kenpo (571930) | more than 11 years ago | (#5326698)

Actually I had, and this is an excellent recommendation. I had forgotten about it, even though I probally shouldnt have, definitly a good one to keep in mind.

Re:other recommendations (was Re:Methodologies) (1)

bADlOGIN (133391) | more than 11 years ago | (#5326834)

"The Mythical Man Month" should be required reading for anyone attempting to manage a software project. Working for a manager who says they've never heard of the book is one of my personal danger flags:)

For the life of me (4, Insightful)

Bob Abooey (224634) | more than 11 years ago | (#5326240)

I can't help but think all this is just one giant mind fuck. The IT industry is such a volatile industry that seems to love to be lead around by the nose and is greatly influenced by the flavour of the month.

Why not try to take a look at some of the long time methods used by engineering industries to see how they go about designing bridges and cars and stuff like? Do you think that GM people stand around and talk about Extreme Engineering for their engineers who design high tech engines?

Re:For the life of me (5, Insightful)

Linux Ate My Dog! (224079) | more than 11 years ago | (#5326407)

Why not try to take a look at some of the long time methods used by engineering industries to see how they go about designing bridges and cars and stuff like?

I live in Boston, home of the Big Dig. Right now is not the best time to impress me with construction as a model for controllable effective on-time on-budget engineering of large-scale projects.

In fact, we get to hear this a lot as software engineers "Look at construction! They got it right!" Well, of all big construction projects I remember (Betuwe tunnels in the Netherlands, Stopera in Amsterdam, Big Dig in Boston) went into time and costs overruns, often by 100 to 400% on either variable.

And then there is my bathroom which I had remodelled a year ago, and the stories of my hoemwoner friends who did the same. On time? On budget? Don't make me laugh. Go do the rounds among people who have had remodelling done: horror story after horror story. Construction people were like software engineers in the dot-com boom: flooded with offers, so they would overbook and the customer who complained loudest would get his project done. Many sub-teams (projects, tilers) did and do not communicate, project leads are at the mercy of the scheduling of the sub-contractors, the quality os not standardised at all but incredibly variable so you have to get "lucky" with who has a slot free to do the work on your project, many of the people are overworked or "self-medicated" to deal with their stress and the conditions of labor.

I bought the whole "Look at construction!" mantra, and then I actually looked at how construction was done. These guys wing it as much as we do for the small projects, and when they can't wing it for the big ones, major shit happens like on our projects. And the old COBOL software is still running after 40 years and will keep running as long as the environment doesn't change, just like bridges stay up for decades as long as the environment doesn't radically change.

Do you think that GM people stand around and talk about Extreme Engineering for their engineers who design high tech engines?

Actually, yes, these people are constantly re-evaluating their process because their time-to-market requirements are constantly getting tighter and tighter. Just read Business Week for six months and follow the changes in the auto industry through their articles: they are all about faster, faster, and listen-to-the-customer constant process-reengineering, with CEO ans design heads being hired and fired depending on how well they can make theri human- and machine-assembly-lines line up and fire.

Re:For the life of me (3, Informative)

pmz (462998) | more than 11 years ago | (#5326893)

Actually, yes, these people are constantly re-evaluating their process because their time-to-market requirements are constantly getting tighter and tighter. Just read Business Week for six months and follow the changes in the auto industry through their articles: they are all about faster, faster, and listen-to-the-customer constant process-reengineering, with CEO ans design heads being hired and fired depending on how well they can make theri human- and machine-assembly-lines line up and fire.

The difference is that the auto industry takes this stuff very seriously and there is often committment from the top executives on down. They incorporate their engineering practices as a core part of their business. They understand the value of engineering and good processes.

The same is far from true in most software firms. Many software engineering managers are just transplants from other parts of the company. They often have little experience or training. They often think in terms of buzzwords rather than fundamental concepts. They often screw up.

Re:For the life of me (1)

PincheGab (640283) | more than 11 years ago | (#5326455)

Why not try to take a look at some of the long time methods used by engineering industries to see how they go about designing bridges and cars and stuff like?

Here you open up a can of worms: First of all, traditional engineering solves much simpler problems that IT: Build a bridge that will support 100 tons, will last 50 years, and will be 100 feet wide. Pretty simple, huh? Will the specs change? Still the problem is pretty simple. Build a high-rise? Still pretty simple and straight forward.

IT has to meet demands not made of traditional engineers: Have you ever seen a 60-story high rise get an additional 30 stories added on? Now, how many computer system do you know that have had a 50% increase in load/features/etc...?

As for development methodology: Traditional engineering principles have been around for hundreds if not thousands of years. Humanity has been building and designing physical things for a great many years. IT is very much new. Not only are the demands increasing, but the underlying technology is changing as well, and very rapidly at that.

The systems we are building are very complex, and the systems we build are much more central to businesses (ie, which is more important to a business, the building it's housed in, or the IT system that it uses?). Add to that the volatile goals of IT systems and you have a monumental problem. It is not a "mind fuck," it is people trying to make change an integral part of systems development. In the face of changing systems requirements, you cannot simply develop an outdated solution because "that's the way it was planned."

Re:For the life of me (2, Interesting)

Derkec (463377) | more than 11 years ago | (#5326587)

This really isn't a fair comparison. GM's engineers make releases every year at the same time. They tend to make only incremental changes to their previous designs. Because of this, they can only react to changing customer\marketting requests at these intervals. Also, there is little room for manevour after release so things pretty much have to be right before wide release. Patches are expensive, difficult and their need may have killed people. Therefore, serious testing has to have happened before a true release.


Wait a sec....


Incremental and regular releases, insulation from changing requirements, lots of testing... kinda sounds like what the XP guys want us to do with software. We just have to have much tighter iteration periods.


Seriously though. We are talking about differant engineering tasks. Some methodologies might transfer with only a little modification, but most won't.

Re:For the life of me (5, Insightful)

Furry Ice (136126) | more than 11 years ago | (#5326634)

Do you think that this has never been thought of? This is how software development started. It was abandoned because it does not work. Much of the research in software engineering has simply tried to identify the things which make software engineering so much different from conventional types of engineering.

In the Mythical Man Month, Fred Brooks identifies the "essential difficulties" of software development as complexity, conformity, changeability, and invisibility. I'll explain each of these terms.

  • Complexity: Software does not benefit from repetition. Many other forms of engineering benefit from being able to repeat small elements or scale them into larger elements to scale the project. In software, reptition is eliminated as much as possible through functions and procedures. Scaling-up a software project necessarily involves increasing the number of distinct components. As the number of components increases, the number of possible states and interactions between those components increases non-linearly. It's also important to note that this complexity is the essence of the software. Creating a simplified model of the software is generally useless, unlike in physics.
  • Conformity: The complexity of a software system often stems from the need to conform to arbitrary constraints (the beloved "Requirements" document). Software needs to interface with external systems, software, formats, and rules, all of which are specified without rhyme or reason. This complexity cannot be removed through any design decision.
  • Changeability: Software is under constant pressure to change because it is easier to change than physical, manufactured products. People have an inherent understanding that they cannot ask for a complete redesign of a bridge. Their lack of understanding of software development does not keep them from asking for software changes which may require a complete redesign, however.
  • Invisibility: This one is a little hard to explain, but is closely related to complexity. Software systems are so complex that a useful, comprehensive graph or diagram of them cannot be created. UML diagrams are cute, but you need several different types of them to be able to see the whole picture, and any diagram for a reasonably large system with one type of view of all it's interactions would be ridiculously huge. Couple this with the fact that you need many such diagrams, some of which are not even planar (difficult or impossible to represent in 2 dimensions), and you start to see the problem. The human mind has very powerful visual processing; the engineer gains much by being able to visualize her system. While other types of engineers are able to visualize their systems, unfortunately, software developers cannot.

Re:For the life of me (0)

Anonymous Coward | more than 11 years ago | (#5327136)

Functions are precisely repitition. The implementation of them is simply factored out, in order to simplify the problem and provide a single point of failure and alteration. An advantage not particularly provided to the physical engineering disciplines.

Almost no software providers practice Software Engineering. Frankly they don't tend to know what actually works or not, simply because they never attempt to provide the ethic required to actually engineer something. There are a few, mostly specialized producers, that actually attempt a process that provides correctness in implementation, but I rest assured that most of the tools responding in this thread certainly aren't even remotely familiar with using any methodology in the work place.

I would also imagine than the typical automobile, including its requisite software, is about twenty times more complex than any project you've been involved with. If you think any engineering discipline doesn't have to deal with immense complexity, have to design in conformance to immutable specifications, and provide flexibility for the future, you're one delusional pup.

Re:For the life of me (1)

Jerf (17166) | more than 11 years ago | (#5326693)

Ditto on the other three replies as of this writing pointing out that the construction industry is far from paradigmatic, but also:

Do you think that GM people stand around and talk about Extreme Engineering for their engineers who design high tech engines?

Actually, while I'm sure it wouldn't be called "Extreme Engineering" I would not be surprised that they take a bit more experimental approach to engine design, now that it's all in a computer that can reasonably accurately simulate the effects of various design choices.

Times have changed in the automotive industry. The "waterfall"(-analog) model in the "old days" was forced on them, with an engine design and a few prototypes at best before shipping. Now an engineer can change one component and find out what happens. I suspect they don't use the "waterfall" either anymore, in favor of something a bit more "agile".

Re:For the life of me (1)

photon317 (208409) | more than 11 years ago | (#5327155)


I agree. I still think books like this one are interesting to read, as they help you think about the problem, but essentially the Software Development problem comes down to these simple points, IMHO:

1) Talent - Get talented guys. Programming talent almost really can't be taught, find the "naturals". If you can't find talented programmers, and you're left with the random industry jerkoffs, then resign yourself to a slow process with buggy software.

2) Make them happy - Programmers who are asked to work 80 hour weeks for 40 hour salaries while expecting a layoff at any time between tommorow and 6 months out don't do good work. Increase their quality of life, and they do better.

Other than that, you can spout all the techno-babble you want about software development and it doesn't change a damn thing.

Re:For the life of me (0)

Anonymous Coward | more than 11 years ago | (#5327322)

Looking too closely at physical engineering techniques and practices, in an attempt to improve software development, is a waste of time. Lots of people have tried, and aside from basic management practices, there is nothing there.

What is really needed is (A) experienced programmers, who know how to use tested libraries for maximum benefit, to solve their individual programming tasks and (B) managers that are familiar with programming and know how to manage the programmer type.

XP is a great SD technique, but programmers and managers have to buy into it for it to be truly successful.

Scumm (-1, Offtopic)

worst_name_ever (633374) | more than 11 years ago | (#5326248)

Yeah, those old LucasArts Scumm(tm) games were awesome! I wasted a huge portion of my teen years playing Monkey Island, Maniac Mansion, Day of the Tentacle, and Fate of Atlantis.

What? Oh, Scrum. Nevermind then.

Huh? (2, Funny)

NFW (560362) | more than 11 years ago | (#5326265)

Anyone and everyone on Slashdot probably knows that business-driven software development efforts all too often end up as a mess.

Seems to me that "end up as a mess" describes software efforts in general, no matter what drives them.

Great... (-1, Flamebait)

ggambett (611421) | more than 11 years ago | (#5326269)

Yet another metodology that addresses the fundamental flaws of the last 20 years of software engineering. Another book that makes a subtle but vital revelation about the nature of software projects and how to better run them. Another simple but profound book.

What would be of us if the Jedi Code Masters and Tibetan Monks didn't write this kind of book... once or twice in a month!

Master the Tao, all else will follow (5, Insightful)

arvindn (542080) | more than 11 years ago | (#5326312)

After a number of years of observation, research, and fine tuning, Ken Schwaber and Mike Beedle have released a book that makes a subtle but vital revelation about the nature of software projects and how to better run them.

They have discovered that the Tao [canonical.org] is the heart of all programming.

Hark, the master speaks:

A novice asked the Master: ``Here is a programmer that never designs, documents or tests his programs. Yet all who know him consider him one of the best programmers in the world. Why is this?''


The Master replies: ``That programmer has mastered the Tao. He has gone beyond the need for design; he does not become angry when the system crashes, but accepts the universe without concern. He has gone beyond the need for documentation; he no longer cares if anyone else sees his code. He has gone beyond the need for testing; each of his programs are perfect within themselves, serene and elegant, their purpose self-evident. Truly, he has entered the mystery of Tao.''


A novice asked the master: ``I have a program that sometime runs and sometimes aborts. I have followed the rules of programming, yet I am totally baffled. What is the reason for this?''

The master replied: ``You are confused because you do not understand Tao. Only a fool expects rational behavior from his fellow humans. Why do you expect it from a machine that humans have constructed? Computers simulate determinism; only Tao is perfect.

``The rules of programming are transitory; only Tao is eternal. Therefore you must contemplate Tao before you receive enlightenment.''

``But how will I know when I have received enlightenment?'' asked the novice.

``Your program will then run correctly,'' replied the master.

Learning what Scrum is and how to practice it is not all that profound. However, sitting back and realizing why Scrum works and how it addresses the fundamental flaws of the last 20 years of software engineering is.

Once you obtain that realization, you will have truly mastered the Tao.

Re:Master the Tao, all else will follow (0, Offtopic)

ken_mcneil (90642) | more than 11 years ago | (#5326456)

Ahh...modded up as insightful when it's clearly a joke. It is clear to everyone here that this is a joke right?!

Perhaps this is just confirmation of my long held suspicion that there are people out there with the "All I ever needed to know about programming I learned from /. and when I grow up I want to be a caffein addicted code cowboy" attitude. Truly...deeply...scary. You should all be ashamed of yourselves.

Re:Master the Tao, all else will follow (4, Insightful)

TerryAtWork (598364) | more than 11 years ago | (#5326622)

See, here's the problem.

Programming is still an ART, not a science.

When you hire a coder it's like hiring a poet. You never know what you'll get and everyone wants the other guy to have paid for the coder's learning experiences.

This is hunting and gathering. We haven't hit agriculture in the geek business yet.

Re:Master the Tao, all else will follow (1, Insightful)

Anonymous Coward | more than 11 years ago | (#5326926)

Uh - if you employ a scientist, you never know what you'll get and everyone wants the other guy to have paid for her learning experiences.

And farmers aren't poets.

Tao epigrams (in print) (0)

Anonymous Coward | more than 11 years ago | (#5327444)

Oh wise programmer, I see that you also have been reading "The Tao of Programming" [amazon.com]by Geofrrey James (ISBN 0-931137-07-1). Sharing wisdom and giving credit is the open source way to true enlightenment.

"A program should be light and agile, its subroutines connected like a string of perls."

Totally Useless (5, Informative)

Peter_Pork (627313) | more than 11 years ago | (#5326318)

I glanced at this book before, and I found it totally useless. The few ideas presented are already well-known facts about software engineering, heavily adorned with buzzwords like extreme programming and agile software. I did not see a single idea that was not present in Fred Brooks' "The Mythical Man-Month", that was written back in the 70s. Do not waste your time with this: I'd much rather read a classic, timeless work on project management and its challenges that this scum. If you want to look at contemporary, more applied works, I recommend Steve McConnell's "Rapid Development" and "Code Complete".

"How" eXtrEmE pRogrAMming destroyed my project (5, Informative)

Anonymous Coward | more than 11 years ago | (#5326337)

I've worked with XP on 2 projects and more normal "MSF"-like approaches for about 7 projects. (The remaining ones were kind of unmanaged to begin with, which is the pits)

Anyways, XP doesn't work. Proponents like to say that XP is high throughput, but I just don't see it. At my last job (where XP was employed) programmers had to put in long hours, despite this being against XP tenet. This resulted from abbreviated design cycles and hit-and-run feature development.

We like to talk about agility and mentally substitute quick hack jobs as a way of limiting cost overrun when features change midcourse (which they often do). What XP people don't tell you is that XP encourages these features to be hacked in (simplest thing possible, remember?) without regard for how it might be later removed with little effort.

In other projects where features were designed and implemented with a good degree of modularity, that feature was canned or changed, yet we were able to extricate it with little effort - simply by #defining it out or by not shipping the modular DLL it resides in. In comparable XP-driven projects, I've been told "No, modularizing it is not a requirement. Do the simplest thing - add whatever you need to the existing classes and just do it."

In XP, implementation is cheap up to a certain point where suddenly refactoring becomes imperative. Refactoring is then a very painful process given a very short iteration cycle. You won't find an XP shop that will encourage modularity over implementation time. But, like anything, the biggest gains come from pacing and managing, not from writing as much code as possible in a short amount of time.

Ok, so now you say that pair programming compensates for the short design cycles. Get real - no one really does this because this, too, does not work. Most programmers are like any other people - they can be tempermental, stubborn, selfish, and proud. The worst part is, the younger and more inexperienced the engineer, the less willing he is to accept other points of view. Try working with that. You can't.

Where XP excells is late stage bug fixing, where hit-and-run is definitely the right strategy.

Re:"How" eXtrEmE pRogrAMming destroyed my project (5, Interesting)

tcopeland (32225) | more than 11 years ago | (#5326450)

> Do the simplest thing - add whatever you need
> to the existing classes and just do it."

Hm, that doesn't sound XPish. XP says to refactor as you go. So when you add some code and things are getting complicated, refactor to make it simple.

> You won't find an XP shop that will
> encourage modularity over implementation time.

"Modularity" can be taken to extremes, too:

int x = IntegerFactory.createInteger("5").toInt();

> Most programmers are like any other
> people - they can be tempermental,
> stubborn, selfish, and proud.

Yup, just like anybody else. But how will these people ever improve their interpersonal skills if they don't work with other people?

> Where XP excells is late stage bug
> fixing, where hit-and-run is definitely
> the right strategy.

If you do XP all the way through, the pair programming, short iterations, and especially the unit tests will minimize the "late stage bug fixing". You did have unit tests, right?

Yours,

Tom

Re:"How" eXtrEmE pRogrAMming destroyed my project (2, Insightful)

fliesd (200144) | more than 11 years ago | (#5326586)

So with out doing all the pieces of XP. Having a horrible attitude about working with others, and not trying to do refactoring through out every stage of development. All while working overtime.

It is not a wonder why you have faild and I'm pretty sure it is not XP's fault.

If you use XP in a hit-and-run fashion you'll get hit, and management will dive off, leaving you to blame XP.

Re:"How" eXtrEmE pRogrAMming destroyed my project (0)

Anonymous Coward | more than 11 years ago | (#5326617)

The pair-programming aspect is the core of XP - all the rest is secondary, in my experience.

You're only doing XP if you pair-program. Pair-checkin isn't too bad, either, but at code-write-time is better.

If pair programming isn't working for you, remember that "the only constant in all your dissatisfying relationships is you", and change your attitude.

Re:"How" eXtrEmE pRogrAMming destroyed my project (2, Insightful)

Anonymous Coward | more than 11 years ago | (#5326649)

I've worked with XP on 2 projects and more normal "MSF"-like approaches for about 7 projects. (The remaining ones were kind of unmanaged to begin with, which is the pits)

Anyways, XP doesn't work.


Data is not the plural of anecdote.

Re:"How" eXtrEmE pRogrAMming destroyed my project (0)

Anonymous Coward | more than 11 years ago | (#5326683)

XP does not say that each feature should necessarily be hacked in. When a programmer adds a feature in the simplest way possible, then it is followed by refactoring to attain the primary goals that the system should be as simple as possible and that the programmers should not repeat themselves.
XP does not say: implement each story as atomically, ignoring the rest of the system.

Re:"How" eXtrEmE pRogrAMming destroyed my project (2, Insightful)

Wojina (125814) | more than 11 years ago | (#5326846)

Anyways, XP doesn't work. Proponents like to say that XP is high throughput, but I just don't see it. At my last job (where XP was employed) programmers had to put in long hours, despite this being against XP tenet. This resulted from abbreviated design cycles and hit-and-run feature development.
I'm not an XP expert who has experienced radical success with this methodology. I'm just a developer that tries to maintain a broad perspective on software development. However, I have yet to meet a person who claims to have done XP that actually did XP when you got right down to it. The XP methodology is a package deal. You can't just pick and choose a few ideas from it and call it XP. One company I worked with claimed to be doing XP because they didn't spend any time on design...nevermind the fact that they didn't practice test-driven development, refactoring, pair programming, or user stories.
In XP, implementation is cheap up to a certain point where suddenly refactoring becomes imperative. Refactoring is then a very painful process given a very short iteration cycle. You won't find an XP shop that will encourage modularity over implementation time. But, like anything, the biggest gains come from pacing and managing, not from writing as much code as possible in a short amount of time. Ok, so now you say that pair programming compensates for the short design cycles. Get real - no one really does this because this, too, does not work. Most programmers are like any other people - they can be tempermental, stubborn, selfish, and proud. The worst part is, the younger and more inexperienced the engineer, the less willing he is to accept other points of view. Try working with that. You can't.
So now you're telling me that refactoring was not a priority on your team and that you didn't practice pair programming. Let me also assume that you didn't practice test-driven development, either. You might even have written a few tests, but I'm willing to bet that you didn't develop a full test suite. Did you practice continuous integration? Did you run your unit tests after each build, and did you consider your task complete when your tests passed? My guess is no because it's pretty clear that you tossed out key fundamental aspects of XP because you didn't think they could work in the "real world".

Here's a new reality for you:

Any developer who can't get over his stubborn, selfish, and proud nature to work closely with another peer is not worth hiring.

I'm not saying it won't be difficult for some people, but anyone that wants to can make it work (much like marriage). As to accepting other points of view, my experience is quite the contrary. The younger, inexperienced engineers that desire to improve look to the experienced engineers for advice, and they seek opportunities to work with them. The sad reality is that the more experienced someone is, the less likely that they'll accept the input of others. They've already decided how things work. Clearly, you've arrived.

Re:"How" eXtrEmE pRogrAMming destroyed my project (3, Insightful)

Sharkeys-Day (25335) | more than 11 years ago | (#5327106)

programmers had to put in long hours

That's not XP. XP forbids long hours for more than a week, because you can't write good code when you are tired, overworked, and have low morale.

Do the simplest thing - add whatever you need to the existing classes and just do it.

That's not XP either. XP says do the simplest thing, but specifically does NOT define "simplest" as "least time to implement". The simplest thing in XP is a compromise between least time and least code, with the specific condition that code is not allowed to be duplicated. The least time solution is often "copy this function and modify it for my needs". The XP solution is "refactor this function so I can use it too". This means you are doing small refactorings throughout your project, and modularity appears wherever it is needed.

Refactoring is then a very painful process

Refactoring is painful if you are not confident that the changes will work. If you are not confident, it is because you do not have a full automated testing suite. Let me guess... you aren't doing that either?

pair programming ... no one really does this because this

You tell us about all the parts of XP that you don't do, and then you complain that it does not work. Building a brick wall without mortar won't work either, but it's not the brick's fault.

People way more significant that methodology (5, Insightful)

Boss, Pointy Haired (537010) | more than 11 years ago | (#5326338)

In my 10 years software development experience, I've come to the conclusion that people are by far the most significant factor in the success or otherwise of a project.

In fact, I believe that people are so significant that they make the use or otherwise of any particular "methodology" an irrelevant ingredient in determining the outcome of a project.

Good coders will produce good results with or without methodology.

Average / below average coders will produce average or below average results with or without methodology.

Trouble is, it is impossible to test this theory experimentally; you just have to believe it :)

I think.

Re:People way more significant that methodology (2, Interesting)

Strigiform (240409) | more than 11 years ago | (#5326446)

Your experience matches that of the science-fiction writer Gene Wolfe (a retired engineer) who said something to the effect that people were the most difficult part of engineering.

Re:People way more significant that methodology (1)

PincheGab (640283) | more than 11 years ago | (#5326531)

Good coders will produce good results with or without methodology

Ahh, but are they not "good" because they employ a methodology that works? You cannot build software without following some methodology. If you sit down and start coding, that's a methodology in itself. There's always methodology.

Re:People way more significant that methodology (1)

Boss, Pointy Haired (537010) | more than 11 years ago | (#5326567)

Ok, perhaps what I meant was "Methodology X".

If you enforce "Methodology X" on a good coder, s(he) will just create a wrapper for their own personal methodology within Methodology X.

Re:People way more significant that methodology (1)

PincheGab (640283) | more than 11 years ago | (#5326606)

Hehe, that sounds like an old, conservative fart! Maybe that's why I find going back to college for a postgrad so exciting: No stodgy old closed minds!

Re:People way more significant that methodology (2, Funny)

swillden (191260) | more than 11 years ago | (#5326623)

Maybe that's why I find going back to college for a postgrad so exciting: No stodgy old closed minds!

Everyone knows there is no stodgy closed-mindedness in academia.

Re:People way more significant that methodology (4, Insightful)

pcraven (191172) | more than 11 years ago | (#5326579)

Good coders have their own methodology. The key is that they do not follow a methodology just for the sake of the methodology, but they understand what works.

Programmers who recently are introduced to patterns are amusing to watch. They see the patterns, and try to apply them to the problem. But the correct solution to a problem will naturally imply some sort of pattern. Pattern books are useful only in adding to a programmers experience. Here is a problem. Here is a good solution. But don't try to apply our solution to your problem, as your problem will always be a bit different.

Another way to state: People who are good at brain-teasers are usually good at figuring out problems in real life. But rarely do the brain teasers mirror real life.

The other key to success is some good management. Good programmers can get by with mediocre management. But even a team of crack developers will fail with bad management. When you go into a job, always make sure the management is strong. Otherwise you may just be wasting a few months or years of your life.

Re:People way more significant that methodology (0)

devinjones (13739) | more than 11 years ago | (#5327237)

Alistair Cockburn wrote about this in Characterizing People as Non-Linear, First-Order Components in Software Development [crystalmethodologies.org] Here are some excerpts:
"This is a report from experience, from reviewing roughly three dozen projects and methodologies over 20 years."

What I find striking about these projects is that they show:

  • Almost any methodology can be made to work on some project.
  • Any methodology can manage to fail on some project.
  • Heavy processes can be successful.
  • Light processes are more often successful, and more importantly, the people on those projects credit the success to the lightness of the methodology.
When I interview a project, I always ask what caused them to succeed in the end. The single most common answer I receive is, "A few good people stepped in at key moments and did whatever was needed to get the job done."
There is a lot more about the characteristics of good programmers, and how to find them and manage them successfully. I think this is a must read for any project manager.

Obligatory 'real engineer' comment (4, Funny)

kahei (466208) | more than 11 years ago | (#5326339)

Hi,

Why can't software be more like [real engineering field]? Nobody messes around with [extreme programming|OOP|empiricism] in [real engineering field]! I mean, how would it be if [bridges|planes|hospital equipment] were designed like software is? Books like this just make me realize that [software engineering is not real engineering|my branch of engineering is harder and therefore better|OOP is all a myth and everything should be in FORTRAN].

Yours truly,

[crusty old engineer|enthusiastic young engineering student|idiot]

optional: P.S. the term software 'engineering' is a misnomer

Methods are nice... (1)

TopShelf (92521) | more than 11 years ago | (#5326350)

But rock-solid commitment to development efforts by the business users seems to the biggest risk in IS projects from my experience. The two most prominent user attitudes I've run into are:

1) It's a systems thing, so I don't really need to know the details, and
2) I'm too busy to get involved with this effort, even if it means a total redesign of my job.

arrrrggggghhhh....

Judge them by their work... (4, Informative)

NigelJohnstone (242811) | more than 11 years ago | (#5326387)

A quick search on google reveals their past work:

"Ken Schwaber is a Senior Consultant with Cutter Consortium's Agile Project Management Practice and is an experienced software developer, product manager, and industry consultant. He has been in the industry for more than 30 years, starting as a programmer and, by 1984, managing IT for one of Wang's divisions. In 1985, Mr. Schwaber founded Advanced Development Methods (ADM), a company dedicated to improving the software development practice. He initiated the process management product revolution of the early 1990s, when methodologies were automated and put to practical use on ADM's Mate process manager...."

So basically a software development manager for failed Wang that went on to make a company that tells other people how to run projects.

and Mike Beedle:
http://www.mikebeedle.org/
Runs two businesses, started out as a Lasers expert in 93, then in 94 switched to writing books on programming, judging by his papers.

Guys, if you post PR puff like this on Slashdot don't you think people will check if you know what you're talking about?

Obligatory 'real artist' comment (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5326405)

Hi,

Why can't software be more like [real artistic field]? Nobody messes around with [extreme programming|OOP|empiricism] in [real artistic field]! I mean, how would it be if [paintings|songs|monuments] were designed like software is? Books like this just make me realize that [software engineering is not real engineering|my branch of art is harder and therefore better|OOP is all a myth and everything should be in FOURTH].

Yours truly,

[crusty old artist|enthusiastic young art student|idiot]

optional: P.S. the term software 'artistry' is a misnomer :)

No Silver Bullet (1, Insightful)

xyote (598794) | more than 11 years ago | (#5326452)

We've already known why software development is screwed up, and known that for 25 years. Any new book that can't articulate what the known problems are and exactly how the new technique addresses some of those problems is a complete waste of time. And any reviewer who can't convey in his review whether the book is addressing some of these issues is completely wasting our time.

Re:No Silver Bullet (0)

Anonymous Coward | more than 11 years ago | (#5326771)

Software engineering is easy to understand. What I don't understand is how many different books regurgitate what everybody knows already, but with frilly words and fluffy diagrams attached to them...

My golden rules are :

1. Always overestimate the time and cost of a project. Usually you will be spot on.
2. It wont work the first time, so get realistic.
3. It might not work after the 5th time either!
4. Test to destruction, not just general light usage.
5. Educate managers to expect problems as a normal day to day occurance and get them off software cloud 9.

Schwaber consulted at an ex-employer of mine... (2, Informative)

Croaker (10633) | more than 11 years ago | (#5326463)

The whole Scrum thing was a major change of pace for the company I used to work for. They had just "re-engineered" the company, and extreme programming was the next "in" thing for executives to do, so they hired on a new VP (nothing gets done in a company like this without a new VP to manage it) and that VP brought in Scwaber. Apparently, the guy was a real jerk, and there was major friction between him and the rest of the company. One person I know who actually worked with him called him 'a cancer' and claimed he connived to get people fired, including one manager whose job he coveted. From what I was told, Schwaber himself actually got fired over that.

Scrums worked out OK, overall. Since I was not a developer, the daily meetings actually were good for me, because that's when small issues that I needed to know about usually got hashed out. Not being a developer, I can't say much beyond the daily meetings on how scrum worked out.

I transition out of development about 6 months after scrum was introduced. There were major morale issues at the company, and about a year and a half later I finally left to a small startup. It's hard to untangle how scrums worked out in the environment where there were many other issues negatively affecting the company. Lots of stupid decisions, lots of idiot executives. The group I was in just before leaving the company was laid off entirely a month later. Then they freaked out and rehired several people, with back pay and huge pay increases, because they realized after the fact they couldn't get along without them. The company has survived, and its stock has actually gone up in the past year.

Please mod the above down (1)

Croaker (10633) | more than 11 years ago | (#5326597)

You know what, it was inappropriate of me to spread rumors about that guy. Please do me a favor and mod the above down...

Re:Schwaber consulted at an ex-employer of mine... (1)

daviskw (32827) | more than 11 years ago | (#5326797)

I've had the daily meetings. I hate the daily meetings. They are useless and a waste of time. I now spend that time thinking "I should have made it to the meeting." It is a much better use of time.

Our daily meetings go like this: Everybody goes around the table. Each person says what they did yesterday, what they plan on doing today, and are there any impediments.

My scrum statements:
"Yesterday I worked on [blah]. Today I am going to work on [blah]. No impediments." Now there is something useful.

Re:Schwaber consulted at an ex-employer of mine... (1)

pmz (462998) | more than 11 years ago | (#5326921)

the daily meetings actually were good for me

Ugh, nothing is worse than wasting the equivalent of a whole day per week in meetings. They never last "just fifteen minutes," and the result is often a ad-hoc design-by-committee project, where no one has the guts to commit to anything.

punctuation (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5326471)

bADlOGIN should learn how to use colons correctly. (Colons as in the punctuation mark ':'. Not the goatse 'O' .)

perhaps a better book (2, Insightful)

f00zbll (526151) | more than 11 years ago | (#5326559)

would be "how to convince management and HR to hire good people and not bodies." It's been said time and time again by numerous people, but it all boils down to the programmer. Why then hasn't anyone written a book on how to get management to put quality of the staff first. I've worked at companies that had formal testing policies, but to be honest that doesn't work. What you end up with is a bunch of people who are good at memorizing text books, but have no practical experience. Not having a formal interview processes isn't better either. From past experience, the best people where the ones the team had no doubts. The times we hired bodies was when HR bitched and moaned and said "You guys are impossible to satisfy." Or worse, HR throws "The person you're looking for doesn't exist."

In most cases, it is better to not hire bodies. In all the cases I've seen first hand, it results it delays and problems. Not only are the good programmers bogged down with stupid questions, but they end up spending time fixing other's code. The end result is the same programmer is less productive. There really should be a book that teaches programmers how to negotiate with management and how to work with HR. I've had to learn that the hard way.

Re:perhaps a better book (1)

Fulcrum of Evil (560260) | more than 11 years ago | (#5327099)

here really should be a book that teaches programmers how to negotiate with management and how to work with HR. I've had to learn that the hard way.

Yeah, I'm still learning that one. Kind of hard in some places, where management's idea of negotiation is 'my way or the highway'.

scrum? (2, Funny)

i chose quality (413813) | more than 11 years ago | (#5326572)

i thought it was the process of looking at your coded scum and drowning the rising depression in rum, which is a special technique in gonzo-programming... ;-)

There is no holy grail for development (4, Insightful)

master_p (608214) | more than 11 years ago | (#5326676)

After 3 years in full development, all I can say is that the most important part is defining good requirements; which means that the real needs have been understood well. So, the more time is spent in planning and discovering requirements, the better course the project has.

WOW!! 3 years in FULL development, huh? (0)

Anonymous Coward | more than 11 years ago | (#5326968)

That's just long enough to be considered smart by management and stupid by your co-workers. Unless your co-workers have all of 2 years experience. In that case you know it all and you're a god:)

Every small IT shop i've been at does this (2, Insightful)

192939495969798999 (58312) | more than 11 years ago | (#5326739)

and they don't call it scrum, it's called overlord-peasants. The overlord picks what to do , and the peasants do it. The trouble with scrum is that it's only as good as the overlord / manager can be, because if they are adding features that 1) take too long to implement, or 2) don't really help in the long run, then the whole process is wasted. You turn out crap really, really fast instead of turning out crap slowly... fast or slow, it's still crap.

Great! (2, Insightful)

The Bungi (221687) | more than 11 years ago | (#5326805)

software development is an empirical rather than a defined process

I wonder how far this will fly with nazi project managers. They are fairly attached to their ass-backward "methodologies", you know.

Seriously, for the record, I agree with the statement above. But this type of thing simply does not work in most IT shops. I have no problem with some sort of control over the software development process (that is, I'm not saying PMs and PDs are completely worthless) but telling them something like this will probably be useless. They don't think of software developers as artists or craftsmen, but rather as "resources" that need to be managed, cajoled and pushed to meet deadlines. Nothing more, nothing less.

Sad, but true.

I hate to sound like a broken record... (2, Interesting)

Aron S-T (3012) | more than 11 years ago | (#5326815)

Every few weeks someone posts a book here about some new "methodology" that will save the world of Software Engineering. Please write this down and stick this on your forehead. Then have your pair programmer read it to you once in a while:

1. Programmers are not engineers
2. Programming is a human-centric activity
3. There are no "silver bullets"
4. Agile methods are useful only to the extent that they remind us of everything Fred Brooks already said.

Read here [shtull-trauring.org].

for the fragile business! (0)

sniggly (216454) | more than 11 years ago | (#5326827)

Where did I see this ad for software for the fragile business? ID software? Quake3 arena?!! What's agile? when you can frag-ile them more rapidly than your peers. It's agile to sell to them fragile-minded business people a package, software with a membership fee that will be a drain on their resources. It's software for the fragile business so that competitors with the agile OS can slam dunk em off the market with lower prices... agile software development.. what a buzzword! Maybe its GOOD but why use a tainted term?

Next Book... (2, Funny)

BigBadBri (595126) | more than 11 years ago | (#5326866)

Bloated Software Development with Rolling Maul

Describes how to generate useless bloatware using techniques derived from the favoured tactics of the front row - futile, irritating and devoid of any entertainment value.

Sumbitter doesn't know rugby (2, Funny)

illtud (115152) | more than 11 years ago | (#5327056)

The name Scrum was chosen because the process is similar in nature to rugby play where success is built upon being quick, adaptive, and self-organizing.


quick, adaptive, and self-organizing?? Have the authors ever met rugby forwards?

Ken Schwaber in Seattle 18 Feb (2, Informative)

imnoteddy (568836) | more than 11 years ago | (#5327180)

For those of you in the Seattle area Ken Schwaber will be presenting a talk entitled
"Agile Processes and the Scrum Methodology" at the meeting of the Seattle Java Users Group [seajug.org] at 7 PM tonight.

No. Ken Schwaber presentation has been canceled (0)

Anonymous Coward | more than 11 years ago | (#5327247)

Check the newsgroup. He can't make it because of the snow storms on the east coast. He's stuck in Boston at the moment...

It's all about the people (2, Insightful)

slantyyz (196624) | more than 11 years ago | (#5327414)

My last company's advertised methodology was SCRUM. We told all of our customers we used it, and management even convinced themselves that we were using it.

The funniest thing is that SCRUM isn't necessarily a bad model, it's the people who think that it's a quick fix to their process that is the problem.

These KISS methodologies seem pretty hard to screw up, but when you have a team constructed of the wrong people (micromanagers, pigheads, and big-methodology freaks), it's a recipe for failure. Because of the team composition (and team member apathy for that matter), our sprints rarely (if ever) yielded the expected or desired results.

The thing I couldn't stand the most about SCRUM, however, was the silly terminology lifted from rugby. Sports metaphors in a field dominated by nerds? Ugh.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...