Four signs of poorly implemented Agile™
Agile software development. The term 'agile' has been worn more in the last decade than 'synergy' as the answer to corporate zen. Several consulting firms have placed an implicit trademark symbol at the end of the term, as if it were the staple of their entire business model. What are the warning signs that the brand of agile you've chosen is being grossly misimplemented?
Retrospectives without timeboxes. Programmers love to talk about their feelings -- so much so that we block off a couple hours per iteration to tell each other how we really feel. However, we often blab on far too long without accumulating those precious action items which steer our development efforts toward our goals. Time box every retrospective and assign a clock czar to keep the meeting on track. You'll be glad you did.
100% test coverage for the sake of the number. Many teams will keep track of their total test coverage using a tool like RCov. While the statistics these tools provide can offer insight into untested areas of your codebase, they should not be taken as a hard and fast 'YES' or 'NO' to the question, "Do we have ample test coverage?". In the case of RCov, these statistics only report whether or not lines have been executed by test code. Take a pragmatic approach to test coverage and realize that your tests should both cover the breadth of your code base and cover all code paths in a human-readable, expressive manner.
No requirements necessary. We're agile. I've led projects where, in retrospect, I've found myself guilty of understating the requirements to my team. Despite our tendency to throw away formal requirements along with waterfall methodology, we cannot forget the value added with clear, concise requirement documentation. Your team and all stakeholders should be comfortable with your issue tracking system. You should have no more than one place for storing your user stories and defects. They should be specified in a manner such that any developer on your team can start working without needing further clarification from the product owner.
Stakeholder underinvolvement. We tend to have high expectations when we spend hundreds of thousands of dollars (or more) on a product. The idea that we might need to participate in our product's development sounds a bit like being expected to assist the chef at a five-star restaurant. As with any collaborative creative process, software development requires its stakeholders to be as involved as the development team. This means being prepared for planning meetings with groomed backlog stories ready for consumption by the development team. It also means having adept technical writing skills -- or an assistant who does.
