Quick Thinking on Your Feet in the Line of Fire

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

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


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


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

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

BOOK: Nanoconvergence

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

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

Then go check out www.nanobioconvergence.org

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

BOOK: Design for Trustworthy Software

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

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

BOOK: OOAD 3e - updating the classic

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

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

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

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

BOOK: xUnit Test Patterns

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

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

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

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

'Nuff said!

BOOK: Lean Software Strategies

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

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

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

You can read the full review at agilejournal.com.

Upcoming Agile/Lean book reviews

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

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

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

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

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

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

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

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

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

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

Lean CM

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

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

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

Defining Agile SCM

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.

Five R's of Agile SCM Baselines

Almost a year ago I posted an entry on the "5 C's of Agile SCM Codelines". This time I'm posting on the 5 R's of Agile SCM Baselines. I think these are as follows (note that most of these are not unique to Agile/Lean):

• Repeatable -- The steps to create the corresponding Build (Configuration) from its sources should be repeatable: for any baselined configuration, I should be able to build it the same way, over and over again.
  


• Reproducible -- The corresponding Build (Configuration) should be reproducible: for any baselined configuration, I should be able to reproduce it whenever desired.
  


• Reportable -- The corresponding Build (Configuration) should be reportable: for any baselined configuration, I should be able to report all needed details about its content: what files & versions are in it, which changes/requests are in it, who made which change to what (& when), how it was built and with what tools & options, etc.


• Releasable -- The corresponding Build (Configuration) should be releasable: if I have "baselined" it, then almost by definition, it means it should be of 'releasable quality' to the next downstream consumer. (This implies it should be correct + consistent + complete to the extent agreed upon with the its stakeholders.)


• Repairable -- The corresponding Build (Configuration) should be readily repairable: if, for any reason, it is discovered to have some kind of problem, then I must be able to readily repair it either by retracting it and replacing it with it's predecessor, and/or by removing/repairing the offending content and releasing it as a new (corrected) baseline.

I use the term "reportable" instead of "traceable" here for two reasons: 1) 'traceable' doesn't begin with 'R', and 2) 'traceable' brings to mind many negative associations with manual tracing, rather than simply providing the necessary transparency and ability to trace (without necessarily implying doing all that tracing, much less doing it all manually).

Note also that "repairable" may not imply that the cost of repair is low. Ideally, the repair can be done as quickly as possible by the development organization, but getting it to the consumer(s) may be both costly and time-consuming. So, rather than "low cost", being "repairable" speaks more to maintainability, and the ability to quickly understand the system and what must be done to repair it. We want to repair it with minimal interruption of flow, and with a minimum amount of overhead.

Why is any of that particularly "agile"? Most of it isn't, but the 'take' on reportability certainly is, and the notion of "releasable" may seem agile to those who feel the codeline should (ideally) be in a readily releasable state. CMers would say that "releasability" was always part of what a baseline requires (and they'd be right).

What do you think? Did I miss any other important R's? Or should something else be used instead? Would an additional R-word or two not listed above help differentiate between "Agile" CM versus more traditional CM?

Here are all the other R-words I considered:

Recoverable Reliable Reversible Retractable Retainable Realizable Relocatable Remediable Repealable Replicable Revocable Relapsable Rebuildable Recapturable Reconfigurable Reconstitutable Reconstructible Recordable Recyclable Referable Retrievable Reusable Restorable Renewable Replaceable Representable Respectable Responsible Removable Reachable Readable Receivable Reclaimable Recognizable Recommendable Reconcilable Recreatable Remissible Rectifiable Recuperable Redeemable Reducible

If anyone cares, I looked it up at Dictionary.com searching for "r*ble"

Software CM is Not a Process!

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?

BOOK: Release It!

I just received a copy of "Release It! Design and Deploy Production-Ready Software" by Michael Nygard. This looks to be yet another winner from the PragmaticProgrammers' Pragmatic Bookshelf. In fact it made #1 on Amazon.com's "Hot New Releases" list for Design Tools and Techniques for the past two weeks.

