Martin Geddes argues that longer term - after the cyclical surge to offshore is over - your job may be safe after all.

As a product developer in the USA, I need to have empathy with the needs of the natives to be able to ideate good product solutions to the communications problems they face in their everyday lives. The marketing department needs to communicate to those customers and use social cues (sports teams, historical events, entertainment personalities) that they know will resonate with their audience.

Martin is highlighting the fact that lean suppliers that generate "pull" demand from the market add most of the value (in the value stream) at the last step in that stream. Hence, the local supplier who is intimate with the customer is ultimately going to win in the market. I've called the logical conclusion of this "supply chain software development". The notion that platforms, technologies, components and middleware may ultimately get developed in low cost economies but the finishing will be done in local markets. Just like production manufacturing assembly - components will be commodities which will fetch low prices but be sold broadly. Finished products will be tailored to markets and will sell in low volume but at high prices (relative to the total sustainable market price). I'm talking here about geographically dispersed re-use of software. It might take 15 years for this to play out in full. What we are seeing now is just the beginning of a change. In the short term, there will be pain. In the long term jobs will come back but only to smarter, leaner, software firms who can deliver valuable software on-demand.

|

Agile methodologists often make a big deal out of how disciplined teams need to be to go agile. I've been reading Jim Collins, Good to Great. Jim highlights from his study of companies which made the transition from merely "good" to "great" that they have a culture of discipline. I want to list the quote in full...

"A Culture of Discipline. All companies have a culture, some companies have discipline, but few companies have a culture of discipline. When you have disciplined people, you don't need hierarchy. When you have disciplined thought, you don't need bureaucracy. When you have disciplined action, you don't need excessive controls." Jim Collins, "Good to Great" p.13

To me this sums up the essence of agility and provides an explanation for heavyweight methods. What is missing in heavyweight traditional methods is a culture of discipline. These methods are heavyweight precisely because they DO NOT trust the discipline of the engineer but rely on process to verify or enforce rigor, precision and quality. The key is "trust". If you trust your disciplined workforce then it's easy to go agile.

Hence, it seems that in order to go agile, a manager must first start by instilling a culture of discipline in the organization. This would seem to be a necessary precursor for success. So necessary in fact that it should probably precede a move to an agile development method by several months. By first encouraging discipline, the organization will make a smoother, faster transition to agile methods and the results will be better earlier and more easily sustained later.

It is ironic then that Barry Boehm and Richard Turner chose to use the term "discipline" to represent traditional (or heavyweight) software engineering methods, in their recent book, Balancing Agility and Discipline - A Guide for the Perplexed. Collins' observation seems at odds with this. Traditional methods are heavyweight precisely because they DO NOT rely on discipline but rather rely on process adherence. I much prefer the term coined by Jim Highsmith in Agile Software Development Ecosystems where he describes traditional methods as "rigorous software methods" (or RSMs). The term "rigor" describes the situation better. Rigor does not imply trust or discipline but it does imply quality. Traditional methods are designed to deliver quality. They don't assume any standard of discipline. As many agilists have argued, traditional methods do not acknowledge the "human nature" of software engineering. Instead they compensate for it - often at enormous economic cost - with process. It is precisely this economic cost which I expose in "Agile Management...".

|

The McKinsey Quarterly has an article, "Who Wins in Offshoring" [Registration Required], which analyses the overall effect of offshoring knowledge worker jobs from the US to Asia. The conclusion is that the net effect is positive - a 12-14% gain. However, the piece does admit that displaced workers will suffer personal hardship even if the country doesn't. Most workers when re-employed are doing so at lower wages and often in part-time employment.

The total possible wealth creation does not, of course, ease the plight of people who lose their jobs or find lower-wage ones. The statistics showing that 69 percent of those who lost jobs in the nonmanufacturing sector were reemployed also show that 31 percent were not fully reemployed. And while, on average, those who found new jobs secured similar wages (96.2 percent of their previous wage), 55 percent took lower-paid jobs. As many as 25 percent took pay cuts of 30 percent or more.

|

A discussion about my Concorde post from yesterday, led me to remember an article I wrote over 4 years ago about the true value of airline service. In "Speed is the Essence of Usability", I show that usability is really just a process for the validation of value creation. In the airline business value is delivered as an end-to-end solution - the fastest time from door-to-door.

My goal is to get to the destination. I do this by making a journey. There are many factors involved: Road to the airport; ease of parking; journey time from car park to terminal; check-in process; airline; aircraft; flight time; ease of rental car check-in; journey time to the rental car pick-up; road from the airport at the other end.

