Tuesday, January 23, 2007

New Rules Resonates

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

Sunday, January 21, 2007

Recipe For Success

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

Saturday, January 20, 2007

Managing the Software Engineering Function

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

Friday, January 19, 2007

New Rules for Old Geeks

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

Monday, January 15, 2007

Handy on Failure Tolerance

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