I've been thinking a lot about the material in Good to Great by Jim Collins. I'm wondering if his theory of a Hedgehog Concept, as he calls it, can be used for personal decisions as well as corporate strategy.

First let me explain the Hedgehog Concept. Borrowing a graphic from the book, a hedgehog concept is the intersection of three ideas - what you are passionate about, what you can be best in the world at, and what drives your economic engine.

I'm not in a position yet to say how I'm using this idea of a Personal Hedgehog Concept for my own career development. I may be able to say something more towards the end of the first quarter of 2004. However, I'd like to use another example - the recent career of blogerati cognoscenti - Cameron Barrett.

I've met Cam on a few occasions and had the pleasure of dining with him twice while I lived in Kansas City. Recently, he took a job with the Wesley Clark presidential campaign in Arkansas. A far cry from his web developer contracts in New York City. This has led to criticism on his Camworld site, such as this,...

Sorry Cam, but Clark won't win AND web-based campaigns are overrated. Yes, the build buzz, but it's miniscule and really has no impact on the real vote. Show me real data that disagrees with me. We can get all excited about this stuff, but it's mostly insignificant besides ego building.

Let's consider this criticism using Collins' Hedgehog Concept.

Those who know Cam or have followed his weblog for many years, will know that he is passionate about web standards, UI design and web development but they will also know that he is deeply passionate about politics - particularly traditionally democratic liberal issues. What drives Cam's economic engine? For years he has been paid to build state-of-the-art websites with a focus on open standards, good UI design and high performance to cost ratios. That leaves "What you can be best in the world at?" It seems to me that the market niche for building a winning online political presence is wide open.

Therefore I feel that it's irrelevant whether Clark wins or loses. Cam can only be a winner. He will come out of the experience with a Hedgehog Concept which positions him as the world's leading developer of political campaign websites. Now that is something which he could make a career out of for the rest of his working life. The web can only get more and more important as a political tool over the next 20 years.

What's your Personal Hedgehog Concept?

|

Just a few links this evening...

Concorde Deux?

These boffins at EADS, as reported on the BBC, clearly didn't read my earlier post about why Concorde (and supersonic travel) just doesn't make sense when you think about the constraints in the problem. Is there a market for Paris to Tokyo in 2 hours? What does it do to the door-to-door journey time? Can it be filled with 300 people every day? and will that represent sufficient business to repay the investment? The critical question to ask in EADS marketing department is, "are we taking a holistic view of this problem?" Customer value is delivered by solving the end-to-end problem - my journey starts when I leave my mother-in-law's house in Shiki (near Tokyo). It ends when I get to the hotel on the left bank in time to shower before dinner and catch some jazz in a local club. Who am I? Someone other than the agile manager ;-) Maybe a dealer in fine art work ourcing a piece for a rich client back in Japan. But are there 300 of me every day who absolutely must arrive before I departed? ;-)

Bangalore Texas

"The Indians are coming" - some nice insight from The Economist on how Indian outsource firms are having to create a presence in the USA in order to make their services more politically attractive.

Instant Companies - just add re-use and stir

Om Malik, a favorite journalist of my friend Martin, has a piece, "The Rise of the Instant Company", in Business 2.0, about the rise of new low dollar startups which are thriving quickly through re-use of COTS (commercial off-the-shelf) components. These companies are in Internet switching, security, and more consumer oriented areas such as home entertainment. The essence is re-use of cheap off-the-shelf hardware such as Intel processors, standard disk drives and other bits, then add some open source software - particularly the Linux OS - which leaves all the R&D effort for new software, i.e. the recipe is a couple of large dollops of reusable hardware components, some knowledge worker brain power, a few all nighters, then leave to cook for 18 months to 2 years, and voilà a nice $200 million dollar company to flip to a slower lumbering goliath with brand recognition and an established sales channel.

I wonder what Om would think of my ideas to take the re-use and value chain the whole way through to the software.

|

HR Myth #2 - "Divide and Conquer" or "You Get What You Negotiate". Many HR managers see it as their job to squeeze new hires on their pay and package. They see this as reducing costs and directly helping the bottom line of business. In some cases, they are incentivized to get good deals from new hires. This can be counter-productive. Once again, it is a cost accounting driven focus on cost.

