I have taught project management courses at the University of Wisconsin-Milwaukee since 2002. While I teach 'traditional,' process-oriented PM classes, I recently started teaching an "Introduction to Agile" course that I have now delivered twice. The course is a 2-day overview of Agile concepts and methods - students are introduced to the Agile Manifesto, a brief history of the "movement," overviews of Agile methodologies such as Scrum, XP, and Unified Process, and comparisons to waterfall/traditional process-oriented methods. I also spend a significant amount of time debunking hype around these topics - concentrating on what Agile methods can - and cannot - do for an organization. The primary goal of the course is not a deep dive into one or two of the methodologies, or to boldly (and foolishly) proclaim that Agile methods solves all problems on all software development projects, but to present an unbiased overview that students can come to their own conclusions as to how (or if) Agile methods would work in their organizations.
The students are mostly senior IT folks up to the middle management level. Almost all of them come from process-oriented project backgrounds, and a significant number hold the PMP (Project Management Professional) certification. My fellow faculty members in the program tease me about 'undoing' all of the instruction that we give them in the process-oriented classes
I laugh, then I get on my kevlar vest...:)
My students are bright, capable, and professional people. I enjoy teaching them, and because this material is so different from what they expect or are used to in their respective organizational settings, the questions and commentary can get, well, a bit direct. Not mean or nasty, mind you - just that they have difficulty seeing paths to success with Agile methods given the techniques and constraints that I put in front of them.
The following is a list of frequently-uttered exclamations (in no particular order) by my students both times I have taught the course:
"I cannot offer a plan that only includes this iteration and the next one - they (management) want to see the whole thing scoped out in advance." Well, then we're back to process-oriented project management, aren't we? I reinforce the notion of uncertainty at the start of projects, particularly those of requirements, as the basis for why all of this came about.
"Our CFO develops budgets on a fiscal year basis, and our estimates routinely turn into the actual budget. If we're only dealing with a couple of iterations at a time, how to I deal with the budget planning issues given the time mismatch?" Good question and I wish I had a better answer other than give the ballpark estimate for the fiscal year and more precise detail as the iterations unfold. The CFO probably won't like that answer either, but then contrast it with the process-oriented projects that routinely blow their budgets and he isn't getting decent forecasts in any event.
"I cannot dedicate 100% of the project team's time to an agile project. they need to fix bugs/provide support/work on other projects and stuff in addition to this one." This represents an interesting paradox asserted by some commentators (for example, Joel Spolsky) who claim that true agility means that resources can be shifted on-the-fly as needs dictate, whether is on a project or something else. My response is that nothing kills a project (or at the very least, it's momentum) faster than constant resource shifting in and out of the effort. This applies regardless of the methodology used, so its not just unique to Agile. The real problem here is that team interaction and self-direction are being relied on in Agile projects over comprehensive documentation. Take the resources away or severely constrain their availability to the project, with little or no docs to fall back on, and trouble lurks right around the corner.
"Our management will have a big problem with the concept of self-directed teams and the notion of a Scrum Master as a facilitator, rather than as a project manager/leader." This is very typical in command-and-control and micro-managed organizational environments. In those situations, Agile may not be a proper cultural fit or used as a "silver bullet" on flailing project efforts, with predictable outcomes - usually negative. I mentioned that self-directed teams are not rogue bands of cowboys and cowgirls doing what they please or think is "right" without accountability and overall direction. Also, the customer must assume responsibility and accountability for the effort, and if they can't or won't, then the whole point of developing software in this manner becomes moot.
"We cannot utilize a common project room - everybody has cubes or offices on different floors of the building, or are in many different buildings." This usually goes hand-and-hand with the "can't commit resources at 100%" issue. The same answer applies here - team interaction and direction along with incremental releases are replacing documentation and other artifacts to produce working software. If you amputate the critical team communication paths necessary for success, the outcome will generally be negative.
"Pair programming sucks!" Well, I'm no big fan of it either, but XP'ers are...:)
Those are the highlights...more to come later when I think of them. In the end, people liked the course and gave it good-to-great reviews, but in larger enterprises, trying to get Agile off the ground and working in a lot of these people's environments will be akin to moving heaven and earth.
Which is why I will keep teaching this class and see how many more minds I can open.