Monday, January 28, 2008

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:


Thursday, January 24, 2008

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

Monday, January 21, 2008

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!

Thursday, January 17, 2008

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

Wednesday, January 16, 2008

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:
Several of the materials I found were course lectures from various Universities:

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


Tuesday, January 15, 2008

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.

Sunday, January 13, 2008

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

Friday, January 11, 2008

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

Wednesday, January 09, 2008

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.

Monday, January 07, 2008

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

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

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.

Wednesday, January 02, 2008

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