Forgot your password?
typodupeerror
Programming Books Media Book Reviews IT Technology

Agile Software Development with Scrum 168

Posted by timothy
from the don't-break-your-nose dept.
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."
Agile Software Development with Scrum
author Ken Schwaber and Mike Beedle
pages 158
publisher Prentice Hall
rating 9/10
reviewer bADlOGIN
ISBN 0130676349
summary This book could be viewed as the Why component to all of Extreme Programming's Hows. It explains managing software development as an empirical process.

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.

This discussion has been archived. No new comments can be posted.

Agile Software Development with Scrum

Comments Filter:
  • What is Scrum? (Score:5, Informative)

    by Anonymous Coward on Tuesday February 18, 2003 @11:41AM (#5326157)
  • by MondoMor (262881) on Tuesday February 18, 2003 @11:47AM (#5326202) Homepage Journal
    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.
  • Totally Useless (Score:5, Informative)

    by Peter_Pork (627313) on Tuesday February 18, 2003 @12:04PM (#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".
  • by Anonymous Coward on Tuesday February 18, 2003 @12:07PM (#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.
  • Less heavy going (Score:4, Informative)

    by tarquin_fim_bim (649994) on Tuesday February 18, 2003 @12:08PM (#5326343)
    Is a piece by Mountain Goat Software [mountaingoatsoftware.com], they explain things with pictures, much better for us simpletons.
  • by NigelJohnstone (242811) on Tuesday February 18, 2003 @12:15PM (#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?

  • by grey1 (103890) on Tuesday February 18, 2003 @12:15PM (#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]]
  • by Croaker (10633) on Tuesday February 18, 2003 @12:24PM (#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.
  • by pmz (462998) on Tuesday February 18, 2003 @01:30PM (#5326893) Homepage
    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.
  • by imnoteddy (568836) on Tuesday February 18, 2003 @02:05PM (#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.
  • by Norman Lorrain (11572) on Tuesday February 18, 2003 @09:17PM (#5331224) Homepage
    about Scrum tomorrow (wednesday) [ucalgary.ca]
  • by Anonymous Coward on Wednesday February 19, 2003 @01:56PM (#5336271)
    First let's realize that someone has to choose what to do.
    Second, let's realize that someone(or more) has to do it.
    Now scrum advocates having a set of features agreed upon at some level. Perhaps not detailed. Now the developers will accomplish the task(s) while protecting the system's integrity and adding logic & strength to the request. Nothing is wasted, if it isn't right then it was a good learning experience for the "overlord"

Lisp Users: Due to the holiday next Monday, there will be no garbage collection.

Working...