Slashdot Mirror
Agile Software Development with Scrum
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.
Scrum is a way for everyone to feel good about their job
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.
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.
They have discovered that the Tao is the heart of all programming.
Hark, the master speaks:
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.
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".
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.
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.
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.
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.