What is really interesting about the conclusion in this article is that no one supplier controls the constraint - the total journey time. This makes strategic planning in the airline business very difficult. Is the answer vertical integration - control the value chain, control the constraint - or collaborative, open, transparent, partnership? The company (or companies) which work(s) this out will conquer the travel business.

David Taylor describes this dilemma as "Winning as a Team" in Chapter 3 of "Supply Chains". He points to the trend toward partnership between companies with a core competence at one point in the chain, rather than vertical integration. He calls well formed partnerships - "virtually integrated" businesses. However, he points out that the truly transparent, collaborative partnerships may be an unobtainable nirvana. There is a basic conflict between such mutually agreed partnership and capitalism. The need to improve profits ultimately makes companies want to squeeze their partners in a supply chain.

If some group of businesses does work this out, they won't be the only winners. We the traveling public will win too. Business can be really simple - align your business goals and ability to make profits with the goals of the customer.

[Read more about David Taylor and Supply Chains from his companion web site supplychainguide.com]

|

I've been thinking about how One Page Management techniques could be worked into "Agile Management...". I decided not to try and include it in the book because it is primarily about personal goals and achievement and reporting those up through several layers of management. To have added it to the thesis would have required a re-write and perhaps a 1 year delay in the book.

Hal Macomber has been thinking about Khadem and Lorber's approach too and he has posted his ideas as One Page Project Management over at his blog, Reforming Project Management.

|

I'm on record elsewhere as stating that I think the main inhibitor to improved performance of big corporate America is the annual strategic planning process. Jeff De Luca does a fantastic job of articulating why this is so in his latest FDD newsletter, "Requirements - the Budgeting Syndrome". Quite simply annual planning and the budgets associated with them are the main inhibitor to lean business and a constraint on improved performance.

