Monday, March 12, 2007

HR Myths #5: Pay for Performance

It’s my turn to add to the conversation. [I don’t often find time to do that.]

Esther Derby and Jason Yip both find blog column inches to riff off Jeffrey Pfeffer’s testimony on the merits of Pay for Performance. I’ve blogged about this before 3 years ago in a previous HR Myths post.

While I might deal with performance review feedback differently today, three years later, having more experience at these things, my general conclusion remains the same - Pay for Performance can lead to dysfunctional behavior encouraging individuals to look out for themselves and discouraging team working that enables higher productivity from the whole team.

Our annual employee survey interestingly asks the question, “We have a good performance review system?” I wonder if your company asks a similar question of its employees? I can’t share our results with you, but draw your own conclusion. Are Pay for Performance schemes universally disliked by a significant portion of knowledge workers?

A couple of years ago, I had lunch with Lisa Haneberg, the crafty middle management blogger. Lisa knows a lot more about HR than I do, and has actually spent time hanging out with HR types at their industry conferences. I asked her whether HR policies come from the tooth fairy or if she could enlighten me on the source of the ideas. Though she knew more than I, she couldn’t point me at original work, or authors, to understand the source. [If anyone reading this knows the origins of modern human resources methodologies, please leave a comment.]

I expressed my concern that typical performance pay rules were like cost accounting - somehow left over from a previous era of management. Modern Cost and Management Accounting was created by Donaldson Brown of General Motors to provide a means of making local decisions in mass production manufacturing. Mass production was based on ideas in time in motion study and Scientific Management by Frederick Taylor. This gave us the efficiency metric that seeks to optimize utilization at individual stations on a manufacturing line. It’s based on the assumption that optimizing locally (for efficiency) will lead to optimal performance for the system as a whole. The concept has largely been debunked by the Lean and Constraints Management movements. Successful manufacturing companies have abandoned Scientific Management. However, its accounting method, remains the industry standard and is widely taught in colleges all over the world. My curiosity revolved around whether HR policies can be traced to a similar pattern of development. Were they created out of the mass production era paradigm that local optima leads to globally optimal performance? If so why do they continue to persist in the post-mass production era?

Thomas Kuhn described the inertia that exists within a profession and why innovation and new ideas often come from outside that profession. For example, Eli Goldratt, a physicist promoted the Throughput Accounting alternative to Cost and Management Accounting. Ray Immelman has taught us to look for a tribal explanation first. Immelman’s model is simpler to understand but amounts to the same thing as Kuhn. He suggests that when a tribe has determined its mechanism for establishing the tribal pecking order - the individual value (IV) within the tribe - there will be huge inertia to changing that mechanism, because it would undermine an individual’s ranking in the tribe and cause a loss of individual security (IS). Fearful from reduced security and of loss self-esteem no one wants things to change. The result is that an established profession has no incentive to change. In fact, it has huge inertia to maintain the status quo - hence, Immelman’s model predicts precisely what Kuhn observed.

This leads to my observation that, if Cost Accounting survives because it suits the accounting tribe, could it also be true that policies such as Pay for Performance remain ubiquitous because they are deeply ingrained as part of the tribal lore and value mechanism in the human resources tribe?

Interesting then that when Steve Ballmer was looking for a new manager to run human resources at Microsoft, he chose Lisa Brummel, someone from the marketing side of the business with no background in HR. Did he intuitively know that he needed someone from outside the tribe to shake up HR? or was he a Kuhnian thinker who understood the need for a non-HR professional to take the reins? Regardless of which, Brummel wasted no time in abandoning the forced ranking and severely modifying and simplifying the Pay for Performance scheme at Microsoft. Scoble for one was delighted!

Other HR Myths #1, #2, #3, #4 Technorati tag: Agile, David+Anderson, Human+Resources, Organizational+Agility, Performance+Management, Talent+Management

Kanban Conversation

The blogosphere’s trackback system is badly broken. As a result many blogs that link other’s stories do not trackback. A couple of my recent posts have attracted considerable commentary. J.D. Meier riffs off my recipe for success and kanban system posts. As always J. D. finds his own slant and adds to the conversation. He really understands the bloggers imperative to generate an open collaborative dialog that adds value with each post.

Jim Highsmith has been posting a series of advisories from the Cutter Consortium expressing what each of the four elements of my recipe for success mean to him: focus on quality; reduce work-in-progress; balance demand against capacity; and prioritize.

Dennis Hamilton finds that J.D. Meier’s thoughts helped him re-form his view on my recipe for success and relate it to his own experience in a nano-ISV and comes to the conclusion that maybe he needs a kanban system of his own to avoid the transaction costs of running iterations like mini-projects. It’s nice to see the ideas resonating with people in different circumstances.

