Agility and Project Leadership

A study conducted by Yoh seems to show that companies advertised a total of 558,918 agile jobs from 2010 to 2012. During the same time period, there were merely 121,876 active candidates, just 17 candidates for every 100 jobs.  Of the available job seekers, more than 50 percent have 10 years of experience or more, while less than two percent have one to two years of experience. The agile gap exists across the U.S., varying only in its degree of severity:

• Demand outstrips supply by nearly 4x
• Companies have to pay a premium for Agile expertise
• The agile talent gap is most significant in the Pacific Northwest
• Labor pressure for agile talent goes from bad to worse
• Competition for agile talent is fierce

This is revealed in their infographic below:

As I've mentioned in a previous post, the US government is adopting Agile even going so far as requiring the use of the method as this section of a 2010 DOD mandate stipulates:

SEC. 804. IMPLEMENTATION OF NEW ACQUISITION PROCESS FOR INFORMATION TECHNOLOGY SYSTEMS.

I'm seeing signs where Kanban is becoming what the Gantt chart was to project managers in the 20th century.  It's becoming all the rage in Agile and rightly so, since it provides the kind of simple dashboard to visualize where the status of your backlog of requirements are at the moment.  Futhermore, the simple and effective way to visualize the WIPs lends itself well to both high tech and low tech implementations.

Though it may seem like the newest thing, it is in fact a creation by one of the greatest process improvement thinkers and guru that also symbolized the resurgence of Japanese manufacturing after the second world war.  He pretty much is the founding father of Lean that launched the infamous Toyota Production System.

Here's a great introduction to Kanban and the history of its creation by Taiichi Ohno:

My future articles and posts here will involve many discussions of Kanban, so I thought I'd pay tribute to it's great founder.  For those who may want to read about his system directly, I would recommend reading his famous book Toyota Production System: Beyond Large-Scale Production.

I was directed to this interesting Q&A panel discussion on Agile Portfolio Management by Rally Software that is archived on YouTube:

This post from Scott Dunn of Software Development and Human Capital highlights a section from the talk that is a great quote from Dave West, VP Research Director at Forrester Research:

"It's interesting, what we at Forrester have observed across the industry this particular kind of  maniacal kind of addition to the program management kind of practice. PMO's have grown in size and stature in organizations and become incredibly…big, in terms of their execution. One thing that it illustrates is that complexity does not solve complexity.  As organizations wrestle with increasingly diverse portfolio, time-to-market pressures, one thing that they want to do is add more complexity. "When in doubt, add more governance!","When in doubt, add more people to manage the people that are managing the people!" "When in doubt, get more Gannt charts!" And I think that we've found that that does not work. I think it's clear that breakthrough companies or companies that are definitely driving the industry around change and innovation are not solving those problems with complexity."

Despite the fact that Frederick Brooks wrote about the absurdity of this notion in his infamous book The Mythical Man-Month: Essays on Software Engineering nearly 40 years ago, this idea still perpetuates itself!

It's time to start incorporating the Lean and Agile mindset to the PMO!

Almost  a year from today, I wrote a post on the cult of Agile where some in the community were so adamant in their beliefs and passion for Agile being the one and only true way to manage software development projects (and in some extreme cases, all projects), that they come accross like cult leaders that borders on religious extremism.

A case in point: my blog post on the metaphorical comparison of Scrum, the most popular of Agile methods, and how the popularity mimics the rise and success of a global brand such as McDonalds, was shared on the Scrum Alliance LinkedIn group to see what other Agile PM professional thought about it.

Here's a response from a Scrum Alliance group member Ken Ward, an Agile trainer and proponent (I would normally not list a person publicly in this instance, but the person in question did post his opinion in a public forum so I think it's fair to credit the statement to him):

"Is Scrum becoming the McDonalds of Agile?" what you mean the old 'waterfall' and 'PMP' way was better? does not that imply the 'PMP', 'Waterfall' way is the 'cesspool' of past failures!!?  Scrum does 'get it' 'Done" if companies can not adopt the Agile or Scrum frameworks and do it correctly because they cannot give up the 'old school' 'command and control' failures of past days the failure is the fact that they, the company only wants to 'throw it over the wall' and then 'blame ' the failure' on the IT department . they have to get into the game and accept their responsibility to drive the development and take the 'ownership' of deciding what it is they need in terms of software and take the responsibility for their own 'failures' if they can not determine what it is they need developed!!  Lets say 'PMP' and Waterfall" is the 'cesspool' of IT failure and not compare Agile and Scrum as a "McD's'...

Personally speaking 'McDonalds' is the cesspool of 'fast food' and cannot, should not and will not be compared with the likes of 'Scrum', McDonalds is Scum, and 'Scrum' is Agile. I take offense at the charactization of 'Scrum' with McDonalds and "I'm not loving it"!  Bad choice of comparison. Yes that is the 'point' I was making!!

This was my response:

I think a vitriolic attach on "waterfall" or "PMP" is not warranted and will only polarize the traditional and Agile camps even further. In addition, it discredits the movement as well, which would be a shame since in certain situations Scrum is a great method. I've been involved in software waterfall projects that went quite well due to having the same ingredients required for Agile to flourish (organization support, adoption, etc.) and just as there are multiple flavors of PM techniques, there is correspondingly a wide diversity of projects which require an evaluation into whether Agile, waterfall or a combination thereof is needed. Rationalism should prevail.

To me this is a cautionary tale to not take our pet methods or practices too seriously.  They are just tools to help us complete projects, for as I stated nearly a year ago, "in the end, all that matters is whether your project was done on time, within budget/scope and most importantly, to customer satisfaction.  No one will care whether you did Agile, traditional or voodoo magic."