Any line manager in a corporate will know what it's like to budget. What is the process usually like? Well, several months before the manager has to submit his budget for the next year he starts working on it. The manager looks at last year's numbers, he considers the projects and items for the coming year, and so on. As the budget is for a long period of time, usually a year, and the manager has to do it well in advance, he puts in as much buffer as he can reasonably hope to explain. In fact, many will ask for the maximum they think they can get, not what they think they will actually need. Oh, by the way, the smart manager also makes sure that all of this years budget is completely spent (otherwise he may not get as much to spend next year) and plans to spend earlier rather than later (since we've all suffered budget cuts before).

|

It was with some sadness that I followed the news of Concorde's last commercial flight. I remember as a small boy in the early 1970's being taken to Prestwick International Airport to see the first one. It is one of my earlier memories. Concorde isn't an aircraft - it is an icon. Concorde is the quintessential essence of London and the crown jewels of the national flag carrier, British Airways. You cannot arrive at London's Heathrow Airport without seeing the 1:5 scale model. You cannot avoid the souvenirs of London and Britain which carry its image. Apparently the French had something to do with it. But its wings and engines were British - what else is left? The drooping nose, perhaps. The main contribution from the French was to leak the blue prints to the Russians resulting in the TU-144.

In the days when America was putting men on the moon, the world's only supersonic passenger aircraft was British - and that was something small boys could be proud of - something inspiring. That's what makes Concorde an icon of Britishness in the latter 20th Century.

So why is it gone and not replaced? Why are slow, fat, large, ugly aircraft all the rage?

Simply put - for most passengers, the vast majority in fact - time is not the constraint. It makes more sense to go slower and save money. For businesses this reduces costs. Reduced costs go straight to the bottom line. Faster speed would only be worth it if it increased throughput. This would only be true when the passenger is a constraint (or works within one) of a business. Most businesses just blindly save costs with corporate travel. Most businesses also have no idea where their constraints on increased throughput lie. The result is that saving costs blindly does make sense. The chance that the constraint will be impacted is slim. However, when a constraint's capacity is reduced through slow travel, there will be a loss in throughput for the business.

Why is this not much of an issue in the early 21st century? As the IBM advertisement used to say "Show me the flying cars! They promised us flying cars!" and then explained that we don't need them because we have the Internet. So there is no need for a supersonic jet airliner in the 21st Century, then? I think that is a hasty conclusion.

Some market research, TOC-style! Who would want to justify the costs of flying supersonic? Someone who is a constraint on throughput? Who are such people? Celebrities for the most part. There is only one Ewan MacGregor. If you booked Ewan MacGregor then only the physical presence of the man will suffice. There is no substitute available. If a celebrity such as Ewan MacGregor wants to maximize his revenue generating potential then he needs to get places fast. So it is no surprise then that before the tragic accident, Concorde was very popular with the showbiz glitterati.

So would there be a market for a replacement? If a plane could be built cheaply enough and a limited number made for routes such as New York - London, Los Angeles - London, Los Angeles - Tokyo, then it is just possible that there might be. The Economist thinks that there are alternatives such as private jets - more flexible substitute products. They are not so fast in the air but the total door-to-door time is comparable with Concorde.

And therein lies the lesson - the time spent in the air is not the system constraint! The goal for a celebrity is door-to-door transport in the shortest possible time. Spending billions to shorten the time in the air may not be the best use of funds. There may be better ROI from reducing the time spent getting to, from and through airports and providing flexible flights in small private jets from quiet private airfields.

Britain continues to lead the world in fast cars - almost all racing cars are made in Britain, even the ones which go around in circles in the United States - and it iconified the fast passenger aircraft. Why couldn't it brand itself as "fast" Britannia, and niche market its products as fast, good and expensive? Britain needs something to be proud of! The Millennium Dome just didn't hack it. A new Concorde project might be the thing - something around which people could rally - something to be proud of - something to print on all the tourist souvenirs for a new century. However, the economics just don't seem to be there. Building a new Concorde appears to be a poor use of funds - even when the derivative effects of inspired little boys who grow up to be productive in other ways, are fully taken into account.

Bottom line - when you're not the constraint, you don't get the investment! Sorry Concorde! I will miss you.

[Thanks to Daniel Vacanti for suggesting this topic]

|

I got home this evening and found a box waiting for me. It contained a book that I heard was in development, Supply Chains by Dr. David A. Taylor - one of my favorite authors.

I first heard about Taylor when I was working at a startup in Scotland called MDi Systems in the early 1990's. My boss bought the first edition of Object Technology: a Manager's Guide. Everyone in the office thought it was a great book. I'm amazed to think that now I am only 2 degrees of separation from Taylor - he is a friend of Peter Coad and peer reviewed the drafts of Peter's Java Modeling in Color with UML book.

My first flick through this new book suggests that it is really good. Written in Taylor's plain and simple style with all his beautiful hand drawn illustrations. Not a software engineering book but for those interested in management science, I suspect it is a "must have". I'll comment on this again when I've had time to read it.

|

The TOC World 2004 conference will be held from April 13th to April 16th in Uncassville, Connecticut, USA. If you would like to attend and would like to see me present my software engineering material at this event then please fill in the "What you would most like to see at TOC World 2004" section of this form and show the organizers that their is an interest in a TOC solution for software engineering and agile software development. Hopefully if there is demand AGI Goldratt Institute might invite me to speak.

|

An interesting white paper titled "TOC Project Management in Aircraft Assembly" [Registration Required] about how Boeing is using TOC, has been made avilable by the AGI Goldratt Institute. The article looks primarily at the deployment of Critical Chain scheduling and Earned Value metrics between Spring 1999 and Fall 2000.

In this paper, Dave shares the dilemma of needing to quickly improve schedule and cost performance, yet not wanting to lose ground introducing a new, but unproven application of TOC Project Management (TOC PM). He tells of managers, schedulers and workers who make the tough calls against established practices as they pilot TOC PM in the factory on an EMD program - and gradually implement TOC PM factory-wide. Dave describes the meaning of the logistical and cultural changes required to make the program successful. Ultimately, the factory makes TOC PM, Lean Manufacturing and Earned Value Management System work together.

|

Chapter 1 is intended to lay out the theories which are discussed throughout the rest of the book. It leads off with Dilbert (from March 14th 2003) being asked by a customer to start delivering "just in time". Needless to say the hapless customer is rebuked. A very brief history is then given of the Theory of Constraints, Just-in-Time, Quality Assurance (Deming), Total Quality Management, Lean and Six Sigma along with a comparison chart. Eli Goldratt's theory on the 3 phases of evolution in scientific development - classification, correlation and effect-cause-effect - is explained.

It then takes a look at some topics which have been actively debated or promoted in the agile community recently. The definition of empirical versus defined processes is examined along with their relationship to chaos theory. Systems Thinking is introduced and Complex Adaptive Systems (CAS), a.k.a. Emergence is described.

The chapter concludes with a summary. Agile management techniques must cope with uncertainty - software development is an uncertain business but not necessarily chaotic. It suggests that "delaing with uncertainty" be achieved by using the principles of TOC, Lean and Quality Assurance. Agility is delivered through a focus on quality, reduced work-in-process inventory, focus on system bottlenecks and reduction of variance. Agile management methods are methods of empirical control but this does not mean that agile software development is necessarily chaotic or constantly on the edge of chaos. In CAS terminology, agile software methods are adaptive systems which exhibit emergent properties - e.g. standup meetings, burndown charts - and desired adaptive behavior - working code. Chapter 2 takes up this system theme and goes further...

|

Mary and Tom Poppendieck seem to agree with me that the most important measurements in agile software management are the inventory of work-in-progress and the lead time to complete that work. "Agile Management..." Chapter 5 - Software Production Metrics - gives a full treatment of this topic.

Mary and Tom also agree that abstraction is the important route to simplifying what we do as managers. However, their essay, Toward a New Definition of Maturity does have a major flaw in the foundation of its argument - the use of Miller's paper from 1956 "The Magic Number Seven Plus of Minus Two : Some Limits on our Capacity for Processing Information" and his discover that "short term memory" can typically only hold 7 items +/- 2 - which they suggest affects our ability to analyse things and is limited by this short term memory, which psychologists now refer to as "working set memory".

This really is a stretch of the original work. In fact, Miller references work by Bousfield, which I also referenced in "Agile Management...". Bousfield showed - 1 year earlier in 1955 - that humans had trouble categorizing random words into more than 6 categories. There are later studies to show that people become attached to these categories and find it impossible to change them. The common language expression for this is "pigeon-holing".

To quote Miller's final paragraph from his paper,

And finally, what about the magical number seven? What about the seven wonders of the world, the seven seas, the seven deadly sins, the seven daughters of Atlas in the Pleiades, the seven ages of man, the seven levels of hell, the seven primary colors, the seven notes of the musical scale, and the seven days of the week? What about the seven-point rating scale, the seven categories for absolute judgment, the seven objects in the span of attention, and the seven digits in the span of immediate memory? For the present I propose to withhold judgment. Perhaps there is something deep and profound behind all these sevens, something just calling out for us to discover it. But I suspect that it is only a pernicious, Pythagorean coincidence.

It seems that our ability to categorize and abstract and the number of elements in our working set memory are probably only coincidentally related. I'm not aware of any paper which has more recently proved a link between these two.

So does this invalidate what the Poppendieck's are saying? No, not in the slightest. The metrics suggested are the right ones. It is simply the case, that they need a better way of articulating why abstraction is difficult and why Systems Thinking is difficult. Dr. Miller doesn't have the answer.

|

I'm sitting at ForUse2003 listening to Arlen Bankston of CCPace who is presenting "Can Designers Dance? Surviving Agile Teams and Astringent Customers". Arlen has been working as a ui designer with XP teams.

He has found a good way to avoid confusion with metaphors. The XP metaphor might pollute thinking on the ui design. So he has dropped metaphor from the method and replaced it with shared vision - one of Peter Senge's 5 disciplines.

The specifics of the shared vision are a Visual Vocabulary diagram and usage-centered design role models and task cases.

|

I'm attending ForUse2003 in Portsmouth, New Hampshire. The coolest thing about this is that I get to meet luminaries like Larry Constantine and Ivar Jacobson. I was fascinated to learn last night that Jacobson agrees with my conclusion from last Thursday - that the OO paradigm has really reached the end of its usefulness. Ivar's focus is on Aspect Oriented Programming. He has some other fields of interest and was showing an interest in Agile Management and what I've been doing.

Some other notable attendees include Ron Jeffries (of XP fame) and Tom Poppendieck, co author of Lean Software Development.

Both Ivar and Larry have promised to take a look at my book. I wonder what they will think?...

|

Ron Crocker works as a Fellow of the Technical Staff with Motorola where he helps to organize large development programs for telephony equipment and mobile phones. He is also an agile enthusiast. He's been developing methods of scaling agile methods to large scale problems by introducing architecture early in the process and separating out concerns into layers on a stack. In some respects this is similar to FDD but Ron is taking it even further. He has a book coming out soon, Large Scale Agile Software Development. To get an idea of what he's talking about take a look at these slides on his Grizzly method from September 2002.

|

Over the next 18 weeks, I am going to summarize Agile Management for Software Engineering, in a series of twice weekly blog entries - one entry for each chapter. I'd like to start today, with a summary of the Foreword and the Introduction. For those who have skipped to Chapter 1, it really is worth going back and reading the front matter.

The Foreword was written by Eli Schragenheim who co-authored "Necessary but not Sufficient" - the most recent Theory of Constraints novel about the supply chain management solution for TOC. Eli is a software guy, an accountant and a long time expert in TOC as he explains. He lists the two key benefits of TOC thinking as: vastly improving the flow of products to market; and the marketing problem of determining the real value of a product or feature to an end consumer. He rightly observes that my book focuses mostly on the first of these two. Only one chapter - Chapter 16 - Agile Product Management, address the second.

The Introduction sets the scene for why the book is necessary and what benefits it delivers for the reader. It discusses the recent trend in the economy and the trend to outsource software development to locations where the labor is much cheaper. If jobs are to be retained in the expensive West then software development organizations need to improve their competitiveness. It introduces the basis for agile management techniques as a hands-off, highly delegated style, using metrics to transparently report the progress of an empowered workforce. It discusses the advantages found in other industries from changing working practices rather than introducing technology based solutions. The agile revolution is categorized as a rebellion against bad management and a passionate push for a "better way" to deliver software. Finally, it offers the suggestion that perhaps their is a latent economic miracle waiting to be unleashed. What if software development today is as effective as the auto-industry in 1911? There is a potential for a 20 fold improvement (or put another way - 95% efficiency gains). If agile methods allow us to unleash even a fraction of this potential what would it mean for you, your job and the prospects for your employer?

|

We had a quarterly all hands meeting at my office today. It was a GM and below level meeting. At the end during the question session, a relatively new employee, a Russian immigrant with improving English, bravely asked, "What about outsourcing - are we going to get it?" (sic) Yeah, you go guy! Stick that outsourcing to us baby!

Our GM deferred the question to my immediate boss, who indicated he was going to delegate it on to me, then he suddenly decided to answer it himself. To my dumbfoundment he then uttered one of the most profound statements I've heard on the topic. So good in fact that I quote it for you now - only slightly paraphrased.

We will outsource when there is no knowledge associated with an activity, such as repetitive execution of test plans. We will not outsource where there is knowledge to be gained and retained such as writing test scripts or programming automated tests. We will also outsource when we have resource issues. We will look at each case in turn. When it makes commercial sense we will outsource to elevate a bottleneck.

It's a textbook answer. It combines Donald Reinertsen's information theory ideas - in this case, the knowledge to be gained - with the Theory of Constraints and Throughput Accounting -  the bottleneck and the commercial sense - which suggest that investment should be focused on constraints. When there is a temporary bottleneck, a temporary investment is needed to alleviate it. That's when outsourcing makes sense.

When to outsource is discussed in "Agile Management..." in Chapter 13 Staffing Decisions.

|

I promised to publish more about The Business Rules Approach by Ronald Ross after I'd read more of it. I also want to relate it to Streamlined Object Modeling, by Nicola, Mayfield and Abney. The latter, shows how to apply business rules into an object-oriented design in a systematic way. So it seemed likely that the two methods were compatible. I have now read both of these books and I believe that there is a benefit in combining the techniques.

Let me save you some effort. The meet of The Business Rules Approach is in Sections 2 and 3. Ignore Section 1 - I found it, boring and wasteful of my time. How to write requirements as business rules is described in chapters 8 & 9 and these are the key chapters.

As I mentioned in earlier posts, The Business Rules Approach divides the requirements space up into 3 areas: Facts (and the Fact Model); Business Rules; and (User) Tasks (though Ross calls them Processes). Let me talk about these in turn.

Facts

Facts and their close cousins Terms describe the domain of a problem. Ross (the author) introduces a new notation for Fact modeling. He did this to avoid confusion with data modeling. Terms are either entities in a domain or attributes of those entities. Facts are relationships between Terms. In addition there are Derived Terms and Calculated Terms - these are also referred to as Functions.

Translation

What FDD calls a Domain Model - Ross calls a Fact Model
What FDD calls a Domain Object - Ross calls a Term
What FDD calls a Feature - Ross calls a Derived Term or a Calculated Term
What FDD calls as Association (on the Domain Model) - Ross calls a Fact

Advantage of Facts

The Fact Model (Domain Model) has a very low variance and changes little -  it is after all based on facts. Regardless of changing requirements in a domain, the Fact Model will suffer very little need for refactoring.

Business Rules

Business Rules describe (primarily) constraints on Facts. [There is that word constraint :-) again].
Such as "A Customer with a Checking Account must also have a Savings Account"

