Agility and Project Leadership

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?

In part one of my Kanban and Beyond series of articles, I discuss the manufacturing roots of Kanban that many of us in the IT project management industry are not aware of that originated in Japan for Toyota over 30 years ago.  But this may give the perspective that it is mainly practiced in the auto manufacturing industry or that it has evolved mainly for use in Lean software development.

That's hardly the case and in the video below published by The American Innovator, which is a great show lead by Paul Akers on the ideas that are shaping and continuously innovating the US industry, has a great video showing how Kanban is used at FastCap, an industrial cabnet making and woodworking company owned by Paul Akers:

This shows how Kanban and Lean can be used in any industry to drive innovations and improvements both in the US and beyond!

Here's an interesting video on how Kanban is implemented in TFS for the Microsoft Visual Studio 2012 toolsets:

TFS is a service that allows you to remotely manage your software development efforts both locally and with remote teams.  Interestingly, it is now not tied to only MS developments tools such as VS 2012, but can be used with Eclipse for developing  Android applications with Java for example.

More interesting for me as an Agile project manager is that this tool provides an electronic form of Kanban to manage and track the development process for a software project that can be viewed and updated by anyone on the team anywhere.

Seems a feature was just added to allow one to create customizable columns.  The Channel 9 video also provides a nice brief introduction to Kanban as well as how the visualization tool  works.  Check it out!

And sure enough, this post by InfoWorld quotes a survey done by VersionOne on the leading cause of Agile failure:

In the survey's seventh year, "we dug a bit deeper into why agile initiatives fail and found that in two-thirds of the cases, it was either a failure to integrate the right people or to teach a team-based culture," the report states. Other reasons include communication problems between development teams and other areas of the business and problems with the Scrum master. (Scrum is a popular agile methodology, and agile itself emphasizes iterative software development, with processes evolving along the way rather than being predetermined.) External pressure to follow the traditional waterfall processes was cited as a failure factor as well.

As I've indicated in a post on Project Management Central, it's as much of a state of mind that's most important for the success of Agile and that having a self-organizing and effective team is a "state of mind" nurtured by the larger organization.

The failture to nurture this important aspect of Agile is a failure to create the culture for an organization's people to thrive.  That's why I end this post with none other than a Dilbert expose on the pitfalls of Agile adoption by the pointy haired bosses: