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
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
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. We do almost all of them where I work, and also make 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
I started to idly watch this video presentation, but quickly found that it describes a situation eerily close to our own, so I have decided to set some time aside to watch it in proper detail. I hope it pays off!
InfoQ: Planning with a Large Distributed Team
I’m definitely enjoying reading Mark Needham’s blog. Today it included an interesting article discussing productivity among individuals, pairs and teams.
Team Productivity vs Individual Productivity at Mark Needham
An interesting article, apparently based largely on the keynote from Agile 2008. Some clever stuff about estimation, averages, and the wisdom of crowds in the context of software development teams.
Gojko Adzic » Bulding smart teams
I’ve never worked on a team with an explicit Agile Coach - I know several people who have worked in that role, just never with me.
With that in mind, this article is an interesting exploration of what the role of “agile coach” actually entails.
thekua.com@work » The Agile Coach Role
I’ve certainly seen this in action. Confusion between the idea of a team, and the practice of a bunch of people “working together”. They are quite different things.
thekua.com@work » What do you have more of?
can’t argue with this. The particularly important point is that the benefits of co-location are so valuable that they should justify a surprisingly high level of cost. Many employers seem to assume that co-location is only worthwhile if it is virtually free.
AGILE IN ACTION: Distributing teams is a silly thing to do
This article certainly echoes some things which I have observed. It’s hard to gain the full power of an agile approach, if the agile teams don’t have the ability to address issues across the whole solution. However tempting it may seem to solve the problem of team size by splitting teams across architectural boundaries, this is rarely a good way to solve big problems in a smart way.
Splitting teams by task or feature, and letting each team solve their task or feature in a way which is optimal in the context of the whole system, will almost always result in a more effective solution, and often a solution which is actually much simpler/cheaper than the way it might have been achieved if each team only considered one part of the system.
InfoQ: Choose Feature Teams over Component Teams for Agility
All teams have their ups and downs, and sometimes it seems as if a team would just be better without a particular person. A recent article from InfoQ discusses this situation in the context of the Survivor TV show, popular in the USA, where contestants repeatedly get the opportunity to “vote someone off the island”.
InfoQ: Voting Someone Off the Island on an Agile Team
While I can see that in some situations the ability of a team to decide together that it’s just not working for some team member is useful and valuable. However, I can’t help worrying that there is a hidden dark-side to this.
As well as making rational consensual decisions, groups also exhibit other, less desirable, characteristics. It’s easy to imagine someone being “voted off” because their ideas challenge the status quo, because they threaten the complacent assumptions of the rest of team, or simply because they are different.
A mob, even a small mob, can be a dangerous thing. “Reality TV” such as the above-mentioned Survivor, Big Brother, The Weakest Link, and many more have shown us this again and again. Do we really want to encourage the mentality of conspiring to “vote off” the most challenging competitors in software development?
many developers intuitively understand the benefits of working in small tightly-focussed teams. Apparently, one way of determining whether your team is an appropriate size is using Pizza as a measure. Seems an interesting idea, although I have yet to find any definition of what sort (and crucially, size) of pizza should be used.
fuzzylizard » Two-Pizza Teams
The same author later returned to the topic to point out some potential problems with this approach