One question that seems to come up again and again, with unfortunately greater frequency given the realities of lay offs in the current business climate, is: "How do we use Scrum to measure individual performance?" The short, and admittedly unsatisfying, answer is: "We don't!" The team is a single unit in Scrum that succeeds or fails as a unit.

I make ScrumMasters... sort of...

One of the things we advocate in Scrum (and really most agile proponents do as well) is small cross-functional teams. I discussed what we meant by cross-functional and some of the reasons why in a previous entry. Now I’d like to look at why we recommend small teams.

An interesting discussion that frequently crops up when introducing Scrum to certain organizations and individuals is the argument that they don't have time for backlog grooming because they have "work" to do. I get this argument a lot during coaching engagements when I tell team members they need to spend five percent of their time grooming the backlog.

One of the main myths of traditional project management relates to measurement precision. Traditional project managers have numerous statistical tools in their arsenal. Such measures as earned value or cost performance indicators etc. are touted as providing a precise scientific measure of how we’re doing. All of this points back to a Tayloristic view of software and product development.

One of the principle practices in Scrum (and in fact most if not all agile methods) is the use of “cross-functional” teams. Somewhat surprisingly there is often resistance at the team level to creating these cross-functional teams, but sometimes this is a result of misunderstanding what we mean when we say that a team is cross-functional.

When we are introducing Scrum to a new environment, we often get into debates, sometimes heated, with people who question the validity, truth and/or value of a particular agile or Scrum principle. My general feeling is that any time spent having a philosophical argument with a client/Product Owner is time not spent adding value.

At a recent meeting of a Scrum users group in Portland, Oregon, the topic of release planning came up.

Management is demanding release dates a year out, but Scrum says not to do that because of the rapidly changing environment that is software development.