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.
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.
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?
All the best,
--Bob
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.
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.
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.
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.
programmers had to put in long hours
... no one really does this because this
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
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.
That the ideas presented in this book are not new, doesn't make them useless. I'd almost say on the contrary. The "soft" part of my book shelf contains
The Pragmatic Programmer
XP Explained
GoF Design Patterns
Object Oriented Software Construction (Meyer)
Software Craftmanship
Code Complete
Getting familiar with different takes on and approaches to software development has definitely made me a better developer. XP (and SCRUM and other agile methods) has a lot to offer, and a few short comings too. It is not the end all be all of software processes, but it was *the* new thing that made everyone aware of the benefits of unit testing and refactoring, even if these disciplines were not new at all. XP's two major short comings in my opinion is that it puts too much responsibility on the customer and the "simplest thing that could possibly work" does not strictly allow experienced developers to leverage their experience to solve the problem as fast as they are able. I'd like to get my hands on this book and see just how SCRUM differs from XP - I bet it will make me a better developer.