Katch the KanBan Kraze!

For those who haven't been keeping up with "Agile 2.0" or "Post-Agile", one of the more recent developments has been KanBan for Software Development. I first heard about it from David Anderson in a presentation he gave at about a KanBan System for Sustaining Software Engineering. Then I heard David and some others saying how they did away completely with iterations and simply release every two weeks, and shortly thereafter David started a KanBan Development YahooGroup.

Anyway, I think it looks extremely interesting and promising, particularly for folks in an internal IT or tool development group where much (if not all) of their work is sustaining engineering of existing tools and not so much major new feature/product development.

So I thought I would roundup several resources on the subject for folks who might be interested in learning more:

• Wikipedia page on KanBan
  
• Strategosinc description of KanBan
  
• Yet another decent description of KanBan
  
• KanBon.com's "Business Lean" blog
  
• InfoQ.com article on Visualizing Agile Projects using Kanban Boards (also available from DDJ online)
  
• InfoQ.com article on Incremental Software Development without Iterations
  
• InfoQ.com article on Kanban Applied to Software Development: from Agile to Lean
  
• An article from Dean Leffingwell ("Scaling Agility") on The Simple, Visual, Iteration Kanban
  
• David Anderson's Blog and Articles
  
• Corey Ladas' "Lean Software Engineering" blog
  
• Occasional articles posted at the Agile Practitioner's Forum
  
• KanBan Development YahooGroup

Mary Poppendieck on How to Fail with Agile

Marry Poppendieck gave a keynote at SQE's Agile Development Practices Conference during the last months of 2007. The slides for that presentation are now available online. The presentation is entitled Welcome to the Mainstream (and How to Fail with Agile)

An interesting read!!!

Best SCM Best Practices Article

The November 2007 issue of the CM Journal was devoted to the theme of "What Best Practice is Best?" Joe Farah's article on The Top 10 SCM Best Practices was quite possibly the best article on SCM best practices that I've come across to date!

Joe actually first lists his top ten "runners up" followed by his top ten. They are as follows (read the article if you see any terms that are unfamiliar to you):

1. Use of Change Packages
2. Stream-based Branching Strategy - do not overload branching
3. Status flow for all records with Clear In Box Assignments
4. Data record Owner and Assignee
5. Continuous integration with automated nightly builds from the CM repository
6. Dumb numbering
7. Main branch per release vs Main Trunk
8. Enforce change traceability to Features/Problem Reports
9. Automate administration to remove human error
10. Tailor your user interface closely to your process
11. Org chart integrated with CM tool
12. Change control of requirements
13. Continuous Automation
14. Warm-standby disaster recovery
15. Use Live data CRB/CIB meetings
16. A Problem is not a problem until it's in the CM repository
17. Use tags and separate variant code into separate files
18a. Separate Problems/Issues/Defects from Activities/Features/Tasks
18b. Separate customer requests from Engineering problems/features
19. Change promotion vs Promotion Branches
20. Separate products for shared code

Granted, some of these may not be particularly Agile (nor were they meant to be specific to Agile development or Agile CM) but it's still a pretty darn good list in my opinion!

Lean Research from MIT

A couple months ago I stumbled across the MIT Lean Advancement Initiative (LAI) website at http://lean.mit.edu

It is a veritable goldmine of papers and research relating to lean product development and lean systems engineering. You can search through the publications yourself. I took an initial pass thru and found the following couple dozen papers whose abstracts caught my eye:

• A Comparative Review of Lean Thinking, Six Sigma and Related Enterprise Process Improvement Initiatives
• Measuring Value in Product Development
  
• Improving the Software Upgrade Value Stream
  
• Strategies for Lean Product Development
  
• Understanding Lean Manufacturing According to Axiomatic Design Principles
  
• Value Stream Mapping and Earned Value Management: Two Perspectives on Value in Product Development
  
• Value Stream Analysis and Mapping for Product Development
  
• Sources of Schedule Risk in Complex System Development
  
• Lean Enterprise Model
  
• Cost Awareness in Design: The Role of Data Commonality
  
• Construction Design as a Process for Flow: Applying Lean Principles to Construction Design
  
• Performing Collaborative, Distributed Systems Engineering (CDSE): Lessons Learned
  
• Creating High-Performance Enterprises
  
