I'm in Munich this week at the OOP 2007 conference. I've been stalking the exhibition and chatting with vendors. I'm amazed at the number who are outsourcing or offering outsourced services and the range of options. In the USA, we're used to having two main options - China or India. Here in Europe there are a lot more options. One vendor offered to undercut my Indian test vendor on price by doing my testing in Israel. He claimed that he wasn't as cheap as the Chinese but he'd easily beat any price from India. It seems that the Indians are already having to differentiate themselves on quality!

Other options I heard were Lithuania, Estonia and Bulgaria. Interesting that Poland, Czech and Hungary already seem to be off the outsourcing radar.

There are some clear advantages for the Europeans with these outsourcing options - the main one I can see is time zone compatibility and its close neighbor geographic proximity that facilitates cheap travel between vendor and customer. In some cases a mere train ride away. It seems to me that Europe is better placed to build a software development value chain than America. And that as a result, technologies that facilitate value chain development such as software factories, ALM tools like VSTS, and analysis and modeling techniques that enable cleanly partitioned, well encapsulated, loosely coupled, highly cohesive architecture are more likely to gain traction first in Europe than in America. Technorati tag: Agile, David+Anderson, OOP+2007

Sometimes I find I do my best work when I'm not thinking too hard about it. Today after my presentation at OOP 2007 in Munich, I was in a long conversation about enterprise scale agile development, listening to an explanation of how to assess whether an organization is ready to adopt agile processes across the entire software development organization. I found myself reply and saying,

"I think there are only two questions you need to ask, only two criteria: how much trust is there in the organization? and how failure tolerant is the management and the culture?"

In a culture that embraces a high level of trust, a low level of audit and bureaucracy, and the consequent highly delegated and empowered decision making framework, then going agile will be possible.

With a management that takes risks and tolerates failure as a positive learning experience then going agile will be possible.

Where there is a lack of trust or a lack of risk taking or an intolerance to negative results from risk taking then going agile will be painful, problematic and subject to failure. Technorati tag: Agile, David+Anderson, OOP+2007

In the past month or two, I've had a couple of emails from project managers that opened something like this... "David, I'm planning on reporting project [insert name] as red status this week for the following reasons [...] I just wanted to let you know and check that it is OK with you?" My reply in both cases was "Go for it!"

This came as quite a shock. It seems that it isn't culturally acceptable to report bad news and experienced PM's have made a career out of not doing so. Hence, the politically astute invitation for me to do something about it before the red status gets reported. So my response was unusual. What the PM's fail to realize is that I see red status as my friend.

In a world where everything is green and all projects are on schedule there is no appetite for change. In fact change is risky. Change creates a J-curve effect - things get worse before they get better. Change puts schedules at risk. Change turns green projects red. However, in a world where projects are already red, there is appetite for change. People expect managers to intervene and do something to fix the problems. Managers can take several directions but the two main intervention strategies are tactical/symptomatic fix, or strategic/root cause fix.

When urged by a PM to do something about red status, many function managers may be pushed in to reacting with a tactical/symptomatic fix that pulls the project out of red status quickly but leaves it in danger perhaps bouncing in and out of red status throughout its lifecycle. A strategic/root cause fix involves a change in methodology, a new process implementation, or significant cultural change. In order to have enough space to make such fundamental change and fix things for long term success, it may be necessary to have a portfolio dashboard that it lit up in red first. Tactical/symptomatic fixes may seem attractive - they are often easy to do and they keep everyone happy. However, they ultimately lead to much more effort and they don't represent the behavior of a truly high impact middle manager. True high impact performance comes from taking the time to make the strategic changes necessary so that further and continuous management intervention will not be necessary.

So the next time one of your projects turns red, don't panic! Red status can be your friend. Use its power as an enabler for true high impact sustainable process changes. Technorati tag: Agile, David+Anderson, Software+Engineering, Project+Management

It's taken me a while to publish the last of my thoughts from my trip to Asia last August. Better late than never.

Will your next job be in Asia? (particularly if you are a manager)