Translation

Business Rules have no direct translation in FDD. We typically write them as notes to Features or simply embed them in Use Cases and cross-reference from the Feature definition.

Advantage of Business Rules

The Streamlined Object Modeling book dedicates a whole chapter (Chapter 4) to Business Rules. It explains how to map them on to a Pattern-Player model (Domain Model - similar to a Domain Neutral Component model using color Archetypes). The advice in this chapter can be mapped directly onto a Domain Model in FDD.

Nevertheless, Nicola and Mayfield observe that business rules are subject to change more often and have a greater uncertainty attached to them. So finding a method of reliably implementing them in code is a bonus.

Ross goes further. He wants them implemented in separate code. His suggestion is that business rules are encapsulated on their own.

It makes sense to separate out business rules during the requirements because they have real business value and are definitely client-valued functionality. This fits with the spirit of "tracking the flow of value". They are also subject to greater uncertainty and as Donald Reinertsen pointed out in Managing the Design Factory, systems should be partitioned architecturally to decouple uncertainty. It makes further sense to list business rules because Nicola and Mayfield have shown how to map them directly to code. This allows the requirements to be directly mapped to working code which facilitates end-to-end traceability.

Hence, it would seem to be advantageous to build a list of Features and a list of Business Rules in a Value-Driven software engineering method such as FDD.

