Saturday, December 30, 2006

Essential CVS and Global Outsourcing with VSTS

Just received two new books about version-control tools:
The Essential CVS, 2e book is one of the better CVS books available these days. I think I like it better than the classic one by Fogel, but not quite as much as the Pragmatic Programmers "Practical Version Control with CVS" (still - it's pretty close).

To be honest though, I really dont feel like CVS is very desirable among free Version-control tool offerings when we have the likes of Subversion, Monotone, Arch, and others that support the more recent paradigms and higher-levels of abstractions for working with project-wide streams (branches) and more.

The VSTS book is rather interesting. The "Global Outsourcing" parts of the title, and some of the corresponding content, would likely "turn off" a lot of folks. It even has a brief section about Agile development (to which, you'd think "global outsourcing would be anathema).

Mickey Gousset published a review of the book back in October, and it's worth a read. I mostly agree with the comments he makes. I think the book is pretty good, but there is another one coming soon that I expect I'll like a whole lot better, as well as several VSTS books available from

Still, if you need to do a lot of distributed development across geographically dispersed sites, and want to use VSTS not just for its versioning capabilities, but also the tracking and coordination capabilities, this is probably the book to get.

Sunday, December 24, 2006

Upgrading my Blog -- tagging in-progress!

I've upgraded to the latest version of Blogger now that it's no longer in beta. There are still a few blog-entries I haven't "pushed out" yet. I will be going through my old blog-entries and trying to add "tags" to them.

What that means to subscribers of my blog is that you will see dozens, perhaps even hundreds of "new posts" of "old" blog-entries. You might want to temporarily unsubscribe until you see a subsequent entry from me saying Ive finished "tagging" all/most of my prior blog-entries.

Wednesday, December 20, 2006

Agile Tooling Survey Results

From Pete Behrens' Agile Executive Blog, the results to the Agile Tooling Survey they conducted in October are now available online at

    With over 500 survey responses from 39 countries, we feel this survey
    provides an excellent benchmark for where the agile movement is at
    today and how we are using project management tooling to assist our
    agile processes.

    This report builds a corporate profile of companies that are following
    agile processes today and then uses that profile to analyze how they
    are using project management tooling to support various aspects of
    their agile processes.

It's rather interesting to see what sorts of tools are being used for version-control, defect/issue/enhancement-tracking (DIET), and project planning & tracking, particularly when some high-profile Agilists would have us believe that (other than version control) Agile should "eschew" such tools.

I don't think the problem is the tools. I think the problem is most of them were/are made and used in a non-agile fashion that didn't have the agile way of working in mind. Now that there are some tools out there which do, it seems they are helpful after all :-)

Thursday, December 14, 2006

Product-Line CM in CACM

The current issue of Communications of the ACM is focused on Software Product-Lines for software engineering. It has a number of interesting articles on software product-lines and product-families for large-scale reuse.

It even has a few articles related to CM of product-lines, particularly change-management and variability-management:

Friday, December 08, 2006

Dimensions and Views of SCM Architecture

The November issue of The Rational Edge has three articles that are closely related to my ideas about applying what we know about software & enterprise "architecture" to the domain of SCM/ALM solutions (and another article about an SCM tool vendor "eating their own dogfood"):

Some of you may recall my 4+2 Model Views of SCM Solution Architecture. I've since updated the picture a bit as follows (which Ive now updated over there too), click on the small image below to see a much larger one:

Anyway - reading through the above articles (particularly the one on model "dimensions" and the one on UML+RUP+Zachman together) gave me some more thoughts about my 4+2 views model, such as:

  • I have "scale & diversity" as a dimension of "concerns" that bridge all views. I wonder if that corresponds to the "scale" or "level" dimension referred to the in article on dimensions of system models?

  • I also have change/creation time, and decision binding time as a "dimension" of concerns. It's not explained real well though. I suppose it corresponds to considering both a "static" and "dynamic" perspective for each view. In a sense there are lifecycles (e.g., promotion cycles) for the elements in each view, as well as important times when decisions are committed to, and/or when artifacts or changes are made. When dealing with variation (diversity) across a product or system, the binding-time employed by the solution can be of great importance.

  • By adding a +2 view to RUP/Kruchten's original 4+1, I end up with something that sort of maps to the 6 columns of the Zachman model. Does this mean my 4+2views are really a subset of Enterprise Architecture (EA), or might it mean that its some kind of "bridge" between the two?

  • Does it really make sense for me to have Organization and data combined into a single view, or is Data really a separate view (a +3 view?), or should I not go so far as to equate metrics, queries and reports with "Data", but rather as the requirements for data (and hence the possible "bridge" mentioned above)?

  • What if I compare contrast my 4+2 views with the model or views put forth by any of ITIL, RUP-SE, DODAF, TOGAF, FEAF, or others (see below)? What value does mine add that warrants being its own "thing" instead of just some poor sawed-off wannabe clone of one of the others?

Anyways, these questiosn made me want to go look-up some of these other models and views. I found some pretty good online articles for some of them (I'm sure I missed a few as well). Here they are:

I welcome feedback/comments on any of my thoughts above!

Saturday, December 02, 2006

The Cone of Uncertainty

I came across a great set of responses to an IEEE Software Article by Ted Little that seemed to question the cone of uncertainty. Among the respondents were Phillipe Kruchten and Steve McConnell. This prompted me on a search for resources about the cone of uncertainty. Here is what I came up with:

Does anyone know of others? I'm particularly interested in anything available online by Barry Boehm and also from Steve McConnell. [Updated 2/2/2007 - Steve McConnell emailed me himself with the URL to a recently available article on his website]

Friday, November 24, 2006

Giving Thanks

It is the day after thanksgiving here in the U.S. Many of us have been with extended families eating obscenely large amounts of wonderfully homecooked meals and desserts and remembering what we are thankful for.

I have a LOT to be thankful for right about now. My surgery was a success and I'm still healthy. More importantly my sister is doing well with her new kidney, and we are both thankful for that, and for our children and our families (our entire family was incredibly helpful and supportive to the both of us - it's amazing to have a family like that)!

Like I said, I have a lot to be thankful for. And yet, I'm also rembering that today is a year to the day since John Vlissides passed away after a long-term battle with cancer.

John was not only co-author of THE seminal work on Design Patterns, he was also the series editor for the SCM Patterns book: he encouraged Steve and I to write it and was a mentor to us both. I would encourage folks to (re)visit the wiki-page created in John's memory.

During this time of year with the winter holidays coming, many of us give money to charities. Before John battled cancer he endured the loss of one of his own children to cancer as well, and his favorite charity was the Children's Cancer Fund (for obvious reasons). This year, I'm also a big fan of the National Kidney Foundation as well as the National Multiple Sclerosis Society (both for personal reasons).

Give Thanks! And Give Generously! :)