• Corporate Decision Analysis: an Engineering Approach
  
• Systems Development Technical Interactions and Innovation: A Networks-Based Investigation

Happy reading!

Stellation Archives

Several years back there was an interesting open-source Eclipse project named "Stellation" at www.eclipse.org/stellation. It was to be an advanced/modern version control tool with lightweight branching and support for fine-grained checkout at the logical/semantic level.

Then about 2-3 years ago it just up and disappeared. I tried doing several websearches for it, but to no avail. Then on the revctrl mailing list I saw someone inquire about it, and I chimed in too wondering where it had gone.

Karl Fogel (of CVS and Subversion fame) replied with exactly what I was looking for ...

You can get the whole project archived as a tarball here:

http://archive.eclipse.org/technology/archives/stellation-project.tar.gz

It used to live at http://www.eclipse.org/stellation/. Those pages have been pulled, with no redirect left behind (a bit annoying when an open source project does that!).  But a search on eclipse.org pulled up this thread:

http://dev.eclipse.org/newslists/news.eclipse.foundation/msg00766.html

...which pointed to...

http://www.eclipse.org/technology/archived.php

...which pointed to the above tarball.  Summary from the archive page:
"Stellation is a software configuration management system designed to be an extensible platform for building systems based on the integration of advanced or experimental SCM techniques with the Eclipse development environment. The Stellation project will be using this system to integrate support for fine-grained software artifacts into the Eclipse environment, with particular focus on dynamic program organization, and inter-program coordination.

The Stellation website, newsgroup, mailing list, source code, and latest download are available in a compressed tar archive (110Mb) [http://archive.eclipse.org/technology/archives/stellation-project.tar.gz]"

So now you know! (and so do I).

The Majesty of the Mythical Man-Month

I am still amazed at the number of software managers who are unfamiliar with "The Mythical man-month" lesson that says (paraphrasing here) adding more people to a late project makes it even later. So I decided to round-up some resources on the subject. Here they are:

• Wikipedia entry on the Mythical Man-Month
  
• Code Reads #1
• Serverside.com Walkthru of chapter 1
• The Mythical Man-Month curve
• MMM entry on the "Myths in Software Engineering" Wiki
• TechRepublic.com review
• Software Team-size: the Mythical Man-Month
• Classic Quotes from the Mythical Man-Month
• Late projects, man-months, and the software crisis
• Frederick P. Brook's quotes on software engineering
  
• The Mythical Man-Month and the Future of Software Development

Several of the materials I found were course lectures from various Universities:

• Univ. of Colorado lecture
• USFCA Lecture notes
• UC Irvine Lecture
• UTA Lecture
• William & Mary Lecture
• U. Virginia Lecture/Study notes
• Macquarie Univ. Lecture
  

I like the classic quotes! Among my favorites ...

“Adding manpower to a late software project makes it later.”

“How does a project get to be a year late?... One day at a time.”

“Nine women cannot deliver a baby in one month”

“Program maintenance is an entropy-increasing process, and even its most skillful execution only delays the subsidence of the system into unfixable obsolescence.”

“Plan to throw one away; you will, anyhow.”

“Conceptual integrity is the most important consideration in system design.”

“If a system is to have conceptual integrity, someone must control the concepts. This is an aristocracy that needs no apology.”

“The purpose of organization is to reduce the amount of communication and coordination necessary.”

“Build a performance simulator, outside in, top down. Start it very early. Listen when it speaks.”

“The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. Yet the program construct, unlike the poet's words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself... One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be... It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time.”

“The computer resembles the magic of legend in this respect, too. If one character, one pause, of the incantation is not strictly in proper form, the magic doesn't work. Human beings are not accustomed to being perfect, and few areas of human activity demand it. Adjusting to the requirement for perfection is, I think, the most difficult part of learning to program.”

Understanding Version-Control

Eric Raymond, famed OpenSource co-founder and Unix guru, author of The Cathedral and the Bazaar and The Art of Unix Programming, is currently working on a draft of a work entitled "Understanding Version Control"

It is an interesting read, and covers some of the more recent systems like Bazaar and Mercurial. For those who wish to give feedback, there is a link you can follow for a reviewers' mailing list.

BOOK: The Art of Agile Development

My review of The Art of Agile Development is in the January 2008 issue of the Agile Journal

This is an amazing book! The Art of Agile Development is nothing less than 10+ years' worth of agile development experience distilled into a single compendium of practical insight and mindful application of Agile practices and principles. James Shore and Shane Warden have succeeded marvelously in doing exactly what they set out to do: "packed everything we knew about the day-to-day practice of agile development into 400 pages ... to provide a complete how-to guide and starter kit for beginning and intermediate agile practitioners" (quoted from the book's website).