Meanwhile, John Hunter and Piergiorgio Grossi are both good enough to draw attention to my kanban post. On the other hand, draw your own conclusion as to whether photo industry blogger Paul Melcher is adding to the conversation with his observation on our choice of kanban cards.  Technorati tag: Agile, David+Anderson, Lean, Kanban, Blogosphere, J.D.+Meier, Jim+Highsmith, Curious+Cat, Cutter+Consortium

Thursday, March 08, 2007

Kanban in Action

Earlier when I described my approach to managing and leading software engineering at Corbis, I mentioned that I was introducing a kanban system for our sustaining engineering activity. Since we introduced it, we’ve released new versions of our IT systems and business application software twice per month. However, sustaining doesn’t run on a traditional agile two week iteration (or sprint) type system. It uses a kanban system to pipeline change requests (CRs). When a CR is complete it sits in the Release Ready state until a scheduled release happens on every second Wednesday.

Though we track all CRs in Team Foundation Server using the TeamLook client for Outlook to provide access for those who don’t use the Visual Studio IDE on a daily basis, the day-to-day work is tracked on a white board using Post-IT notes as kanban cards.

Our sustaining process is driven from a floating pool of regular software engineering resources, there is no dedicated sustaining or maintenance team. By setting a kanban limit we can guarantee to the Governance Board that we are meeting our commitment to dedicate a certain percentage of our resources to sustaining activity, without dedicating specific heads.

Each morning the team meets for a standup around the kanban white board to discuss the work-in-progress and how to keep it moving. Darren Davis, a manager on my staff, can be seen leading the meeting, working through each card and discussing it with the assembled (virtual) team. The cards on the board contain the title of the CR, the ID number from Team Foundation Server (TFS), and above each card is written the name of the currently assigned member of staff. Team members are responsible for updating the board and moving kanban cards as they progress a CR through the system. Darren uses the daily standup to insure that the electronic data in TFS is synchronized with the physical board. The kanban system is essentially self-organizing but with a management validation point daily.

The key to the board is worthy of description. A red star indicates that the item is severely aged and exceeds the 28 day service level agreement (SLA) for processing through the system. This allows the “late” item to be self-expedited without direct management intervention. Blocked CRs have pink sticky notes attached to indicated that there is an open issue in Team Foundation Server. These pink cards also contain the description of the issue and the ID number from TFS. There are some other types of notes on the board for bugs and maintenance CRs. Here is the key: Yellow - customer-valued CR; Blue - customer-valued (and requested) bug (fix); Green - IT maintenance item e.g. SQL 2005 upgrade; Orange - additional (or extra) bug; pink - issue.

The kanban limit for the system is 20 cards, divided in to different stages in the process - systems analysis, development, test, build/merge, deployment. In addition, we allow for 3 extra bugs to be anywhere in the system. This separate kanban limit of 3 bugs allows us to burn down the bug backlog using slack resources. When these resources are not available, we will remove or reduce the limit of 3 “extra” bugs. There is also an additional kanban limit of 2 maintenance items. This allows us to fix a small percentage of IT resources to do vital systems maintenance and upgrades such as API version upgrades, and platform upgrades like .Net2.0 or SQL Server 2005.

The kanban system allows us to deliver on 3 elements of my recipe for success: reduce work-in-progress (in fact it limits it completely); balance capacity against demand (as new CRs can only be introduced when a kanban card frees up after a release); and prioritize. We hold a business prioritization meeting once per week with vice presidents from around the company. They get to pick new CRs from the backlog to allocate against free kanban cards. This forces them to think about the one, two, or three most important things for them to get done now. It forces prioritization.

The kanban system also frees us from the constraints of time-boxed iterations. Even though we are making a release every two weeks, items in the system can take up to 60 days to move through depending on their size and complexity. Items that would be too big for a single two week iteration can still be fed in to the system and will work through and be released without any special management attention.

And finally, the kanban system has freed us from the management overhead of running each iteration like a mini-project. The system has become largely self-organizing and little management attention is required unless exceptional circumstances emerge requiring an expedite request or a date change to a scheduled release due to environment or system maintenance issues. Technorati tag: Agile, David+Anderson, Lean, Kanban, Software+Engineering

Creativity 2.0

