InfoQ have published an article which offers a compelling argument that common corporate performance reviews are fundamentally broken, and should be abandoned. While I largely agree with this premise, I don’t see a great deal of improvement in the proposed solutions.

Perhaps it reflects differences in the kinds of places we have worked, but for me an effective performance review should concentrate on a holistic view of how the individual has contributed to the success of the organization. I am worried that neither of the two proposals encourages “thinking outside the box” and doing whatever is most effective for the business. Instead, they concentrate on reinforcing existing decisions such as pigeon-holing staff into “team members” and “managers”.

InfoQ: Performance Reviews Banished

Agile processes are an obvious choice for development work within a business, but have traditionally not sat well when dealing with customers and contracts who like to specify detail, delivery and price before work starts. Negotiators and lawyers have no obvious answers to hand and, rather than take the risky route of creating a new agile contract, usually fall back to the apparent safety net of an implicit waterfall process.

If there were some example “agile” business contracts available, some of the risk for the contract negotiators might be removed.

InfoQ: Working Group Formed to Produce Reusable Agile Contracts

I’m currently working on some software which sends notifications to users (using SMS, email, or whatever) and have faced the inevitable problems with testing it. On balance I’d prefer not to receive a test SMS on my mobile phone every time our continuous integration system runs an end-to-end test.

Gojko Adzic has some thoughts about how to make such a system more straightforward to test.

Gojko Adzic » How to test e-mail notifications properly

Looks like an interesting list, especially if you happen to work for a company which is looking for a new CEO right now.

The Seven Things That Surprise New CEOs — HBS Working Knowledge

Team composition and team dynamics are fascinating me right now. We are trying to grow an effective development team, and encourage a process where both the team as a whole and the individuals are doing their best for the company, the product, the customers and them selves. Linda Rising has some thoughts about some of the things that can perturb this effort.

InfoQ: Interview: Linda Rising: Prejudices Can Alter Team Work

We have some pretty lively iteration retrospectives as part of our process, but so far they have almost exclusively focussed on the issues affecting the process. Sarah Taraporewalla wonders if such discussions should also cover thoughts about the code base and the changes made to it.

Sarah Taraporewalla’s Technical Ramblings » Retrospectives for the code base

Looking at the the way collaborative, creative, teams work in fields other than software development can be very useful. There’s an argument that creating a software release is a lot like creating a music album, for example. Chris Johnston has followed this train of thought and asks if we need an analogue to the “producer”.

Chris Johnston » Who plays the role of technial producer on Agile teams?

I’d not seen this, and if you haven’t either then it’s well worth a read. Tim Ottinger gives a detailed list of the ways that Test-Driven Development (TDD) changes code.

Testing Will Challenge Your Conventions

To make software development work, everyone involved needs a good working knowledge of the product, the domain, the solution and so on. Communicating enough, but not too much, information can be tricky, especially in an agile environment where anything can change at any time.

Tarek Abdelmaguid has an interesting list of ways to communicate while working on a project. I have done most of these for various clients and employers, and also made a lot of use of instant messaging. There is definitely scope for using more structured communications such as mailing lists, internal blogs and forums, though.

On Programming and Applications Development: Project Development Knowledge: Sharing and Enduring

Planning what order to do stuff in is a vital, yet very difficult, part of software development. Agile wisdom usually stresses the need to do things in order of “business value”, but this can sometimes be extremely tricky to evaluate.

Another approach is to do things in an order intended to decrease risk, such as starting with the most worrying, or least understood parts of a system.

InfoQ: Iterating To Acquire Knowledge, Not Just ‘Business Value’

While this sounds plausible, I am not sure I entirely agree the reasoning. Behind the idea of ordering things by risk seems to be the idea that there is some bounded set of requirements, known early enough in the process to be able to determine their “worry”. To me the whole point of agile development is to step outside that assumption into the real world where work needs to start before full scope is defined, where priorities change on a whim, and development on a product may be cancelled at any time.

Starting work by spending a few iterations investigating complex/risky parts of some imagined future product instead of delivering usable but minimal versions from the first iteration seems somewhat irresponsible.