Some of the hardest work I've ever had to do as a coach is convincing teams how to collaborate (interact) when they develop a product. But if an organization REALLY wants to be agile, they have to learn and accept that developers will work better if they collaborate than if they work independently.
A very common problem that many organizations have to deal with has to do with those "specialists" in the organization that are among the handful of people who have a particular skill. Common skills that fall into this category are technical writers, database architects, UI experience analysts, etc. The problem, of course, is that there aren't enough of these folks to put them on Scrum teams.
A few months ago, I wrote the first in what I hope to become a series of blog posts on things that we need to stop wasting time doing. I want to focus on activities that APPEAR to be really important, but are really just hold overs from old-style management techniques that assume that software development is actually a defined process as opposed to an empirical one. In the first blog post, I focused on the time wasted in release planning. This blog post will focus on my next target: trying to plan detailed capacity for a a Sprint.
Scrum teams are defined as meeting certain criteria. First, they have to have the skills on the team to get the job done that they are going to be asked to do. Second, the team should be between 3 and 9 people (prior to 2007, Scrum suggested that the team be between 5 and 9; more recently, it seems that size was changed to 3-9). Third, the team should be self-organizing. It's the last part I'd like to talk about in this blog post.