The leadership at Corbis (my employer) has a new blog, Creativity 2.0. It’s mainly a voice for CEO Steve Davis and President Gary Shenk to talk about their ideas for the developing online media and media services market. And as it’s a blog, to have them enter the conversation and help shape the future of creative media. I heard Steve was planning to do this a few months ago and I rushed out to the nearest bookstore and bought him a copy of Naked Conversations. Thankfully, Steve and all his executive committee colleagues chose to keep their clothes on for the launch of the blog  Technorati tag: David+Anderson, Corbis, Creativity2.0, Steve+Davis, Gary+Shenk, Naked+Conversations

Friday, March 02, 2007

Opening on My Team

I’m looking for a Technical Architect to come and help me lead a Lean Software Engineering evolution at Corbis. The position reports directly to me and is the most senior individual contributor position in the Technology organization. I’m looking for someone who is still hands on with code, can demonstrate and teach unit testing, automated build and test, agile domain modeling and conversion in to working code, as well as help lead an evolution of our development processes based on Lean and Agile principles. If you are passionate about bringing Lean ideas to software development, would love to work on my team and for my boss Stephen Gillett, value the opportunity to work at Bill Gates’ private company and see Seattle as a ideal location to grow your career and professional development, then I’d like to hear from you. The position reports to me on my management team alongside my six existing direct reports.

The Corbis employment web site does not allow me to bookmark the individual job position. So I’ve pasted the requirements below. If you are interested, please follow through by visiting corbis.com and completing the application form and submitting it to our HR department. Thanks.

Technical Architect - Description

This is a new staff position reporting directly to the Senior Director of Software Engineering. The Technical Architect position is intended as a “leader in training” position. A Technical Architect will be expected to take a leadership position managing a technical team in future and will be given the chance to build leadership credibility and respect prior to taking a management position when a suitable one becomes available.

Specifically, in the next 12 months, the Technical Architect to the Senior Director will provide leadership and direction to enable the software engineering team in a transition to a more agile way of working. This position will be responsible for coaching, mentoring, and training existing staff in new techniques for requirements, analysis, architecture, development and testing that will enable the organization to transition to a more iterative, incremental way of working that increases productivity and quality while reducing variability in software engineering practices. The result should be an organization that is more responsive to business needs and delivers greater levels of customer satisfaction.

Responsibilities

Mentoring/Facilitating/Coaching:

• Assigned to key strategic projects, organize and lead a cross functional group to build a domain object model and learn key domain modeling skills.
• Work with business and system analysts to grow adoption of analysis techniques such as the Business Rules Approach and Coad Methodology to streamline and improve requirements gathering, traceability and process alignment
• Facilitate the adoption of agile project management planning and estimation techniques
• Coach and mentor the adoption of code review and unit testing techniques across the development team

Architecture

Work with existing development managers and principal software engineers to understand the coupling and cohesion in the application architecture and devise a plan to refactor the code base to improve coupling and cohesion with a goal of delivering a more robust platform on which future change and functionality can be deployed rapidly with minimal regression.

Project Planning and Estimation

• Help develop metrics and data recording (using Team Foundation Server) to enable successful planning and estimation of software projects and iterations
• Liaise with the PMO personnel to insure plans balance team capacity against demand
• Help drive a more iterative and incremental way of working

Process Engineering

• Assist and advise the process engineering team to develop methodology for the software engineering organization. Coach and mentor the rollout of those processes across the software engineering team.
• Work with the software engineering line management to help drive improved practices in to development and testing teams

Required Skills:

Qualifications:

• At least 8 years experience with software/application development
• At least 2 years experience as a team lead developer or architect
• At least 5 years experience with an agile software development methodology in practice on real projects.
• At least 5 years experience with UML – or other OOA&D approach, Coad Method preferred
• Bachelor in Computer Science or related field (or equivalent job experience) required.
• Masters degree or MBA may be advantageous

The successful candidate will be able to demonstrate a current working knowledge of the state-of-the-art in software engineering practices and management

Good communications skills. Good presentations skills.

Comfortable with leading teams, facilitating meetings, framing decisions and resolving conflict

Experience with advanced development methodologies and techniques, including agile development, feature-driven development, and object-oriented development.

Knowledge of requirements development and analysis techniques such as the Business Rules Approach, Goal Directed Design, Feature Analysis or User Stories.

Advanced knowledge of software development lifecycle and methods, software testing procedures, and configuration management.

Proven ability to schedule software development and to lead a development team in producing quality products.

Experience facilitating modeling and design session and running on-the-job training sessions

Strong analytical skills, interpersonal communication and organizational skills.

Proven long term experience with enterprise architecture frameworks such as .Net or J2EE (.Net is preferred)

Track record of delivering complex projects in to production web or large enterprise environment

Self-starter with ability to work without supervision and little oversight to drive for results Technorati tag: Agile, David+Anderson, Corbis, Jobs, Software+Engineering, Lean