... I can't think of a better XP practitioner-guide to date that conveys both the practices and principles of XP for novices and intermediate-level readers, and also goes beyond explaining them to provide quintessential insights, tips, contraindications, alternatives, and organizational strategies for how to overcome the many technical and organizational barriers that can stall an otherwise successful attempt adopting XP.

Read the full review

The Truth About Agile Processes

After my previous long-winded entry about "What do you wish your CEO knew about Agile?", I came across this Forrester report on "The Truth about Agile Processes"

It has a summary of what CEOs/CIOs and managers need to know are the changes they need to make in order to adopt agile:

• Larger-teams should be broken into smaller ones
• Functional silos have to be broken down, or at least weakened
• Specialists may have to pick up new skills
• Teams must learn to self-manage, and managers must learn to let them
• Routine activities have to be automated (integration, builds, testing, etc.)

These underlie the message that "going Agile" is more than just a change in one's technical processes. It also requires changing (mind-set as well as process) how one does not only project-management, but also overall management - including status-accounting and reporting of results. And it requires a great deal of rigor/discipline (even tho it may be less formal) in these practices as well as the technical/engineering practices.

You can't expect to make a successful go of Agile by modifying only your technical process & practices. Management has to make some changes too, and the most significant change may be the mind-set for how they are accustomed to measuring and reporting progress (especially for those currently using stage/gate management).

What do you wish your CEO knew about Agile?

Esther Schindler has been posting on a number of different Agile-related groups & forums asking participants the question:

If you could get the boss to understand one thing, just ONE THING, related to Agile development... what would it be? Why that?

When she posted this to the Agile CM forum at cmcrossroads.com, my reply was as follows ...

My "one thing" would be a bit more basic than either CM or "Agile" (IMHO), and culled from Steve McConnell's talks on "Critical Insights for C-level Executives" and "The 10 Most Powerful ideas in Software Engineering" both of which are available online from Construx (unfortunately you have to register to download them, although registration is free and they promise not to spam you)

McConnell starts off with what he says are 5 insights that C-level Executives already know:

• Software projects are late
• Software projects are out of control
• Answers from software staff are often incomprehensible
• Answers from software staff often seem evasive
• Software is the most unpredictable part of the business

Then he goes on to describe what he calls the 7 Critical insights about software development that C-level executives need to know:

• Typical Budgeting Processes Undermine Effective Development (and don't acknowledge the "cone of uncertainty")
  
• Stage-Gate Processes Are Prevalent In Leading Companies
• Low Quality Is The Single Largest Cost Driver
• People (Staff) Exert The Largest Impact On Project Outcomes
• Software Improvement Works Best When Supported at the Organizational Level
• The Tradeoffs Between Cost, Schedule, And Quality Might Not Be What You Think They Are
• Improved Software Practices Offer Exceptionally High ROIs

McConnell describes the 10 most important/powerful ideas in software development as follows:

• Software Development Work is Performed by Human Beings (people are the single biggest influence factor for success)
• Incrementalism is Essential
• Iteration is Essential
• The Cost To Fix A Defect Increases Over Time, Throughout the Development Lifecycle (even when using iterative/incremental/agile development)
  

• There’s an Important Kernel of Truth in the Waterfall Model
• Ability to Create Useful Software Estimates Can be Improved Over Time (The Cone Of Uncertainty)
• The Most Powerful Form of Reuse is Full Reuse
  
• Risk Management Provides Critical Insights into Many Core Software Development Issues
• Different Kinds of Software Call For Different Kinds of Software Development - The “Toolbox” (there is no single best best practice or method across all software projects/products)
• Software Engineering Body of Knowledge - SWEBOK (existing body of knowledge provides a wide spectrum of support for software development practices, especially CM, PM, RM, QM, Testing, Design, Construction, Management, Maintenance, Methods and Tools)
  

So how would I distill all of that into a single statement to communicate to C-level executives? Tom Gilb get's an honorable mention for his "The Ten Most Powerful Principles for Quality in [Software and] Software Organizations", which he summarizes as a single principle saying:

"Motivate people
towards real results
by giving them numeric feedback frequently
and the ability to change anything for success."

For me, the gist of all the above is that most corporate planning, estimation and management "systems" for software are badly broken because they utterly fail to acknowledge the inherent uncertainty and variation that cannot be removed by "up front" attempts at perfectly stable project plans and/or product requirements (see my article on "The Unchangeable Rules of Software Change"):

• The solution is not going to come about by striving ever harder for perfectly stable plans and requirements earlier in the project!
  
• The only successful way to manage that is through effective and continuous management of risk and change!
  
• And the most effective means of doing that is through the use of iterative and incremental techniques that put people first in order to give frequent feedback and reflection on real-results throughout the course of the project (while still leveraging the existing body of knowledge to serve those people so they can best serve the business).

Many companies seem to behave as if merely identifying risks and having mitigation plans is sufficiently effective, and they just need to do that "up front" and then monitor the risk-list without having to spend much time adjusting, adapting, and refining it throughout the project.

Similarly, many companies seem to behave as if they can effective manage change is they basically strive to prevent changes once the project/requirements is (are) initially baselined.

All that is poppycock! Effective risk and change management comes about only by taking a continuous approach to manage them that use regular increments and iterations to achieve frequent feedback on tangible, valued results. Even that by itself is not enough, because if you do not enable and empower your people to act on those results, collaboratively, throughout the entire lifecycle, then you won't be very effective or efficient at reaching your goals. Your process has to leverage the power of your people rather than being an obstacle that overly constrains/controls them.

That all goes for CM and managing change just as much as it goes for development and managing projects! Stop thinking it is feasible to drive out 100% of the variation and uncertainty early in the project, and rechannel that energy instead on managing risk and change continuously, utilizing iterative/incremental means to attain frequent & regular feedback. Then make sure you empower your people to act on that information by effecting necessary changes as quickly as possible, and using processes that regularly embrace such changes instead of stalling or preventing them.

Flexible Development, Manage It, and Continuous Integration

During my hiatus from this blog since the summer, I still managed to keep up with a few of my book reviews for The Agile Journal. Here they are (with hyperlinks) ...

Flexible Development: Building Agility for Changing Markets by Preston G. Smith published September 2007 by Jossey-Bass My rating: Very good for those looking to apply Agile principles outside of software development. And a very useful concept and measure of flexibility. Read the full review in the December 2007 Agile Journal (also see the book's website at www.flexibledevelopment.com)

Manage It! Your guide to Modern Project Management by Johanna Rothman published June 2007 by the PragmaticProgrammer's Pragmatic Bookshelf My rating: Outstanding! If a budding project manager came to me, with knowledge of text-book project management concepts and project management tools, and asked me "what one book would you recommend to help me swiftly bridge the gap from theory into modern-practice that would most increase my chances of succeeding" I'd be hard pressed to find another book that I'd recommend more highly than Manage It! Read the full review in the November 2007 Agile Journal.

Continuous Integration: Improving Software Quality and Reducing Risk by Paul Duvall, Steve Matyas, and Andrew Glover published June 2007 in the Addison-Wesley Signature Series My rating: Outstanding! For those of you seeking a book on the subject of Continuous Integration (a.k.a. "CI") ... look no further. The book you have got to run out and get is here! No other book to date even comes close to being such a comprehensive and authoritative source of principles, practices, and current technologies and resources about continuous integration. Read the full review in the October 2007 Agile Journal (also see the book's website at www.integratebutton.com)

Visual Studio Team System Better Software Development for Agile Teams by Will Stott & James Newkirk published May 2007 by Addison-Wesley Professional My rating: A highly practical and comprehensive "nuts and bolts" guide for how to use Microsoft's Team System to do eXtreme Programming (XP) using the Agile values. Read the full review in the August 2007 Agile Journal (also see the book's companion site at www.bettersoftwaredevelopment.org)

Oh, and don't forget to look for my upcoming review of The Art of Agile Development in the January 2008 issue of the Agile Journal.

Back for more in 2008

I'm back! My apologies for the six month hiatus since my last blog-entry.

I spent most of the latter half of 2008 being thoroughly enmeshed in a "death march" project at work (as compared to the "near-death march" project I worked for the first half of 2007 :-) . I had intended to try blogging at least every other week, and even have a half dozen blog-entries that I had started and planned to "make coherent" but simply didn't get to. You'll probably see a few of those in the coming weeks.

As of 2008 I will return to blogging regularly, at least weekly on average, and occasionally only bi-weekly or sometimes 2X per week. I have some new thoughts about the meaning of "Agile" CM and CM/ALM Architecture I intend to discuss, as well of plenty of links and resource-lists compile, books to mention, and articles to note (some of them from me ;).

Quick Thinking on Your Feet in the Line of Fire

Do you find it a challenge to both think and act quickly and gracefully in key situations? I ran across three books in the past year all of which have great advice on how to train yourself to do exactly that:

• Quick Thinking on Your Feet: The Art of Thriving under Pressure; by Valerie Pierce


• In the Line of Fire: How to Handle Tough Questions ... When it Counts; by Jerry Weissman


• Improvise This! How to Think on Your Feet; by Mark Bergen, Molly Cox, and Jim Detmar

Maybe this stuff is obvious for a lot of folks who are already skilled at this. Heck some of it is even obvious to me too ... AFTER you learn about it, or while someone is telling you about it. But being able to see it in the moment -- to recognize and identify it, and in less than a heartbeat, respond intelligently and succinctly with grace, civility, shrewdness, and openness, well ... I'm less skilled at that than most (I think) and these are proving helpful to me.

BOOK: Nanoconvergence

The book Nanoconvergence: The Unity of Nanoscience, Biotechnology, Information Technology and Cognitive Science is an utterly riveting short yet well researched, clear and concise text on the coming future of nanocomputing & botechnology and how it will pervade our everyday life every bit as much as barcodes and magnetic strips on credit/debit cards do today. It is both exciting and scary, and really makes you think about software security and quality attributes and regulatory standards and how much more of a role they must be required to play in this science-fiction-becomes-reality future.

I recommend this book, along with a slightly older one called It's Alive: The Coming Convergence of Information, Biology, and Business to get a really good understanding of what this all portends for the future of software and the business and economic ramifications (Think of Enterprise Architecture and how complex it is, then take it all down to the nano-level and meld it with biotech and cognitive science and cybernetics and man-machine interfaces. Then imagine the first Microsoft and Apple releases of the technology and try not to let your skin crawl while being utterly fascinated)

Then go check out www.nanobioconvergence.org

It hurts to even try to wrap my brain around what CM and things like "continuous integration" even mean and how they will be performed and executed in this "new frontier"

BOOK: Design for Trustworthy Software

Design for Trustworthy Software is a rather impressive tome that comprises a compendium of the latest and greatest methods, tools and techniques for system and software design applied to software. It covers Design for Six-Sigma (DFSS) techniques, TRIZ, Taguchi Methods, Quality Metrics, Poka Yoke, 5S, QFD, FMEA, and more.

I expect this book to become a standard reference and graduate-level software engineering text. It is so comprehensive and and yet modern/up-to-date in its coverage. It's a very dry read (and I'm not finished with it yet) and looks to be a comprehensive synthesis of what has been working best in industry for the last 25 years that has only recently (in the past 10 years) been getting some visibility in complex systems software of any significant scale. And it shows how to apply them to software.

BOOK: OOAD 3e - updating the classic

April 2007 marked the release of theObject-Oriented Analysis & Design with Applications, 3rd edition by Grady Booch et.al.

For many, this book was the one that first turned them on to object-orientation as more than just a particular programming language or two, but as an overall way of thinking about how to analyze and design software programs. The book has many classic epiphanies that were precursors to things UML, RUP, patterns and agile development. Booch himself is practically a demi-god of modern software development, architecture and practice.

I guess I've moved on a bit since reading the first edition in the early nineties, because the third edition didn't have as much "zing" for me. And there are so many other good texts around now, that this one reads a bit dry and academic.

I'm actually more interested lately in the work that Booch is doing toward a Handbook of Software Architecture and in his blog.

BOOK: xUnit Test Patterns

xUnit Test Patterns: Refactoring Test Code, by Gerard Meszaros (Addison-Wesley Signature Series, May 2007) is nothing short of FANTASTIC!

As I'm reading through the book, I keep saying to myself "Yes!" and "Aha!" over and over again. This book is very appropros for me right now because I'm dealing with a team that has a legacy codebase and is just trying to develop automated tests and they don't yet have a lot of training or experience refactoring or in automating their own tests, or the xUnit-style tools, much less using all of them together.

This book is EXACTLY what the doctor ordered for my current situation. It covers the basics of test automation styles and frameworks using harnesses and drivers, data-driven as well as other styles and the challenges to be addressed, especially with test setup. It has comprehensive coverage of 68 patterns and an awesome website at http://xunitpatterns.com/ which does a far better job of depicting them than I could on this blog.

If you're trying to get a small group of folks to learn how to do agile-style test-automation and refactoring, this is the book with all the patterns and insight you will want to convey to your team.

'Nuff said!

BOOK: Lean Software Strategies

I reviewed the book Lean Software Strategies for the June 2007 issue of the Agile Journal.

Lean Software Strategies seems to be one of the first books specifically about applying Lean principles and techniques to software development that is not written by the Poppendiecks. When the book first came out, I admit I was put off by several unfavorable reviews at Amazon.com. When I later learned it won the 2007 Shingo prize for excellence in manufacturing research, and saw Lisa Crispin's review at StickyMinds, I decided to give it a second look. I'm glad I did!

Written by Lean experts from two backgrounds, one an academician/researcher and the other an industry practitioner, the style of the book is very different from that of the Poppendiecks. It takes a much more purist (even academic at times) application of Lean production to software development rather than landing squarely on "Agile" or roughly equating the two. I can understand why fans of the Poppendiecks' books, and perhaps those coming from a background that is more "Agile" than "Lean" didn't exactly "rave" about Middleton and Sutton's book. I can also understand the perspective of those coming from a background in Lean production who complain that the Poppendiecks' books are more about "Agile" than "Lean" and that Sutton and Middleton's book is, in their mind, the first book that is truly about applying Lean to Software. I think both camps are "right" in their own way, and that is why I think it is important to read this book in order to gain a broader and deeper perspective of what Lean is and how it applies to software development.

You can read the full review at agilejournal.com.

Upcoming Agile/Lean book reviews

I'm behind in a lot of reading and am finally catching up. As a result I be blogging a LOT about books this month. I have all of the following books (most of which are brand spanking new) that I'll be trying to blog about this summer:

Lean Software Strategies: Proven Techniques for Managers and Developers by Peter Middleton and James Sutton Productivity Press, May 2005

Design for Trustworthy Software: Tools Techniques & Methodologies of Developing Robust Software by Bijay K. Jayaswal & Peter C. Patton Prentice-Hall PTR, August 2006

Patterns of Agile Practice Adoption: the Technical Cluster by Amr Elssamadisy InfoQ online (bound version through lulu.com), March 2007

Object-Oriented Analysis & Design with Applications, 3rd edition by Grady Booch et.al. Addison-Wesley Professional, April 2007

Visual Studio Team System Better Software Development for Agile Teams by Will Stott & James Newkirk Addison-Wesley Professional, May 2007

xUnit Test Patterns: Refactoring Test Code by Gerard Meszaros Addison-Wesley Signature Series, May 2007

Manage It! Your guide to Modern Project Management by Johanna Rothman The PragmaticProgrammer's Pragmatic Bookshelf, June 2007

Continuous Integration: Improving Software Quality and Reducing Risk by Paul Duvall, Steve Matyas, and Andrew Glover Addison-Wesley Signature Series, June 2007

I'm looking forward to writing more about them in the coming weeks!

Lean CM

I found a couple of great resources on Lean CM that are very compatible with the article we wrote last month on Lean-based Metrics for Agile CM Environments.

• Lean Configuration Management – Supporting Increased Value Delivery from Agile Software Teams
  by Jens Norin and Daniel Karlström, in the Proceedings of the 6th Conference on Software Engineering Research & Practice in Sweded (SERPS'06), October 2006 (and also in September 2006 as a Softhouse Whitepaper on Lean CM)
• Gain flexibility & speed with Lean CM
  by Joe Beckett, Plant Magazine, June 2005

I've added these and some others to the list of Agile SCM Articles on the CMWiki.