Earlier quoted context omitted.
That is how I view it: - "big A" Agile has books and approved tools and coaches from outside the company holding week-long all-day workshops. - "little a" agile has devs/QA/etc. suggesting ways to make the process of building and shipping software smoother. I'm currently working on a "little a" agile team. Upper management doesn't really care what our process is, as long as they get their quarterly release with (most…
I'm becoming increasingly convinced that, to be successful, a team's agile practice needs to largely fly under the radar of upper management. As soon as upper management catches wind, you'll need to justify every little process flow change to them, or they'll start demanding regular reports with burndown charts and plots of velocity over time and crap like that. At which point, you're done. Things officially suck for…
I think that's a management problem you'll run into with any development methodology you use. There are a lot of management types that slavishly focus on metrics whether or not they make any sense, and they can do tremendous damage to any organization.
Give those people a tool and they'll find a way to misapply it, whether it's velocity, or performance reviews, or LOC, or whatever.
Prime example of this was stack ranking at Microsoft. How much productivity was lost due to the political maneuvering and backbiting caused by their misunderstanding of bell curves?