Saturday, November 18, 2006

The Buildmeister's Guide

I received a copy of the book The Buildmeister's Guide: How to design and implement the right software build and release process for your environment, by Kevin A. Lee, who runs (the book is also available on

I really liked Kevin's earlier book on ClearCase, Ant and CruiseControl: The Java Developer's Guide to Accelerating and Automating the Build Process. Even though it was specific to ClearCase it had a lot of really good information in general about build/release process automation. The Buildmeister's Guide "builds" on that (no pun intended) and covers build automation tools (such as CruiseControl and BuildForge) as well as Version Control in general (including tool selection and branching/merging policies). It also covers more than just Java, and has sections on other language & environment factors like .NET and C++.

All in all, it looks like a very good, and short (~110 pages) guide for beginning and intermediate build-meisters to learn a whole lot more about effective practices, resources and tools for software building and releasing.

Saturday, November 11, 2006

Simplicity in Better Software

Back in May of this year I blogged about how Simple ain't Easy: Myths and Misunderstanding about Simplicity. That entry ended up being quite popular and very well received.

This month, a streamlined version of that entry is the featured article in the "Last Word" column for the November 2006 issue of Better Software magazine. The writing is a bit more compact, though I did end up having to trim a few thoughts I had really wanted to keep. The quotations and links from the original entry didn't make it into the article, but were instead made part of the online "Sticky Notes" for the November issue.

For those with access to the printed magazine who have a chance to read both the article and the blog-entry, I'd appreciate your feedback as to whether you like the article better, or the blog-entry better, and why.

Sunday, November 05, 2006

Surviving CMMI, Lean Sigma, ISO-9000 and Surgery

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.

Monday, October 23, 2006

Mind Hacks and Surgery

This will be my last blog-entry for at least a couple of weeks. I'm going in for surgery tomorrow to have my kidney removed and transplanted into my sister. It will take me about two weeks to recover to the point where I can sit in front of the computer for any length of time - and another two weeks before I return to work. (Well wishes and prayers for both my sister and me will be warmly welcomed :-)

I received two pretty cool books from O'Reilly the other day. They're not your normal fare. And I havent finished either of them yet. But I'm leafing through them and they both look waaaayyy cool and extremely useful:I'm looking forward to making my way through the rest of these two books and learning more about how my mind works and how to make better use of it (and better "maintain" it :)

Monday, October 16, 2006

Scaling Agility: Summary of Resources

I published a bunch of entries with numerous resources on different aspects of Scaling Agility. I wrote most of them several days apart but many of them got "pushed out" (published) together in sudden bursts. Here they are again:
Feel free to post a comment with other links are anything you feel warrants a new category (e.g., melding Agile with any of Lean, TOC, or Six Sigma)

Tuesday, October 10, 2006

Lean view of Deming's 14 Points for Management.

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.):
  1. The world has changed and managers need to adopt a new way of thinking. Delays, mistakes, defective workmanship and poor service are longer acceptable.

  2. Quit depending on inspection to find defects and start building quality into products while they are being built. Use statistical process control.

  3. Don't choose suppliers on the basis of low bids alone. Minimize total cost by establishing long term relationships with suppliers that are based on loyalty and trust.

  4. Work continually to improve the system of production and service. Improvement is not a one-time effort; every activity in the system must be continually improved to reduce waste and improve quality.

  5. Institute training. Managers should know how to do the job they supervise and be able to train workers. Managers also need training to understand the system of production.

  6. Institute leadership. The job of managers is to help people do a better job and remove barriers in the system that keep them from doing their job with pride. The greatest waste in America is failure to use the abilities of people.

  7. Drive out fear. People need to feel secure in order to do their job well. There should never be a conflict between doing what is best for the company and meeting the expectations of a person's immediate job.

  8. Break down barriers between departments. Create cross-functional teams so everyone can understand each-other's perspective. Do not undermine team cooperation by rewarding individual performance.

  9. Stop using slogans, exhortations and targets. It is the system, not the workers, that creates defects and lowers productivity. Exhortations don't change the system; that is management's responsibility.

  10. Eliminate numerical quotas for workers and numerical goals for people in management. [We add: Eliminate arbitrary deadlines for development teams.] This is management by fear. Try leadership.

  11. Eliminate barriers that rob the people of their right to pride of workmanship. Stop treating hourly workers like a commodity. Eliminate annual performance ratings for salaried workers.

  12. Encourage education and self-improvement for everyone. An educated workforce and management is the key to the future.

  13. Take action to accomplish the transformation. A top management team must lead the effort with action, not just support.

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 escapes me at the moment) on the relevance (or lack thereoff) of Deming's writings and philosophies in the world of today.

What are your thoughts?

Sunday, October 08, 2006

Aikidoka Leadership, Influence and Conflict Resolution

There are a few good books about conflict resolution & leadership that use Aikido style/philosophy throughout. I highly recommend them for anyone interested in the connection between leadership and martial arts philosophy:

There must be some of you out there who have some other links to share on this topic! Leave a comment with your favorites!

Wednesday, October 04, 2006

Scaling Agility: Distributed Agile Development

Current issues of IEEE Software, CACM, and ACM Queue have articles related to agile distributed development and release management ...

The Sept/Oct 2006 issue of IEEE Software is about Global Software Development. It has several Agile-related articles (like A Practical Management and Engineering Approach to Offshore Collaboration)

This months CACM theme is "Flexible and Distributed Software Processes" with articles on distributed agile development (which are currently available online), including:
ACM Queue an article on Agile/Iterative Release Management entitled Breaking the Major Release Habit.

Other resources on Distributed Agile Development:

Also, although it's not specific to Agility, the book Software without Borders appears to have some good reviews by several folks who are well-respected in the Agile community (also check out the online references section of the book.

Saturday, September 30, 2006

Scaling Agility: Agile Program Management

Over the past months I've come across a bunch of good links & papers on the topic of "Going Agile" at the program-level:

Michele Sliger (of Rally Software Development) has several good articles and presentations on Relating PMBOK Practices to Agile Practices
On using Agile methods in organizations with a stage/gate approach to program management, see some of Per Runeson's work in this area:
Murray Cantor has some good papers on Governance and Variance as it applies to Agility:
Some other papers & resources:

Those interested in some advanced agile planning concepts should look at Jeff Sutherland's paper on Scrum II - The Future of Scrum: Parallel Pipelining of Sprints in Complex Projects (and the presentation slides that go with it)

There are several REALLY GOOD whitepapers on Adopting & Scaling Agile at Rally's Agile Knowledge Portal, including the following in particular:

There's gotta be some other good stuff out there and Agile Portfolio, Program and Multi-Project Management! If you know of any - please add a comment and hyperlink or URL!

Thursday, September 28, 2006

Scaling Agility: Agile Systems Engineering

Over the past months I've come across a bunch of good links & papers on the topic of "Going Agile" at the program-level for large systems and systems of systems. Some of these relate to Agile program Management and others are more about Agile Systems Engineering (and some relate to both). I'll mention the ones on Agile Systems Engineering in this blog-entry and leave the ones on agile program management for a subsequent entry:

That's the best I came up with. If you know of other good links on this topic, please send me a comment!

Tuesday, September 26, 2006

Scaling Agility: Adapting Agile to the Organization

Here is a list of resources I've found that I feel are applicable in figuring out how to scale Agility for a large organization and project. (On the subject of metrics and values, I personally find Sam Guckenheimers work to be of greatest interest):

Additions and corrections are welcome!

Thursday, September 21, 2006

Scaling Agility: Seamless Agility across the Enterprise

David Anderson writes about the recent Agile2006 conference in his blog-entry Thoughts for Agile2006:

Scaling Agile. The BIG issue for this year is scaling agile across a whole organization. I see this as having three parts - program or multi-project management and the rollup of schedules and resource plans to a Director or VP level; architecture and enterprise level modeling of a domain and data center; and finally configuration management including build, integration, branch and merge strategies, and work-in-progress batching and related communication.

Ive been dealing with this topic a LOT lately in my own organization as part of efforts to spread amd adapt Agile methods across a large distributed enterprise working with large systems and teams. Ive been researching and collecting lots of resources, including some earlier blog-entries on Agile CMMI and Dancing Elephants and Agile Adoption across the industry.

My perceptions of where the "seams" of the enterprise are that are hardest to introduce Agility into are the close collaboration and alignment required across organizational (lifecycle discipline) boundaries and geographic boundaries (and I find the former to be more difficult to surmount than the latter.)

If I try to categorize them as different areas or aspects that each require the ability to be agile, I come up with something like:
  • Process - Adapting Agile to the Organization (making processes responsive to change)

  • Product - Agile Systems Engineering/Architecture (making the requirements & architecture be responsive to change)

  • Project - Agile Program Management & Governance (making the project be responsive to change)

  • People - Distributed Agile Development (collaborating across multiple sites, teams, and timezones)

  • Organization - Agile Metrics/Reporting, Governance, and Organizational Design

  • Environment - Agile CM, deployment, operation/support, etc.

I'll be blogging separately with lists of resources of found for several of the above.

Monday, September 18, 2006

TEA-Time - a metric to elicit TDD behavior?

I've been thinking about a metric that might elicit Test-Driven behaviors in my organization. As a first step to TDD, we definitely want folks to create automated tests as much as feasible and execute them frequently. Once they get that, I've been thinking about what sort of metric might encourage them to actually work in short, test-driven cycles, where requirements are elaborated test-by-test (given a use-case or story, write the first test, write the code to pass the test, refactor, rinse-lather-repeat).

Some of these folks are very much ingrained in a systems engineering V-model lifecycle that does a lot of big-requirements up-front. So ensuring they work to automate tests and execute them frequently isn't enough to enourage them to use an interative approach of fine-grained TDD-style elaboration. An idea I had for what to measure is something I chose to call Test-Execution Availability Time, or TEA-Time (I figure if nothing else, my friends in the U.K will like the name :-).

As proposed, Test-Execution Availability Time (or TEA-Time) would be defined as the mean time between when a system requirement description is first baselined, and the time at which a "sufficient" number of automated tests for the requirement were implemented and ready (available) to be executed.

I was thinking that if a group was measuring this and wanted to behave in a way that minimized TEA-Time, it might encourage them to elaborate requirements in an iterative and incremental fashion, in smaller and smaller "functional slices". One thing I'm not sure of is what "a sufficient number of automated tests" should be in the above.

Any thoughts or comments?

Friday, September 15, 2006

REVIEW: Practices of an Agile Developer

