•
•
•
•
My Agile SCM co-authors Rob Cowham, Steve Berczuk, and myself have written an article for the May CM Journal on An Agile Approach to Release Management
We're relatively pleased with the article, and all collaborated together quite well.
I received my program for the Better Software Conference & Expo this coming June 9-12 in Las Vegas (alas, I will be unable to attend). The description for the keynote that will be given by Jean Tabaka caught my eye. Jean Tabaka is an Agile Coach from Rally Software Development and the author of Collaboration Explained: Facilitation Skills for Software Project Leaders).
Her keynote is entitled "Attacking Waste in Software: Three Practices We Must Embrace Now" and the abstract is as follows:One of the seven principles of Lean Thinking is “eliminate waste.” Eliminating waste means minimizing the cost of the resources we use to deliver software to our stakeholders. Jean Tabaka proposes three pivotal practices that we must embrace to aggressively attack waste in software delivery —- Software as a Service (SaaS), Community, and Fast Feature Throughput:
When IT and all software organizations embrace these practices, they will eliminate waste within their organizations, reduce the waste that consumes our entire industry, and ultimately support the broad 21st century global mandate to manage our scarce resources.
I can't help but think how these same "pivotal practices" apply equally well to Agile CM, resulting (presumably?) in Software CM as a Service (SCMaaS), Community, and Rapid Change-Flow (where the latter refers to both quickness and responsiveness of change assessment and approval, as well as to development velocity as the changes flow through codelines and become integrated, built, promoted and released).
My review of Lean Project Management is in the February 2008 issue of the Agile Journal.Lean Project Management: Eight Principles for Success, is actually a second edition of the eBook Eight Secrets to Supercharge your Project with CCPM. It is available both in hardcopy and eBook formats. Lawrence Leach (www.advanced-projects.com) is perhaps best known as author of one of the most comprehensive texts on the subject of Critical Chain Project Management (CCPM). In this book, subtitled "Combining CCPM and Lean tools to accelerate project results," the author essentially integrates Lean Thinking into CCPM, along with elements from the Theory of Constraints (TOC) and PMBoK/PMI. Leach calls the result Lean Project Management or LPM.
... All in all, I found Lean Project Management to be a fairly quick read providing a good overview of some TOC and CCPM fundamentals and how they align with Lean thinking, as well as how Lean thinking can be applied to some of more traditional PMBoK methods. Someone looking for a more comprehensive reference on TOC thinking processes and CCPM would probably be better off reading Goldratt's books, the work of William H. Dettmer, and the 2nd edition of Leach's Critical Chain Project Management. But for those wanting the bird's eye overview with a brief "zoom in" on some of the details, along with how Lean thinking helps tie it all together with some of the more traditional project management methods, Lawrence Leach's Lean Project Management is a nice overview text describing some of the most powerful aspects of TOC and CCPM through "Lean eyes for the PM guy!"
Read the full review
Regarding my previous posting about Software KanBan, much as I really do like it and have nothing but the utmost respect for the likes of Corey Ladas and David Anderson, there is one major quibble I have with some of the stuff being said ...
I think all the stuff saying it is Iteration-less and Iteration-free is a bunch of hooey! I don't agree at all and I think it is extremely misleading to say that Software KanBan doesn't use or need iterative development.
Don't get me wrong - I think I understand where they are coming from. There is often a great deal of recurring and heated discussion on numerous Agile forums about "Ideal" iteration length. I understand how folks can be sick and tired of that (to be honest, I myself never really paid too much attention to those particular discussion threads about ideal iteration-size).
The idea that is new or revolutionary for some is that release/feature content is decoupled from development! One or more features/requests are being worked in parallel, and every two weeks (or however long) some combination of newly developed functionality from those that are ready is selected to be released (rather than before development is underway).
But it seems to me that this is just an application of Agile-style development iterations applied to multi-project management. It is Releases that are decoupled from iterations (and hence iteration-free). But as I see it, the iterations are still present: they are where the development is, on the various feature "projects" that are being developed in an incremental and iterative manner, each at their own rhythm (some might be every two weeks, others might be less frequent, but they all find their pace).
I don't believe for one second that each of those features/requests are specifying and elaborating 100% of their requirements before they start coding anything. Looks to me like, for all but the smallest of requests, they may flesh out a certain amount of requirements up-front (be it lightweight use-cases, or even something a bit more formal), but only to a high-level or medium-level of detail. And from that point on through, the detailed requirements, implementation, and feature-level testing and integration-testing they are proceeding in a VERY MUCH iterative fashion.
It may not be a strict fixed length, in that the rhythm may fluctuate and readjust from time-to-time, but it definitely does have a regular rhythm! The length of any given "iteration" is fixed to the cadence of the feature-team (even if it is a team of 1 or 2). Not all iterations may be the same length, but any given iteration is working to a fixed due-date rather than letting that cycle stretch out until the "scope" is complete.
So don't let anyone tell you that Agile development need not require working in an iterative manner. It most definitely does (and at multiple levels of scale). Just don't assume it means that iterations must always be a property of a "release" as opposed to some other related chunk of work (possibly multiple ones proceeding in parallel).
It is not the releasing that needs to be iterative, it is the development. And if the releases are decoupled form development (which I think is a GREAT idea), then the development of any non-trivial sized feature or request still will need to proceed in an iterative manner according to some regular cadence that gets established.
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:
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:
Happy reading!
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!!!
Jens Norin has written een article about Lean configuration management. There is a lot that I disagree with, but it also gives a lot of things to think about.
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.
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.
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:
I'm looking forward to writing more about them in the coming weeks!
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.
I've added these and some others to the list of Agile SCM Articles on the CMWiki.
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)
by Joe Beckett, Plant Magazine, June 2005
The May issue of the CM Journal is devoted to the theme of CM & Agility. Myself and Rob Cowham wrote an article for it entitled Defining Agile SCM: Past, Present and Future.In our earliest articles on the topic, we defined Agile SCM as "the pragmatic application of sound CM principles & practices in accordance with Agile values, using Lean thinking, to serve the needs of the business!" We wish to elaborate what that means in terms of SCM for Agile development, but even more importantly in terms of how we should apply Agile, Lean and their related principles to SCM processes and procedures.
Basically, we try to emphasize that Agile CM is more than just CM for Agile projects, it also means making CM itself be Agile and using the principles tools and techniques of Agile, Lean, TOC (and even some Six Sigma) for CM. Give it a read through and then give us your feedback!
There is also (finally) a new forum on CMCrossroads.com specifically for Agile CM. Of course one of the discussion topics is "what is Agile CM?" and a lot of detractors saying there is no such thing - that it's just plain old CM for Agile projects and that CM is still CM. I contend it ain't the same old CM, and that Agile CM does more than simply apply classic CM discipline & principles to Agile projects, it also applies Agile/Lean principles, tools and techniques and is just as different from traditional plan-based CM as different architectural styles.
[updated June 1, 2007]
CMMI on the surface is definitely not very inviting to Agile. CMMI can be done in an agile fashion however. If CMMI is something you have a need for, then for secrets of how to do it "Agile-style", and details of success stories and lessons learned, take a look at the following links:
Also see "Integrating Agile Methods", and "Teaching the Elephant to Dance: Agility Meets Systems of Systems Engineering and Acquisition" (and others) from the CSE 2005 Annual Research Review.
The (hopefully) provocative title of today's blog-entry is inspired by Phil Armour's essay "Software is Not a Product!", which is one of many profoundly insightful essay's from his book The Laws of Software Process.
Armour maintains that:The core issue with the business of software is that we misunderstand what software really is. Software is thought of as being a product, it is looked at as being a product, it is mostly managed as if it were a product. But it's not a product... The hard part about creating software systems is not creating them, it is in acquiring the knowledge necessary to create them (correctly).
Therefore:Software is not a product, it is a medium for storing executable knowledge.
Our lack of understanding of this basic fact is one of the key issues facing the software industry. We do not "build systems"—we acquire knowledge. The systems we ship to our customers are actually the byproducts of the real activity, which is to learn.
The business imperative is that the real product is the knowledge that is in the systems we ship to the customer, and we don't manage that at all.
So today, I'll attempt a similarly-themed "riff" about Software CM, beginning with the assertion that Software CM is not a process!
This assertion might seem shocking to some. Other CMers might say they have known this all along, saying CM is a discipline (rather than a process), and that numerous formal definitions of SCM have said this for quite some time: SCM is a "discipline" that "governs" or applies "technical and administrative direction and surveillance" to the functional components of CM (item identification & planning; item storage, versioning & change control; status accounting, audit & review).
If software is a medium for storing executable knowledge, and software development is a knowledge acquisition & creation (learning) activity, then the result of software CM is the medium through which software development changes and collaborative learning must ultimately flow.
If the result of software CM is a medium for the conveyance of changes by executing the knowledge gained from learning, then software CM itself must impose some form of order (structure & rhythm) to achieve this resulting collaborative flow of change-flow.
For me, terms like "order" and "structure" evoke memories from my years participating in the software patterns movement and study+discussion of the works of Christopher Alexander. For Alexander, patterns were all about discovering the innate order in structures that emerged naturally from the recurring attempt to resolve (trade-off) the same set of competings concerns (forces) for the same problem in the same/similar contexts. The resulting structures and their sequencing and interaction is what all comes together as an overall (emergent) architecture.
Hence, I would say that Software CM is an emergent yet intentional architecture that ensures the orderly, efficient flow of software development change & collaboration.
The elements of this Software CM architecture include practices, tools & technology, teams & organizations, valued deliverables & intermediate work-products, changes to and assemblies of these deliverables & work-products, and the set of needed status/tracking reports & measures.
Hmmn, this fits in rather nicely with my 4+2 Views of SCM/ALM Solution Architecture and perhaps even does a good job of tying together SCM with Agile/Lean (collaboration & flow), and software patterns (particularly SCM Patterns :).
So there you have it: Software CM creates the medium through which software development changes & activities must flow. Therefore, Software CM is the intentional architecture of software development change-flow.
What do you think?
[last update: 27-April-2007]
For a colleague at work, I compiled a list of resources covering Lean principles & practices, their integration with Six Sigma and/or Agile development methods, and the application of Lean to software development. I thought others might find it useful, so here it is ...
My paper in this month's issue of The CM Journal is about Lean-based Metrics for Agile CM Environments.
Some readers will recognize some of the content from earlier blog-postings of mine on Codeline Flow, Availability and Throughput, Nested Synchronization and Harmonic Cadences and Feedback, Flow and Friction, but there is also a lot more content there too!This month we take an "Agile" slant on metrics for CM, including the CM process itself. Agility is supposed to be people-centric and value-driven. So any metrics related to agility should, at least in theory, provide some indication of the performance & effectiveness of the value-delivery system, and how well it supports the people collaborating to produce that value. We borrow heavily from the concepts of Lean Production (and a little from the Theory of Constraints, a.k.a. TOC). Let's see where it takes us ....
My surgery went well. I returned from the hospital one week ago and am now able to get around on my own (and do some email :-). My remaining kidney is still learning to do the work of two and will be growing larger in the next couple months (in order to compensate). I'm still dealing with the usual to-be-expected-stuff and hopefully within another couple of weeks I will be mostly back to normal (except that I still need to wait another 2months before trying to lift anything >10 lbs, like my 3yr old & 4 yr old :).
I received a few more books in the mail that look like they will be very helpful to someone like myself trying to introduce/increase Agility in a large corporation that has already committed to the likes of SEI CMMI, ISO-9000 (TL9000 for Telecoms), and Six Sigma.
These books will help someone like me to "speak the lingo" when presenting Lean/Agile principles and practices to those well versed in the above. The Lean Sigma book will (I hope) especially show me how to use the methods and tools of Six Sigma itself to support Lean concepts and techniques.
There has been a really great discussion thread on the Lean Development YahooGroup on the subject of "How do I find bottlenecks?"
I particularly liked a reply by Alan Shalloway that linked things back to W. Edwards Deming's 14 points for management from his Theory/System of Profound Knowledge. Allan's translation has a bit of a "Lean" slant to it, and doesn't explicitly mention eliminating/reducing variation quite so much. Here is how he summarized it:
Re respect for people, the best place to start, IMHO, is Deming. Here are his fourteen points (Chapter 2 of Out of the Crisis, by W. Edwards Deming, MIT Press, 2000; originally published in 1982.):
These go back 60 years. And (I can't help myself) these principles are in the context that process causes 94% of the errors - so work on the process to support the people! (people and process, people and process, people and process, ...) ;)
Alan Shalloway, CEO, Sr. Consultant
Net Objectives, Gold Level Sponsor of Agile 2006.
Integrating people, process and technology through training, coaching and consulting.
Alan's website also has some really great articles, papers, presentations and resources on Agile, Lean, Scrum, XP, Design Patterns, and all things related to Agile development and object-oriented design.
For some slightly different interpretations and summaries of Demings 14 points and Seven Deadly Sins, see the following:
There has also been a thread on another discussionlist (sorry - the name
