This is getting old, isn't it? I still think I might try to turn this into a book of some kind, though, so we press on.
5. You can't touch some code because someone "owns" it. Or there's some piece of code that only one person can work on. Sometimes this can happen because what a unit of code does is so complicated and so specialized that there's only one person on your team capable of understanding it. But most of the time what is happening is some combination of a person's ego becoming involved, a lack of sufficient unit testing, and insufficient cross-pollination of code modules among the members of the team. Consider this situation very carefully, because it means your code base now has a single point of potential failure. If only one person understands it, what happens if that person gets sick or wants to take a vacation? If someone's ego gets involved, it's almost always to the detriment of the rest of the team. Or are people just afraid to touch it because something might break? That's the easiest case to deal with: keep adding unit tests until people feel comfortable with that safety net. Pair Programming can help with the cross-pollination, as can inflating an estimate, biting the bullet, and giving the work to anyone BUT the person who "owns" that code. Collective code ownership may be a little painful and a little slow in the short term, but in the long run, you'll be glad you did it.
4. Your team lives from one crisis to the next crisis. Management is freaking out regularly. Flailing, weeping, wailing, and gnashing of teeth. What could this possibly have to do with Agile, you ask? Quite a lot: it's an indication that your Agile process has completely broken down or your stakeholders are not playing the game. If Agile were working properly, why would Management need to freak out? They'd have a predictable set of deliverables for each iteration and each release. They'd have a good idea of the team's velocity. They'd have a decent idea of when things would be "done". They'd be seeing progress in the form of demos regularly. If they're completely disengaged and not participating, you're going to need a heart-to-heart. If they are flailing because your team has given them timelines, and they just don't like what you had to say, then you have a trust issue between your stakeholders and your team, and again, you need to have a heart-to-heart. If Agile is new to your organization, you need to set expectations accordingly, and make sure everyone understands how the game is played. Remember, though, out of crisis can arise opportunity: if you can hold your team together and execute cleanly, you can demonstrate how Agile can provide the predictability and response to change that has your reporting chain in an uproar.
3. Your team has more than 6-8 developers. Agile performs best with small teams who can meet regularly and communicate easily. If your product is really a product of products, consider breaking teams apart along product boundaries. You may be tempted to break teams apart across some other boundaries, but try not to do that. Remember, you're trying to satisfy a product owner; the key word is "product." How can you do end-to-end iterative development if you've aligned "vertically" instead of "horizontally." Give it some thought, because there's a decent amount of overhead in bootstrapping a new team. Reflect on the values of Agile, and form your teams in such a way that you can satisfy the various roles most effectively and play the game by the rules.
2. Chickens are being pigs. Pigs are being chickens. Or to put it another way, someone is regularly stepping outside the boundaries of their role in your meetings. This could be a product owner trying to change the rules of your Scrum, a Scrum Master trying to influence the implementation of your code, a developer trying to inject a feature into the product that wasn't requested, etc. It can also take the form of "Some Guy" trying to do anything at all in your meetings. When this happens it is the responsibility of the Scrum Master to call it out, explain why it isn't allowed, and remind everyone what their roles are. If you're playing soccer out on a pitch, you can't have a handful of players decide they want to play rugby, nor can you have your goalie decide he wants to play forward. For the game to work, the players must first agree to the rules, and then play by those rules.
I seriously hope I'm done this time, and that anything else I think of will be a straightforward repetition of one of my previous articles:
