Sunday, September 23, 2007

Thoughts on Enterprise Agile Transition

While at Agile 2007, I attended a discovery session led by Pete Behrens, of Agile Executive Blog. Pete had assembled 3 of his clients who had all taken their teams through enterprise level transitions to an agile approach to software development and project management, along with a group of perhaps 60 conference attendees. We sat in small circles of 6 or so folks per group. The session was divided in to talks by each of Pete’s clients, some summarization from Pete himself, and group chats followed by some “show and tell” to the wider room.

My big take-away from the session was that several of the folks in my small group and at least one of the main presenters, gave a summary of their transition to agile that went something like this…

One of our execs met some guy sitting in First Class, who persuaded him that if we weren’t agile we were being left behind. So when he got back from his trip, he sought me out as a known change agent and asked me to lead a transition to agile development. So I assembled a small team and we learned all their was to know about agile. [Perhaps we hired a consultant to help us.] Then we made a plan of how to take our teams from the traditional waterfall style development method we’d been using to an agile/Scrum approach. Over the next 9 months we executed on that plan, and gradually we saw all the agile practices adopted across all of our teams. We completed that process 3 months ago and now we are agile!

Does anything strike you as ironic about this?

The way to enterprise agility was to make a big plan up front, based on a top-down, management led initiative, and to command and control the team to change to an agile style of working. Then to execute against the plan, and when every task on the plan was completed to declare that the change was done!