Are you a developer who wants to improve your personal development habits in a way that helps not just yourself, but also incrementally improves your project and your team? If so, then run, don't walk, and get your hands on Practices of an Agile Developer: Working in the Real World by Venkat Subramaniam & Andy Hunt, from the Pragmatic Programmer's Bookshelf.

Want to know more about why? Then read the complete review in the September issue of The Agile Journal (the theme for September is Collaboration and Reuse).

Tuesday, September 12, 2006

Agile CM on YahooGroups

As mentioned in an earlier blog-entry, I have created an Agile CM Yahoo Group. The description is:
The agile-cm group is for the discussion of ideas relating to Configuration Management for Agile development and of applying Agile concepts, methods and tools to the practice of Configuration Management itself (and CM "Patterns"). This includes aspects of CM that relate to agile development, refactoring & design patterns, agile project-management, Lean, Theory of Constraints (TOC), even SixSigma and CMMI to the extent that they can help CM and related practices to be more "agile".

As I wrote earlier, I hope this new agile-cm group will have a healthy balance of both SCM folks and Agile development folks so we can have some constructive multi-faceted discussions.

Saturday, September 09, 2006

How I Blogged my Summer Vacation

Some of you may have wondered what the heck happened to my blog during August and the first half of September. Well - I lost some write-access to my website for a lot of the summer (while my host was recovering from a denial of service attack) and I couldn't login and update it.

I had several blog-entries "queued up" simply needing some final cleaning-up before I made them live, and that got interrupted, then I couldnt access them, then I had some vacations/travel, then I needed to "catch up" when I got back to work, and so on ...

So over the next week or two I'll be "pushing out" the entries I wrote-up in August, using the date they were originally written. I'll also be making available the talk I gave in July at Architecture & Design World 2006 on the subject of "SCM Patterns for Agile Architectures."

In October/November I may not be blogging much at all as I'll be trying to recover from major surgery (I'm giving one of my kidney's to a family member).

Monday, September 04, 2006

Relating SCM Patterns to SCM Principles

Our August Agile SCM column in the CM Journal is about Relating SCM Patterns to SCM Principles. The article is pretty flimsy, barely a skeleton, and that's pretty much entirely my my fault. I meant to write more "meat" about how certain principles are the underlying forces behind several patterns. I wanted to show how the principles are strongly related, much the same way patterns in a pattern language are related. And I wanted to show how that structure shaped the relationships between the patterns as well. Rob did a really good job trying to put together what I had with what he could come up with, but I didn't really give him enough and couldn't easily convey it in a way that made it easy for him to "run with it!"

It's not that I don't see those relationships, I do. And I'm not lacking for words to describe them either. I'm having trouble describing them clearly and concisely. A big part of that is because I still don't like the names of the SCM Principles as I've described them so far. Their names currently relate to the OOD Principles they were derived from. I think that might speak to programmers, but not to folks trying to do version control (even if they also wear "developer" hats). I really want to go back and rework the names of the principles to be more simple and direct.