In almost all companies it is directly against company rules to discuss what you - the knowledge worker - are paid with your colleagues. Why? Simply put, it is a divide and conquer strategy by Human Resources. They believe that by enforcing silence with a threat of summary dismissal, they will save the company money and reduce complaints from disgruntled employees. In a few companies, it is also illegal to discuss your pay scale grade with other employees. This is the ultimate in Big Brother style control because it theoretically prevents employees from learning that someone doing the same work is on a higher grade than them. HR believes that this enforced silence reduces complaints, saves the business money and makes employees happier.

Both Steve McConnell and Paul Glen (and I) would disgree with this. HR is thinking about a purely local optima - reduced complaints to HR. They aren't seeing the system as a whole.

Steve McConnell believes in total transparency in pay scales. We've heard a lot about transparency on this site recently. Well this is how Steve's company, Construx of Bellevue, WA, provides transparency in their pay process.

Salary Structure. We've found that an organization's traditional reward system must be structured to support [personal] professional development goals; otherwise, project goals will supercede [personal] development goals. ...

Our ladder levels have exactly one salary level at each level. The salary for each level and each employee's ladder level is public information within Construx. Employees have a tangible incentive to reach the next ladder level because they know the salary adjustment that will occur with that promotion. [McConnell, Steve, Professional Software Development, Addison Wesley, 2003, page 158]

Note that there is only one pay amount per level - no sliding scale. There is total transparency in the system, and as Steve describes elsewhere in the book, there is a publicly defined definition of qualifications for each level on their pay ladder. Every employee is able to judge whether another employee is fairly graded because they know them, they work with them and they will know their skills.

Paul Glen explains in Leading Geeks why Steve's approach is best. In the chapter, "The Essential Geek", Paul explains the elements of what he refers to as the geek psyche. One of those elements is "a sense of fairness". Geeks love and expect meritocracy.

Geeks are generally not captivated by money. ....

Their attitudes to money are much more tied up in their strong sense of fairness and justice. No one wants to be taken advantage of; everyone wants to feel fairly compensated for their value. The passion for reason combines with a strong belief in meritocracy to create an atmosphere where money is a primary measure of the value that one delivers to the organization. [Glen, Paul, Leading Geeks - How to Manage and Lead People Who Deliver Technology, Jossey-Bass, 2003, pages 40-41]

As a manager, I spend a lot of time balancing equity amongst team members. I make adjustments in pay to recognize contribution and to reflect the merit of the individuals. I often get into heated arguments with HR people. Why? Because I'm often trying to clean up the mess they make.

Software development IS a people business. The best way to exploit the people constraint is to keep them happy and well motivated. That is best achieved through a transparent, merit based pay scale.

|

"Merit Based Pay" or "We don't care about productivity look at our cost control" is the first in a series of blog entries which seek to blast away the human resources myths which exist in the software industry.

It's traditional in the knowledge worker world for companies to have pay scales and levels e.g. Level 56 = $24,677 to $33,103. Any employee who is a Level 56 grade will receive a base salary between the two amounts. In some companies, these scales are lies. Often there is a mid-point or median. In my example above it might be $28,500. Companies' executives decide what kind of performance they'd like to achieve for stockholders. Then then decide whether they need upper quartile, 2nd quartile, 3rd quartile or lowest quartile employees to achieve those goals. In many large companies today, they don't pay more than the 3rd quartile. So in my example the pay scale is truly $24,677 to $28,500. In this respect, most pay scales are lies.

This is the classic cost accounting mistake of focusing on cost. There are numerous examples of programmer productivity being upwards of 10 or 20 fold better between a good software engineer and a bad one. In fact, some studies say the worst to best can be 50 fold [1]. However, a good manager knows that they only need to pay a modest amount more for good people - perhaps the upper quartile for a pay grade. So why not hire only upper quartile candidates? Pay 50% more and get 1000% better productivity. Hire less people and control costs that way. Isn't that the best solution?

My feeling about why this doesn't work in large companies relates to relative standards. It is assumed that hiring managers will not have good metrics for providing balanced equity across the organization. It is further assumed that hiring managers may not be good at screening candidates. It is further thought that hiring upper quartile people sets a dangerous "elitist" example for engineers when other jobs in the company are not hired this way. In other words, mediocrity is both assumed, desired and controlled. Specific grades are generally awarded based on length of service, experience or age as this is assumed to be the most reliable indicator of someone's contribution and their value to the organization.

So companies which claim to be meritocracies, in fact, are not. They pay people in a very narrow band. In my example, you can be sure that everyone on that Level 56 grade is being paid between $27,000 and $28,500 despite the fact that some of them will be 10 times more productive than others.

