Agility and Project Leadership

Sure, we like to think we can control the successful outcome of our projects, but as we all know, there are often times organizational barriers that are just too hard to overcome.  

This article on InfoQ list some common barriers that's helpful to keep in mind:

1. Ineffective use of the retrospective
2. Inability to get everyone in the planning meetings
3. Failure to pay attention to the infrastructure required
4. Bad ScrumMasters
5. Product Owner is Consistently Unavailable or There are Too Many Owners Who Disagree
6. Reverting to Form
7. Obtaining Only "Checkbook Commitments" from Executive Management
8. Teams Lacking Authority and Decision-Making Ability
9. Not Having an Onsite Evangelist for Remote Locations
10. A Culture that Does Not Support Learning
11. Denial is Embraced Instead of the Brutal Truth
12. People will always put their own interests ahead of the interests of the group.
13. People are self-interested
14. Commercial production decisions are based on rational expectations.
15. Karl Popper's "First law of collective action". You can never get more than 5 people to agree on anything

What barriers have you come across not listed above and what did you do to overcome them?

Software development and project management are very serious technical topics, so to add a little levity to your day, I present this video of how a "Scrum-Master" actually acts more like a "Scum-Master" (please note the semantic differences!):

Enjoy!

As part of my continuing series on Agile practices and techniques that extend outside the boundaries of software development, I stumbled upon a couple resources that resonate with me as a one time student and now part time faculty instructor for continuing education programs in project management for schools such as UCLA, UC Irvine and the University of Redlands.  This also includes for profit and volunteer PM and PMP training programs that I get called into periodically.

• Close collaboration and feedback from the students – students are in a very practical sense my customers, since they paid to take the courses and training and my role as paid facilitator requires me to ensure they are getting the educational and training services through close collaboration, open dialog and constant feedback  
• Continuous and iterative development of educational topics – Though my syllabus is planned out ahead of time, I have to be flexible enough to adapt to each class I teach.  Various students have multiple needs and if a topic that engages and interests them catches wind, then it’s my duty to incorporate it and adjust my schedule.
• Transparency and student focus – I incorporate a form of stand up meetings in which the students and I review what we learned and how it could be better, what’s on the agenda and schedule for the next assignment, and if there are any impediments getting in the way of the students and what I can do to remove them.  This creates a high level of transparency and forces me to focus on what the students want, not what I think they want.

I've posted this topic and question in various forums related to project management and I think it has direct bearing on Agile and for any management method, framework or process for that matter.  So I'm reposting on this blog to see what PM.com members think:

I saw this interesting thread in a LinkedIn discussion group for Agile and Lean Software Development, that questions the the common perception of Agile being an iterative method and process.  I'm guilty of this myself as I often talk about Agile methods in those terms, but as the post indicates, there's nothing inherent in the original Agile Manifesto that promotes having to do iterations:

The vast majority of people assume that Agile = Scrum = Iterations but the agile manifesto doesn't say anything about iterations or Scrum. What it does talk about is early and continuous delivery of value which could be achieved in other ways such as multiple overlapping iterations or continous flows.So are iterations really essential for agile? Are continuous flows of value a better way? Have you done agile without iterations? If so how did you go?

It really was Scrum that advocated using interations (or what they call "Sprints") and since it is the most popular of the Agile methods, those in the community often equate Agile with iterating.

For me personally as a practicing project manager, I'm naturally more inclined to align myself with Scrum's notion of iterations and delivering a "potentially shippable" product at the end of each iteration since it will give a clear delineation of when a project is done.

Having a process based on continuous improving flows seems more like developing operational efficiencies rather than delivering a project that can adapt better to changes in a highly uncertain environment.  That is not to say that a project's process could not benefit from continuously improving flows.  That's why things like incorporating Kanban is highly beneficial to moving task flows.

It's just my preference to have something like Scrum be the driving force for my projects and to incorporate things like Lean and Kanban process improvement flows where needed.

What's your take on this?