What is clear is that the future of the software industry lies in Asia. China, India and many other Asian countries are producing a lot of computer science and related field graduates. They have demographics in their favor - lots of young talent. They have work ethic in their favor. They have a liking for process and holistic system thinking approach embedded in their culture. They value quality and the pursuit of perfection. And most of all they have low costs (at least for the time being). What they don't have much of is experienced software industry management talent!

Recently, I've known several people working for Motorola or Microsoft who have gone to China to manage teams. Indeed had I not joined Microsoft in 2004, I may well have ended up in Beijing leading a team for Motorola. The Director of Microsoft in Taipei who invited me to his city told me with a wink and a smile, "If you wanted I could find you a job in Taipei starting next week." It seems to me very likely that my next job may well be in Asia. [Just to clarify - I have a big job to do at Corbis and I imagine being there for several years. Don't panic! (particularly Corbis employees reading this) I'm not looking for a new job.]

Are you prepared to up root your family and relocate to Asia even for a few years? If you are a manager then chances are you already have a family, and a spouse with a career. Moving to a whole different culture is disruptive. Would you pull your kids out of school? Would your spouse suspend his or her career? and is it worth it?

Well, think about this! If you are 40 years old now, you probably have 30 years of useful and viable career left ahead of you - don't kid yourself about retirement at 65 or earlier. [However, a "3rd life" option of semi-retirement and work as a consultant may be an option at an earlier age but it doesn't affect what I'm going to say.] During those 30 years most of your industry is going to move to Asia in the way that manufacturing abandoned Western shores in the latter half of the 20th Century. Do you want to be unemployed IT manager in your early 50's with kids to put through college and a mortgage with 15 years left to run? or do you want to have a viable career that will last in to your late 60's? Will getting some Asian experience now assist you with that? Will Asian management experience enable you to have a healthy 3rd life career as a consultant, perhaps living in America but traveling to Asia regularly? Technorati tag: Agile, David+Anderson, Software+Engineering, Management, Asia+Technology

Trackback is a sadly broken feature of the blogosphere. It is simply too difficult to use and requires the poster to make too much effort to link a trackback. So you could be forgiven for missing a couple of blogs that resonate with my thoughts on new rules for managing old geeks.

Some of my former colleagues on SQL Server at Microsoft say Amen, and Thom Allen points out that they are still his vacation days. Technorati tag: Agile, David+Anderson, Software+Engineering, Management, Aging+Workforce

My email signature comments have made blogosphere news in the past. For the record, my current signature quotation at Corbis reads "Perfect is the Enemy of Good Enough" and it was chosen for a very specific reason. There was a tendency to seek perfect information before making decisions. I needed to change that mindset and encourage decision making and progress with less than perfect information. But this post isn't about that...

In the final months before I left Microsoft, I changed my email signature from the one Clarke Ching highlighted to read, "Recipe for Success: Focus on Quality, Reduce Work-in-Progress, Balance Capacity against Demand, Prioritize" These four statements really boil down all my management teaching in to four actionable directives that will deliver significant improvement.

I have to thank Don Reinertsen for really helping me to distill my work down to these four bullets. I had the pleasure of conversing with Don over a couple of meals in the past two years and his advice helped form my thoughts around what I originally called the "low hanging fruit." In other words, the four simple things that any new manager can do to produce improvement and lead a change initiative with minimal impact on the organization. I need to thank Julie Chickering for encouraging me to come up with a more positive way of framing those thoughts. "Recipe for Success" is so much better than "Low Hanging Fruit."

This message of four actionable directives is so simple and powerful that I found on my arrival at Corbis that our process engineer Rick Garber had printed them out full page and laminated the copies. Many of my staff had them pinned up in their cubes. On my first day, I walked in to my office and discovered that my white board contained the same message written in red erasable marker. 4 months later it is still there - a constant reminder to me and visitors to my office. Each bullet point acts as a guide in framing all the decisions we make about software engineering and all the processes we put in place.

