Wednesday, January 24, 2007

Are You Ready to Go Agile?

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

Tuesday, January 23, 2007

Why Red Status is my Friend

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

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