Slashdot Mirror
Lean Software Development
Jim Holmes writes "Mary and Tom Poppendieck's Lean Software Development: An Agile Toolkit is a great read for anyone interested in agile software development. That includes developers, leads, and managers interested in speeding up development cycles, improving quality, and getting their customers the best value. This book's been out since May, 2003, but it's well worth picking up. The concepts within are absolutely applicable now, and will continue to be for quite a few years." Read on for the rest of Holmes' review.
Lean Software Development: An Agile Toolkit
author
Mary and Tom Poppendieck
pages
240
publisher
Addison Wesley
rating
9
reviewer
Jim Holmes
ISBN
0321150783
summary
Toolkit for getting agile development in your organization.
Lean Software Development is full of pertinent comparisons between the current state of software development and the massive changes in manufacturing over the last three decades, specifically demonstrated by the Toyota Production System, and 3M's innovative atmosphere for bringing products to life. The Poppendiecks make a great case as to how similar changes in software development can reap great benefits in the software production industry. Who It's For The book's very useful for anyone involved in or around the software development process: developers, leads, managers, and corner-office types. Corner-office types won't get as much out of the book as those in the trenches, but the Poppendiecks' arguments against overly-constraining process management systems may help high-level managers come to understand that such systems can actually hurt production.
Who It's Not For This book isn't for closed-minded folks who think the waterfall method and a preponderance of documentation and process control are the bee's knees. The book talks specifically about how Six Sigma, Capability Maturity Model (CMM), Capability Maturity Model Integration (CMMI), and Project Management Institute (PMI) certification can drag down development productivity and quality. Also, it's not for folks who are unwilling to consider that shorter delivery cycles improve feedback, quality, and lower cost.
(Note that the authors specifically point out that agile development does not mean tossing out all documentation and process.) What It Covers The book is labeled a "toolkit" for lean development, and it describes 22 "tools" -- that is, approaches which will help an organization move to a leaner development system. The authors start off with a great explanation of what lean practices are and how they can benefit software development. They then move on to more detailed coverage of important principles.
The book's broken into chapters covering the seven principles the Poppendiecks lay out as fundamental to agile practices: eliminating waste, amplifying learning, deciding as late as possible, delivering as fast as possible, empowering the team, building in integrity, and seeing the whole. Those seven principles may sound like marketing blabberspeak, but the Poppendiecks nail each section down with terrific discussions of applicability.
They've also got great examples tying the principles into how manufacturing has so drastically improved its processes. Each chapter concludes with a "Try This" section aimed at getting your group moving in a lean direction.
The second biggest benefit after the book's content is the extensive reference list. There's an impressive bibliography, and each chapter is loaded with footnotes referencing various books, articles, etc. This gives interested folks a great guide for further reading.
The book's summary chapter is especially good. It concisely wraps up the book in the somewhat tongue-in-cheek format of an instruction sheet for the tools the Poppendiecks have laid out. The "Caution - Use Only As Directed" section is particularly useful because it shows how one should not use the principles: "Eliminate waste does not mean throw away all documentation," and "Deliver as fast as possible does not mean rush and do sloppy work." The summary also breaks out high-level details for implementing in large and small companies. The authors are particularly helpful in pointing out strategies for dealing with difficult process improvement programs such as Six Sigma, CMM, and/or CMMI. They point out the political aspect of how to approach implementing agile methodologies in organizations constrained by such "helpful" policy systems.
There's also a note for folks working in safety-related fields where regulations and immense processes dictate how to do work: Shortening cycles in such environments can better ensure people aren't killed by software failure. What It Doesn't Cover Despite the great coverage of the principles and tools, this book isn't a detailed guide for implementing agile processes at your organization. The authors are very adamant that no two organizations function alike. Implementing agile processes requires some careful forethought before jumping in. The authors don't advocate any one methodology over another, so don't look to this book for help in deciding whether you want XP, FDD, SCRUM, or any one of the other alphabet-soup-of-the-day agile buzzwords.
Additionally, I thought a few items were given pretty cursory coverage. One example is in the chapter on late decisions where the authors breeze right over implementing a quick persistence layer to put off deciding on exact database implementation. I particularly would have liked more detail in that item. On the flip side of that; however, is the great detail given to value stream mapping, feature implementation burn rates, and several other very, very useful items - so my complaint is really that one particular item I'm working on right now wasn't covered as well as I'd have liked. Bottom Line This really is an important addition to your reading list if you're at all interested in learning how an agile environment can increase your speed, quality, and cost effectiveness. It's a great book if you're in need of guidance on how to look at and improve your current environment. It's also a great book if you need backup for convincing either your co-workers or management that a move to agile is necessary.
You can purchase Lean Software Development: An Agile Toolkit from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Lean Software Development is full of pertinent comparisons between the current state of software development and the massive changes in manufacturing over the last three decades, specifically demonstrated by the Toyota Production System, and 3M's innovative atmosphere for bringing products to life. The Poppendiecks make a great case as to how similar changes in software development can reap great benefits in the software production industry. Who It's For The book's very useful for anyone involved in or around the software development process: developers, leads, managers, and corner-office types. Corner-office types won't get as much out of the book as those in the trenches, but the Poppendiecks' arguments against overly-constraining process management systems may help high-level managers come to understand that such systems can actually hurt production.
Who It's Not For This book isn't for closed-minded folks who think the waterfall method and a preponderance of documentation and process control are the bee's knees. The book talks specifically about how Six Sigma, Capability Maturity Model (CMM), Capability Maturity Model Integration (CMMI), and Project Management Institute (PMI) certification can drag down development productivity and quality. Also, it's not for folks who are unwilling to consider that shorter delivery cycles improve feedback, quality, and lower cost.
(Note that the authors specifically point out that agile development does not mean tossing out all documentation and process.) What It Covers The book is labeled a "toolkit" for lean development, and it describes 22 "tools" -- that is, approaches which will help an organization move to a leaner development system. The authors start off with a great explanation of what lean practices are and how they can benefit software development. They then move on to more detailed coverage of important principles.
The book's broken into chapters covering the seven principles the Poppendiecks lay out as fundamental to agile practices: eliminating waste, amplifying learning, deciding as late as possible, delivering as fast as possible, empowering the team, building in integrity, and seeing the whole. Those seven principles may sound like marketing blabberspeak, but the Poppendiecks nail each section down with terrific discussions of applicability.
They've also got great examples tying the principles into how manufacturing has so drastically improved its processes. Each chapter concludes with a "Try This" section aimed at getting your group moving in a lean direction.
The second biggest benefit after the book's content is the extensive reference list. There's an impressive bibliography, and each chapter is loaded with footnotes referencing various books, articles, etc. This gives interested folks a great guide for further reading.
The book's summary chapter is especially good. It concisely wraps up the book in the somewhat tongue-in-cheek format of an instruction sheet for the tools the Poppendiecks have laid out. The "Caution - Use Only As Directed" section is particularly useful because it shows how one should not use the principles: "Eliminate waste does not mean throw away all documentation," and "Deliver as fast as possible does not mean rush and do sloppy work." The summary also breaks out high-level details for implementing in large and small companies. The authors are particularly helpful in pointing out strategies for dealing with difficult process improvement programs such as Six Sigma, CMM, and/or CMMI. They point out the political aspect of how to approach implementing agile methodologies in organizations constrained by such "helpful" policy systems.
There's also a note for folks working in safety-related fields where regulations and immense processes dictate how to do work: Shortening cycles in such environments can better ensure people aren't killed by software failure. What It Doesn't Cover Despite the great coverage of the principles and tools, this book isn't a detailed guide for implementing agile processes at your organization. The authors are very adamant that no two organizations function alike. Implementing agile processes requires some careful forethought before jumping in. The authors don't advocate any one methodology over another, so don't look to this book for help in deciding whether you want XP, FDD, SCRUM, or any one of the other alphabet-soup-of-the-day agile buzzwords.
Additionally, I thought a few items were given pretty cursory coverage. One example is in the chapter on late decisions where the authors breeze right over implementing a quick persistence layer to put off deciding on exact database implementation. I particularly would have liked more detail in that item. On the flip side of that; however, is the great detail given to value stream mapping, feature implementation burn rates, and several other very, very useful items - so my complaint is really that one particular item I'm working on right now wasn't covered as well as I'd have liked. Bottom Line This really is an important addition to your reading list if you're at all interested in learning how an agile environment can increase your speed, quality, and cost effectiveness. It's a great book if you're in need of guidance on how to look at and improve your current environment. It's also a great book if you need backup for convincing either your co-workers or management that a move to agile is necessary.
You can purchase Lean Software Development: An Agile Toolkit 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 an unfortunate last name the authors have.
I'll have to write a book myself: "Anorexic Programming" by Smart Ass. "The Ultimate in Lean and eXtreme Programming"!
Evil people don't think they're evil. - George Lucas, Making of Ep III
I think the waterfall method and a preponderance of documentation and process control are the bee's knees.
Seriously, who uses the phrase "bee's knees" anyway and what is so great about bee's knees?
RE: "Eliminate waste does not mean throw away all documentation,"
Cobblers!
I remember distinctly reading on some Agile XP whatever site that CRC cards (the documentation is the code and unit tests!) are used long enough to get the devs on board with what to do AND THEN THEY ARE DISCARDED.
Stuff's real good if you're doing your comp sci 101 homework but in the real world you need a process.
--- Jump!! Fire!! Bullet time!! - Lego version of the Matrix
What the hell is anorexic programming, would that be like...aww screw it I can't think of anything.
If it's ANYTHING like lean beef, I don't want it!
Most upper management are only about those things! Besides, having coded for companies before, I know that if you don't properly document your code and make sure you have a preponderance for process control in place typically the whole thing goes to shit. And what is this about the bee's knees!?
Generation Trance: What generation are you?
moooooooooooo
Is this a derivative of the methodologies behind Lean Six Sigma?
There's big money in that, my graduate software engineering course last semester had a speaker in from a NASA contractor that pushed LSS as a way to manage all kinds of different engineering and production variances e.g. misfiring rocket engines.
The president has been kidnapped by ninjas!
Are you a bad enough dude to rescue the president?
Banana oil, I say!
If brevity is the soul of wit, then how does one explain Twitter?
but don't like the Slashdot whore-link: clickey
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
...spamming the book reviews with his referral-fee-laden "give me commissions!" cry. Pathetic.
We just went through this with a new project. One of the usual suspects started putting out huge emails with a hundred questions/requirements/concerns such that you'd need to solve desktop fusion before protyping the thing and the lead architect just basically slapped him and said no, I'm not even going to answer this - let's keep it informal, get it going first and see what we can do and what makes sense. Probably saved the company $100k that day.
Doesn't work for everything, but when it does, use it.
The revolution will NOT be televised.
This book's been out since May, 2003, but it's well worth picking up. The concepts within are absolutely applicable now, and will continue to be for quite a few years.
Is it just me, or are things changing too fast when a development process has a shelf life of less than two years?
If you want to feel your head really spinning, pick up a copy of The Mythical-Man Month. Things don't actually change that much.
I don't have a problem with most of these development methodologies perse, but most of them seem to lack the entire concept of DATA and INFORMATION.
I haven't read the theoreticals of a lot of these methodologies but have worked in several places that say they practice them. What I've found is a bunch of developers (not saying anything about their programming skills) that don't understand databases or design of data structures. I find it difficult to extend many of these systems that are frankly poorly designed. Do these methodologies include some prep work on gathering business requirements and understanding the underlying information relationships?
There are a lot of similarities to XP
So what? Vista is in Beta now.
Two full years? woah. amazing.
There are a substantial number of programmers in this forum. You know the truth that I have spoken.
Rapid Development: Taming Wild Software Schedules. Redmond, Wa.: Microsoft Press, 1996. 660 pages. Regardless of preconcieved ideas regarding a book from MS Press, this is one of the best books I have read and has helped me/us ship our titles on schedule
One thing I wonder when I read this is: Six Sigma has been named as a large contributing factor for the successful completion of hundreds of huge projects that have been very successful. GE and Motorola swear by it and it's used in many other industries as well.
Has anyone actually used this stuff that the authors are writing about? Have they ever completed (or managed the completion of) a large-scale project that has been very successful? I agree that things like Six Sigma have reached management "fad" status but the point is that part of the reason it got that way is that it works. Maybe SS is not the magic bullet that it gets billed as, but it is effective. I want to see someone that has used these "tools" to successfully complete a project.
-D
Off topic, yes. Flamebait, no.
"This book isn't for closed-minded folks who think the waterfall method and a preponderance of documentation and process control are the bee's knees."
Loading...
What do you call a male cow that has just swallowed a grenade?
Abominable!
What do you call that male cow after the grenade explodes?
Noble!
One of the least considered, studied, and written about things is project methedology. It seems like all the books about the subject relate to automotive production, where the Japanese flooded the market with their philosophy. Afterward, automotive companies hoisted these philosophies on unsuspecting suppliers. The number of paradigm shifts that auto suppliers have endured as a result over the last 20 years is amazing.
Yet I have never had a large client try to push a project development methedology for software on us. There has never been discussion of any of these, and it seemed that for the most part, we as a group were on our own when it came to evaluating various options.
I've been waiting for someone to start talking about the various paradigms and structuring philosophies for a while. For projects as complicated as large software systems, it is frequently a lot of trial and error, followed by more of the same. Finding any comprehensive discussion has been impossible. Hopefully this will foster more books on the topic. Software is becomming such a critical part of corporations, government, and daily life, that not only are the tools that we use important, but so is the way that we use them.
I would also be interested in seeing some sort of discussion as to how various team-structuring philosopies fit with various classes of development tools. For example, database development lends itself to a different approach than web design, simply because of the design process, hurdles that have to be dealt with, degree of expertise, and expense of the individuals that participate in the project.
Friends help you move. Real friends help you move bodies.
Never forget: 2 + 2 = 5 for extremely large values of 2.
Now comes the question... why would anyone want such a level of bureaucracy? Well, in our case, we were responsible to the government, and from what i can tell, the government equates "paper trail" with "accountability and transparency." In other cases (commercial software), this would allow a company to switch contractors if the current contractor started acting nutsy or broke a contract in some way.
Think of the group paying for the contract as "the boss" and two contract groups called "Bob" and "Tim." The boss wants to pay someone to develop the MegaApp for him. Bob and Tim both make promises about how fast they can develop the MegaApp and how much it will cost and how much quality the MegaApp will contain after they work their respective voodoos. Bob makes some egregious claims, and the boss (because he's a manager) believes Bob and passes over Tim's more realistic promises. Bob, of course, fails to deliver on his promises, but the boss saw that some of what Bob did met some of the requirements. Since the boss made sure that Bob and Tim implemented CMMI level 3 before they could even be considered for contract, he has the option (or believes he has the option) to take the deliverables (including CMMI documents) to Tim. Tim, who is accustomed to using CMMI level 3, should theoretically be able to pick up the project in a short period of time and run with it due to the high level of documentation.
Just like communism, it can sound good in theory and look good on paper but will probably only work well in a perfect world.
Note: Carnegie Mellon developed CMMI.
Disclaimers:
NO ONE claims agile development techniques should be used in these problem domains except those who have no experience in them. This is even in the description of agile software devlopment on Wikipedia (see the discussion in the section "When to use agile methods"). The reviewer is at least clueless and even possibly dangerous.
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben
At the borg HQ even. Lean basicly packages agile concepts into a business-tasty format. There's nothing in Lean that contradicts with XP or Scrum (in fact, it tends to amplify it). The fact that these practices come from proven manufacturing and distribution practices give the concepts more credit . If you're having trouble "selling" either XP or Scrum, take a look at this. It should sell itself.
*** Sigs are a stupid waste of bandwidth.
We had Jim Highsmith, Mr. Agile Manifesto, talk to our engineering team. What a waste of money.
If you believe Agile works, you probably also believe Google can be implemented with JEEE and Oracle.
These Agile guys really don't know what it takes to release large commercial products with million lines code, with many dependencies, many languages, requiring marketing campaigns, press tours, support training, etc.
More versions cost more money.
Sure Agile might work for small internal IT projects where you have one customer and you can roll out changes whenever you want without any change control or worries about upgrades or localization.
Agile is for "lean" projects only.
shouldn't be telling a dev team the time of day let alone what path to follow to build "Hello World". There's nothing fundamental in Lean, XP, or Scrum that Brooks didn't manage to say 30 years ago(yes. 30. 3-0. Thirty. Near 1/3 of a decade. check the copyright). It's not that things are changing too fast, it's a matter of ajusting your process and your understanding of building software. One great example of this is comparing the origional XP book to the 2nd edition. Kent corrected himself and altered the details after learning a lot in 4 years, but the core is still there.
*** Sigs are a stupid waste of bandwidth.
You go into any corporate software "design" or "requirements" meeting and over half the attendee's will contribute nothing but useless documentation or Microsoft Project files about the 2-3 folks who actually do the work.
Process employs these losers. We need PROCESS!! And LOTS of IT.
Imagine having time enough to read all these methodology books? But, if that were the case, I'd probably waste it snowboarding or something...
There's nothing fundamental in Lean, XP, or Scrum that Brooks didn't manage to say 30 years ago(yes. 30. 3-0. Thirty. Near 1/3 of a decade. check the copyright).
I don't think that's entirely true. Test-driven development, for example, seems pretty new. Hardware cost had to be pretty low before each developer could compile and run all the project tests every few minutes of development. I also don't remember Brooks talking about weekly iterations.
That's not to knock "The Mythical Man Month", by the way. I completely agree that it's required reading.
If you believe Agile works, you probably also believe Google can be implemented with JEEE and Oracle.
That's boldly, if unintentionally, ironic. Not only is Google hiring all the Agile developers they can find, but many agilistas have a lot of contempt for the ultra-heavyweight EJB-style approach to things.
These Agile guys really don't know what it takes to release large commercial products with million lines code, with many dependencies, many languages, requiring marketing campaigns, press tours, support training, etc.
There's no question that complicated projects have to be done differently than simple projects. But even there, you can place approaches along an agile/non-agile spectrum. You also shouldn't mistake "I don't know how" for "it's impossible".
Becoming agile also requires a fair bit of supporting infrastructure. For example, my Extreme-Programming-built code bases typically have a 1:1 production-to-test-code ratio. Bug rates for many XP projects are well under one per developer-month. Quality at that level enables fantastic agility in ways that seem impossible at typical quality levels. If you regularly have production relases with zero bugs found, weekly releases don't seem nearly as scary.
Run from the Poppendieck!
Ethiopian outsourcing??
Please sign petition to restore sanity to our banking system!!!
http://financialpetition.org/
But the 99.9 % of projects ARE'NT so big as google. Please, don't force us to work as any software project is a rocket-science endeavour.
Good points. In terms of practices you're quite right, and there's a lot about the how things get done today that couldn't be done 30 years ago. The values and the emphasis on people as a fundamental point of building software still remains. I'm of the opinion that Brook's "surgical team" can be realized in part through the XP team (but then again, I'm XP biased:)
*** Sigs are a stupid waste of bandwidth.
But will it enable customer driven, lean, agile XML based go-to market paradigms and rapid value driven innovation? That's the question.
The software in the space shuttle cannot fail. billions of dollars and people's lives are on the line, so it cannot fail.
At CMM level 5, you don't fix the bug when you find it. You fix the process that let the bug happen in the first place.
CMM Level 1 is no process. anything goes, really.
CMM Level 2 is fixing the bug and documenting that you found it. That more or less boils down to using a bug tracking system, keeping good version control, and everyone following this process.
CMM Level 3 is the software engineering level. that basically means that everyone in your organization builds their software similarly (software design and documented use of design patterns is good here).
Levels 4 and 5 is all about keeping a database of your processes and fixing your processes. Process flaws cause bugs, not code errors. You don't fix your code, you fix your process.
It's important to note the budget for the team writing the space shuttle code. Lots and lots of money and lots and lots of time go into that software. Ordinary application writers like us don't get that luxury.
I do understand your point, but in this case the individual I mentioned (who IS in the IT dept.) does nothing but obstruct, and his method is bureauocracy (sp?) in the extreme. Trust me, nothing but termination will keep him from grandstanding in meetings and bringing up superfluous problems, so this is not a worry.
We're re-engineering a process, throwing stuff out and discovering what's do-able and what's not. The concerns and issues involved are real, but many are simply what I'd call "dragging the walrus", which means that we don't actually HAVE to support every single exception that's ever been done because we're also going to set new guidelines for how the input (in this case scannable documents) are going to be delivered. So there's a lot of cruft there that really does NOT need to be handled in the future. To make the project overly complicated and deal with all of this old crap up front (which IS going to disappear!) is simply a time-waster in the extreme.
There are certainly projects that have to specified down to the last detail going in, but the trick is to know which is which.
The revolution will NOT be televised.
I admit, I haven't read the book, but from my understanding of Agile methods and CMM, the two are not mutually exclusive. CMM is about improving and maturing the processes that you use. A company at CMM 1 has virtually no process, and can't repeat their results. But agile methods such as XP are processes, and often have even more effort put into improving them than more traditional methods such as the waterfall model. One common misconception about CMM is that it's about creating a whole lot of unnecessary documentation. If the documentation is unnecessary, that's not CMM at all, a CMM 5 company only does documentation that adds value to their processes, just like agile methods.
I've been the founder/CTO for two tech companies that created "large commercial products with million lines code [sic... ha ha ha!]". I have always used some variation on lean/extreme programming, and it's been great. Both companies sold for millions of dollars and the products are chugging along (one of them more than ten years old). So you can argue all you want, but I'll just sit here enjoying my cocktail on the beach!
Six sigma is more about production processes, but Lean product development certainly has a lot in common with agile methods. It takes a bit more rigourous approach to the process though -- development certainly isn't research and there are lots of opportunities for reuse of old lessons and/or artifacts, for example.
-Stu
And Toyota is slowly driving their competitors into the ground. I'd take another look. There's a lot more to Agile than the surface-level debates, especially if you look at it in the context of Lean product development techniques.
-Stu
Lean product development is about iteration, and it's how Toyota & Lexus designs its cars, noted as the most reliable in the world. Why can't these techniques also apply to software, which is arguably even easier to change iteratively than car part designs?
-Stu
... is available on the iTunes store podcast section. Search for "Agile". Otherwise, you can get it here.
i - This sig provided by
Lean manufacturing was around in the 70's, based on the Toyota Production System. Agile is an application of lean princples to Software Development. Or more accurately, if you apply lean principles and tools to software development, you get Agile practices, since Agile practices are the natural result of Lean thinking.
More importantly, Mary has delivered real product from more projects than most of us have ever attempted. She brings real credentials earned in product development to the table. What do you bring besides attitude?
Honestly, look it up, before you pull more drivel out and bandy it about as if you were clever.
i - This sig provided by
I just hope more rigour and discipline can be instilled to get past the bullshit surface-level debates (how much documentation, XP = hacking?, pair programming is/isn't stupid) that really distract from the whole point of the exercise.
I would highly suggest the following to get a better understanding of how this might fit into a software context:
Toyota doesn't have a meticulously defined development methodology. Nor does it use PERT or Gantt charts to track its car development projects. Nor does it have a "project manager" to sequence & assign tasks (it relies on a "Chief Engineer" to coordinate the whole effort). Car development certainly involves a lot of written documentation, but there is no massive "requirements" document that is written up front -- there are lots of alternative requirements and design documents for sub-systems and parts and various tradeoff curves. The scope and requirements vary through the cycle of the project. There is also iteration on design, and lots of reuse of prior designs and artifacts.
Toyota designs cars in a way that many people in the Agile community would love to design software -- in an interative and incremental fashion, without the massive soul-deadening top-down process enforcement. And they deliver the best quality, time to market, and profits in the auto industry.
-Stu
... several large financial firms I can't mention, the department of defense, most of modern manufacturing, 3M, etc.
More versions isn't what Agile/Lean means. It means more iterations. You make versions (or releases) when you're ready to go to market. That's a business decision. You will certainly have many iterations before your business feels you've built enough to go to market. The technical job is to make sure that, to the extent you've gotten to high-priority scope, the quality of the code is such that it could be released at the end of any iteration, if the business sees enough of it's features in.
People like Martin, Schwaber, Popendiek, Augustine, and the like... they have helped companies release 500K+ lines of code projects. Now explain WHY you feel large projects cannot use Lean or Agile. And what in God's name made you think that there was no change control or worries about upgrades or localization.
Perhaps Mr. Highsmith was engaging at too philosophical a level, and expecting you folks to adapt Lean/Agile to your environment. If you have heavy release control needs, you sync up the cycles to your release cycles.
Jeez, what is wrong with people on slashdot. Criticize with substance, not merely ad-hominem. Some of us "Agile guys" have done what you say we don't know how to do.
i - This sig provided by
The Agile environment pays for itself many times over when you work in a world where each check-in kicks off compile, package, db create/destroy, 3k+ unit tests, appserver deploy and launch, and 2k+ functional/acceptance tests that culminate in auto deployment to stage on success. It pays again when at the end of each 1 week itteration you do a load test and deploy consistently to live. You feel great. "Of course we deployed to live. It's Wednesday."
The strange part, is that when you've worked like this for a year, you wonder how the hell you though you were getting anything done before.
*** Sigs are a stupid waste of bandwidth.
I saw the Lean Software development presentation given by Mary last week. The best part was when she referenced the interviews done for the book "The Polaris System Development" by Harvey M. Sapolsky (Harvard University press, 1972) citing that the PERT charts were found to be useless in actual project managment and were just hacked up to keep congress happy so that the teams could get things done.
I shudder to think of the job I worked 5 years ago. They bought huge HP plotters to print out the MS Project charts, updated on a daily basis. In the most degenerate case, one documentation manager with two direct reports spent most of his day revising, planning, and in meetings so that he could show how far behind his team was slipping. The irony was that he had a background in documentation at that company, with those tools, on those products. He could have pitched in and helped make the deadline. However, his resource was not allocated for that project in that capacity so...
Some people like to use the level of Dilbert cartoons to spot bad software development environments, but the existence of MS Project printouts is a dead giveaway:)
*** Sigs are a stupid waste of bandwidth.
Anyway, what's with all this "rapid" development? I've seen a lot of hastily thrown-together shite in my time, so maybe a slow, methodical approach is really the rapid approach. Grasshopper.
The moment a book claiming to be about software engineering trashes management processes like this, you know to call BS. It never ceases to amaze me how pretentious code-monkeys believe their immature approach to development is somehow hamstrung by proven management techniques that are able to deliver multi-million dollar projects ranging from constructing and mechanical/plant engineering, to the design and manufacture of electronics and automobiles.
Let's start with some basic facts. PMI doesn't dictate your development methodology. PMI doesn't assume your project is cast in stone from day 1. PMI is about ensure that a reliable process is in place, and that there are measurable goals and delivery points so that you can check your progress in terms of time and quality. And if that's not how it works in your company then you have a management-monkey who didn't learn shit from the certification.
CMMI worries about you having processes and procedures in place for various activities that are essential to the software process in a commercial environment, and capturing important information between steps in the process. It doesn't really care if you use the waterfall model or XP (although compliance is easier if you're using the waterfall model).
The problem with Software Engineering at the moment is that it is being approaches as a technical problem by ivory tower academics. They're floundering in baths of bullshit and fighting with management types because they're unable to contribute anything new, they wank about perfect quality/process and forget about real-world concerns (i.e. commercial environments), and they're making old mistakes. Management theory has addressed (in other areas) many of problems we are seeing in SE. Somehow, SE thinks it is unique. It's not. It's just another production / operations function.
And before you even think of bitching that "making software is not like a factory" - read a management textbook. Design (the creative, unique, once-off part ... y'know, like software development) is a production function. And it has to consider all the same things as SE ... oh, like user requirements, and a project plan, and quality, and maintainability, and testing, and ...
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
Don't put easter eggs like Hot Coffee in.
I think you mean near 1/3 of century.
The author does not have any scientific credentials, but worked for a couple of firms of which only one is mentioned on the back cover.
:-), meanwhile it is more than a year since we have it and it really sucks. People spend lots of time trying to get in sync with the slice system, many groups have to cheat (sort of pushing slices around) long term goals cannot be achieved because whithin slices decisions are made that cancel things planned in the future, projects get canceled after moving them trough slices rendering all the slice planning useless and, and, and ...
Most of the examples in the book are invented, theoretical models that are not or are hardly applicable in real life. Some of them even use very questionable values (see page 9 diagram "value stream for cola cans" where the bottler needs 1 minute to process a can - that would be the doom of every cola producer). Even though the diagram is borrowed, a serious writer would check the values and not throw them in the book as M. Poppendieck did.
It is one thing to take a fancy idea (Extreme Programming) and repackage it to sell it as your own. With enough marketing and strong contacts in the field (influential friends that work for big companies) you might score some big consulting contracts and sell the books. It is another thing to scientificaly prove that this can work for a mid to large size software development company.
The introduction of a process like this in a large company will swallow tremendous financial resources and will consume large amounts of time. If at the end it proves as the wrong process, the company is stuck with it and will have to invest constantly in fixing it.
I work for a large company that implemented this thing (Lean Software Development - LSD
All this time, the consultants and advocates for this process are cashing big time, they are brought in to "analyze" things and "fix" stuff. There are expensive lunches, trainings, plane tickets and so on that go with this "process".
A large organization has to find its own way of doing things from inside and develop the models and processes whithin the walls of the company. There are things to take in account like the availability of engineers on the job market, vacations, sick days, distribution of knowledge, personality, and so on that are not addressed at all in this 200 pages book about LSD.
Maybe there are good ideas in the book, some of the tools there can prove to be usable, but I personally think that there is no need to hire M.Poppendieck to teach an organization how to steer the development boat.
If you want to be hooked on LSD, go for it, but remebmer that just like an addiction, it is hard to get rid of.
If not, save the money and learn to do things that are good for your development shop yourself.
Had a great ime reading on how to worj with this program. Enjoyed the read thought it was very well written.