19.1.09

The Story of India



"India's history is a ten thousand year epic but for over two millennia, India has been at the center of world history."


The Story of India is a new six hour documentary from PBS and the BBC.  It purports to trace the history of modern India from 70,000 BCE to 2007.  When I first read this, I thought the goal was too ambitious, and figured the show might not even be worth watching.  

But... I was very much mistaken.  This PBS and BBC joint production, narrated by Michael Wood, is the first TV or film production I've found that captures the feel of India.  I've watched the first four instalments, and have certainly learned a great deal; but more importantly, I've been transfixed by the beauty and intelligence of this documentary.

And the good news is that you can still (in the US anyway) see it on TV for free, on PBS.  

If that doesn't work for you, or if your DVR is all filled up with footage of the US presidential inauguration, then you can buy the movie on DVD here.

I won't even try to summarize the content of the first four installments of this six-hour film, but I will say that the photo slide-show here really captures the feel of the film, and the film really captures the color and energy of modern India.

Take a look through the PBS site, and if it looks compelling to you, do try to watch this movie.  You won't be disappointed!




13.1.09

Old news, but interesting

If I were more diligent in keeping up with commentary about the outsourcing industry, I'd have posted this last week.  But alas, I was traveling and working, and this is the first chance I've had to summarize the latest big news in Indian Outsourcing.  

Satyam Computer Services, formerly India's third largest IT outsourcing company (53,000 employees) is now known as "India's Enron."  The company has been embroiled in scandal since the end of December, and as facts unravel, it appears that this publicly traded company, once a winner of prestigious awards for corporate governance, has been manufacturing earnings reports for some time.  

So far, the founder has been arrested, the CFO has been taken in for questioning by Indian authorities, the stock has been delisted, and the company's external auditor may be under investigation for complicity.

This is interesting for a few reasons:
  • It's a fair bet that Satyam won't weather this as a company, meaning their assets, contracts, and more importantly talent might be acquired by one of the remaining Indian outsourcing companies.
  • This scandal calls to question practical wisdom about corporate governance.  Satyam was publicly traded, and gave the appearance of being in compliance with all regulations, standards and best practices for corporate governance. Lots of companies in the US seek to partner with publicly traded companies on the potentially mistaken assumption that SOX compliance (or other similar international standards for governance) will reduce risk and prevent the kind of fraud Satyam is accused of committing. There's still more investigation required in the Satyam case, but being publicly traded is clearly no guarantee of being well governed.
  • I suppose this is not news, the US doesn't have a monopoly on corruption, though US companies are probably still statistically over-represented in recent corruption cases.
More on this story in these stories from the Financial Times:



4.1.09

Elance

I posted some time back about a freelance aggregation site called Scriptlance. I just stumbled across another reference, in a blog I read called "Cool Tools." The post in question talks about an aggregation service called Elance. They've apparently brokered $60M in contracted freelance jobs in the last year, with a very small dispute ratio. According to Kool Tools author Kevin Kelly:

Elance's escrow service holds the payment and protects both the work provider and you the employer. The site provides status updates on work done, and plenty of communication between the parties. Workers must pass a competency test to qualify to be listed. Some freelancers can also pass expertise tests in a mild form of certification, say for working on java or ajax, etc. Elance freelancers did about $60 million of work last year and less than 1% of the jobs had any kind of dispute, and most of those were self-resolved by the fact that the entire transaction correspondence is logged. (quoted from Cool Tools.)

I really like this business model. I'm on the verge of bidding out a logo design, and a web site redesign, and I'm going to try Elance. More news on this project and business model as I get it.


2.1.09

Outsourcing and process

The CMMI Maturity Levels, from Wikimedia Commons 

I have had dozens of conversations through the years about outsourcing and process. They usually start with questions about "what process is best" for a given team structure. I have a very pragmatic approach to this problem, that sometimes comes across as heretical.

The process doesn't matter.

I've worked in shops that spent a lot of time focusing on process. I've worked in shops that spent next to no time on process. I've come to the conclusion that process models and frameworks alone have very little impact on productivity or quality.

What matters is having smart people who know how to work well together.

The paradox in my heretical belief system comes in the nearly universal truth that smart people working together will develop and document a process, and will often optimize that process, write it down, diagram it with swim lanes and flow charts, and update it when they change it.  It's human nature to develop process.

The best teams I've been a part of developed process communally and adapted the process perpetually.  

The lesson for leaders in this observation is this:
  • Don't spend a lot of time focusing on your process model, whether it's for software development or IT service delivery.  Certainly don't do this at the expense or exclusion of first-order problems.  
  • Instead, give your team the mission of determining their own process definitions.  Make the mission of developing process definitions subservient to the mission of building software, or delivering service, or doing what ever it is your customers pay you to do for them.
  • Make sure your team writes their process or processes down.  Make sure it's reviewed by some contingent of your leadership team or executives.  (That's less to get input from the reviewers, and more to make the staff structure the way they talk about the process.)  
  • Make sure the staff has some way to train new hires or new team members on the expectations around how the team works together.
  • Make sure there's a feedback mechanism to get inputs and good ideas into the process.
  • Make sure the process is malleable.  
You'll notice that the CMMI process model doesn't define what kind of work flow you should use.  It doesn't mandate what format your functional specification takes.  It doesn't demand that you make your meetings 90 minute seated affairs with parliamentary rules of order.  Neither does it give guidelines that your meetings be held in conference rooms without chairs, to make them go faster.  The CMMI process model defines some broad, universal concepts that all projects go through.  As a process definition, it really just maps the high points.  It's up to you and your teams to fill in the details.  I think this is appropriate.  

So my ultimate guidance is that the process doesn't matter.  What matters is having one, and communicating what it is.  (In this, your SDLC can be thought of as just another high-expectation task you need to document.)  All a process model is is a statement of expected behavior of people in groups solving problems. 

I will add one caveat, because I've seen a lot of teams attempt to adapt their process to integrated global teams -- Agile software development methodology, with daily scrum meetings, does not work well if your scrums have to involve teleconferences with remote teams in different timezones.  It's too cumbersome to give the kinds of productivity lifts for which this particular process trick was designed.  Instead of doing one big scrum,  consider decomposing your project a bit more, and allowing the remote teams to each work on discrete release components, so they can have their scrum meetings be self-contained in their local centers.  It won't always work, because you won't always be able to break the project into discrete components, but it's a good hack to allow a bit more productivity across two lobes of a global team.