Process / (User) Tasks

Ross describes Processes but he really ought to call these Tasks or even User Tasks as they describe flows of interaction mainly with the user.

Translation

These are not Use Cases. They don't have business rules or facts and terms embedded into them. They are more like what Larry Constantine used to call "Essential Use Cases" and later renamed "Task Cases". Ross' processes are more like screen flows. They could be represented in a Visual Vocabulary diagram or a UML Statechart.

Advantage of Tasks

The advantage of capturing tasks separately - as my employer does with VV diagrams and I have shown with Statecharts  - is that they can vary independently of business rules and the much more stable fact model. In fact, almost everyone recognizes that UI designers reserve the right to make changes almost right until the end of a project. Bottom line - tasks change often!

Conclusions

The Business Rules Approach offers us the possibility of a new lightweight method of requirements definition which is better able to cope with change and separates out concerns more efficiently - unlike use cases which couple concerns. Ross refers to techniques such as Use Cases generically as "procedural methods of requirements definition".

The Fact Model - Business Rules - Tasks separation offers us a cleaner mapping between requirements and code. One Term is one Domain Class or ERD Entity or an attribute of a class or entity. One Fact is one association on the model. One Derived (or Calculated) Term is one Feature in FDD. One Business Rule is one Business Rule in Streamlined Object Modeling. One Task is one VV diagram for several Views and Controllers/Actions which are UI Features in FDD.

