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.
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?
A bee's "corbiculae", or pollen-baskets, are located on its tibiae (midsegments of its legs). The phrase "the bee's knees", meaning "the height of excellence", became popular in the U.S. in the 1920s, along with "the cat's whiskers" (possibly from the use of these in radio crystal sets), "the cat's pajamas" (pyjamas were still new enough to be daring), and similar phrases which made less sense and didn't endure: "the eel's ankle", "the elephant's instep", "the snake's hip". Stories in circulation about the phrase's origin include: "b's and e's", short for "be-alls and end-alls"; and a corruption of "business".
try { do() || do_not(); } catch (JediException err) { yoda(err); }
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?
It's not so much that development processes are coming and going, it's just that people are tailoring the processes around what works.
...managers rejoice...projects continue to fail...however, the projects with good people continue to prosper. So, what is wrong? oh, we need agile, iterative, incremental, eXtreme, [insert buzzword here] processes. TEH SAVIOR!!!...managers rejoice...projects continue to fail...however, the projects with good people continue to prosper. Things are a little better though, because the processes are closer to how good people do things.
I've been seeing this agile stuff for almost 8 years, and that doesn't mean it wasn't around before that.
So, gather around boys and girls, here is how you write software (does not apply to stuff like mission critical embedded software)
1. Ask customer what they want
2. Build something
3. Show it to customer, and ask what they want changed
If you make that cycle short, have good engineers, reasonable customers, and competent management, you will rule the universe.
What happens is that projects often have stupid and/or lazy people involved, so there are tons of failed projects. So, awhile back, the academics get together and come up with this deal where you do this extravagent design/requirements process upfront. TEH SAVIOR!!!
Help me take back Slashdot. When did 'News for Nerds' become 'FUD and Conspiracy Theories for Extremist Nutjobs'?
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:
And will cost $500k in the long run. Those questions, concerns, requirements, etc should have all been recorded. The future user who just got smacked down for expressing his/her concerns will likely develop a less then positive view of the IT department, and be significantly less likely to partake in future design meetings where those requirements and concerns will become much more imporant.
I have been dragged through numerous develop now, design later! projects, and each one of them has gone over schedule. I'm still trying to clean up this current project that I got hired into. The users were still bringing us new requirements for the invoicing system 2 months after it went live. Not to mention the actual framework that the app was built off of was a hodge podge of misc code. Finally we are getting things standardized and working on a solidified portal and framework system. Poor planing, a complete lack of requirements gathering, a complete absence of a clear unified design, and many other poor initial lead and management decisions have us still working on corrective maintenance for an app that was released six months ago. All for the sake of developing and releasing the first version in 4 months. No thanks, I'd take 4 months of design and huge emails up front in exchange of 8 months corrective maintenance any day.
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
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.
You guys are both wrong. It's not the method that matters, it's the people. Good software engineering is the key in either system, and neither system is perfect for all situations.
The key to agile programming is being able to actually handle massive requirement changes. I'm talking about the kind of requirement changes where all of those precious unit tests and acceptance tests you wrote get invalidated overnight. If your requirement changes are more minimal, then they're not going to be a problem with either method. They key to being able to handle massive requirements changes is good software design. Excessive coupling between components means that when one component becomes worthless (because of said changes) its hard to salvage other components that are still valuable because they are too tied to the deprecated component. Without good software design, agile programming won't help in the worst case scenario. This is especially important for agile programming, because its approach increases the likelihood of the worst case scenario.
Now I will say that a waterfall approach leads to several bad practices. First, it leads to a mythical man-month type of fallacy. Management tends to think that because of all the documentation present that they can manipulate "resources" like pawns in a game of chess. Second, it encourages bad design because you think you know everything. Third, and this is the worst to me, it gives false value to low value assets, i.e. people who don't actually produce anything. When a company values its process more than its employees, then it winds up hiring lots of people whose only function is to manage the process. Of course this is not unique to waterfall companies, but their emphasis on process does encourage this.
Agile programming also encourages several bad things. It encourages the over-valuing of development and under-valuing of design. I've often seen programmers with the attitude that's ok to build something that sucks because they will make it better in the future. Second, it tends to encourage overly-conservative programming. Its faster cycles discourages tasks that don't easily fit into these shorter cycles.
Of course the biggest limitation of agile programming comes from its roots. It clearly shows its consulting roots with its need for customer involvement. The kind of customer involvement it wants is very expensive for the customer (if we're talking enterprise software, maybe it's cheaper for consumer software.) If the customer is already paying you to build the software, then they might be willing to make this investment. If instead the customer is only a potential customer who might buy the software when it's done, then they are much less likely to make such a large investment.
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.