Scrum Doesn't Work for Us

"...because..." and then I hear a list of how a company, or a team, or a project is 'different' from others out there. This is common, and though there are great assessment tools out there, let me share with you three common issues that I and other coaches see.

1. The user stories are not estimated in points. I've heard lots of explanations of why, or how management doesn't understand points but understands hours, or points-to-hours conversions posted on the walls. In the end, the principle remains that we don't estimate well (just refer to the initial estimates of pre-agile projects). We compare well, referring a current feature or request to a simple, previous one that we know well. Also, estimating hours is often unconsciously optimistic. Not only do we think in terms of ideal, uninterrupted hours, but we don't stop and factor in risk, complexity or unknowns when saying "That will take 8 hours". Estimates are planning Marc and Liz's 2 hour meeting at church on Saturday, story points are planning Marc and Liz's wedding.
2. The team isn't voting on the size. Sam the Helpful Manager says, "Joe's the architect and he just tells us how many story points it is." Well, just because Joe (AKA Smartest Guy in the Room, whether others agree or not) is the architect, doesn't means he's as smart as everyone else on the team combined. No one person can see all the issues, has all the combined detailed experience, has all the creativity and innovation to come up with the best solution. And, worse yet, my experience is that it is less about Joe voting and the team missing out on better sizing, it's more often about pride, power and control. Joe likes his position and title and doesn't want to share power or the stage or 'important meetings' with those less than him. And because the team doesn't discuss and vote on the size, they don't feel or have a psychological ownership of the work. Someone else signed you up "Bob's Crazy No-Pain, No-Gain Exercise Boot Camp" how much will you really be into it? If the team didn't vote it, the team doesn't own it.

3. Don't know that you don't know. This is perhaps the most dangerous because teams think they know what to do and how to do it (but don't). It's like visiting another country and plugging in your hairdryer as a means of learning that voltage is different in other countries (and then blaming the hair dryer manufacturer). The first antidote is having an expert on site - someone trained in agile. The second is getting as many people as possible involved in the agile community (conferences and local events) in order to keep learning.