As I stated in my previous post, I’d been there before and struggled to achieve both scale and longevity with the changes. My fear with many of the enterprise scale transitions now taking place is that they will suffer the same fate. When the management that led the change is gone, the teams will gradually atrophy back to a traditional way of working. Unless a fundamental change in the organizational culture is achieved and the new culture is institutionalized from top to bottom in the organization, then I fear that the benefits of agility - even they are recognized as hyper-productivity in some teams - will be short-lived. An agile may get labeled as just another management fad. [Check out Sanjiv Augustine answering the 5Qs at PM Boulevard and his scenario #2 that Agile may indeed be just the management “fad of the year.”] Technorati tag: Agile, Software+Engineering, David+Anderson, Pete+Behrens, Sanjiv+Augustine

Institutionalization of Culture versus Prescribed-Change of Process

While success stories are all very well, in the agile community we know that we learn more from our mistakes and challenges than from our successes. Hence, I thought it might be more useful for my readers to hear some of my frustrations from my first year leading the software engineering team at Corbis than simply to read my self-congratulations from last week.

I blogged before that I took a different approach on joining Corbis. I went after the culture rather than leading change to a specific prescriptive method, such as Feature Driven Development. I did this because I wanted to achieve organization level change and institutionalization of the results. Previously, I had enjoyed localized success with my immediate development team or project but had not managed an enterprise level adoption, nor had the changed survived my departure by more than a year - at both Sprint PCS and Motorola. As I also stated I was afraid of the J-curve effect that driving home a specific prescribed process change might have at Corbis. So I opted for the long game of cultural change.

While I’m delighted with the results and the cultural change, while hard to measure objectively, appears to be widely recognized anecdotally, I am frustrated by some of the results. I’ve seen a lot of code released and a lot of successful releases. I’ve seen some very high quality and very few defects escaping in to our production environments, but I haven’t yet seen hyper-productivity.

Jeff Sutherland has been talking a lot about how difficult it is to achieve hyper-productivity. He talks about how few Scrum teams have ever achieved it. [He defines this as performance at least four times higher than might be normal.] He holds up the team that created Borland Quattro Pro as one of the highest performing teams of all time. A team that produced at least a 10x productivity gain. At Agile 2007, I spent some time with Jeff and shared with him the data from the Device Management project that Daniel Vacanti and I led at Motorola in 2004. The data compares favorably with the Borland Quattro Pro project. Even data from lesser performing FDD projects (the Singapore project - though it was a much larger project) and others from my team at Sprint and some others from FDD teams I’ve met along the way, tends to indicate hyper-productive results, and often with incredibly high quality data. Hence, over the years I’ve been used to achieving hyper-productivity with my teams.

So what’s up at 710 2nd Ave in Seattle? Why no hyper-productivity?

My guess on this is that cultural change and institutionalization and what goes with it - a high degree of autonomy, delegation, empowerment and self-organization - takes a lot longer to achieve hyper-productive results. The advantage is that change is achieved with a much lower degree of resistance, with very low attrition and change-driven churn and the change will stick and survive management changes and the general churn of projects and personnel over the coming years.

In the past, I’ve been an aggressive change agent. The CMO at Sprint PCS described me as “hard driving.” That approach achieved some localized results but equally it made me unpopular with some and probably left a residue of resentment towards management led change amongst the skeptical individual contributors. Folks acquiesced and played along with the rules of FDD and they enjoyed the success of projects delivered, but when the management wasn’t there to enforce the rules any more, they fell back in to the same old ways of working. The right way is to let the team make change its own. Through ownership the seeds of long term support and advocacy are born.

So while I wait for hyper-productivity to emerge or evolve through a series of kaizen events, I’m not unhappy. I set out to change a culture and to achieve an institutionalization of those changes that will eventually survive me and the rest of the management team. I’ve delivered on that goal, but darn it I miss the kick out of seeing some hyper-productivity. Technorati tag: Agile, Software+Engineering, David+Anderson,

Thursday, August 02, 2007

There is no Customer Service

Recently I’ve taken to walking a block from my office building to get my morning coffee at the 3rd Ave outlet of the Cherry Street Coffee House - actually the original Cherry Street branch is also just 1 block away in the other direction but I prefer the 3rd Ave outlet. While the baristas in the Pegasus Coffee House in our building might be pretty and sexy, the coffee just isn’t as nice (IMHO).

Today I noticed for the first time that there is something else going on at Cherry Street Coffee House. Something that fired off my passion for management and leadership. The owner, Ali Ghambari is a passionate philosopher who is building a business based on values. There was a card stuck to the espresso machine and it read…

There is no customer service because there is no customer.
We are building individual relationships based on
mutual respect and forging a great community
through the fire of love.

You can view the card here. And a whole collection of Ali’s other values here.

Quoting from the About page on the web site, you understand that Ali recognizes that differentiating his business is a vital part of being successful. He has chosen not to pursue the Plus One style of marketing - no cupcakes or radical art work on the walls or tight abdominals, cleavage and belly buttons on show at his shops, just an impassioned focus on community and deep relationships with his customers.

With all of the exceptional coffee houses in our great city of Seattle, you never can stop improving quality and maintaining the highest of standards. The things that make our house special, are first and foremost the true belief that it takes ‘True Love to build Great Community’ and through deeper connections with our community we will capture great energy that no money can buy.  Technorati tag: Management, Leadership, Cafe, Seattle

Friday, June 15, 2007

Policies - You’ve Got the Power

If you are a manager reading this, then the chances are you are running a department with sub-optimal performance. Much of that performance is being constrained by policies. Those policies may have been around for years. Many of them pre-date you taking control of the team. Many of the staff have forgotten why a certain policy was introduced. They are part of the folklore of how things are done around here. Often your shop floor individual contributors will know that these policies are affecting performance but they abdicate any responsibility viewing it as a management problem.

Guess what? You are the manager!

Policies are under your control (or maybe your boss or an upline manager).

If a policy is affecting the performance of your team - change it! Show some courage. Make a change. Just do it!

For example, we had a policy that locked down our test environment for 3 days after every release. Since introducing our kanban system for sustaining work, we’ve put a release out every two weeks. A 3 day outage in testing was constraining our productivity by limiting our test capacity to only 70% efficiency. The effect was lower total throughput of change requests and delivered business value. A small cross functional team investigated the policies behind the 3 day lock down and discovered that most of the original reasons for the 3 day period no longer applied. On the recommendation of the team, I changed the policy to 1 day, giving us back 20% of our testing capacity. Since we made this change in early April we’ve seen continued growth in throughput of processed change requests delivered to production each month.

Where are your policy constrained bottlenecks?

Tuesday, April 10, 2007

Why Aren’t Managers Paid More?

In Thinking for Living, Thomas H. Davenport argues that managers of knowledge workers should be paid a premium for assuming the position as manager and letting go of the relatively safety and security of their individual contributor knowledge worker job. His reasoning is simple - managing and organizing knowledge workers is so vital to their productivity - self-organization and empowerment only go so far then management has to step in. However, the first management level job requires the individual to take a huge personal risk - abandon the skill set that made them successful and learn a whole new skill set as a manager. In order to attract the correct candidates in to management goes his thinking, it is necessary to pay a premium. How much of a premium is hard to say but 10%-20% would seem appropriate.

The interesting thing is that compensation professionals tell me that a premium salary is not supported by the market for managers in software engineering. I think that there is one main reason for this and a number of secondary reasons that might indicate a root cause for the problem. The first reason is basic economics and the fact that uncertainty in the nature of the work forces managers to maintain a flexible workforce of contingent labor (contractors). This is typically 10%-50% of the resource pool. The contingent nature of contract labor requires that a premium is paid for the hourly paid contract labor. Good people, confident in their technical skills and their ability to renew and refresh those skills regularly can earn a premium as contractors. Often earning more than middle managers and junior executives. Put another way, a geek can earn more as a contractor than he or she could make suffering through 10 years of climbing the corporate ladder as a manager. Hence, permanent full time individual contributor knowledge worker jobs fetch higher rates too. And as such, there is no premium for management. In fact, the market would suggest that managers should really be paid less!!!

Clearly this is a problem! If knowledge worker productivity is primarily a factor of effective management - and Barry Boehm made a science of this discovery in software engineering - then there is a conflict when the open market will not remunerate managers appropriately. What is causing this conflict?

I feel there may be a number of reasons and feel free to comment and add to my list [Update: Aarrrggghhhh, Murphy’s Law - this would have to be a post where that bug in Haloscan kicks in and the comment option is unavailable. If you want to leave a comment use the comment box for the previous post. Thanks.] First, I feel that geeks always look for a technical solution to a problem, before they will pursue a people or process solution to a problem - in other words, tools over operational innovation or sociological or psychological changes within a workforce. If the answer is always to deploy a new software-based tool, then the demand will always be for high-end geeks who can make the best software. Secondly, technical innovation and problem solving is valued over operational innovation and an ability to quantitatively management to a plan. All that tribal individual value is bundled in to an ability to create great product innovation and solve significant problems in computer science rather than process innovation and the soft skills it takes as a manager to motivate a team.

In conclusion, I feel that if we are to deliver on Davenport’s vision that good management will come from offering a premium for knowledge workers to make the leap to a new skill set then we must first start to value management skills more highly. In order to value management skills more highly, I believe that we must embrace Barry Boehm’s observation from 25 years ago - poor management can increase software costs more than any other factor. So far, we’re an industry in denial of this basic truth. Until we face our own brutal reality - that good management works and bad management hurts - then there is little hope for fixing the situation.

Related blog post: Social Networking for a Living, Why Good Managers Still Matter to Agile Development
External Links: Crosstalk article from 1996, Management Impact on Software Cost and Schedule  Technorati tag: Agile, David+Anderson, Software+engineering, Thinking+Living, Thomas+Davenport, Management, Knowledge+Worker