Thoughts On Software

Burndown charts are one of the most common artifacts of an Agile software development environment. As a tool to provide insight for management into the state of a project, burndowns are useful and easy to understand. As a tool to motivate developers, they are counter-productive and often abused. The information contained in a burndown chart should be largely irrelevant to the day-to-day work of a developer. Let's consider a scenario: assume you have a team of developers who are skilled, intrinsically motivated (i.e. enjoy their work), and focused on delivering the highest priority features as defined by the product owner. Now assume the burndown chart displays a slope indicating that the project is behind schedule.  What is a developer supposed to do with that information?  What actions or behavior is he or she supposed to alter based on that knowledge? Let's consider his or her options: (1) Cut corners to go faster.  This is obviously short-sighted. By omitting criti...

1. Undermines Teamwork Teamwork suffers when your incentive system primarily recognizes individual achievement. Collaboration is key to producing quality software. 2. Undermines Autonomy & Purpose Feeling like you're performing to get a carrot (raise or promotion) or avoid a stick (termination) undermines an individual's sense of autonomy and purpose which is strongly tied to intrinsically motivated behavior. It is critical to have intrinsically motivated people in creative problem-solving jobs like software development.  (See previous posts) . 3. Damages Trust Between Manager and Subordinate It reinforces the idea that the manager's role is primarily to evaluate and critique. Instead of being on the same team working toward common goals, the performance review clearly places the manager and subordinate in antagonistic roles on opposites sides of the table.  It reinforces the worst boss stereotypes. 4. Not Objective No one has found a good way to quantify a so...

Beginning in the era of the industrial revolution, managers were trained and encouraged to focus on increasing productivity though increased efficiency.  This trend has continued into modern management with techniques such as Total Quality Management that focus on identifying and eliminating waste in a system. It can't be denied that this approach can be very effective when applied to a consistent, repeatable process like a manufacturing assembly line.  However, this focus on efficiency is inappropriate and even detrimental  when applied to creative, problem solving activities like software development, and unfortunately these lessons learned from manufacturing dominate the way software development is organized and managed.  It even influences some of the practices taught under the banner of Agile. This fallacy, that software development can be organized into consistently repeatable processes, was the assumption of the waterfall methodology.  Software developm...

Organizations ignore the power of the tribe at their own peril.  In our earliest primitive state, a human being had almost no chance of survival on his own. It is only as a group that we thrive.  So it is no surprise that scientists believe that the primary purpose of our large sophisticated brains is social interaction - the complex glue that holds groups together. These instincts around our tribe are hardwired in our brains. They can motivate us to unparalleled levels of self-sacrifice and loyalty or drive us to irrational conflict and mistrust.  There are almost no boundaries to the lengths that we will go to protect and sustain the people we consider to be a part of our tribe, and almost no depths to which we won't sink to eliminate threats from opposing tribes.  It is the root of obsessional loyalty to professional sports teams, as well as murderous gang violence, and ultimately war. It is no surprise then that organizations from the m...

"Carrots & Sticks are so last Century. Drive says for 21st century work, we need to upgrade to autonomy, mastery and purpose." So says Daniel Pink as a summary of his best-selling book Drive that has popularized the astonishing research into the nature and power of intrinsically motivated behavior.  How can a software development organization apply these principles to create a competitive advantage? Pink popularized the research of many behavioral scientists, particularly Edward L. Deci, which began with his landmark publication Intrinsic Motivation published in 1975. Pink uses the Open Source software movement as an example of the power of intrinsic motivation. In Open Source projects, we see people creating world class software, such as Linux, without any extrinsic motivation - no carrots (no financial incentives) and no sticks (fear of being fired). Something from within - something intrinsic - drives them to these creative heights. (If intrinsic motivation seems to...

Maybe it's because of the relative youth of the profession of software development that we seem to be constantly looking to other, more established, professions for analogies as guides to how we should organize and manage our work.  If taken too far, I think this type of comparison is detrimental such as the numerous analogies often made to the building trade - e.g."building software", and "software architects".  There may be a few similarities, but overall the work is so different that adopting terms and practices from construction often leads to misunderstanding and frustration.  What about a restaurant kitchen as an analogy for a software shop?  Is there anything we could learn?  I worked in a large restaurant as a waiter in college and had the opportunity to see how a traditional restaurant kitchen is structured. It is very hierarchical with distinct and well bounded roles. At the bottom of the ladder are kitchen assistants.  These are minimally skill...