Agile Software Development with Scrum 168
| 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.
What is Scrum? (Score:5, Informative)
sounds interesting... (Score:3, Insightful)
Re:sounds interesting... (Score:4, Insightful)
In that case, no development methodology will work. The best methodology to follow is to send the team (non)member home.
Re:sounds interesting... (Score:1)
.
Re:sounds interesting... (Score:2)
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!
Re:sounds interesting... (Score:2)
It's as if you're comparing two models of automobile, and insisting that the second CAN'T be better than the first, because it doesn't run underwater.
Re:sounds interesting... (Score:2)
I thought you were still commenting on the suitability of SCRUM. My bad.
Re:sounds interesting... (Score:2)
lack of promotion, or lack of substance? (Score:2, Interesting)
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? (Score:5, Insightful)
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? (Score:1)
Extreme Programming won't be labeled a fad until Microsoft gets ahold of it.
Scrum? (Score:2, Insightful)
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? (Score:5, Interesting)
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? (Score:2)
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.
And the managers keep doing this because by and large, software developers (especially less experienced ones), let themselves be walked all over. Instead of saying to their managers, "listen, this is insane, the answer is NO", they say .. "uh .. ok ..." and then proceed to work 15 to 20 hour shifts for the next few months. So you bail the manager out, get a pat on the back, and the manager walks away with the idea that he can do this again, because his hardworking, obedient developers will save him each time.
Although the economy is a bit rough at the moment, that does NOT mean that employee abuse is somehow OK. Developers, learn to "just say NO" to ridiculous expectations. Tell him straight, that you think it is just not reasonable to be able to finish the project in the specified amount of time. Work hard but work normal hours, with maybe a little overtime, and if the project still runs late, it means that not enough time was allocated. Your boss will have to answer to the client, and after this happens a few time, he will start to learn not to make insane promises to clients. If you honestly worked as hard as possible within reasonable work hours, it plain and simple is not your fault that the project ran late.
Managers abuse employees because employees let them.
Re:Scrum? (Score:2, Interesting)
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.
Empirical - IOW... (Score:1)
"We don't know what we're doing"...
"So we'll fake it"...
Methodologies (Score:3, Insightful)
other recommendations (was Re:Methodologies) (Score:2, Informative)
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) (Score:2)
Re:other recommendations (was Re:Methodologies) (Score:1)
For the life of me (Score:4, Insightful)
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 (Score:5, Insightful)
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 (Score:4, Informative)
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 (Score:2)
How are they fundamentally different? What is simple about designing a car, the materials that go into it, the tolerances of all the moving parts, the factories that will build it, the tooling for those factories, and the tremendous effort of managing many thousands of employees? The more exposure I get to automotive and manufacturing engineering, the more impressed I am that cars work at all let alone for 250,000 miles for the better ones.
And yes, software engineering for non-trivial projects is this complex, also, but I rarely see a "software engineer" that admits it or even is aware of it. That is why most software still sucks.
Re:For the life of me (Score:2)
Re:For the life of me (Score:1)
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."
Arrogance (Score:2)
Re:For the life of me (Score:3, Interesting)
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 (Score:5, Insightful)
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.
building industry equivalence (Score:2)
I'm doing research in the building industry and many of the things you mention are valid in the building industry too. In a different wording:
Allmost everything is a one-off project. We ain't building 10000 volkswagens of about the same type. THEN you can do some "traditional" engineering and some heavy process optimisations. Basically the building industry builds prototypes only (apart from soviet housing blocks).
Changing requirements. Yes. The architect changes his mind. The customer changes his mind. The constructor has to do it. Faults creep into the design, the constructor has to compensate for it.
Perhaps an extra analogy:
BAD BAD professional relationship between customer and contractor. The customer wants the cheepest ride possible. The contractor has to accept it. But the customer unvariably made errors in his specification. The contractor is quite happy to do a bit more work to correct that, but he attaches a hefty price tag to it.
Both the construction and the software industry have their big problems. Some can be cured by better processes, some by a culture change, some by better information. But probably not all.
Well, that's where we engineers are for, isn't it? Solving nice problems!
Reinout
Re:For the life of me (Score:2)
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 (Score:2)
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 (Score:2)
Huh? (Score:3, Funny)
Seems to me that "end up as a mess" describes software efforts in general, no matter what drives them.
Master the Tao, all else will follow (Score:5, Insightful)
They have discovered that the Tao [canonical.org] 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.
Re:Master the Tao, all else will follow (Score:5, Insightful)
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 (Score:1, Insightful)
And farmers aren't poets.
Totally Useless (Score:5, Informative)
Re:Totally Useless (Score:4, Insightful)
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.
"How" eXtrEmE pRogrAMming destroyed my project (Score:5, Informative)
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 (Score:5, Interesting)
> 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 (Score:1)
Unit testing, at least on most of my projects, just isn't possible. The reason: The database. I work for a financial firm writing internal j2ee apps that hit enormous databases (yeah, even the development databases) with diverse users. There is just no way that, on a short iteration cycle, I can assume that the state of the database can be reset to some baseline in any sort of timely manner.
I'd love to be able to host the database on my own computer and engage in rapid prototyping as some XP'ers suggestion, but there's just no way. Maybe on smaller projects, or on framework projects, or on shrink wrapped products. But not in my line of work.
Not that I don't love the idea of Unit Testing. I do. I just haven't seen it provide much more than trivial benefit to any of the projects I've worked on.
Then again, maybe I'm an idiot. (Actually, on second thought, I *am* an idiot.)
Cheers,prat
Re:"How" eXtrEmE pRogrAMming destroyed my project (Score:1)
> iteration cycle, I can assume that the
> state of the database can be reset
> to some baseline in any sort of timely manner.
Right on. So don't test against the database directly. Use mock objects. Since you're doing J2EE, I reckon you're using JDBC in your session beans, or you're using a bunch of entity beans, or you've got some sort of DAOish layer somewhere. Any of those can be mocked up in one way or another; give it a whirl.
I don't mean to minimize the difficulty of unit testing J2EE stuff - I mean, any time a bean gets resolved it throws a wrench in the tests. But try to refactor as much as possible into plain ol' Java objects, and mock out the rest.
I'm an idiot too - that's why I write a bunch of tests, otherwise I'd be breaking things all the time
I've had great results with unit testing PMD - here's [sourceforge.net] the current test report. So I'm pretty hyped up on them....
Good luck,
tom
Re:"How" eXtrEmE pRogrAMming destroyed my project (Score:1)
In the case of PMD, what appears to be a framework/tool, Unit Tests are probably a dream. With database-based J2EE apps, less so.
At the same time, I like the idea enough to make another dash at it. We'll see how it goes.
Cheers,prat
Mock database objects (Score:2)
If you have mock database connections, don't let the name fool you. They're not database connections, and you shouldn't implement any kind of whole 'layer' in a mock database connection.
Which means, if you can hand your code that is under test a mock connection, don't have one "mock connection" for the whole system. Make a "mockMyThingConnection" that (if it can) stores off the requests in order, and returns a predetermined set of results. Then check the requests to be sure they're what you expected.
The simplest case of this is where you have something that makes one simple query, like looking up a country. Your unit test can make a simple mockConnection (heck, it could be anonymous , even) that will check that the request it gets fits some sanity values (asks for the country table and includes the code passed in, for example) and then returns the result you expect the real data layer to give you.
This mockCountryConnection is *only* for this test case, and is trivial to write.
You're right that you won't catch any problems with the data layer for this kind of unit test, but then again, you're not testing the data layer. Presumably, you have other unit tests for the data layer, then integration tests (perhaps monkey-based*) for the interaction between them.
I tell myself every day, "MockObjects do not have to do anything resembling the full contract of the objects they replace".
-Zipwow
* Monkey-Based Integration Tests: This is our current approach where I work. It involves one or more non-automated semi-intelligent button-pushers who follow a rigorous training program before going bannanas on the application.
Unfortunately, we're non-optimal in our implementation of this because we have extra-intelligent humanoids doing the heavily scripted (but not automated) button-pushing. This is non-optimal because their talents of interface evaluation, and non-obvious error detection aren't being fully utilized.
Re:"How" eXtrEmE pRogrAMming destroyed my project (Score:2)
What type of database are you using that you can't have a local instance of the tables? Not an entire copy of the live data, but a small subset of test data? DB-2? Even then, you should be able to create a small test database instance and test against that. Sure, it does require management support to find people to set it up, but automated unit tests are a central component to XP. Without them, there's not much point in doing anything else.
Slashdot had a story [slashdot.org]of how one group managed it. Here, we're setting up similar things against Oracle.
Jason Pollock
Re:"How" eXtrEmE pRogrAMming destroyed my project (Score:2, Insightful)
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 (Score:2, Insightful)
Anyways, XP doesn't work.
Data is not the plural of anecdote.
LOL! _Exactly_! Mod parent up (Score:2)
Re:"How" eXtrEmE pRogrAMming destroyed my project (Score:2)
Re:"How" eXtrEmE pRogrAMming destroyed my project (Score:2, Insightful)
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 (Score:4, Insightful)
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.
Re:"How" eXtrEmE pRogrAMming destroyed my project (Score:2)
Agreed.. to have fixed, unbending "you are not allowed to do this" or "not allowed to do that" rules is silly - sometimes it really is just the most practical solution to do some particular thing, such as copy 'n paste a function. Certain types of behaviour should of course be discouraged, and other types encouraged, but choosing what to do is very much dependent on precisely what you are doing. Its impractical and wasteful to always pair programmers, for example, but I believe it is a good idea to do it once in a while, particularly, less experienced programmers learn a lot when doing that. It sounds to me like the ACs "XP-destroyed project" had more to do with people trying to follow a bunch of rules "religiously". That, and more likely, (a) general poor management (i.e. unrealistic time/budget etc) and (b) bad programmers. Nothing can save you from bad programmers, and there seem to be more bad programmers than good out there.
Re:"How" eXtrEmE pRogrAMming destroyed my project (Score:3, Insightful)
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
Re:"How" eXtrEmE pRogrAMming destroyed my project (Score:1)
What you did was not XP. You even admit it in the same breath
If you're not enforcing the tenets, its unfair to say that "XP doesn't work".
Re:"How" eXtrEmE pRogrAMming destroyed my project (Score:2)
Start refactoring the same day you start coding. Properly done, agile development will not be any faster than traditional development - thorough unit testing and refactoring take time. If it seems wildly faster than traditional development, and late in the project you find refactoring painful, it's a fair bet you've let the lack of micromanagement affect your personal commitment to quality. Agile development is not an excuse to write bad code, and every developer should feel personally compelled (and organizationally free) to improve unsound code the moment it emerges. Thorough unit tests ensure that refactoring doesn't affect a retrograde improvement in existing functionality, so the pain should border on non-existent.
The goal is for the end result to more accurately reflect the customer's needs, to contain less unanticipated functionality, and to mitigate the danger of new features and feature creep, not to reduce the initial cost of development of a given feature.
People way more significant that methodology (Score:5, Insightful)
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 (Score:2, Interesting)
Re:People way more significant that methodology (Score:1)
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 (Score:2)
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 (Score:1)
Re:People way more significant that methodology (Score:3, Funny)
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 (Score:5, Insightful)
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 (Score:1)
I observe that those said people are often good at minutiae of life but can never get their heads out of their arses long enough to see what is really happening in real life:-)
As for the grandparent comment about people being more important - isn't this exactly what agile "methodologies" recognise? Whilst I am not a convert to the lap dancing extremities of extreme programming, I do strongly agree with the underlying observations made with regard to agile development.
I particularly enjoyed Martin Fowler's [martinfowler.com] knock off of the endless comparisions between software development and civil enginering. In a wide ranginging article [martinfowler.com] he manages to capture just about all the hazy confused conclusions I've arrived at after 15 years in this industry.
Re:People way more significant that methodology (Score:2)
Absolutely!
But it doesn't mean their results will be used by the customer.
In other words, good people will develop things "right". Methods help you develop the "right thing" by providing a communications framework between the team, management, and the customer.
Agile methods like SCRUM and XP were created under the assumption that people ARE the the most important thing in development and methodology is secondary. They ask: What's the least intrusive set of ceremonies/tasks/disciplines so a group can work effectively?
XP in particular was created because many projects get canned because:
a) results were delivered, but they weren't the results the customer wanted,
b) money ran out and they couldn't use results developed up to this point (it was all "groundwork"),
c) customer needs & direction changes and it eventually costs too much to modify the design, so the project is cancelled or re-written.
So -- in the end, hire good programmers, have a good manager, and use a process that is congruent to your goal.
If that goal involves constant requirements change, and unclear customer requirements -- an agile method like XP or SCRUM may be more appropriate than an incremental process like MSF or Spiral or RUP (which can be made to be agile too).
Obligatory 'real engineer' comment (Score:5, Funny)
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
Re:Obligatory 'real engineer' comment (Score:1)
Less heavy going (Score:4, Informative)
Re:Less heavy going (Score:1)
Methods are nice... (Score:2)
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... (Score:5, Informative)
"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?
Re:Judge them by their work... (Score:1)
No Silver Bullet (Score:1, Insightful)
Schwaber consulted at an ex-employer of mine... (Score:2, Informative)
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 (Score:2)
Re:Schwaber consulted at an ex-employer of mine... (Score:2)
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... (Score:2)
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.
perhaps a better book (Score:2, Insightful)
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 (Score:2)
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? (Score:2, Funny)
There is no holy grail for development (Score:4, Insightful)
Every small IT shop i've been at does this (Score:2, Insightful)
Great! (Score:3, Insightful)
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... (Score:3, Interesting)
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! (Score:1)
Re:for the fragile business! (Score:2)
So if tomorrow, Microsoft releases "SnigglyOS", are you going to change your
Next Book... (Score:2, Funny)
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.
Bad Marketing (Score:2)
First "Extreme Programming", now "Scrum". Yuck.
Sumbitter doesn't know rugby (Score:2, Funny)
quick, adaptive, and self-organizing?? Have the authors ever met rugby forwards?
Ken Schwaber in Seattle 18 Feb (Score:3, Informative)
"Agile Processes and the Scrum Methodology" at the meeting of the Seattle Java Users Group [seajug.org] at 7 PM tonight.
It's all about the people (Score:3, Insightful)
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.
An Improvement: (Score:2, Interesting)
Software (yes it is!)
Creation of some bugs
Realization of the fact we have bugs
Objectification of the bugs into modular and reusable parts
Timing of when to unleash bugs
User requirements: They had better require bugs!
Many Iterations to turn bugs into Features!! (MS only needs one iteration to do this)
Or we can just call it SCROTUM. For example, insted of saying: let's SCRUM, you could say: let's scratch out that SCROTUM problem.
This poorly worded acronym brought to you by the letters X and P.
Carnegie Mellon SEI CMM (Score:1)
Important Background about SCRUM (Score:2, Interesting)
SCRUM was invented by technical people for technical people by a Smalltalk team in 1993. The inventors were well steeped in Brooks Mythical Man Month. The challenge was to get mere mortals to function as well as Brooks Surgical Team, which IBM had shown was the highest productivity approach to software development. The solution came from the Japanese auto industry where they first applied the SCRUM term to new product development. Critics should read:
Takeuchi, Hirotaka and Nonaka, Ikujiro. 1986. The new new product development game. Harvard Business Review 64:1:137-146 (Jan/Feb), reprint no. 86116.
SCRUM is designed to eliminate all project management meetings and replace them with one technical meeting a day about 15 minutes long. It should be led by a technical leader, i.e. someone who does real coding. All decisions are made in the SCRUM.
SCRUM is designed to get management out of the way and to assign them tasks they are responsible to fix, i.e. get stuff out of the way that is blocking team progress. If they can't do that, the SCRUM should replace the managers.
SCRUM is designed to completely eliminate project leaders. Project planning and reporting including complete charts and graphs that will satisfy senior management is designed to be done in less than 10 minutes a day. Development input for project status should be restricted to less than 60 seconds a day. GANTT charts are verboten.
If a SCRUM doesn't do the above, it is not a good SCRUM. Management must give up some control in return for getting a better product faster. Anyone who has seen SCRUM really work will never go back.
Jeff Sutherland http://jeffsutherland.com/scrum
Excellent points. Thank you. (Score:1)
If I subject the public in the future, I may have to stick with Kuro5hin over slashdot so I can get more editorial feedback and provide a clearer picture.
Scrum is not really about coding... (Score:3, Insightful)
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.
Processes are for IT monkeys (Score:2, Interesting)
By contrast, real Software Engineers, would like to think for themselves and excell in their projects because they have a passion for solving real problems, and find themselves hindered by monkey managers who push processes over intelligence. If this is not the truth, open source projects like Linux would not succeed. they dont dictate a process over people, infact they reward people over a process; self fullfilement fo doing something right.
Schwaber will be speaking in Calgary (Score:2, Informative)
Delivering software (Score:2)
1) Have a good manager (the more the better)
2) Have a good programmer (the more the better)
3) Have a process congruent to your goal.
Processes will not eliminate the need for managerial or technical competence.
They do, however, help:
- communicating with the team
- communicating with the customer
- keep an eye on quality.
And the whole point of this "communicating" is to:
- gather requirements
- clarify requirements
- prioritize requirements
- make people realize ASAP the requirements have changed
- figure out how the heck we can encode these requirements in software
The whole point of agile methods like XP or SCRUM is to support projects where requirements aren't clear, their priorities aren't clear or change, and requirements themselves change. Which is like most in-house business environments. It might (or might not) be appropriate to product development.
Cheers
Re:why every developer should love scrum (Score:2)
It's like going to a group psychosis meeting where everybody talks about their own current nerosis and other mental problems. Who gives a shit what some other neurotic braniac is going through.
God I hate these meetings.