The way to break HR Myth #1 is to refocus the business using the Throughput Accounting focus of productivity first, investment second and cost last. Cost first generates mediocrity and mediocrity results in very poor performance from a software engineering organization.

[1] Reference: Sackman, H. W.J. Erikson, and E.E. Grant, Exploratory experimental studies comparing online and offline programming performance", Communications of the ACM, 1968, 11(1)

|

I'm begining to see "Agile Management..." and its promotion of the Theory of Constraints in software development have an influence on other authors. In this Technical Report from October, Alistair Cockburn, cites my book as an influence when he examines whether "process" is the fourth constraint and whether use of appropriate process can be used to "trick" what he calls "the iron triangle" of the three primary constraints in software development - schedule, scope and resources. This is the first citation I've noticed for the book. Thanks, Alistair! :-)

Also, in their latest newsletter, Mac Felsing and Jeff Cohen, of ProcessExchange, explain why small batch sizes are better in software.

|

In Chapter 17 of "Agile Management...", I take a serious look at product management for software services and examine the business model - I choose to use the telecom industry as an example. In order to explain how to do product mix selection, I first have to recast the standard telecom financial model of EBITDA=ARPU-CCPU (Earnings before interest, tax, depreciation and amortization equals average revenue per subscriber less cash cost per user (times the number of subscribers)), into a proper Throughput Accounting model. This was non-trivial.

As many people who read this column know, I work in the wireless data services industry. It is no secret that I used to work for one of the big US carriers, often considered one of the smarter and more innovative - Sprint PCS. When deploying wireless data services, any marketing manager at a carrier is required to construct a business model for the service - remember the service is basically just software in operation. Hence, the business model relates directly to the features that must be coded in the software. Many managers are trained to think in cost accounting terms and work their plans around the "cost per megabyte" and the "revenue per megabyte". The supposition is, that if revenue exceeds cost then you build the software and deploy the service. What's wrong with this model? Simply put it - there is no such thing as a "cost per megabyte" and framing a business case in these terms is simply trying to measure the wrong things.

It is way past time that wireless phone companies realized that there business is more like selling seats on aircraft than commoditized physical components as this article [E+ membership required] in the Economist explains. The essence of the problem is that the cost of building the wireless data network is a sunk cost. There is virtually no marginal cost to carrying megabytes of data across the network. Hence, the true "cost per megabyte" is really $0.00 - nothing!

When might this not be true? In 2.5G networks, the data and voice carrying capacity exist in the same channel space though voice is essentially traditional circuit switched technology whilst data is packet switched. Networks are configured to transfer capacity between voice and data depending on demand. Usually voice takes precedence since it was assumed that voice was (a) more important for customer service and expectations, and (b) more valuable - this assumption may prove to be wrong but that is another story. Hence, the total capacity or bandwidth of the network is a constraint - ah ha! So we have the system constraint. In the event that the capacity is full, then and only then, is there a potential cost of carrying an extra megabyte. That cost is essentially the opportunity cost of carrying some other traffic which might generate more revenue. Until the capacity is completely allocated - there is no cost per megabyte. The cost is already sunk from the build out of the network and is being amortized as a fixed cost rather than a marginal cost per megabyte transported. When the constraint is reached, the ideal carrying mix would be determined by the highest revenue per megabyte.

In Good to Great, Jim Collins explains that great businesses figure out what drives their economic model and what determines the correct denominator with which to measure performance. He gives an example of Walgreens which chose to measure "profit per customer visit" rather than "profit per store". The latter would have driven behavior which encouraged them to close small stores and open fewer larger ones, serving larger areas. This would not have made them great. They became great by opening more stores in convenient locations and generating more customer visits as a result. In turn those greater number of visits generated more profits because store managers were asked to focus on how to make the most "profit per customer visit". The choice of denominator which made Walgreens great was "customer visit".

Coming back to wireless data telecoms, "megabyte" is the wrong denominator. What would be a better denominator? "Subscriber month", or possibly even better is "subscriber communication". In this latter model, the wireless data services product manager is focused on generating the most number of unique communication events. However, "cost" is the wrong numerator. The numerator must be "revenue". In Throughput Accounting, revenue is most important factor, investment is of second most importance and cost a distant third. I explained this in Chapter 2 of "Agile Management...".

Why is all of this relevant to software engineering management? Well, the business model for the service, determines whether the software is commissioned or not. Further to this, it affects engineering decisions and architecture as well as features. If the mind set of marketing is set by "cost per megabyte" rather than "revenue per subscriber communication", imagine the difference it makes to both functional and non-functional requirements in the release mix.

Requirements start with product concepts and product concepts are enabled by market opportunities and a realistic go-to-market strategy (or business model). With the wrong business model, the wrong software gets written, the consumer is disappointed and profits are left on the table when they might otherwise have been turned into shareholder value. The most agile thing any software engineering manager can do, is refuse to build what the customer doesn't need. In order to do that, the product or service definition must have been couched in the correct business terms.

|

Those who have read some of the book will know it is about transparency of process and transparency of tracking the flow of value through the software engineering lifecycle. I really liked this example [E+ membership required] of "extreme" transparency from Japan's recent general election as described in The Economist print edition November 15th page 25. Here is the relevant quote...

Mr Kan told voters that the flamboyant governor of Nagano - who works in a glass office so that everyone can see whom he meets - would join the DPJ cabinet if the party won the election.

|

It is now widely recognized that with software development processes - one size does not fit all! This goes as much for eXtreme Programming as it does for SDLC or RUP. In The Right Tool for the Job, Scott Ambler examines the issues in the latest issue of Software Development magazine. Scott references using risk assessment as a tool to help select the right process and points the reader at the recent Boehm and Turner book, Balancing Agility and Discipline.

Last week, I talked about the problems of having a centralized group which selects tools for use in software development. The same applies to software process. It makes no sense to have a centralized proclamation that the entire enterprise - and I've worked in companies with 20,000 software developers - should use RUP (as an example). Software process choices should be aligned with value chains. The market into which the software is being deployed should be understood and an assessment made as to the stability of the requirements and the likelihood that the application can be deployed iteratively or incrementally rather than holistically. This is what Boehm and Turner call a risk assessment. There are other treatments of the problem.

In Chapter 34 of "Agile Management..." I divide the problem into a 2x2 matrix providing for 4 categories: immature holistic domains; mature holistic domains; immature incremental domains; and mature incremental domains. I then suggest process choices for each of these quadrants.

In Agile Software Development Ecosystems, Jim Highsmith maps the problem space using Geoffrey Moore's technology adoption lifecycle model of Early Market, Chasm, Bowling Alley, Tornado and Main Street, as described in his books, Inside the Tornado and earlier in Crossing the Chasm.

So there is lots of advice out there. The bottom line is that this advice should be followed on an as needed basis - by project or business unit. There should be no grand centralized choice made in the ivory tower. The minor cost efficient advantage of having all the staff trained in the one method, is far outweighed by the problems created and the cost in real ROI terms by using the wrong tool for the job.

|

I've mentioned the notion of creating a software development supply chain to assemble software from components before at this site and on my Yahoo! group. Now Clemens Szyperski and David Messerschmidt develop the idea and examine what makes it different in The Flexible Factory [registration required] in the December issue of Software Development magazine. They speculate that software assembly would be a new "industrial revolution".

They also observe that a market must exist for components. This is not a new observation. The component world dream really started with products like the OS/2 Workplace Shell (OS/2 2.0). That dream was so far ahead of its time that technologies such as CORBA had to be invented for it. In an interview I conducted with Dave Roberts, one of the designers of the Workplace, he recognized the deficiencies of the model - no market place. However, the markets such as ComponentSource and Flashline do not really solve the problem. Any VC will tell you - "there is no money in (software) components". Why not? There is huge money in PC components e.g. processors (Intel) and disk drive controllers (IBM). The reason is that value cannot be measured and hence value falls to the lowest common denominator. Value is primarily determined by cost. Not by the risk carried in the value chain. All that these companies are providing is an online version of wholesaling for component libraries. Something we used to do from firms such as Greymatter.

Dave Roberts believed that web services were the answer to the problem. Runtime metering of method calls. I believed this too and was responsible for an infrastructure called "Wireless Application Manager" which planned to offer runtime metering and billing for wireless web services on the Sprint PCS Vision network. That system was never implemented but ideas like it are beginning to emerge. For example, it is now possible, using technology similar to aspect-oriented programming to weave code into applications which meters the use of method calls and reports it to a central billing system - such as that owned by an ISP or a telco.

This solves the final problem identified by Szyperski and Messerschmidt - that of trust and risk. In the design for Wireless Application Manager, for example, all web services were non-repudiated end-to-end through X-509 certificates on the supplier end and through the handset identification on the other. The access carrier is best placed to play the role of trust mediator. They can also provide quality of service - something which wasn't identified in the SD magazine article. By allowing price differentiation across quality of service lines, supply of services or components will naturally align with value chains and risk is spread across the suppliers in the chain.

The bottom line is that there is a whole lot of infrastructure to be built out before supply chain assembly of software applications will be possible. It involves the development of network access operators to facilitate the marketplace and provide the trust, quality of service, metering, billing, mediation and settlement. It requires a wider use of a meta-data language such as RDF but one which is capable of semantically describing an application in a way which can be identified in an agreed ontology along with its quality of service ranking and its terms and conditions of service, including price. For example, does a downstream partner get a discount for volume - and if so, how much, and how is this administered? Does the end user get to specify QoS and Trust levels for an application such that all the components or services it taps into fit that designated level and will the price the end user pays vary accordingly? Is there a concept of first class, business class and economy for use of a word processor?

Maybe! Just maybe... Check back in 15 years.

|

Chapter 4 introduces a critical theme in the book - uncertainty. It shows how to analyze uncertainty in the 3 key constraints of software development - scope, schedule and resources. There is much greater uncertainty in scope, and considerably less in resources and very little in desired delivery date. Often so much is dependent on a delivery date - a whole marketing and distribution program - that a date cannot slip. Hence, it is certain that the date must be hit. The resources for a project are generally fairly fixed and difficult to vary at short notice. As Fred Brooks said, "adding people to a late project makes it later". The scope, however, does generally have a lot of uncertainty attached to it. Requirements do change and scope does creep.

Rather than classify uncertainty into Deming's traditional 2 types of variation - common cause and special cause - a newer approach is taken where uncertainty is classified into 4 types - common cause variation, foreseen uncertainty, unforeseen uncertainty and chaos.

Buffering for uncertainty is examined and the "local safety" problem are introduced. The chapter ends with an explanation of how to reduce uncertainty through aggregation of tasks with the resultant buffering being calculated as the square root of the sum of the squares of buffers for each task.

The Agile Manager must learn to accept uncertainty is real and through acceptance master it with judicious use of buffers.

|

Keith Ray gives a fine example of test-driven development (TDD) today. He argues that TDD represents "software pokayoke" (mistake proofing of the development process). However, I fail to be convinced. [Sorry to disagree here Keith :-)]. I see TDD as quality assurance. There is a subtle difference between mistake proofing a process and failure proofing a product or service. I think the real "pokayoke" in Keith's example is in this quote...

So how do we know the test is a valid one for the requirements? Well, it looks good to me. I ask my pair partner; he thinks it looks good, too. Since we're doing Extreme Programming, we ask our on-site customer what the log should look like. She looks at our test and says "This displayed text should have an exclamation mark at the end." So we add "!" to the end of the strings in our tests.

The inspection process on the test to validate that it assures the match of output against the requirement is the real "mistake proofing". The inspection step of asking both the pair programmer and the on-site customer if the test is accurate is the vital piece of mistake proofing. That step must be part of the process and it must be conducted or there is a risk that a test will run but be testing the wrong thing. That is Pokayoke!

|

Jeff De Luca is offering early access to Jim Highsmith's new manuscript, "Agile Project Management" from the Feature Driven Development website.

|

I've been wondering about how to separately encapsulate business rules. If you've been following my posts on this topic, then you'll know about The Business Rules Approach and how it separates out domain model from business rules from (user) tasks. The Nicola & Mayfield book Streamlined Object Modeling shows how to map business rules onto a domain model.

However, I find this Nicola/Mayfield approach unsatisfactory. It does not separate out the concerns of domain versus business rules. There is no separate encapsulation of the rules. Rules have a far higher uncertainty and variability than the domain. Hence, separate encapsulation would reduce the regression effect when rules are changed without impact to the domain model. The value of architecturally separating variability is explained Donald Reinertsen's Managing the Design Factory. The purpose is two fold - it reduces regression effects from change, but it also reduces the overall variability in design effort which ultimately reduces schedules.

This paper, Aspect Oriented Programming for Connecting Business Rules [PDF], given this year at Business Information Systems 2003 shows how to implement business rules using aspect oriented programming - cleanly separating out the rules into aspects. This provides the architectural separation of variability.