Recipe for Success: Focus on Quality, Reduce Work-in-Progress, Balance Capacity against Demand, Prioritize Technorati tag: Agile, David+Anderson, Software+Engineering, Management

Nowadays it is very common for software development organizations to be structured in a matrix fashion where the software development and testing functions are separate from project management. Project management gets a lot of focus in literature. Portfolio management and program management organizations are increasingly getting attention but there remains sparse literature on running a software engineering, development or testing function. There is no obvious conferences for function managers to attend or few training courses applicable for function managers who have to learn to manage and lead a specialist function while "lending" their resources to a matrixed project manager from a PMO.

Corbis is structured this way too. My own group consists of 3 development teams, a system analysis team, a test team and a configuration management and build team. These resources are matrixed on to projects coordinated by project managers who work with our Program Management Office. I've written previously about the separation of responsibilities in software development management and my approach at Corbis has been entirely consistent with that earlier thinking. However, I thought I'd share my approach and how I'm tying 3 very simple metrics to the definition of responsibilities in order to drive the appropriate behavior from my line managers and their teams.

My rules are simple. As the software engineering function manager my job is to provide the rest of the business with a team capable of building great software, with high quality, high levels of productivity with the shortest possible lead times, and the highest possible reliability of service. If someone asks us for something we should be able to build it quickly, efficiently, with high quality and deliver on our promise dependably. To do this I need the team to focus on 3 things: productivity - measured as the number of valuable software features or functions delivered in a given time period (e.g. per month); quality - measured as number of defects introduced and escaping in to system test or production; and lead time (to the customer), also known as, cycle time (within software engineering). In addition to these 3 key metrics that are directly related to my goals for the function, I also want the trend data over time, and variation data for each of the 3 metrics. Mean trend data tells me whether our vector is flat, improving or declining while variation data tells me how dependable we are likely to be. If we have an average productivity of 20 features per month but our range is 10 to 45 then we are unlikely to have strong due date performance on lead time promises. Reducing variation improves reliability of service. Improving mean trend data shows that the department is delivering continuous improvement. By measuring productivity, quality, lead time, and their mean trend and variation, I drive behavior that improves customer service, value to the business and return on investment in IT, while avoiding any dysfunctional behavior that might overlap with responsibilities assigned to the PMO to manage and lead projects. Technorati tag: Agile, David+Anderson, Software+Engineering, Management, Metrics

This winter I'm celebrating 25 years in the software industry. I'm also facing the arrival of a mid-life crisis as my 40th birthday approaches this spring. Yes, it's 25 years since a young group of 14 year old school boys (the linked article dates from 1985) launched an advertising campaign in the classified ads in the back of Sinclair User magazine advertising games for the Sinclair ZX81. In exchange for a cheque in the princely amount of 3.50 GBP we would mail you a set of listings of games written in BASIC. You had to type them in to your computer in order to play!!! :-O

Back in those days motivating geeks to write great software was easy - just feed them pizza and cola and let them work all hours of the night and don't worry about all that homework that wasn't being done.

The conventional management wisdom is that the software industry is different. Software programming geeks are different. Motivating them is different. You don't manage them. You herd them. The idea goes that you hire smart people, usually as young as possible, with as little social life or social skills as possible, stick them in an open plan office, let them decorate their cubes any way they like, bring toys in to the office, provide a ping-pong table, fussball table, fully stocked kitchen, free juice, and a budget to order in food after hours, and just leave them alone. The result will be fantastic innovation and don't worry about the quality, the bugs can always be fixed in a future version. This wisdom has prevailed ever since and here on the west coast of the USA it's a formula that has made many executives and venture capitalists rich. So they would see little reason to change a winning formula.

But have you noticed anything recently? Perhaps, when your sitting in a meeting providing status on your latest project? Grey hair perhaps? Balding heads? Bifocals?

As a manager are you noticing that staff need a lot more time out of the office for medical appointments? and other real life events? engagement? marriage? birth of child? death of parent? illness? injury? kids stuck home on a snow day?

