Monday, January 28, 2008

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:

Friday, January 18, 2008

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:

Thursday, January 17, 2008

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 ...

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:

"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.

Wednesday, January 16, 2008

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:

“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.”

Sunday, January 13, 2008

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.

Friday, January 11, 2008

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).

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.

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.

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)

Wednesday, January 02, 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 ;).