Hence, in a world where we capture requirements in a domain model, feature set, business rules and task flow (Visual Vocabulary or Statechart model), we will get the most ideal mapping of code to requirements by implementing the system using an aspect oriented language. This allows a much more accurate tracking of the flow of value. Aspect Oriented technology may lend itself to Lean Software Development and may contribute to pokayoke (designing out the possibility of failure). Encapsulation of business rules in aspects, automatically reduces variation and reduces the chance of failure.

|

Business Week examines the power train of Toyota and wonders if anyone can stop them? The article provides good insight to the advantage that comes from 50 years of developing just-in-time inventory systems, Deming quality assurance, designing out the possibility of failure and a process of continuous improvement.

There are 4* main aspects to Lean Production: Kanban (the notion of self-organizing flow regulation); Kaizen (the process of continuous improvement); Quality Assurance (Edwards Deming's teachings on Statistical Process Control); and Pokayoke (the notion of designing out failure). [* As Hal Macomber points out , in the comments, this list should have included Muda (waste) as the 5th key element]. So far agile software methods have really only developed in two of these areas - self-organization and quality assurance. Despite the feedback loops in agile methods, they are primarily quality assurance loops not learning organization loops. And there is really no equivalent of Pokayoke in agile methods. In fact, early writings on agile methods suggested that tools were not important. There was an almost Luddite tendency to ignore tools and focus only on people.

The closest thing to Pokayoke in agile is the design and code inspections in FDD. However, these don't go far enough. Proper Pokayoke would be using architecture and tools which design out the possibility of failure. Tools such as Statesoft's JStateMachine represent "pokayoke for user interface". A fully Lean software development method will include architecture, modeling and supporting tools.

My final word on this Toyota article is the observation that Toyota is a "failure tolerant" company which has transcended beyond a mere "learning organization". Those familiar with Chapter 11 and 12 of Agile Management for Software Engineering will understand this. My proposal for an agile maturity model calls for a learning organization as level 4 and a failure tolerant organization as level 5. Toyota is clearly a level 5 organization on that scale.

|

Chapter 3 introduces the Theory of Constraints 5 focusing steps: identify the system constraint; decide how best to exploit that constraint; subordinate everything else to that decision; elevate the constraint; repeat for the next constraint. Using the systems thinking approach from Chapter 2, it then shows how to identify and exploit a constraint in software development. This is done using the production solution for TOC known as Drum-Buffer-Rope. The idea, introduced in Chapter 2, that inventory is defined as ideas for small pieces of client-valued functionality defined in the requirements, is used, and tracked end-to-end throughout the system. Where there is a bottleneck, inventory will not flow - it will stockpile at that point in the system. This can be identified through tracking.

The notion that requirements in software are "perishable" is introduced. Hence, the inventory is depreciating every day it is bottlenecked and not flowing. Depreciation in requirements implies change and this costs money. Hence, elimination of bottlenecks to ease the flow of inventory is essential for financial performance.

Chapter 3 then turns attention to the essence of TOC - focus. It shows how to focus management attention, time and money on the capacity constrained resource (CCR) in order to elevate and ease the flow of inventory through the system.

|

Does your organization have a central group which selects tools for use by software engineers? If you work in a large company in the Fortune 1000, the chances are that you do. These groups often go by names such as "Technology Process Group" or "Architecture Committee". Generally, they report into the corporate HQ on the organization chart. They are usually affiliated with research groups and exhibit the look and feel of an ivory tower.

If you are a development manager, you've probably had one of your team complain that he's not allowed to use the best tool for the job because "some idiot at corporate" forces him to use the standard tool. Why does this happen in software development? In a Lean manufacturing plant it is unthinkable that a centralized group of academic manufacturing engineers would make a standard toolset recommendation. In fact, Lean teams are so empowered they get to invent their own specialist tools. Workers are best placed to decide how to get the job done. They are expected to choose their own tools for optimal effectiveness. In the production assembly world where activities are so regulated and repetitive, this may be surprising. However, when you think about the nature of software development, it seems downright ridiculous that anyone other than the software engineer writing the code should choose the tool to get the job done.

So why does this happen - this centralized standard for tools - this proclamation from the ivory tower? Quite simply it is yet another manifestation of a cost accounting fallacy. By choosing a standard tool for say - object modeling - or a development IDE - there will be an economy of scale for the larger license purchase. This is a saving, right? It reduces operating expense, OE, right? Yes, this is potentially true but what does it do to throughput?

In a world where it is now widely recognized that no one software engineering process fits all sizes or domains of project, then it is also highly unlikely that one size of tool will fit all sizes of software development.

There is another argument proffered for single tool selections. It is one of interoperability of personnel and ease of support and maintenance. Again, this is a cost accounting fallacy. It comes about because tools are confused with platforms. Platforms are technology environments which run in production. A RDBMS such as Oracle is a platform. An application server middleware such as Weblogic is a platform. A runtime environment such as Java or .NET is a platform. However, an IDE, or a modeling tool, or a compiler, or a version control system is simply a tool. Platforms are involved in generating throughput for the operational business. A platform must be maintained in production. It makes sense to reduce the number of platforms which must be supported. It does not make sense to cripple a development manager's ability to deliver a project by forcing his team to use the wrong tool for the job.

Now, to be clear, I am not advocating a free for all. A team where every member is using a different IDE is not a team but a group of egos flying in close proximity. Teams must decide on the tools to make them effective. This should be done on a per project basis. The workers writing the code should make these choices by consensus and the development manager should have the freedom to procure the tools the team needs. Centralized tools standards, represent constraining policies. The Theory of Constraints suggests that policy constraints should be eliminated whenever possible. Centralized policy constraints, reduce the empowerment of development managers and developers. This creates a poor environment for optimal productivity. It demoralizes knowledge workers and constrains their performance.

The agile senior executive will seek to eliminate central committees and their cost accounting inspired, policy constraint proclamations, whenever and wherever possible.

|

This is Concorde taxi-ing into its retirement home at Boeing Field in Seattle, WA at 3pm this afternoon. As I wrote last week, I was lucky enough to see the first one and now I witnessed the arrival of last one on its last official flight. For good measure it set the passenger jet speed record for an east to west coast crossing of North America - thanks to the Canadian government who let it fly supersonic.

So why is Concorde sitting here on the tarmac in Seattle, a museum piece, rather than flying? It is after all a young air frame. With proper maintenance Concorde could have kept flying for some time to come. On July 25th, 2000 a Concorde exploded just after take off at Paris. After some extensive modifications the fleet re-entered service but consumer confidence had dropped and its mega-rich customers didn't come back.

As I explained last week, the niche market for Concorde was passengers who are their very own capacity constrained resources - for them, time is money (or some other goal such as, time is leisure). For the mega-rich who needed more time to shop on 5th Avenue, Concorde was the only ticket to have. Those customers didn't come back. Why? Joan Magretta, writing in What Management Is explains why Concorde was grounded using two key ideas in management science. First a business must face brutal reality by believing its metrics and secondly it must be gathering the correct metrics. The Six Sigma principles of measuring for quality of 4 failures per million opportunities is important with safety critical systems in which the customer must have absolute faith.

"The numbers which matter are the ones that help you to face reality, and to do something about it. Consider:

On July 25th, 2000, an Air France Concorde jet exploded shortly after takeoff... The crash left 113 people dead. These were the first Concorde fatalities in the supersonic jet's thirty-one year history. Within days, the Concorde, ..., was grounded indefinitely.

Why was the world's fastest passenger jet suddenly taken out of service? There had been only three disintegrating tyre incidents over thirty-one years, and none had caused a plane to crash before. How bad a safety record is that?

In a word, unacceptable - but that is clear only when you compare the number of incidents to the total number of times the Concorde has flown. Because there were so few jets in service and so few flights per day, the failure rate was extraordinarily high. If that rate were applied to a fleet of U.S. airlines in service, it would produce one serious tyre explosion .... per day. One per day! That is why Concorde was grounded. And it is why management requires the discipline of quantification. Simple numbers help us to face reality and to make sense of the events in ways that our intuition alone cannot do." Joan Magretta, What Management Is, pages 119-120, Free Press, 2002

Why the customers didn't come back is an area for psychologists. We humans are very poor at risk assessment. We tend to over estimate some risks and under estimate others. We try to scale risk taking against the consequences. In this case, the perceived risk of death from flying Concorde was very high - and rightly so, as Magretta points out. British Airways didn't do enough to convince the customer base - that elite niche of Concorde passengers - that the problems had been dealt with appropriately and completely. They failed to communicate the safety improvements. The customers failed to believe and showed through a lack of patronage that they valued their lives more than time saved on transatlantic crossings. Despite the fact that such people perhaps take more risks to their life through other lifestyle choices, for them Concorde seemed like a risk too far. Where human risk assessment is concerned, perception is everything.

In recent months, British Airways filled the jet with supersonic virgins. Those willing to risk their life for the flight of a lifetime. With no solid customer base to sustain it as the flagship service, its value to the BA brand was dimished and consequently its fate was sealed.

|

McKinsey Quarterly is raising the imperative need for improvements in high tech productivity in this article, "What high tech can learn from slow growth industries". I think it is fantastic that widely read, broad spectrum publications such as McKinsey's are prepared to talk about this. Software development needs to get more productive if it is to remain relevant in the 21st Century!

Even matching best practices across-the-board won't lead to sustainable differentiation; high-tech companies must also strive for productivity breakthroughs. Of course, this is easier said than done. Often, a process innovation represents the sum of seemingly disconnected parts.

If I have an issue with this article, it is that it raises the right question but only skirts around the answer. It is all very well to suggest that managers in high tech development need to understand what drives their value chain and learn to manage and focus on what limits its productivity, but managers need solutions not just more to worry about. Readers of this site will be glad to hear that they can look to "Agile Management..." to supply those needed answers.

A key message from this piece is that process change to create superior productivity in software development must be seen as a company wide initiative and must be led from the top.

Furthermore, most high-tech companies value and reward technology innovations rather than business process improvements. When these companies do think about productivity, their efforts are typically scattered and deep in the organization. Disjointed programs probably can't move the needle.

What is vital is a commitment from the top to view productivity as a strategic imperative and to realize the organization's agreed-upon process priorities. Employees, motivated by reward and recognition systems, should understand and agree with the focus on productivity.

|

Chapter 2 introduces many concepts which represent the foundation for the rest of the book. It is a difficult chapter. It starts by introducing the concept of Systems Thinking. This is not new to software, Jerry Weinberg first introduced it in Quality Software Management Volume 1. However, my treatment is simpler and more aligned with complex adaptive systems theory. I separate out desired adaptive behavior - working code - from emergent properties - such as documentation and bug reports. The diagrams map a system for software engineering into three basic areas - an input, an output and a system which converts input to output. Financial metrics for this are then introduced - investment (the value of the input), operating expense (the cost of operating the system), and throughput (the rate of value-added observed at the output).

These financial metrics are based on Throughput Accounting (TA), the management accounting technique developed for the Theory of Constraints. TA takes a global systems view of management accounting, as opposed to traditional cost accounting metrics developed from Taylor's time-in-motion theories. Cost accounting measures locally and assumes that local optima results in a global optimum. The Theory of Constraints rejects this notion and TA was developed to replace cost accounting.

The Net Profit and Return on Investment (ROI) equations for TA are then introduced, followed by a discussion of the relative importance of the three main metrics, T, I and OE. This is based in arguments from Goldratt's The Haystack Syndrome and Corbett's Throughput Accounting. It shows that Throughput is most important, followed by Investment and then reflects that cost accounting focuses first on cost, Operating Expense, then on Investment (inventory) and lastly on Throughput (the rate of gross margin creation). The chapter concludes by observing that the TA focus on Throughput is aligned with the Lean Production principle of "focusing on value".

|

McKinsey Quarterly correctly identifies, in "Programmers Abroad: a Primer on Offshore Software Development", that there is a category of software development which is best done in the local market - projects which have high uncertainty in the user task flow, screen design and business rules. These projects require short iterations and customer intimacy. Projects best done locally with agile methods. Check out Exhibit 3 a 2x2 matrix which identifies 3 classes of software development which may be best outsourced offshore, whilst the fourth must remain on-shore, local and in-house.

Offshore partners may have difficulty maintaining application designs for projects such as e-commerce applications, which have short time frames or call for feedback from users. But once these projects enter the later stages of development, even they can benefit from outsourcing. A developer of business-to-business (B2B) software who regards speed to market as critical remarked, "With our new overseas operation, our team is working round the clock, and I now have access to a larger pool of IT resources than I did in the US alone."

|

Mac Felsing, co-author of A Practical Guide to Feature Driven Development, explains that projects are more easily managed using self-generating metrics based on tracking the value created at fine-grained milestones. This is the first issue of the Process Perspectives newsletter, "The Hidden Costs of Application Development". Mac reports that tracking fine-grained milestones improves the accuracy of reporting, eliminates noise in management metrics and eliminates wasted time and expense gathering project management data.

|