Actually, this book isn't about what I had originally thought from reading the early descriptions. I thought it was going to be related to build+release+deployment engineering (CM guy that I am :). It's not about that at all. It is about architecture and design for production deployment concerns, such as: hardware/software "fit", availability/reliability, operability, stability, capacity, and maintainability (not just of the code, but of the deployed product at the customer's site).

"Release It!" covers all those things many of us software-only, high-level abtractionists forgot (or worse yet, never learned) about design & architecture for where the rubber meets the road. I need to add it to my reading list!

April CM Journal and LDM

The April issue of the CM Journal, and there is a FANTASTIC article in it by Austin Hastings about his Longacre Deployment Management strategy for dealing with database CM. It's long, but well worth the read for the insight into a new way of thinking about and doing CM of a database.

The April CM Basics issue has a companion/predecessor article a Case Study: Enterprise and Database CM the describes the initial problem, motivation and challenges that the LDM approach needed to solve. The LDM article goes into the gory technical details of the solution.

Agile Development Distilled

Lately I've been spending some time thinking about how to distill Agile development within my company on a single powerpoint slide for a top-level Executive. I keep going back and forth between something that shamelessly steals (and modifies) something used to describe RUP, and something that shamelessly steals (and slightly modifies) something from Dan Rawsthorne.

Dan Rawsthorne writes that the "essence of agility is: iteration, validation, feedback." I think something along those lines is ...

Agility comes from rapid feedback & learning in short-cycles using:

• Close Collaboration
  
• Continuous Validation
  
• Frequent Iteration
  
• Dynamic Adaptation

RUP talks about 6 Key Principles For Business-Driven Development:
1. Adapt The Process
2. Balance Stakeholder Priorities
3. Collaborate Across Teams
4. Demonstrate Value Iteratively
5. Elevate The Level Of Abstraction
6. Focus Continuously On Quality

I think an "Agile slant" on that would be:

1. Adapt to Change
2. Prioritize Scope
3. Collaborate Across Teams
4. Demonstrate Value Iteratively
5. Elevate the Level of Automation
6. Continuously Validate Quality

Of course much of this just seems like Steven Covey’s Seven Habits of Highly Effective People. And maybe that is true.

Other sources and quotes ...

Alistair Cockburn writes of Seven Properties of Agile Projects: 1. Frequent Delivery 2. Reflective Improvement 3. Osmotic Communication 4. Personal Safety 5. Focus 6. Easy Access to Expert Users 7. A Technical Environment with Automated Tests, Configuration Management, and Frequent Integration

David Anderson's Agile Recipe for Success is: Focus on Quality, Reduce Work-in-Progress, Balance Demand against Throughput, Prioritize. He also writes "Trust is the essence of Agile"

Jim Highsmith adds that: "Agile Organizations don’t just respond to change; they generate it!"

“Agile development uses feedback to make constant adjustments in a highly collaborative environment." -- Andy Hunt, http://www.sdtimes.com/fullcolumn/column-20060615-01.html

"Short Cycles and Customer Involvement" -- 3rd eWorkshop on Agile Methods

"an inclusive, people-centred approach to doing iterative, incremental software development. It uses a combination of technical and social practices to increase collaboration and reduce feedback cycles" -- Steve Hayes, http://pliantalliance.org/?p=31

"The essence of Agile evolution is to gradually transform a typically conservative, risky and unattractive activity into a positive and proactive development activity." --Dave Thomas, Agile Evolution, http://www.jot.fm/issues/issue_2006_09/column2

See table of "Key Characteristics of Agile" at (Towards an Agile Systems Engineering process)

See Agile Axioms and Seven Core Practices of Agile Development

DSDM in a Nutshell

Getting Real

My Nutshell definitions of Agile Development

Why Agility Works

Scrum Primer

Agile EVM

Allan Shalloway's Agile Explained

Dean Leffingwell with Ryan Martens, Scaling Software Agility, Ch 7 on The Essence of Agile

Not so Agile aspects of Agile Development

The Agile-Oriented Paradigm

More take-offs on Covey's Seven habits are ... Five Habits of Highly Visionary Companies Six Habits of Highly Effective CIOs Seven Habits of Highly Effective Programmers Seven Habits of Highly Effective User Interface Designers Seven Habits of Highly Effective IT Managers The Seven Habits of Effective Iterative Development

From SurgeWorks (http://www.surgeworks.com/our-methodology) ... In a nutshell, Agile Methodologies are focused on delivering maximum business value in minimal time. There are several different Agile approaches, but all of them focus on a similar set of core practices. They are: Iterative development Business prioritization Adaptive to changing/evolving requirements Active user involvement

Defining Design Quality

Nice article on Defining Design Quality at InfoQ.com. The article heavily references the work of James Shore, who is currently working on a book with chromatic entitled "The Art of Agility". It has a pretty nice definition of design quality:

"A good software design minimizes the time required to create, modify, and maintain the software while achieving run-time performance."

It also references a few other nice articles:

• An Artima interview with Erich Gamma which notes that "Modification and maintenance time are more important than creation time."
  
• An article by Alistair Cockburn on programming as theory building
  

This also ties in quite nicely with Agile ideas about "Simple Design" and some earlier blog-postings of mine about Simplicity in Design (and ChangeThis for Simplicity).

Best Kept Secrets of Code Reviews

The folks over at SmartBear software have written a nice little book entitled The Best Kept Secrets of Code Reviews. It's free if you go over to their webpage and ask for it (you have to fill out a registration form, and it takes a few weeks to arrive, but they havent spammed me at all since I registered with them a few months ago).

This is a pretty good book and it is VERY pragmatic! It is applicable to Agile development too! [You don't have to do Pair-Programming to be Agile! Pairing is part of XP, which is one particular agile method -- several other agile methods do not require it.]

SmartBear also has a pretty neat suite of tools that look to me like they would be REALLY USEFUL for an organization trying to streamline some of its otherwise heavyweight processes for peer-reviews and related quality metrics:

• CodeCollaborator - Automation for paperless peer code-reviews
  
• CodeReports - Continuous source code metrics over time.
  
• CodePickle - Suspend & resume code changes in local developer sandboxes (implements the PrivateVersions pattern without using version-control branches)
  
• CodeReviewer - automated peer-to-peer code reviews across remote sites
• CodeHistorian - Data-mining and visualizations for version control systems.

And "No!" they did not ask me to blog or say anything nice about them or their products! I'm simply coming from the perspective of someone in a large organization who has witnessed a lot of homegrown and heavyweight processes and tools for these kinds of things, and don't see too many commercial tools addressing the peer-review aspect of development and trying to make it lighter-weight and better-integrated with version-control and the rest of SCM.

The have some other nice resources too:

• Agile Peer Review: Methods, and Results (Powerpoint Presentation)
• The Case for Peer Code Review
• Brand New Information about Code Reviews
• 11 Best Practices for peer code review
• 2500 Reviews at Cisco® - The Largest Case Study of Code Review, Ever
• Why formal inspections fail
• Team-Building for the Cold, Dark, and Alone
• Compare 5 styles of review
• Pros & Cons of Four Types of Review
• Social effects of peer code review

Looks like a lot of "good stuff" to me!!!

Agile in March RationalEdge & April CrossTalk

The March issue of The Rational Edge and the April issue of Crosstalk are both devoted to the the theme of Agile Software Development this month!

Lean-based Metrics for Agile CM Environments

My paper in this month's issue of The CM Journal is about Lean-based Metrics for Agile CM Environments.

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

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!

Elements of Agile Style

Joe Little has authored a nice little booklet on The Elements of Agile Style

Top-down Agile Adoption in March Agile Journal

The March issue of the Agile Journal is about scaling-agility and agile adoption in the enterprise.

Scaling Agility - new book & blog

Dean Leffingwell, previously known for his book Managing Software Requirements: a Use-case driven approach has just published a new book entitled Scaling Software Agility: Best-Practices for Large Enterprises. He also has a corresponding Scaling Software Agility blog. See the forthcoming reviews on amazon.com.

So how did Dean go from being a requirements-management guru to being a large-scale agile guru? It's not too big of a leap if you think about it! Dean is at Rally Software Development these days (the noted Agile consulting services & tool vendor) and has also authored a few Agile Whitepapers, an essay on The Essence of Agile (now an excerpt from the book), and a few articles for The Agile Journal, most notably Agile at Scale: 7+7 Practices for Enterprise Agility.

SEI Reflections on Agility: Challenges, Dillemas, & the Way Ahead

Interesting paper from Linda Levine and the SEI about Reflections on Software Agility and Agile Methods: Challenges, Dillemmas & the Way Ahead (see the corresponding presentation slides)

Some other related documents from the SEI are:

• Systems of Systems: Scaling Up the Development Process; by Watts Humphrey. SEI Technical Report CMU/SEI-2006-TR-017


• Documenting Software Architectures in an Agile World; by Paul Clements, James Ivers, Reed Little, Robert Nord, Judith Stafford. SEI Technical Note CMU/SEI-2003-TN-023


• Integrating Software-Architecture-Centric Methods into Extreme Programming (XP); by R. Nord, J. Tomayko and R. Wojcik. SEI Technical Note CMU/SEI-2004-TN-036, ADA431084


• Using Earned Value Management (EVM) in Spiral Development; by Lisa Brownsword, Jim Smith. SEI Technical Note CMU/SEI-2005-TN-016

See! Not everything from the SEI is about CMM or CMMI ;-) They also a have a wealth of resources on Software Architecture and Software Product-Lines and other areas of Software Engineering!

Practical Guide to Seven Agile Methodologies

In October of last year over at DevX.com, Rod Coffin and Derek Lane wrote a darn good article (in two parts) that gives a nice, concise overview of seven agile methodologies:

• An Overview of Seven Agile Methodologies -- PART 1
  
• An Overview of Seven Agile Methodologies -- PART 2

Check out some of the other articles at the DevX.com Architecture Zone.

ChangeThis for Simplicity

There are a lot of REALLY GOOD manifestos over at ChangeThis.com! Back in May 2006 I blogged about Simplicity in Design and included several links/resources on the subject. Turns out ChangeThis.com has a few good manifestos on the subject as well (and gets more every month). Here are the ones I liked most:

• Elegant Solutions: Breakthrough Thinking the Toyota Way, by Mathew May -- This is a distillation of Mathew May's book The Elegant Solution: Toyota's Formula for Mastering Innovation (also see the Elegant Solutions blog)


• The Simplicity Cycle, by Dan Ward -- "In the Simplicity Cycle, goodness is a general term that means slightly different things depending on a variety of contexts." In technology, goodness represents operational functionality or utility; for an academic discipline, it represents increased understanding; and for system design it reflects design maturity. If the context is art, maybe goodness means beauty" ... increased complexity does not inherently equal increased goodness, learn more by reading this manifesto.


• The Six Laws of the New Software, by Dror Eyal -- The Six Laws are: Single Idea, Collaborate, Disappear, Simplify, Release, Comply.


• Six Design Lessons from the Apple Store, by Jesse James Garret -- The Six Lessons are: Create an Experience, Not an Artifact; Honor Context; Prioritize your Messages; Institute Consistency; Design for Change; Don't Forget the Human Element!

Other manifestos not necessarily related to the above that I found interesting are:

• Software that Lasts 200 Years, by Daniel Bricklin
• Manifesto to Accelerate: 15 Truths, by Dan Coughlin [added April 5]
• The State of Competitive Advantage, by Mitchell Gooze
• A Manifesto for Mavericks: Why the Most Original Business Minds Win, by William Taylor and Polly LaBarre
• Going for the Go Point: The moment when a decision becomes action, by Michael Useem
• Thinking Through Problem Solving, by Valarie A. Washington
• The Bio-Teaming Manifesto: What teams can learn from Mother Nature
• How to Manage Smart People and Why Smart People Defend Bad Idea, both by Scott Berkun
• Managing with Aloha: Using Hawaiian values to change your business, and your relationships with employees and customers, by Rosa Say
• The Paradox of Choice: Why More is Less, by Barry Schwartz
• LESS: What Customers Want, by Bruce Kasanoff
• The Answer is Biodiesel, by Michael Briggs (Trade-in your Prius and buy a VW! What's better than hybrids and fuel-cells? The answer is biodiesel)
• Beyond Therapy: Biotechnology and the Pursuit of Happiness, by The President's Council on Bioethics
• A Physics of Ideas, by Nova Spivack
• Slacker @ Work, by Brendan Connelly
• Make Art, Not War, by Mary Anne Davis
• The CEO of the 21st Century, by Mark Goulston
• How to be Creative, by Hugh Macleod
• George Lakoff Manifesto, by George Lakoff
• How To Get Better Teachers -- and Treat Them Right!, by Chester E. Finn, Jr.

BOOK on ERP for IT

Charles Betz' book Architecture and Patterns for IT Service Management, Resource Planning, and Governance: Making Shoes for the Cobbler's Children really ought to be required reading for anyone that fancies themselves a "CM professional" (especially Software CM) or an "Enterprise Architect."

I've been following his erp4it blog for over a year now (and his corresponding erp4it YahooGroup). Those looking for a taste of what the book is like can look there, and also at the paper ERP for IT which I understand was an early precursor for the book that has since been vastly updated and expanded in the latter.

Even though the subject of the book and the blog doesnt explicitly scream "CM", the content in the book and the blog are filled with often fundamental and profound insights about CM from the enterprise view (not just IT/ITIL) and where software CM, infrastructure CM, and network/element CM all fit in to the bigger enterprise picture. Several of his post that are among my favorites made their way into the book in some form or another:

• A Data Architecture for IT Service Management -- you'd never know it from the title, but this is practically a primer on what is a configuration and what is a configuration item (and much more)
  
• A Configuration Management Maturity Model
  
• Element versus Enterprise CM
  
• Two key distinctions to help scope your CMDB -- about the difference between Configuration Items and Events (quick - what's the difference between a "release" and a "baseline"?)
  
• Is CM a process?
  
• DBMS Configuration Management -- and the difference between Software CM, Element CM and Enterprise CM
  
• Model-Driven CM
• A Value-chain approach to IT
• A simplified ERP for IT architecture -- the CM system figures prominently in this one
• IT portfolios, service catalogs, and enterprise architecture -- change management (at all levels of scale - including governance) links them all together across the value-chain
• Fundamentals of integration metadata
• A story of too many tools
• A metadata rant
• CMDB Chaos and Confusion: Making Sense of the Madness

And if that weren't enough, the book also puts together three of my favorite topics: CM, patterns, and architecture.

Recursive Make Reconsidered

In an earlier blog-entry reviewing the book Code Craft, I mentioned the classic paper by Peter Miller entitled "Recursive Make Considered Harmful" ...

Anyway, I recently ran across a bunch of webpages that examined or revisited the issue. I thought several of them were worth sharing, so here they are:

• Recursive versus Non-recursive Makefile architectures benchmark
• Recursive Make isn't all that bad
• "Recursive Make Considered Harmful" Revisited
• Recursive Make Reloaded
• Implementing non-recursive make
• Non-recursive make for Linux kernel
• Non-recursive Automake
• Makepp manual pages on recursive make in legacy makefiles and problems associated with recursive makes

Five Things About Me

I've been "tagged" amidst the recent spree of fellow bloggers who are being "asked" to disclose five personal tidbits about themselves that most people don't know. I won't disclose who tagged me, and I won't be tagging anyone else, but I will comply with the request just for the heck of it ...

1. I don’t drink beer or wine – I hate the taste!

When it comes to alcoholic beverages, the only ones I like are those sweet mixed drinks where you can barely taste any alcohol (you know, the ones that are for "sissies").

2. I got inebriated once when I was two years old (in China no less)!

Or so I'm told ... I don’t remember any of it, but as it was told to me, my folks were flying the family to China, and the airline lost our luggage. As consolation, the airline put us up in a hotel and threw a party for us (and several others in a similar situation). Apparently someone spiked the fruit-punch and I never knew what hit me. My sister says I was walking late at night on the shoreline of Taepei, swaggering, swaying, and hiccuping every couple minutes. Eventually my father picked me up and carried me with my head resting over his shoulder, still hiccupping with a giddy grin on my face, pointing at everything I saw and giggling my head off like only a toddler can. (Hmmn – could this explain #1? :)

3. I lived in Taiwan during 1966-1967, and in Hawaii during 1969!

My Dad was a political science professor, and was at the time one of the foremost experts in his field on US-China relations. He would travel to China or Taiwan every now and again for extended periods of time (weeks or longer). One time he took all of us with him and we lived there for a year. In 1969 he had an exchange program with another professor from University of Hawaii on Oahu. Our house was at the top of a very big hill (or a very small mountain :). I went to pre-school at Noalani elementary school in the Manoa valley.

4. I used to be a dancer, and had 20+ years of classical training!

My mom was a dance teacher, and got me started when I was 4 (along with my older siblings). When I got older I decided to stick with it and got to be quite good at it. All in all I had about 20+ years of classical ballet training, along with modern/contemporary, jazz, and a bit of tap and African. I was in a local dance company during my college years and for a short while after. I was good too! I kept up with it until my mid-30s when I was eventually diagnosed with degenerative disc disease. Sometimes guys would try and give me a hard time about my dance background (that's right about the time I would "let it slip" that I also held black-belts in two different martial arts :-)

5. I have Tourette’s Syndrome (TS)

It's noticeable but mild in my case - not like the more pronounced cases you typically see and hear about on TV shows like Oprah or 20/20.

So there it is; I've done the deed!

BOOK REVIEW: Code Craft

Nostarch Press recently published the book Code Craft: The Practice of Writing Excellent Code by Pete Goodelife.

I have to say the book looks pretty "excellent" itself. It may even become a new classic, replacing the old classic "Writing Solid Code" by Steve MacGuire. And if Steve McConnell hadn't recently updated his even more classic "Code Complete" with a 2nd edition, I might even put Code Craft on a par with that. It's that good!

It's not just about programming & design either. Like Code Complete it covers pretty much all of "software construction." It has some good stuff about build, integration, test, source-control, and more.

About my only pet peeve is that in the "Answers and Discussion" section it talks about recursive make versus inclusive make schemes. It has a pretty good discussion, but I couldn't find any reference to the classic paper by Peter Miller entitled "Recursive Make Considered Harmful". That kind of bothered me because I don't think there's any good excuse for it. It also made me wonder if there were some other places I didn't know about where appropriate references/citations were missed or neglected. (It's not severe enough to make me recommend the book any less highly though!)

I would probably put Code Craft on the "REQUIRED READING" list for any relatively new professional programmer, and have them read it just before before reading Code Complete.

Agile CM/ALM in 2007

Every January at CMCrossroads.com the CM Journal focuses on CM predictions for the coming year. My contribution for this year is Agile SCM January 2007 - Looking Back to Move Forward where I reflect on the previous two years' predictions and update them just a bit, with lots of emphasis on Rational Jazz and MS VSTS:

ALF and Corona? or Open-Sourced Jazz?
While there has been activity on the websites for the ALF and Corona projects, we havent been hearing so much about them in the media outside of Eclipse-centric conferences, and press-release announcements from yet another vendor with an Eclipse "compatible" release of their software. While this certainly doesn't shatter the prediction, there has been more attention (perhaps due to more marketing?) about the upcoming ALM collaboration framework from IBM Rational called "Jazz."

Based on the RDSC 2006 Day 2 Keynote presentation (and also at JavaOne), Jazz is touted as the next generation of the Eclipse platform and the team based software development platform. Rational will of course provide a tool-set to go with it, but says it plans to release the overall framework (and code/APIs) under Open-Source. The claim is that the result is an ALM collaboration architecture which is inherently scalable to provide true support for geographicall dispersed development projects in a true collaborative fashion. Well known names from Rational have been presenting Jazz at various conferences throughout 2006 and generating lots of "buzz," as evidenced by articles and blogs like the following:

• IBM is Revamping Rational
• IBM Jazzes Collaboration
• JavaOne 2006: Keynote on Agile Eclipse, Transparency, Honest, and Retrospective
• Rational Jazz Soon to Eat More of It's Own Dog-food: Transparency
• Jazz is the news
• IBM Jazzing up Rational Offerings, from InfoWorld
• IBM to employ open-source development style for tools, from eWeek
• Online Collaboration and Agile Software Development, from Dr. Dobbs Journal
• Big Jazz News on IBM developerWorks blogs
• Agile Requirements Engineering in the Jazz Collaborative Development Environment, from Rutgers 2006 Software Engineering day
• Hot Jazz vs. Cold Beans, blog-entry

Interestingly enough, with all that marketing buzz, Rational was also very clear about that fact that Jazz would not be released until after 2006. So look for even more "hype" and "hope" in 2007 when the first releases of Jazz become available, and especially when the core Jazz infrastructure is released as open-source under the auspices of Eclipse project. It will be interesting to see the impact this has on the Eclipse ALF and Corona projects (which Jazz doesn't currently use, althought it could conceivably make use of Corona in the future) and the Eclipse BIRT project (which Jazz does make use of). Current marketing would suggest that Jazz is the new vision, or more aptly, more likely, the new open-source hope to slay (or at least compete with) MS VSTS

The site founder, Patrick Egan, usually also initiates a discussion thread to engage the readership into the topic, and this year was no exception, as Patrick asked us What needs to change in CM and ALM for 2007. At the end Patrick added "How does CM fair in an increasingly Agile world?"

This sparked the perennial debate about "Agile CM" and whether or not it's any different from more traditional/mainstream CM. Folks wanting to read the whole thread are certainly welcome to do so. I'm going to excerpt what I think are some relevant thoughts from what I posted ...

My thoughts are much along the same lines as Frank's posting. I think we need to raise the level of abstraction of our thinking and problem solving. There are tools that do this, but the problem is that until the "lowest common denominator" tools catch-up, the majority of the state of the practice won't move too far past that (IMHO).

I do think its a good thing that two of lowest common denominator tools on the version-control side seem to be in the process of being supplanted with successors that go further in this direction (CVS -> Subversion, and VSS -> MS VSTS). I don't see as much on the change-tracking side, and integrations still aren't very integrated for the most part.

Regarding "an increasingly Agile world" ... as more and more shops and companies (and vendors) say they are "Agile", the more the term "Agile" becomes diluted and branded, and more of a marketing term than anything else. And that does do damage (as Joe mentioned); In fact it does the most damage to those that are doing it justice.

I do however think that the increased emphasis & visibility on frequent automated integration is a good thing, and that the trend of not only doing more of that, but using that as a mechanism of generating and reporting more (and more accurate) metrics is also a good thing. ...

The term "Agile" and the ideas behind it is no better or different from other "fads" like Object-Orientation or [software/design] Patterns. They had lots of hype and buzz, they had some legitimate improvements to contribute to the state of the practice (even if the ideas themselves weren't new - that's not necessary in order to have great impact/influence), and once everything was all "hyped out" they faded into the woodwork, as a natural, acknowledged, part of the fundamental knowledge we should use+apply everyday.

Increasingly, software CM implementations & deployments will need to better accommodate an increasingly Lean/Agile world (and it will be more important to know the difference between the pretenders and the real-thing). While I agree with Joe and others that the basic tenets of what CM is and what it is supposed to be don't change because of Agile, the fact remains that the norm for how CM is actually practiced and implemented in many shops will need to change.

Many tools/vendors are already headed in that direction, and have recognized the trend foretold by Thomas Friedman (The World is Flat), Peter Fingar (Extreme Competition) and others like Dan Pink, John Seely Brown, and more. With CollabNet, MS VSTS and Rational Jazz, the emphasis is on connecting and collaborating. And ways of doing software development and CM that fail to acknowledge that, and at least the first five of what Steve McConnell calls The Ten Most Important ideas in Software Engineering are going to have a tougher go of things than they have in the past.

As to whether or not "Agile CM" does (or will) exist, that will be determine by the people who end up actually doing it, and defining it. Anything claiming to be "Agile" will need to legitimately embrace the ideals of collaboration and the human element that Agile emphasizes, as well as at least the first 4 of the 10 ideas McConnell identifies. It will also need to embrace Lean principles and techniques. And if I get to have any part in shaping it, I think it should also include heaping helpings of Theory of Constraints (including Critical Chain) and Six-Sigma as they apply to CM and the "throughput" of change-flow, and change management.

All those things have something useful and important to offer us, and for those that can sift thru the hype and wannabees, there are huge gains to be had (whatever the trendy term end up being). I also agree with Bill Langston that there are some relevant standards (as well as "classic" ideas & methods) that are important to maintain, and which must "temper" the application of the newer and trendier (instead of always going back and forth between rigid and unyielding extremes).

Maybe it should be "Jeet Kune Do" CM instead of "Agile" CM :) Because we need to look at the new things and "keep what is useful" without abandoning the old so we can adapt and change as the speed of business and technology mandates.

Blog upgraded -- tagging COMPLETE!

I'm done upgrading my blog to the new version of blogger. Some of you may have already noticed the new template. Although I tried to keep the same scheme, I couldnt keep the title/header section the same, so the font-size there is a bit smaller and my picture has moved to the top-right below the header section. The right hand panel is also a bit different, the "Previous" and "Archives" section have been merged into a a single dynamic "Archives section with a hierarchical listing.

In addition, I finished tagging my blog-entries with labels. The new "Categories" section lists all of the categories and the number of entries in each category (along with a hyperlink to take you to all entries filed under that category).

Oh yeah! I'm also using a newer picture now -- It's amazing just how much one's hair can thin/recede in just a few years :-(

If youre seeing this, then you should no longer need to worry about any more previous entries getting republished "en masse" anytime soon. Very shortly now I'll be "pushing" my last 4 entries "live" in the next couple of days.

Lean Software Development Resources

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

Books:

• Agile Management for Software Engineering, by David J. Anderson, Prentice-Hall PTR, September 2003

• Lean Software Development: an Agile Toolkit, by Mary & Tom Poppendieck, Addison-Wesley, October 2005 in The Agile Software Development Series
• Implementing Lean Software Development: From Concept to Cash, by Mary & Tom Poppendieck, Addison-Wesley, September 2006 in The Addison-Wesley Signature Series
• Lean Software Strategies: Proven Techniques for Managers and Developers, by Peter Middleton & James Sutton, May 2005 by Productivity Press
  
• Managing the Design Factory, by Donald G. Reinertsen, The Free Press, New York, 1997
• Product Development for the Lean Enterprise, by Michael N. Kennedy, Oakela Press, 2003
  

Presentations:

• Lean Project Management, by David J. Anderson
• Agile Management for Software Engineering, by David J. Anderson
• Managing Lean Software Development with Cumulative Flow Diagrams, by David Anderson
• Lean Manufacturing and the Theory of Constraints – Focusing Lean, by Eric Gowland
• Lean Accounting & Throughput Accounting, Peter Milroy
• Lean Six Sigma - Benefits beyond CMMI L3, Nancy POMA, EDS, October 2006
  
• Software and Lean: Like Chocolate & Cranberries, by James S. Sutton, STSC 2005 Proceedings
• Lean Software Development, by Dr Christoph Stiendl, 2004
  
• Lean Thinking: The Theory behind Agile Software Development, by Mary Poppendieck, 2002
• Implementing Lean Software Development (Practitioner’s Course), Mary Poppendieck, November 2006
• Competing on the basis of Speed, 1hr video presentation to Google by Mary Poppendieck
  
• Other talks by Mary Poppendieck at http://www.poppendieck.com/events.htm

Articles/Papers:

• Business Process Management: What's Driving Toyota?, Baseline magazine, September 2006
• Agile Product Development: Managing Development Flexibility in Uncertain Environments, by Stefan Thomke and Donald Reinertsen, California Management Review 40, no. 1 (fall 1998): 8-30
• Managing Lean Software Development with Cumulative Flow Diagrams, by David J. Anderson
• Agile Software Management Accounting for Systems, by David J. Anderson
• Agile Software Management: Dealing with Uncertainty, by David J. Anderson
• The Lean-Agile Connection: Developing Quality Software Efficiently by Alan Shalloway
• Introducing the Integrated Theory by Dan Rawsthorne and Alan Shalloway
• Whitepaper: Agile Work Uses Lean Thinking, Whitepaper by Mishkin Berteig
• Business Performance Through Lean Six Sigma : Linking The Knowledge Worker, The Twelve Pillars, And Baldrige / by James T. Schutta
• Introducing Lean Software Development, by the Lean Software Institute
• Lean Six Sigma and High-Performance Organizations Combined, by Tom Devane (book excerpt)
• Lean Thinking. Protein-based dietary fad or Management’s New Testament?, BPM Europe
• Bringing Lean Systems Thinking to Six Sigma, by Paul Mullenhour and Jamie Flinchbaugh, 2005
• Lean Software Delivery with the IBM Rational Solution, by Clay Nelson, The Ratioinal Edge, October 2006
• TOC and Lean, Iowa State University Center for Industrial Research and Service
• Lean Thinking for Process Improvement, part 2 of a three part series by bizmanuals.com
• Six Sigma and Lean Manufacturing, by Michael Baudin
• Agile vs Lean Software Develompent
  
• Lean articles at isixsigma.com
• How to Compare Six Sigma, Lean and the Theory of Constraints, by Dave Nave, Quality Progress, March 2002
• Software Development Convergence: Six Sigma-Lean-Agile, by David Hallowell
• Design for Six Sigma and Lean Manufacturing, by Praveen Gupta, 2001

Websites / Blogs:

• Tom & Mary Poppendieck’s home page at http://www.poppendieck.com/
• David Anderson's Agile Management website at http://www.agilemanagement.net/
  
• Lean Enterprise Wiki search engine: http://lean-enterprise-swicki.eurekster.com/
• http://www.leansoftwareinstitute.com/
• http://leaninsider.productivitypress.com/
• http://www.lean.org/
• http://www.evolvingexcellence.com/
• http://www.leansoftwareengineering.com/
  
• Lean blogger Pete Shmula at http://www.shmula.com/has lots of nice blog-entries/articles on aspects of Lean
• NetObjectives Lean Software Resources at http://www.netobjectives.com/resources/lean
  
• Lean manufacturing - Wikipedia, the free encyclopedia

Top 10 ACME blog-posts in 2006

Happy new year to all! I thought this would be appropriate for my first blog-entry in 2007 ...

Here are my top 10 blog-entries of 2006. This is based not on hit-counts, but rather on reference counts (number of mentions in other blog-posts, forums, articles, etc.) in some form or another. Note that there was a tie for the #10 spot.

1. Dimensions and Views of SCM Architecture
2. Scaling Agility: Summary of Resources
   
3. The Unchangeable Rules of Software Change
   
4. Agile SCM Principles: From OOD to TBD+CBV+POB
   
5. Trustworthy Transparency over Tiresome Traceability
   
6. Simple ain't Easy: Myths and Misunderstandings about Simplicity
   
7. Codeline Flow, Availability and Throughput
   
8. Impacts of Extreme Globalization and Extreme Competition
   
9. Agile vs MDE: XP, AMDD, FDD and Color Modeling
   
10. Nested Synchronization and Harmonic Cadences and Feedback, Flow and Friction
    

Some of the above surprises me. Some of it is close to what I was expecting ...

• I'm truly astonished at the #1 post - both because it was so recent and also because I'd seen very little indictaion of interest in my 4+2 views of SCM architecture (most folks probably just liked all the links that went along with it).
• The #2 and #3 entries don't surprise me, and I'm happy to see them there.
• I'm very surprised the "Simple Ain't Easy" post didnt rank much higher. I personally liked that one and my "Unchangeable Rules of Software Change" the most in 2006. And I saw so much discussion and mention of the "Simple Ain't Easy" post, I honestly expected it to be the #1.
• I am surprised by the ranking of the posts on codeline flow & throughput, and nested synchronization & harmonic cadences. I had the impression that struck most folks as rather esoteric.
  

For anyone interested in what the next ten most popular ones were ... here they are:

11. Business Agility Defined
    
12. Extreme Traceability
    
13. Nutshell Definitions of Agile Development
    
14. 5Cs of Agile SCM
    
15. Cost, Cruft and Constraints
    
16. Pragmatic Multi-Variant Management
    
17. Agile IT Organization Refactoring
    
18. Trends in SCM Predictions for 2006
    
19. Everyone Wants to be LUVed
    
20. Lean Principles for Branching
    

Here's hoping I can do as well or better in 2007!