Software, musings, and life
The good news is that I won the blogging contest that was tied to the recent conference. Yay! Now I just need to carve out a huge block of time to read through these 12 great books.
This may take a while...
I’ll tackle the first 3 in order, most likely. After that, I’ll see what looks the most interesting at the time.
I previously wrote about the first half of Mary’s Agile Vancouver 2011 presentation, which focused on performance appraisals. Here I’ll cover the second half, which discusses use and misuse of financial compensation as well as the disconnect between the assumed results of traditional compensation techniques and their actual effects on motivation. Note that motivation is a large topic, and this post only scratches the surface.
Mary started this part of the talk by showing “Drive”, a talk by Dan Pink (author of Drive) animated by RSA Animate. It’s a great clip, one that I’ve seen before but didn’t mind seeing again. In case you haven’t seent it, here you go.
The real take-away here is that money doesn’t serve as good motivation for tasks that require collaboration and cognitive skill. It may serve as some motivation, at least to do the minimum amount of work required to get paid, but you won’t necessarily get people going above and beyond. What are the assumptions that underpin the current model of financial compensation as motivation? Are financial incentives good for anything?
The traditional way of thinking is that financial incentives can motivate people to do better work, signal to the employees what the business thinks is important, and attract external talent to the company. Motivation has already been discussed here, but it’s worth mentioning that a bonus or raise to encourage better work (or as a reward for good work) is based on the assumption that job performance is under the control of the individual. This is not always – perhaps even not usually, according to systems thinking – the case. While it’s certainly important for a company to let its employees know what goals are important to the business, associating financial rewards with these goals opens the system up to gaming or micro-optimization, and sends the implicit message that, if people were compensated properly, almost any management or organizational problem could be solved. As for attracting top talent to an organization, the only trait you can be sure a high salary will attract is the love of a high salary. Like Dan Pink pointed out, hard-working, highly talented individuals are often more than happy to give their work away if they have the right motivation.
Mary goes on to enumerate even more assumptions behind financial incentives, taking time to challenge each one. The idea that money is an important motivator for people is challenged by research that shows most people claim that they are motivated by other factors, and that intrinsic motivation is the best motivator. As mentioned above, using financial rewards as an means to enhance performance is an instance of the fundamental attribution error, that is, that people are directly responsible for all of their own failings (as opposed to the environment that they are in). Individual rewards are predicated on the idea that individual performance can be reliably and unambiguously assessed, something that is incredibly difficult in a highly interdependent field like software development. An argument against group measurement and reward instead of individual – that is, that slackers will take advantage of hard workers – is challenged by evidence that shows very few people take advantage of situations like this, due to strong peer pressure to perform.
This is not to say that it is trivial to implement a bonus scheme and rewards plan that avoids all of the above problems, although Mary had some simple advice to get started – “Pay people enough that money isn’t an issue”. The key is to create what Arie de Geus calls a “living company”, where individuals know the company is invested and investing in them. Such a company’s goal is to perpetuate itself into the future, creating profits in the near or long term, as opposed to being focused soley on short term gains. As an example, see Amazon’s recent letter to shareholders, which emphasizes a long-term view and commitment to being around for a long time and solving interesting problems, possibly at the expense of short term profit margins. On the motivation side, it is critical to ensure your information workers are challenged sufficiently and improving their skills, as per Csikszentmihaly‘s idea of flow.
Keep people in the flow channel
This is an interesting topic for an Agile conference, as it’s something that really needs to start at an organization level, as opposed to at the team level (barring companies that have team-specific compensation). In that way I see it as more of a Lean topic – a distinction I tend to use is that Agile topics are often team based, while Lean tends to apply to the entire organization. A gross oversimplification to be sure, but one that helps focus (and hopefully not overly-narrow) my thinking. Either way, it was a great presentation and a provocative look at a one of the elephants in the room.
Further reading:
I didn’t get around to writing this weekend, but to keep my semi-regular post streak going I’m going to do a relatively easy entry. I’ll be following up with the rest of my Much Ado About Agile VI posts shortly.
After last year’s Agile Vancouver conference, I wrote about my to-read list, books that were either written by presenters or featured prominently in presentations. How did I do with getting through this list? Let’s see.
First up, books I didn’t read:
No particular reason that I didn’t read these, they just haven’t bubbled to the top of my list. The Fifth Discipline is seemingly a fixture on my to-read list, so that should probably be the one (from these three) that I get to soonest.
And now, the books I read, with a short summary of my thoughts.
The meat of this book is written in the style of patterns, much like Design Patterns, or the original, A Pattern Language. It presents a framework for introducing change into organizations, and its’ smart writing and non-linear style had my flipping between sections for hours at a time – this is this style of book that would thrive as a Wiki. I can’t say that I’ve used any of the techniques knowingly since I read the book, but that’s primarily because I haven’t tried to drive any widespread organizational change in the last year. The next time I try, I’ll be laying out a game plan based on this material.
Focused on moving retrospectives away from dull conversations about what did and didn’t work, this book is a quick read. Unfortunately, I haven’t had much success in applying the suggestions in this book. I’m not sure if it’s because of team dynamics, or my inability to successfully implement the approach, but I find that whenever I try to make use of one of the activities it falls flat. Perhaps it’s just a habit thing – do it a few times and it will get easier. I haven’t given up yet, so I may yet post again on the subject.
Nothing really groundbreaking here, but it is a good starter for anyone looking to go into management, and a reference for those of us already in the role. Much of it I see as common sense, but that’s speaking as someone with 3 years experience managing a team where I know everyone and am quite familiar with the way the organization works. Side note – I had this in my backpack during this year’s conference, and happened to see Esther Derby and Johanna Rothman standing next to each other after Johanna’s keynote, so I now have a signed copy 
So, I read 50% of the books – that’s not too terrible, given that I’ve read a ton of other books in the last year. One thing that I didn’t adopt was the SQR3 method, which is unfortunate – I find that I’m doing a lot of reading, but my recall and long-term understanding is not where it could be. Re-reading last year’s post (and thus rediscovering SQR3), and listening to the recent Manager Tools podcast on How to Read a Book has me committed to improving my reading style. Marking notes in the margin may be difficult with ebooks (I love my new Kindle), but that’s no excuse – either through the Kindle’s notation interface, or through hand-written notes in a notebook, I’ve resolved to improve my non-fiction reading.
I’ve seen Mary Poppendieck speak several times, and I’ve also read her books. When I saw her name on the program of this year’s Agile Vancouver conference, I expected a presentation on reducing waste in a development organization, promoting flow, or perhaps encouraging set-based development, as would be befitting her reputation as the “Queen of Lean”. Although I’m sure any of the above presentations would have been well worth attending, I was pleasantly surprised to see that Mary was planning to focus on appraisals and compensation, two elephants in the room of almost every organization. I took a few pages of notes from this talk, so I’ll split it into two posts – this one on appraisals, and a followup on compensation.
Mary started by giving a history of performance appraisals, from their first documented use in 3rd century China, to Taylor’s scientific management theories in the early 1900′s, to their near ubiquity we see today. Given their prevalence, and the feeling one gets that nobody outside of the occasional HR organization enjoys either giving or getting performance appraisals, the assumptions behind these reviews merit examination. To help frame the discussion around these assumptions, Mary listed the 4 services that performance appraisals are assumed to provide: a motivation to improve performance, career / professional development guidance, a paper trail for corrective action, and a basis for pay and promotion. I’ll tackle the first three here, and save pay and promotion for the next post, Compensation.
The Bobs enjoy a good appraisal.
As a motivation to improve performance, yearly appraisals are prone to several problems. The value of feedback, either negative or positive, goes down in proportion to the cube of the amount of time between the event generating the feedback and the feedback itself*. If you are trying to effect change in an employee, the best time for feedback is “immediately”, followed by “as soon as you can get that person alone” for items that are better off discussed in a private setting. Additionally, combining positive and negative feedback from a large time frame into one review tends to mute the effect of the positive feedback, since people tend to focus more on the negative. You can think of these ratings as a game without a winner, where the best you can hope is maintain the status quo. If you were to give a high rating to a mediocre performer, it would not give them any motivation to change, so you’d still have a mediocre performer. If you were to give a mediocre rating to a high performer, the high performer (who probably knows she’s a high performer) will be disappointed and probably reconsider how hard she should be working.
To counter the assumption that appraisals are necessary for professional development, Mary touches on the body of research that covers how people across a wide variety of fields learn and master new skills. A concept I first heard about in Malcolm Gladwell’s book Outliers, the steps to work towards mastery are as follows:
Now, most of us may find that list a bit daunting, but that is the price of mastery. That said, not everyone expects to master every skill they attempt to use – the closest to 3 hours a day that I spend on any one thing besides sleep is riding the bus, for example. The important thing to note is that in this list of elements of deliberate practice (having a teacher or coach, pushing your limits, obtaining immediate feedback, and dedication), appraisals don’t really cover any of them. How then can they be expected to promote meaningful growth?
The idea of creating an audit trail in case of punitive action or dismissal may appear to make sense in today’s litigious society. Indeed, Mary points out that formal performance reviews gained a lot of popularity following the 1960′s civil rights movement in the US, when such systems were set up to prevent untraceable systematic discriminatory dismissals. However, if this system is meant primarily for underachievers and others needing corrective action, why must all employees go through the process when the vast majority of them are in no danger of being let go?
In my next post I’ll write about the second half of Mary’s presentation, which challenges the use of appraisals as a basis for pay and promotion, and in doing so questions several other common aspects of the dominant compensation model and dives into the complicated area of motivation.
* Simmons’ Law. Yes, I just made that up, and I have no empirical data to prove it, but the disproportionate value of immediate feedback when compared to delayed feedback is a well-known phenomenon. At worst, I’m off by a coefficient.
Further reading:
- Get Rid of the Performance Review, Wall Street Journal
- Bringing Out the Best in People, Aubrey Daniels
Some presentations I’ve attended make me wish my direct reports were there. Others make me wish my boss (or his boss) was in the room taking notes. Dave Sharrock’s presentation at this year’s Agile Vancouver conference, entitled “Leading Agile Change – Walking the Walk”, brought things to a new level. By the end of the talk, I was rueing the fact that my entire peer management group was not there, along with the management of other parts of the organization.
Dave’s dialogue described an experience report where he and other Agile coaches were brought in to a large organization to assist with their Agile transformation, but the goal of the talk was not to educate the audience on how to do huge transitions. Rather, Dave presented a generic planning tool and thought process for leadership teams, called Agile Strategy Mapping, that is applicable for almost any type of strategic planning. Agile Strategy Mapping involves defining high-level strategic objectives in terms of critical success factors, defining necessary conditions for these critical success factors, and then creating a prioritized backlog of tasks required to realize these necessary conditions. Using Agile Strategy Mapping, Dave went on to show how a leadership team can implement organizational change and strategic goals in a focused, incremental way.
A simplified Agile Strategy Map: Goal in cyan, critical success factors in gray, necessary conditions in yellow. The white condition is a nice-to-have.
The term “leadership team” is an important one; Dave spent a healthy portion of the talk describing the fundamental differences between “working teams” and “leadership teams”. Unlike working teams, leadership teams are often not dedicated to a specific problem space. They are ultimately responsible for the work being done, and most of their influence comes through delegation. This is not to say that working teams do not have responsibility or are in any way inferior. The delineation of the two groups is not into a hierarchy of importance (although of course there is some role power involved), but rather is meant to serve as recognition that the two types of teams have different capabilities, requirements, and working styles. Dave’s main push is that, despite these differences, Agile Strategy Maps enable leadership teams to achieve goals in a more Agile fashion.
The concept behind the Agile Strategy Map isn’t rocket science, but the idea of breaking down large, over-arching strategy goals into bite-size pieces is a good one, and one I believe many organizations would benefit from. As is true for working teams, a prioritized backlog fosters collective ownership and shared goals. Even the act of creating the Agile Strategy Map can serve as a valuable focusing tool for leaders, helping turn a group of managers into a team. This team building and collective ownership can then serve to form the basis of a positive feedback loop, on the backbone of small definitive commitments, strong accountability, and a focus on customer value instead of small, local optimization.
Although I really enjoyed Dave’s presentation, and will be using Agile Strategy Mapping as the technique by which I will introduce ideas and recommendations from this conference to my management team, there were some notable shortcomings to the experience. At one point we broke into small groups (6-8 people) to try our own hand at Agile Strategy Mapping. I didn’t really enjoy my small group experience – the ideas generated for critical success factors were too generic and non-actionable (i.e. “mindset change” as a critical success factor), and the concept of necessary conditions seemed lost on most. I may have also been a victim of groupthink, in that the majority of people in my group were from a single company and thus presumably had some shared background and perhaps preconceptions about the planning process. Finally, there appeared to be a large number of individual contributors (as opposed to leaders / managers) in the audience. This is not a problem in and of itself, of course – I was certainly very interested in management and leadership when I was still a junior programmer. However, Dave’s presentation was squarely aimed at those in leadership roles – I feel some of the negative feedback he received may have been due to a disconnect between individuals who were expecting something targeted at grassroots efforts.
Further reading:
The second talk I attended at the Agile Vancouver conference was presented by Michael Feathers, who you may know from his book Working Effectively with Legacy Code. Titled “Discovering Startling Things From Your Version Control System”, Michael described how by mining data that already exists – that is, the commit history and contents of your version control system (git, perforce, cvs, etc.) – you can discover interesting metrics about your code base. The great thing about this idea is that almost every software development shop should have this data available; organizations that don’t have this data because they don’t have version control likely have larger concerns than metrics gathering.
I’m familiar with metrics, and have written about them before, but this is the first presentation I’ve seen on considering metrics about your code as it is. That is, instead of the usual metrics of product performance, or unit test coverage, or even team-based metrics such as velocity or throughput, the idea is to examine the evolution of your code over many revisions to see how it has progressed (or, quite often, regressed). This allows you to ask ask several interesting questions of your code base. As an example, for the following two cases, which one is easier?
- adding code to an existing method, or adding a new method
- adding a method to an existing class, or adding a new class
By looking at how code changes over time, we can give empirical answers to these questions, the assumption being that developers will choose to do the easy things. Histograms of method size vs. time and number of methods per class vs. time can answer that and other questions. Michael gave examples of three popular open source code bases – Clojure, JUnit, and Fitness – all of which seemed to honour some variant of the open-closed principal (that is, classes should be open to extension and closed to modification) since the vast majority of classes were not modified over time.
He went on to list many other metrics you could investigate from your source code’s data:
- method complexity vs. time, which allows you to see refactoring as dips in complexity
- commits vs. hours in the day, minute of each hour, second of each minute
- added complexity over time, added per hour of the day
- number of files touched per commit
- average lines per commit by month
Perhaps the most interesitng chart was a plot of the number of commits to a file vs. the complexity of that file, similar to the following:
Here it looks as if the code base is separated into four quadrants. In the upper right, you have files that have very high complexity that are also changed a lot. These are the big scary functions at the core of your product – the ones that have been around for a while, nobody really understands, and may have relatively few unit tests so refactoring is more difficult. In the upper left, you get code that was likely submitted already in a complex state, and only lightly modified thereafter; perhaps these methods were the result of weekend-long hacks, functionally complete but perhaps a little overly complex. The lower left contains well-factored, not frequently changed code – the utility or base classes of your product, for instance. Finally, the lower right quadrant contains simple code that is very frequently changed. As often as not this would be something like XML, configuration files, or other such data stored as code.
Although these metrics can be interesting, there some caveats. Variations in personal style, such as the average size of a commit, isolated vs. large changes, and the like can greatly skew the numbers. Comparing different codebases can also fall prey to variations in environment – differences in implementation language, nature of the problem being solved, and a variety of other problems.
Besides simply mining my own code base for the metrics Michael suggests, I see other opportunities with this line of thinking about code. Tying your revision control system to your defect tracking system could allow you to see trends of defects over time as they evolve in the code, and perhaps giving a threshold for refactoring – that is, if something has more than X complexity, it’s twice as likely to produce bugs. Predictions about which functions are prone to getting over-complex could be made using artificial intelligence and machine learning techniques. All of this could become an add-in to your continuous integration software – the list goes on.
Next post: Dave Sharrock on Leading Agile Change.
Further reading:
Johanna Rothman‘s keynote to the Much Ado About Agile VI conference started with a simple question – has Agile crossed the chasm? While many people may believe that may be the case, Johanna is convinced that we are still in the early adopter phase.
Although much work has been done and progress made in the 10 years since Agile got its name, Johanna argues that we’ve only done the easy work. Agile adoption is working well for small teams, in small- to medium-sized organizations, but it is much harder to find Agile success stories in larger organizations. Many such organizations have attempted an Agile transition only to fall back to waterfall or chaotic development methods after 2-3 years (or less).
Small Agile teams within larger organizations have not been too helpful either. These teams, perhaps established through the will of a talented manager or through an Agile pilot program, are often up against enormous organizational pressure. This results in the team building fences around itself, being very protective and defensive of its culture and practices. While seemingly well-intentioned, these fences lead to a local optimization problem, where the existing Agile team may hesitant to change their ways even for the good of the entire organization.
Johanna sees a fundamental disconnect between intent and action; while intent may have indeed crossed the chasm, action is falling behind. Part of this is due to the “breadth-first” adoption approach that is all too common. Instead of trying to gain deep understanding of the principles behind Agile, or examining individual Agile practices in the context of organizational problems, practices are often sprinkled around or introduced with little or no background. I know that I have had several exchanges similar to the following.
Developer: Yeah, we’ve been doing Agile for a while.
Chris: How’s that working for you? What do you do?
Developer: Well, we sit together when we code. QA and product management sit with us too.
Chris: Okay… have you seen any benefits to having an integrated QA team? Have your releases sped up?
Developer: Integrated? Well, they still do all the testing after dev’s done, so not much has changed. I guess we write more unit tests now. Oh, and our planning sessions are called sprints, and we stand up in meetings now.
A quick stand-up survey of the crowd confirmed that this experience is not uncommon. When a standing crowd was asked to sit down if you either don’t have a cross-functional team, don’t have a prioritized backlog, or don’t produce shippable product on a regular basis, about three-quarters of the room (myself included) took their seats. It seems that the marketing – that is, the idea and intent of Agile – has greatly outpaced the adoption (or retention) of practices and the mindest behind said practices.
The rest of the presentation was rooted in the idea of a “growth mindest” versus a “fixed mindset”, but Linda Rising gave a wonderful day 2 keynote on this very topic so I’ll defer most of my comments until then. One point that is worth mentioning is the idea that a successful and sustainable Agile adoption requires not just practices or ideas, but both personal and organizational cultural changes. Indeed, to quote Johanna’s slides: ”Agile encourages personal change – Agile requires cultural change.” Changes such as belief in power distance and comfort with uncertainty (Geert Hofstede‘s model as applied to organizations) are often overlooked by those transitioning to or already practicing Agile. To truly succeed in a venture such as organizaitonal change, a more holstic, cross-discipline view must be taken – a theme that continues to reappear over the course of the conference.
In the next post, I’ll cover Michael Feather’s talk on mining data from your version control system.
Suggested Reading:
9th sphere web design
Comment