If you are playing agile the way I do (which I call Xanpan), I encourage sprint-spanning stories in order to improve flow. I allow for stories that span sprints but I won’t let them continue forever (Three sprints and you’re out!). Additionally, my teams try and break sprints down into smaller pieces of work.
All that said, small stories are far better than large stories, but you need to get good at writing small stories that fit within two-week sprints. The "complete-within-the-sprint" rule can be an effective way of forcing teams to get away from stories that are too large. While this rule is fine to aspire to, it is something that requires practice and learning on your part. It isn't something you can do on your first day of agile or even after a few days spent on an agile course .
7. Developers get to do what they like.
No, developers do not get to do what they like. If this is true for you then you are doing it wrong. Agile needs well-disciplined teams. What gets done should be lead from a specific role, usually designated the customer or product owner. If developers are doing what they like then there is a good chance something is wrong with that role, the person playing it, or the authority vested in it.
It seems to me that the business-side sometimes feel as if developers get to do what they like because they fail to grasp the nature of agile, which is a collaborative process they involves discussion and negotiation between those who are building the system and those who requested the system.
8. Scrum and Kanban are sworn enemies.
Some individuals get a lot of eyeballs by saying that Scrum and kanban are sworn enemies. A cynic might even say the marketing efforts behind both methods might view the image of competition as a useful publicity tool.
In my experience, many teams are combining ideas from the iterative methods (Scrum and XP) with ideas from kanban. One combination, ScrumBan, was described by Corey Ladas four years ago and I continue to evolve my own Xanpan method. (In case you haven't guest it, Xanpan is a fusion of XP and Kanban.)
9. Agile doesn’t work for fixed deadline projects.
Agile works best in fixed-deadline project environments. When team members use agile, particularly the Scrum and XP versions, they receive much of their power from the harnessing deadline effects: sizing work to the deadline, individual motivation and willingness to renegotiate just what is being built to meet a date.
A corollary to this is that agile methods are also very good for fixed-price work since costs are overwhelmingly wages multiplied by time.
10. Agile doesn’t work on Brownfield projects.
Agile works best in environments where something already exists, so-called Brownfield work. On a Greenfield effort—one with no existing codebase—first base is a walking skeleton, a bare-bones system that works end to end. Brownfield projects start with a working system in place.
Granted it's harder to retrofit automated tests to a existing system than creating tests for a new system, but it is far from insurmountable.
11. Agile doesn’t work on Greenfield projects.
While it’s a myth that agile doesn’t work on Greenfield projects, remember that your first objective is to get yourself to a steady state where you can think like you are operating on a Brownfield project.
Believe it or not, for every two people I meet who tell me "I can see how agile will work for Greenfield projects, but we have an existing system," I meet someone who holds the reverse point of view.
Automated testing in a Greenfield environment is easier, but the fact that no codebase or working product currently exists to begin with presents its own challenge. There is often an "all-or-nothing" mentality among developers and managers that needs to be overcome. Additionally, many developers are concerned with the need to design and architect. It can be hard to accept evolving, emergent design until one has experienced it.