Blog
: October 2003
Friday, October 31, 2003
Your Job May Be Safe After All
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.
Posted by David on 10/31 at 02:33 PM
(0)
Trackbacks •
Permalink
Thursday, October 30, 2003
Instilling Discipline
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…”.
Posted by David on 10/30 at 01:00 PM
(0)
Trackbacks •
Permalink
Who Wins In Offshoring
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.
Posted by David on 10/30 at 12:56 PM
(0)
Trackbacks •
Permalink
Tuesday, October 28, 2003
Door to Door Value
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]
Posted by David on 10/28 at 02:43 PM
Permalink
One Page Project Management
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.
Posted by David on 10/28 at 01:43 PM
(0)
Trackbacks •
Permalink