This is something Ive been working in my mind on and off for alkmost a decade now. To me, it is of profound important - perhaps even the most significant contribution I'll have made to the field of SCM to date. THe interest level doesn't seem to be so high on the scm-patterns list and the forums (but that hasn't deterred me - yet :). I really do think it's not a coincidence that principles of object-oriented design also manifest themselves as fundamental principles of SCM solution design (because I think both are all about architecture - and minimizing and managing dependencies).

I'd really like feedback. On this stuff so if you've had a chance to read thru the June, July and August Agile CM columns, I'm going to create a new YahooGroup about Agile-CM for discussing these and other Agile CM issues. Hopefully this new agile-cm group will have a healthy balance of both SCM folks and Agile development folks so we can have some constructive multi-faceted discussions.

Tuesday, August 29, 2006

More SCM Books in 2006

Some more SCM books have come on the market in the past 6 months or so. Several of them are worth a look: I realize Practical Perforce isn't new - I just can't stop gushing about how great it is! Laura Wingerd really has a gift for elegantly and simply stating important (and sometimes profound) insights about SCM, particularly when it comes to component/container-based SCM and codeline branching and management.

Global Outsourcing with VSTS looks interesting - not really sure if I like it enough to recommend it just yet. It certainly has an attention grabbing title.

The 2nd edition of Pragmatic Version Control using Subversion is just as outstanding as the first edition. It is my first choice for an introducitory book on Subversion and Version Control.

Kevin Lee's book on using ClearCase, ANT and CruiseControl is nothing short of outstanding. If you're a Java-shop using ClearCase and want lots of practical tips and tactics for doing automated builds and accelerating the build process, this book is a MUST HAVE! Kevin's website is also a great resource. Now that IBM/Rational has acquired BuildForge I imagine their will be updates at his website (and eventually a 2nd ed?) about using Clearcase with BuildForge (and maybe some stuff regarding Maven2?). He apparently has some new (online PDF-only) book out called The BuildMeister's Guide from a new series/publisher called Buildmeister books.

Pulsipher and Buckley did a great job in their earlier book The Art of ClearCase Deployment. Now they have a similar book about ClearQuest entititled Implementing IBM Rational ClearQuest: An End-to-End Deployment Guide. So far it looks very good. It's also the only ClearQuest book I know of - so If youre using ClearQuest for anything but a small or informal project you probably should get your hands on this book in a hurry!

Thursday, August 24, 2006

Everyone wants to be LUVEd!

I had a posting on Scott Berkun's project management (pmclinic) list that was rather well received. I thought folks here might be interested in it ...

Someone else had written:
> I've found that powerful people respect people who do not back down from them. Make your point forcefully.

I responded with:
That could backfire really badly! That might work with some, for others it will only make things worse. Either way, what they are looking for is respect for their perspective. They want to be LUVed:
  • Listened to,
  • Understood, and ...
  • Valued.
Making any assumptions about what it means to them to be LUVed and what behaviors they feel demonstrate LUV could easily be jumping to conclusions down a very wrong and unconstructive path.

Chances are the "annoyance" is because, somewhere, somehow, the two people involved have different notions of what it means to feel respected and to be treated respectfully and be LUVed. What you regard as disrespectful and disruptive may seem just the opposite to him. He may feel that by giving what you say substantial thought and vocalization on multiple sides to be an act of mindfulness rather than dissension.

I would suggest getting together one-on-one for an open, honest, and candid yet compassionate discussion about what each of you need and what you should/can expect from one another. Dont attribute feelings/motives/intent to him, instead describe his (or her) actual, factual, observed behavior and how it makes you feel, what that makes you think, and its consequences/impact on you and others.

Something is certainly out of alignment between the two people in question, but it may not be objectives or intent, but rather differences in values and belief as to what constitutes respect, progress (versus disruption) and what things are most/more important for overall success.

So in terms of advice, I would add an 'E' to the end of the LUV acronym to make it LUVE: Listen, Understand, Value/Validate, Empathize:
  • Listen attentively to what the other person has to say
  • Understand it to the best of your ability (you don't have to agree with it, just "seek first to understand")
  • Value/Validate what was said. That doesn't mean agreeing with it; It does mean finding the value in it and validating that value to the speaker.
  • Empathize with the speaker. Try to identify the feelings they are experiencing and demonstrate your understanding of it, and that it is okay for them to have those feelings.
I wish it was as easy to do habitually as it was to write about. If I could develop the above habit, I would be 10X more effective in both my personal and professional life!

Saturday, August 19, 2006

Agile Adoption across the Industry

I've been needing to do some research into the apparent state of Agile adoption & usage across the industry. For those who are interested, here are the URLs I have gathered (some of them are pointers to excerpts or abstracts that you have to register and/or pay to read the entire article - but I found other URLs that summarized the information in them).

Agile Survey Results
Other Articles and Reports on Agile Adoption:
[updated 14 Sept with articles from and]

Monday, August 14, 2006

Relishing Ruby and Rails

I've been trying to keep-up with what's going on in the scripting world. Perl6 still isn't out yet. And Ruby and Groovy seem to be the hottest and most popular & promising.

Groovy is still trying to win support and evolve to a JSR implementation, and achieve a big following. Not clear yet if it's going to succeed or if it has stalled out. The attempted revival of the "Practically Groovy" series at IBM developerWorks suggests maybe it's still alive and kicking.

Ruby is positively on Fire! And Rails is a big part of the reason for that (though there is a similar "Grails" project for Groovy). I've been wading my way through books on Ruby. The best ones were from the PragmaticBookshelf, but now O'Reilly has a some good Ruby books too. So now my Ruby reading list is as follows (I'm about half-way through it):

So far, it seems like Ruby and Rails is an amazingly hyperproductive language and fraemwork that takes what many feel are the best of Smalltalk, Python, and Perl, makes it fun and elegant, and makes web development and enterprise integration for simple to glue together production-quality stuff in less than half the usual time.

So right now I would say that Ruby (and Rails) seems to be winning out over Groovy, and some (including Bruce Tate) even think it's beating out Java. I guess we'll see. Right now Ruby (with Rails) appears to lay claim to the title of scripting language with the fastest growing popularity and user-base.

Saturday, August 12, 2006

Some Good SQL Books

I've been needing to "brush up" on my SQL and RDBMS skills (let's just say it's been a while :-). I found the following books from O'Reilly and Addison-Wesley to be extremely useful, in order of increasing usefulness:
The first two above are from Addison-Wesley. I found them to be good for a "quick review" for someone who used to do SQL and RDBMS extensively 10+ years ago but whose knowledge is a bit rusty and outdated.

The second two books above are from O'Reilly. I really like the two O'Reilly SQL books! I refer to them the most right now. The SQL Cookbook updated a lot of my existing knowledge and added to it, and the Art of SQL is fantastic! I just love the way it uses Sun Tzu's "Art of War" to apply to winning the "war" on DBMS and DBM complexity!

Sunday, August 06, 2006

SCM as the Architecture of the Evolution of Architecture

One thing I particularly liked about my presentation of "SCM Patterns for Agile Architectures" at the Dr Dobbs Architecture & Design World 2006 conference in downtown Chicago...

I offered up several definitions or perspectives of SCM, including a traditional description, an Agile one, and an architectural one. I liked my architectural definition (I hadn't used that one before - I had used the other two in previous definitions). I said that, from an architectural perspective:

"Configuration Management is the Architecture of the Evolution of your Architecture!"

I rather liked that! I sort of used that to justify the title of the presentation, and presented an IEEE definition of architecture, along with Kruchten's 4+1 views model of software architecture. I then used that to justify my 4+2 model views of SCM/ALM solution architecture. I updated my drawing of the 4+2 model a bit. I think the addition of the Who+When+When+Where+Why+How shows how it may be a possible "bridge" between the Zachman Framework and the 4+1 views model.

Once again, the presentation is here. Feedback is welcome!

Friday, August 04, 2006

SCM Patterns for Agile Architectures

Back in Mid-July I gave a presentation on "SCM Patterns for Agile Architectures" at the Dr Dobbs Architecture & Design World 2006 conference in downtown Chicago.

I gave a 90 minute presentation, and I had 100 powerpoint slides. I had no intention of covering all of the slides. I had the presentation split up into an intro, plus 4 subject areas. In "Agile" fashion, I planned to do "dynamic prioritization for fixed-scope time-boxing" by polling the audience to see which sections were most interesting to them (and which patterns within which sections were of greatest interest). I figured we'd get through the introduction (which has an updated picture of my 4+2 views model of SCM/ALM architecture), and then 2 of the 4 remaining sections (3 at the very most).

I ended up making it through all of the sections and finishing on time - but I couldn't have done it without skimming quickly over the individual patterns/slides that were of least interest for my audience. Overall, I think it went pretty well. I probably wasn't animated or charismatic enough in my presentation style and should vary my tone of voice a bit more. The pictures I used were very cool and very apropos, and very well received (which is good cuz I spent a TON of time finding ones I liked that had copyrights I could use).

For those who are interested, I've made the slides available here. I welcome your feedback in improving them!

Sunday, July 30, 2006

The New Rules: Agile beats Big

The July 24 issue of Fortune Magazine has an article entitled The New Rules as the cover story, with the cover saying "Sorry Jack! Welch's Rules for Winning Don't Work Anymore (But We've Got 7 New Ones That Do)"

I think the new rules it discusses are very much about "Agile is better than Bigger!" and "Bigger isn't necessarily better!" The list of new rules is:
Old Rule: Big Dog Owns the Street.
New Rule: Being Agile is Best; Being Big can Bite You!

Old Rule: Be #1 or #2 in Your Market.
New Rule: Find a Niche, Create Something New.

Old Rule: Shareholders Rule.
New Rule: The Customer is King.

Old Rule: Be Lean and Mean.
New Rule: Look Out, Not In.

Old Rule: Rank your Players; Go with the A's.
New Rule: Hire Passionate People.

Old Rule: Hire a Charismatic CEO.
New Rule: Hire a Courageous CEO.

Old Rule: Admire my Might.
New Rule: Admire my Soul.
All in all I thought it was pretty fair-minded. There was even a sidebar to the article that gave Welch a chance to respond to the criticisms. You'll probably need to read the article for further insight into what exactly is meant by each of the "new rules" above. There was plenty of commentary across the industry on the article! (Just Google on "The New Rules" +Fortune +"Sorry Jack" and look through the results)

Monday, July 24, 2006

Agile SCM Principles - From OOD to TBD+CBV+POB

I finally finished a set of articles I'd been working on for almost 10 years on and off on the subject of "translating" principles of OOD into principles of SCM. See the following:
The principles of OOD translated into principles of Task-Based Development (TBD), Container-based Versioning (CBV), and Project-Oriented Branching (POB).

Here are the principles that I translated. Most of them are from Robert Martin's book Agile Software Development: Principles, Patterns, and Practices, but a couple of them are from The Pragmatic Programmers:

Here is what I ended-up translating them into. Note that some of the principles translated into more than one principle for version control because they applied to more than one of changes/workspaces, baselines, and codelines. I'm not real thrilled about the names & acronyms for several of them and am open to alternative names & acronyms:

    General Principles of Container-Based Versioning
    The Content Encapsulation Principle (CEP) All version-control knowledge should have a single authoritative, unambiguous representation within the system that is its "container. In all other contexts, the container should be referenced instead of duplicating or referencing its content.
    The Container-Based Dependency Principle (CBDP) Depend upon named containers, not upon their specific contents or context. More specifically, the contents of changes and workspaces should depend upon named configurations/codelines.
    The Identification Insulation Principle (IDIP) A unique name should not identify any parts of its context nor or of its related containers (parent, child or sibling) that are subject to evolutionary change.
    The Acyclic Dependencies Principle (ADP) The dependency graph of changes, configurations, and codelines should have no cycles.
    Principles of Task-Based Development
    The Single-Threaded Workspace Principle (STWP) A private workspace should be used for one and only one development change at a time.
    The Change Identification Principle (CHIP) A change should clearly correspond to one, and only one, development task.
    The Change Auditability Principle (CHAP) A change should be made auditably visible within its resulting configuration.
    The Change/Task Transaction Principle (CHTP) The granule of work is the transaction of change.
    Principles of Baseline Management
    The Baseline Integrity Principle (BLIP) A baseline's historical integrity must be preserved - it must always accurately correspond to what its content was at the time it was baselined.
    The Promotion Leveling Principle (PLP) Define fine-grained promotion-levels that are consumer/role-specific.
    The Integration/Promotion Principle (IPP) The scope of promotion is the unit of integration & baselining
    Principles of Codeline Management
    The Serial Commit Principle (SCP) A codeline, or workspace, should receive changes (commits/updates) to a component from only one source at a time.
    The Codeline Flow Principle (CLFP) A codeline's flow of value must be maintained - it should be open for evolution, but closed against disruption of the progress/collaboration of its users.
    The Codeline Integrity Principle (CLIP) Newly committed versions of a codeline should consistently be no less correct or complete than the previous version of the codeline.
    The Collaboration/Flow Integration Principle (CFLIP) The throughput of collaboration is the cumulative flow of integrated changes.
    The Incremental Integration Principle (IIP) Define frequent integration milestones that are client-valued.
    Principles of Branching & Merging
    The Codeline Nesting Principle (CLNP) Child codelines should merge and converge back to (and be shorter-lived than) their base/parent codeline.
    The Progressive-Synchronization Principle (PSP) Synchronizing change should flow in the direction of historical progress (from past to present, or from present to future): more conservative codelines should not sync-up with more progressive codelines; more progressive codelines should sync-up with more conservative codelines.
    The Codeline Branching Principle (CLBP) Create child branches for value-streams that cannot "go with the flow" of the parent.
    The Stable Promotion Principle (SPP) Changes and configurations should be promoted in the direction of increasing stability.
    The Stable History Principle (SHIP) A codeline should be as stable as it is "historical": The less evolved it is (and hence more mature/conservative), the more stable it must be.

You can read the 2nd article to see which version-control principles were derived from which OOD principles. Like I mentioned before, I'm not real thrilled about the names & acronyms for several of them and am open to alternative names & acronyms. So please share your feedback on that (or on any of the principles, and how they were "derived").