Agile Otter Blog

I know it's going to sound like I'm trying to talk my boss and yours out of giving us both raises, and of course I'm not, but I keep hearing people tell me they're worried that they can't work in teams because their system pits them against one another. Usually it's an excuse or reason for not pairing. "If I improve my colleague, he will beat me to the incentives" or "if we do his work first, then there's a chance I'll fall behind."  I'm not a fan of individual work assignments , and I'm not a fan of competitive incentives . Rather than rant about it, I'd like to point you to some other authors and how they feel about the topic: Daniel Pink suggests killing your performance ratings . InfoQ balanced comments pro and con individual rewards. Peter Scholtes says reviews are  ineffective, even harmful  and performance appraisal are incompatible . Esther Derby suggests ways to support team-based work  and  performance ...

Linda takes us from a negative to a positive affective style, from a posture of seeming or being to one of becoming.  There is just so much to know and understand here. If you don't already love Linda Rising, you surely will after this. Notice the tie-in to Seeming v. Being v. Becoming . Mine is derivative, of course.

Branching is a coping mechanism. There is a lot of branching and release-time cherry-picking of features in the commercial software world. It seems to alleviate some pain and make the process more manageable, but I fear this is at too great a cost. Many development groups branch due to dysfunction. Note that I am not talking about open source projects. I'm specifically speaking about commercial projects where programming talent is not free. I'm also not talking down distributed version control, where every checkout is really a separate branch. I am concerned more about use of branches for the wrong reasons and at a high cost. Often branching is used to put off integration. This is a losing game. After so many changes to the trunk a branch will no longer slide seamlessly into the release stream. We can work around that problem (itself a work-around) if we merge forward all branches periodically so that they track the trunk more closely. This activity is time spent on featu...