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:
  • by f00zbll (526151) on Tuesday February 18, 2003 @11:44AM (#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.
  • Scrum? (Score:2, Insightful)

    by Masa (74401) on Tuesday February 18, 2003 @11:47AM (#5326208) Journal
    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.

  • Methodologies (Score:3, Insightful)

    by j_kenpo (571930) on Tuesday February 18, 2003 @11:49AM (#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.
  • For the life of me (Score:4, Insightful)

    by Bob Abooey (224634) <bababooey@techie.com> on Tuesday February 18, 2003 @11:52AM (#5326240) Homepage Journal
    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?
  • by PincheGab (640283) on Tuesday February 18, 2003 @11:52AM (#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.

  • by PincheGab (640283) on Tuesday February 18, 2003 @11:55AM (#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.

  • by arvindn (542080) on Tuesday February 18, 2003 @12:03PM (#5326312) Homepage Journal
    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.

  • by Boss, Pointy Haired (537010) on Tuesday February 18, 2003 @12:08PM (#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.
  • by Linux Ate My Dog! (224079) on Tuesday February 18, 2003 @12:17PM (#5326407) Homepage Journal
    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.
  • No Silver Bullet (Score:1, Insightful)

    by xyote (598794) on Tuesday February 18, 2003 @12:23PM (#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.
  • by f00zbll (526151) on Tuesday February 18, 2003 @12:36PM (#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.

  • 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.
  • by fliesd (200144) <danNO@SPAMdanflies.com> on Tuesday February 18, 2003 @12:40PM (#5326586) Homepage
    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.

  • by TerryAtWork (598364) <research@aceretail.com> on Tuesday February 18, 2003 @12:46PM (#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.

  • by Furry Ice (136126) on Tuesday February 18, 2003 @12:48PM (#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.
  • by Anonymous Coward on Tuesday February 18, 2003 @12:50PM (#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.
  • by master_p (608214) on Tuesday February 18, 2003 @12:56PM (#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.
  • 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! (Score:3, Insightful)

    by The Bungi (221687) <thebungi@gmail.com> on Tuesday February 18, 2003 @01:17PM (#5326805) Homepage
    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.

  • by Wojina (125814) on Tuesday February 18, 2003 @01:24PM (#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.
  • by Anonymous Coward on Tuesday February 18, 2003 @01:34PM (#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.
  • by Sharkeys-Day (25335) on Tuesday February 18, 2003 @01:55PM (#5327106) Homepage
    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.

  • by slantyyz (196624) on Tuesday February 18, 2003 @02:33PM (#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.
  • Re:Totally Useless (Score:4, Insightful)

    by pong (18266) on Tuesday February 18, 2003 @02:48PM (#5327541) Homepage
    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.
  • by William Tanksley (1752) on Tuesday February 18, 2003 @03:17PM (#5327706)
    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.

    Wow. I bet you'd also say that design is cheap, up to a certain point where testing becomes imperative. Or perhaps that implementation is cheap, up to the point where you have to integrate with the other programmers.

    Wrong. Testing, and refactoring, are imperative from day one, according to XP. Before you add code, you start with cleanly factored code; if it's not clean, refactor it until it is. Then write the first component of your design in the form of a test. Next implement the code to make that test pass. Continue writing down more of your design in the form of a test and making the tests pass.

    Once your design is fully expressed as tests and the tests all pass, refactor the code *immediately*.

    Note how testing and refactoring are intermingled with coding? If you put the testing, coding, or refactoring off till later, you'll quickly find that your work becomes painful.

    Integration should be constant as well -- the entire product should be ready to ship at least once a week, and should be built and tested in full at least once a day. If you put this off, you'll be creating work for yourself and setting yourself up for an expensive failure.

    -Billy
  • by PinglePongle (8734) on Tuesday February 18, 2003 @06:30PM (#5329752) Homepage
    unlike eXtreme Programming, which is mainly about coding.

    Scrum is all about managing the project, and in a way which matches the reality I perceive better than "traditional" models.

    I've read the book in question, and I believe in Agile methods. One of the comments above says "methodologies are nowhere near as important as people" - check out the Agile Manifesto [agilemanifesto.org]; line 1 says "we value individuals and interactions over processes and tools". Ken Schwaber (and Jeff Sutherland, who posted a reply here) are co-signatories.

    The big problem I have found with Agile methods is that often the senior management team is unwilling to relinquish the impression of control over their projects. They insist on knowing everything up front - time, scope, budget - and even if they understand the empirical nature of software projects, that sense of control is very hard to give up.

    I have found many of the "Top-down" implementations of Agile processes to be buzzword driven - the last thing you need to do Scrum is a new VP; the Scrum is intended to make the VP redundant ! I'm not surprised many people have had bad experiences with XP - the 12 practices are finely balanced, and distorting that balance (e.g. by over-emphasizing "the simplest thing that could possibly work") is a great way to ruin a project. Of course, I'm inclined to believe those organisations will struggle with any methodology; one thing Agile methodologies seem to do is draw out organisational weaknesses.

    I'm working on a project right now where we have a very agressive schedule; we are pretty sure we can code the thing, but because our average corporate decision takes longer to reach than the project's timeline, we're hitting some rough spells. The cause is the decision making process; the effect is an unhappy project. In a "traditional" project, with analysts and project managers etc. and a sizeable up-front analysis phase, our corporate weakness would be less obvious; because we're saying "decide today, we'll have working code by the end of the week", our inability to decide is highlighted.

    I'd recommend Ken's book; it's worth reading, and even if you don't agree with all he has to say, you might learn something.

How many hardware guys does it take to change a light bulb? "Well the diagnostics say it's fine buddy, so it's a software problem."

Working...