My biggest conclusion is that The Business Rules Approach threatens to create a paradigm shift - a discontinuity. What it really highlights is that the encapsulation in object-oriented technologies is misguided and of limited real use. It hints at the fact that we need a new paradigm with rules and tasks encapsulated separately. I believe that this gives the Object Role Modeling (ORM) community with authors such as Terry Halpin and David C. Hay a real opportunity to cross the chasm into widespread adoption. It also hints that technologies from Microsoft that are influenced by ORM (MS has never really been an OO shop) may provide a time-to-market advantage over traditional OO technologies like Java. The point being that a system which architecturally partitions uncertainty will lead to faster development and faster subsequent incremental iterations.

Necessary Reading

For those with an interest in this, I would recommend...
The Business Rules Approach  - Section 2 and Section 3
Streamlined Object Modeling  - Chapters 1 thru 4

|

A few agile methods, particularly Extreme Programming, like to introduce metaphors. Several agilists I know are constantly inventing metaphors to try and articulate issues and give the reader or listener a mental framework for a discussion. Here is dictionary.com's definition of metaphor.

metaphor. A figure of speech in which a word or phrase that ordinarily designates one thing is used to designate another, thus making an implicit comparison, as in "a sea of troubles" or "All the world's a stage" (Shakespeare).

I'm not a big fan of metaphors. I believe that they constrain thinking artificially and that they confuse people when they break, that it they aren't sufficient to model a whole problem. The UI community has known that metaphors are dangerous for a while. I think that Alan Cooper said it best in this article,

But by searching for that magic metaphor you will be making one of the biggest mistakes in user interface design. Searching for that guiding metaphor is like searching for the correct steam engine to power your airplane, or searching for a good dinosaur on which to ride to work.

So I would like to introduce two alternatives to metaphor - and we all know them well.

Candidate number #1 - Analogy. Here is one of dictionary.com's definitions.

analogy. A form of logical inference or an instance of it, based on the assumption that if two things are known to be alike in some respects, then they must be alike in other respects.

Analogy isn't as strong as metaphor. It is as constraining on thought. Analogies don't break in the way that metaphors do. We tend to recognize the limit of an analogy and realize that the behavior or the attributes of the two things being compared are simply different.

