Boy, these just never get old, do they? Given the span of time it's started taking me to collect another 5 signs, though, I'm hopeful that I'm running out of material. Or maybe I'm just being optimistic.
5. Your iteration runs Monday through Friday. Everyone checks in on Friday. Test is always one week behind. Acceptance is always delayed. I think I've seen this particular behavior in every Agile project to which I've ever contributed, and the cause is very simple: your stories (and probably your tasks) are too big. If you're working on the same story through the entire iteration, either you're making no progress day-to-day, or your story was so big it took the entire week to accomplish. The former problem can be addressed in daily stand-ups by asking what tasks each person completed on the previous day. If the answer is "nothing" then you have a blockage or some other problem that needs to be addressed immediately. The latter problem means you need to spend more time in story decomposition and task breakdown.
4. Something changes. Chaos ensues trying to hide the change. Agile, when properly applied, excels at coping with change. If you've kept your iterations short, decomposed your stories, broken down your tasks, considered your velocity in planning, etc., you can estimate the impact of whatever changed and adjust accordingly. We've all had the key team member falling ill, business priorities changing, last-minute items coming from security auditors, etc. These things will impact your velocity. And that's okay! What you don't want to do is to try to hide the impact of the change, treating your velocity like it's a stick with which to beat people, pulling out all the stops to try to "meet your numbers" for the iteration. That's not what velocity is for; rather, the impact of many small changes over time will reduce your average velocity slightly, and this will ultimately aid you in planning.
3. Rather than decomposing stories, your team lengthens its iterations. Key to being Agile is having frequent opportunities for adjustment and collecting frequent data points about team velocity. Consider this: if you need four data points to start to get a good feel for your team velocity, with one-week iterations, that takes you a month. With two-week iterations, it takes two months. With three-week iterations, it takes three months just to figure out what your velocity is. It's like trying to learn to pilot a jet ski, fishing boat, or cruise ship. Moreover, when adjustments are needed, you're trying to steer a jet ski, fishing boat, or cruise ship. Granted, a jet ski isn't the appropriate watercraft for every situation, but if you're planning to change to a fishing boat or a cruise ship just because you're unwilling to leave some of your gear on the shore between trips, you're not making a change for a good reason.
2. Related to #3, you survive many planning meetings without ever decomposing a single user story. Maybe it's possible that you entered all your planning meetings with all your user stories perfectly decomposed into chunks that can be delivered end-to-end inside of one iteration, but it's not particularly likely to happen iteration after iteration (unless your product owner is exceedingly well-trained). Odds are your stories are going in too big, and you're about to experience #5 from this list. You need to have a discussion about the right size for a user story, the difference between user stories and tasks, and how to write user stories correctly. You may need to allow extra time for planning for several iterations until the right way becomes a healthy habit, and the wrong way starts to feel weird.
1. Your team throws out Agile practices willy-nilly whenever they become more than mildly inconvenient, yet still expects to reap the benefits of Agile. I'm the last person to say that teams must absolutely adhere to Agile dogma (though one could get that impression based on my blog postings), but when you're making tweaks and changes to your process, you really must think carefully about what you're changing, why you're changing it, and what the potential unintended (and direct) consequences of your change may be. If you choose three-week iterations, it's going to take months to establish a velocity. If you don't track or use your velocity in planning, your estimates aren't going to be very useful. Be very cautious here: it's easy to fall into the trap of the "compressed waterfall." And don't complain that Agile failed when you've thrown the baby out with the bathwater, adopting a process that looks nothing like Agile (but still calling it "Agile").
Bonus: Nobody from the team ever acts as a dissenting voice in your commits, retrospectives, or estimation exercises. Nothing says "just get me out of this meeting" than everyone giving a "five" when you call for a "fist of five" to commit for the iteration. Similarly, nothing says "I don't really care about the size of this story" than having a handful of people giving a different estimate, yet automatically giving in to the more-common estimate without any discussion. Your team is getting burned out, they don't understand the process, or they have no incentive to care. Take the time to really understand the underlying problem here, rather than just having a knee-jerk reaction to it. You may find valuable insight.
Like most things in life, what you get out of Agile is directly proportional to what you put into it. Know your Agile practices, but also know why the practices are what they are, and understand the consequences of abandoning, changing, or tweaking the practices in your organization. Make sure these consequences are clearly communicated to your stakeholders, too!