When you're recruiting have you noticed how carefully the applicants read the benefits package literature and negotiate for flexible spending plans and childcare facilities? and how disinterested they have become in the location of the ping pong table? Have you been asked whether prostate screening is covered under the medical plan?

The 80's young gun geeks are still here. They are still producing great software. They still love their jobs and love the profession. They take a pride in what they produce. BUT...

They have kids to get home to. If a project runs in to trouble, they'll still pull an all-nighter and brag that they've still got what it takes as they feel a proud burst of nostalgia for the old days, but 3 days later they'll be out sick struck down by the latest flu variant and you'll lose a week of productivity as a result.

The industry is aging!

We need new management rules for old geeks (like me). These rules mean establishing processes to insure a good work life balance. Old geeks want their capacity to produce balanced against the demand from the business. They won't be death marched. They already regret missing out on their 20's. The gallus geek of yesteryear who talked disdainfully of process, carried his compiler in a holster slung low from his hips and treated management as the pointy haired boss to be ridiculed, now sees process as his friend and his boss as the facilitator of professional success balanced against the demands of real life.

The challenge for us managers is to give management a good name by putting in place lean processes that facilitate rather than hinder, that deliver productivity and work life balance, that lead to great code and healthy coders, that continue to delight customers without the all night code merges and death march schedules.

Old geeks need new rules. Old geeks are great software engineers, they still have a lot to offer. The successful organizations of today will learn how to provide a well managed environment that delivers on the needs and wants of the middle-aged greying developer population. The others will continue to play by the old rules and will suffer continual churn and turnover as they burn out an increasing intolerant workforce. Technorati tag: Agile, David+Anderson, Software+Engineering, Management, Aging+Workforce

Richard Farson isn't the only business writer to have written about building failure tolerant organizations. Charles Handy got there before him. I've been reading Handy's Beyond Certainty. It's a collection of essays and speeches produced over many years. They read like blog entries. Each one is relatively short and during this difficult winter period when I'm commuting on the bus rather than biking to work, I've been enjoying several chapters of the book each trip.

In a piece entitled "Are there bugs in our offices?" where Handy is discussing the need to move to leaner, flatter organizational structures he remarks on lack of trust as a virus that is infecting our offices and breeding inefficiency. He goes on to point out that failure tolerance is the key to enabling a leaner, flatter organization...

Leaner flatter management structures only work if they result in more junior people having some senior responsibilities. The savings come in fewer controllers and requests for permission, fewer inspections and inspectors. More responsibility, however, means that more people will act on their own initiative, and that inevitably means more mistakes. Punish those mistakes, inscribe them in the corporate memory, and you will make it quite certain that no one will exercise their initiative again. The layers of command and checking will build up once more; the savings will vanish.

If the leaner flatter structures are going to work we have to invest a lot of effort in helping those in the front line to make the right decisions, not in punishing them if they make the wrong ones. Asking for help when in doubt must be seen by everyone as a sign of responsibility, not a symptom of weakness. Mistakes if they occur can be a wonderful way to learn, perhaps the only way to learn, as long as we are prepared to admit that they were mistakes and do not try to defend or excuse ourselves. Fear makes all this impossible; fear locks the organization in to rigidity, making it conform to yesterday's rules which may not be the right rules for today's problems.

I chose to highlight the sentence which calls out a key behavior that we encourage in agile teams and agile organizations. However, this whole piece really drives home the point that lean, flat structures, high trust, low waste organizations that tolerate failure and drive out fear will tend to have all these attributes. If you are trying to build a high trust culture but you've got 14 layers of hierarchy then there is a mismatch. If you are trying to drive out fear but you are not failure tolerant then there is a mismatch. If you are trying to be lean and eliminate waste but you're not driving out fear and encouraging learning from failure then you won't succeed. If you aren't encouraging people to ask for help as a demonstration of their responsibility to the shared goals of the team, then you are letting fear fester and discouraging the less confident from contributing fully to your productivity and success. Technorati tag: Agile, David+Anderson, Richard+Farson, Charles+Handy, Management+Organization, Trust, Fear