Candidate number #2 - Abstraction. Here is what dictionary.com has to say about it.

abstraction. An abstract concept, idea, or term

Hmmm. Self defining huh! What does abstract mean?

abstract. Considered apart from concrete existence: an abstract concept.

1. Not applied or practical; theoretical.
2. Difficult to understand; abstruse: abstract philosophical problems.
3. Thought of or stated without reference to a specific instance: abstract words like truth and justice.
4. Impersonal, as in attitude or views.
5. Having an intellectual and affective artistic content that depends solely on intrinsic form rather than on narrative content or pictorial representation: abstract painting and sculpture.

Some people have observed that "Agile Management..." uses a "manufacturing metaphor" to explain the benefits of agile methods. This is totally wrong. It wouldn't even be true to say that I make analogies between manufacturing production and software. Though I do make the analogy that (maybe) the management methods used in Lean Production can be used in software development.

What I do in "Agile Management..." is abstract software engineering as a system. Manufacturing production can also be abstracted as a system. The system concept is abstract. I then apply principles which apply to all systems on my abstraction of software as a system. I then show how to make those abstractions into concrete management practices for software engineering. In Section 1, I talk about a generic "Lean" process and in Section 2 I talk about RUP, FDD, XP and Scrum.

Metaphor just didn't come into it!

|

A big influence on "Agile Management..." was the book "Managing the Design Factory: A Product Developer's Toolkit" by Donald G. Reinertsen.

Management Round Table has this interview with him at their web site. The wisdom of Mr. Reinertsen can also be found online in this series of articles.

There are also some reviews of his book available online. Here are two of my particular favorites:-

• http://halljobs.com/economics/355.shtml
• http://www.pdma.org/bookstore/books/mandes_review.html

|

Martin Geddes was kind enough to point out this article "The Wealth of (Other) Nations" to me today. It seems that others are beginning to suggest that software development in America needs to think about alternative working practices and most of all management theories and business models, if it is to remain competitive. Remember, you heard about the "Silicon Rust Belt" effect first - here at agilemanagement.net!

Doesn't all this sound familiar? More than one analyst has remarked that the current downturn in Silicon Valley and the public outcry over lost IT jobs to overseas competitors in India and China bears an uncanny resemblance to the loss of U.S. manufacturing competitiveness to Japan during the 1980's. Then, as now, it appeared that a low-cost Asian colossus was ready to topple America from its leadership position by employing a host of "unfair" practices, such as paying below-market wages and tilting the bureaucratic playing field to favor export-oriented upstarts over their U.S. competitors.

|

This very interesting academic paper [PDF] discusses the economics of Extreme Programming with a particular interest in the cost of Pair Programming coupled with Test-Driven Development and the possible returns from reduced defect count and the other practices which improve quality. It concludes that XP is very hard to justify economically except in fields where there is a very rapid change in requirements or in markets with rabid competition where sales would be lost by even the slightest delay in delivery - referred to as severe market pressure.

One area where I feel I would like to have seen more data was the effect of the XP Defect Factor. The authors conclude that XP begins to become effective at reduced defect factors of 30% but still with very high market pressure - specifically that almost all the requirements would become obsolete (or of zero value) if the project length doubled. However, I discuss in the later sections of Agile Management for Software Engineering that I believe many agile methods are most effective in very immature organizations. Capers Jones and Karl Wiegers have shown data to suggest that defect rates in immature American development shops can be in the range of 3 to 5 defects per Function Point. Good process and discipline can improve this to 0.4 defects per Function Point. Hence, improvements of up to 80% are possible. I really think that this paper would have drawn different conclusions if a wider range of improvement in the XP Defect Factor had been considered.

The economic model in the paper varies considerably from the one I present in the book. This method uses Net Present Value (NPV) which I ignored primarily for simplicity sake. The authors Muller and Padberg treat what I called Throughput as the Asset Value (of the delivered working code). They use the NPV Discount Rate to represent the loss in Throughput value through delayed delivery - they call this Market Pressure, i.e. someone else might beat the product to market and devalue a feature. This is a neat approach and it could easily be added to the approach I presented in the book.

Development Cost in the paper would be Operational Expense in my Throughput Accounting model. The resultant NPV model is essentially a discounted version of my Net Profit (NP) equation in Chapter 2 of the book.

What the authors have failed to address is the concept of valuing the input - the ideas or requirements for the product - and measuring the value efficiency (effectiveness) of turning that input into value-added output. I call this ROI in my model and achieve it by treating the cost of acquiring the requirements as the input Investment. This concept captures the whole of the software engineering lifecycle in the metric and not just the development and testing phases.

Had the authors included this ROI consideration then they might also have drawn more positive conclusions about XP. XP has a very light requirement gathering method. The cost of gathering requirements is minimized to purely direct customer sessions to write Story Cards. The result is that XP is very value efficient and would produce better comparison on ROI relative to its performance against other methods in Net Profit.

|

I came in to work this morning and an electronic LED stock ticker board was glaring at me from the top of a developer's cubicle. You know the kind you see on the news when they cut to a shot of a Wall St. trading floor. The machine in question was about 2 feet across and was spooling the Yahoo! news.

When I investigated I discovered that a chief programmer who runs the daily standup meeting had decided this would be an ideal peer pressure tool. In our office we run an FDD/Scrum/XP hybrid method. It is mostly FDD but incorporates aspects from the other methods - namely, stadup meetings (which I have documented at The Coad Letter #101) and continuous integration. A tools enthusiast on the team has created some scripts which run the build at regular intervals every few minutes. If the build is broken then everyone on the dev team gets an e-mail telling them the build is broken, the name of the class which broke it and the programmer who checked it in. Now this news will not only appear in the inboxes of team members but will also flash across the electronic board for everyone in the office to see.

An outstanding piece of lateral thinking? Maybe. I'll report back later on our experience with this contraption and whether it improves build quality and team morale.

|

I think that Paul Glen, author of Leading Geeks may be on to something with his ideas about archaeology for software engineering artifacts.

I have recently been helping out elevate a constraint by actively joining a domain modeling, Feature analysis and architecture activity on two projects. As a result I've been playing with Post-It notes on white boards and getting back to full fitness as an object modeler. Several people have commented on the neatness of my models, on the aesthetic quality that they have. Our office manager commented that the latest one looked "pretty" and another developer is privately known to have called the earlier one "a work of art". Note these comments are not aimed at the effectiveness of the object modeling, merely the aesthetic of how it is presented. Once, I've settled on a model. I will create an electronic version in Together and print it out in color. I then put the finished domain model on the wall for everyone to reference.

What would the archaeologist learn about me from this behavior - simply put - I value analysis and design. I see analysis and design as valuable deliverables. Just as we have coding standards to make code look neat and provide for clarity and readability long after code was written, so I believe that models should also be produced with care, follow a style and be clear enough to have value long after they were first created.

Bottom line, if your team isn't producing neat work for activities such as analysis and design, but merely a few scribbles which may never be preserved then they probably don't value this activity. This is likely an indicator that they aren't making their best efforts at it. This could ultimately be wasteful. Is there a relationship between respect for activities other than coding and the ultimate quality of the delivered code?

|

I learned one of my best lessons in management from Peter Coad - the team development cycle of 'forming', 'storming', 'norming' and 'performing'. Peter had in turn learned it from Fred Racey and he documented it in The Coad Letter #40 - Lessons Learned from Fred. I later found a more formal presentation of these ideas in another of my favorite management books, Managers as Facilitators.

The key management concept to take away from this is that in order for there to be a normal working relationship in a team - no matter how large or small - there will inevitably be a period of pain and angst while the group goes through its 'storming' stage. There MUST be 'storming'. It is unavoidable. The experienced manager learns to expect 'storming' and to accept it as a necessary part of growth. A good manager will coach a team through the storms and help them to reach the mutual respect and understanding that comes with 'norming'. A bad manager will take fright from the storm and will seek to punish individuals for undesirable behavior. The result will be a fallback to 'forming' and a resultant lack of productivity.

Recently, I experienced a dynamic between two people, one of whom I knew well and respected as a professional. He had recently joined a team which though not fully established had been in place for a few months. He immediately butted heads with the current team lead who had gained some respect in the organization. For almost two weeks, the scene was ugly. Some others might have wondered if the new guy was a trouble-maker. A less experienced manager may have been tempted to intervene. Indeed the individuals may have wanted intervention - some higher authority to rule on who was right and who was wrong. But it was better to let it be.

Eventually, a design was agreed - painfully. A deadline was approaching and a hard weekend of overtime was required to create the code. This was the crucible - differences were put aside and everyone focused on the goal. By the end of the weekend, the code was complete on-schedule. A weekend of 'performing' had achieved the result. A new found mutual respect existed and a team that had been publicly 'storming' for weeks had finally reached 'norming'.

The moral of this story is that managers should try at all costs not to interfere with team development and inter-team dynamics. Maintaining a hands-off approach will ultimately deliver the best productivity.

|