Surviving the Transistion to an Agile Methodology, Part 2

So your organization has decided to go Agile, and everyone is onboard, and you've started holding Scrum meetings, and coding in sprints, and everything's going to be just fine, right?

For Sale:  One bridge in Brooklyn

One of the biggest problems is the tendency from members of management to decide that "just this once" you need to circumvent the Agile rules, and (add work to the sprint in the middle|work without a Product Owner|pull your one expert on Technology X "for just a few days")

There is usually one manager who continually subverts the plan.  S/he will never say they are not doing Agile, but they will never really get with the program.

On the flip side is the manager who is perfectly fine with doing Agile development, but wants the metrics to keep improving, since they will be measured by the metrics, even if the metric is explicitly not a performance metric (like team velocity).  So this manager will be gaming your estimates so that their team looks like it is always improving.

Another pitfall is the gradual falling away of the sprint planning rules - that the team should make the estimates, that the stories need to be broken up into tasks, and that tasks should be self-assigned.  You gradually see managers trying to re-assert their traditional roles and hand out work based on their own ideas of effort.

Finally, the big Agile-slayer might show up - field support.  Nobody knows how log it will take to handle field issues, because the level of information can vary greatly.  Often you have customers that have political agendas keeping them from giving you good info, or sometime it's just really clueless support people.