Agility and Project Leadership

Here's a webcast of a very interesting talk given at the Lean Software and Systems Conference 2012 by David Joyce in which he argues for a Lean/Agile PMO using Kanban to go beyond the tranditional PMO in managing a portfolio of software/IT projects.

As the kenote summary states:

Even though traditional models and assumptions represent thinking that originated in the 1890s with Taylor (fixation on efficiency and utilisation) and Gantt (of Gantt chart fame) they seem remarkably impervious to change. 

Our problem is that we need to change otherwise we can never achieve true business agility.

In this talk I will contrast the differences between a traditional PMO and a Lean/Agile PMO, outline the value a Lean/Agile PMO can bring, and explain how Kanban can be used as a vehicle to move portfolio management into the 21st Century!

What is advocated is quite a big idea to take Kanban techniques which have their roots in Lean and just-in-time production, to create a hybrid Agile/Lean Kanban board driven PMO.  This is the kind of convergence of Agile that I mentioned in my previous article, that will re-contextualize these techniques going forward.

The author has not allowed the webcast to be embeded so you will have to visit the link to view it directly.  But I also find a presentation below which seems to be the genesis of these ideas:

When conduction Agile, here's a list of 7 deadly sins to avoid:

1.    Forget to get early feedback – It’s important to get feedback early on for items such as user stories, product requirements, Agile charter, etc. to your reviewers as early as you can.  This will save having to do multiple rewrites.

2.    Avoid rather than embrace change – Despite being a practice and method developed to accommodate change the most, you may still find resistance to change especially if your team and customer are accommodated to having requirements upfront.  You have to foster an environment where embracing change is viewed as an opportunity to provide value to your customers rather than something to be avoided.

3.    Order and prioritize intermittently – You have to pursue ordering and prioritizing your product requirements, backlog tasks and daily activities relentlessly.  This will allow you to distinguish the must-haves from the should-haves and won’t haves.

4.    Favor remote over direct interactions – With the plethora of electronic mediums to communicate (mobile, IM, social networking, etc.) and an increasingly globalized workforce, it becomes easy to favor remote over direct interactions.  Don’t get lazy and get your teams to actually stand-up and talk during stand-up meeting as much as you can!

5.    Put off total transparency – Agile is great at revealing and making any problems and issues you have in your projects visible.  It is up to you and your team to proactively manage and act on them.  To be Agile is to embrace total transparency.

6.    Forget to experiment and learn – We can get so focused on delivering the project that we forget to experiment and learn to continually improve.  Use retrospectives to collaborate and document lessons learned and allow teams to not be afraid to experiment, test and learn as many novel solutions to pressing project problems get solved during these brainstorms.

7.    Deliver work that does not provide true customer value – Though it’s both a very explicit and implicit goal of Agile to deliver customer value, you and your team can get easily side tracked into tasks that won’t contribute to customer value and take up a lot of valuable time and effort.  Your team can get too involved with optimizing or tweaking a software feature that’s technical interesting, but will be of little value to your customer.  Don’t get too involved with fancy burn down charts or progress reports, but spend just enough time to clearly and concisely articulate the status of your project to keep you stakeholders in the loop.

In this blog by Mike Cottmeyer, he talks about the "two faces of Agile" where one is emergent, in that you are involved in an R&D like project where you are "experimenting, learning, and adapting (your) approach based on super-fast feedback cycles… and the outcomes, the products they are trying to build, are emergent. The end goal isn’t necessarily clear at the start".  This is in contrast to the convergent type, where you are "to figure out the right products to build, but their markets have a predetermined notion of what to expect...but the outcomes, the products they are trying to build, need to converge around set expectations."

In other words, his argument is that Agile project typically have a clear end goal or one that will emerge.

An approach I think that is missing from the above is what I refer to as the dependent type, which is basically the reverse of the emergent type.  It is an R&D project that runs in reverse.  You have or know exactly what the solution will be, but you have just not discovered an application for it.  So the end goal of the solution is dependent on the application of the solution and if that application delivers business value.  It's a solution in search of a problem.

A good example of this would be Google+.  Google+ is the latest addition to the social networking platforms with Twitter and Facebook as dominant leaders.  Though it rose quickly the user base growth has tapered down and new entrant Pinterest has already surpassed it.  Its initial claim to fame was its deep integration with its powerful search capabilities, but that has so far not been compelling enough to gain momentum to challenge Facebook and Twitter.  Google+ is now adding business collaboration features to gain business users (and most likely to intercept momentum of Microsoft's acquisition of the business social networking site Yammer).

Even when you have a solution and the backing of a mult-billion dollar tech company, you will still need to be agile, adaptive, experimental and continuously iterating to find the right application to your solution!  The Google+ example clearly highlights this dependence.

In line with my recent postings about Agile/Scrum being deployed outside software development, here's a TED video about a sports car called "Wikispeed" that was built and deployed using Scrum and crowdsourcing:

As further proof of this movement in the auto industry, I saw this job posting on GM's job site for an Agile Coach/ScrumMaster position.  It does a fairly good job of describing the position that is in line with Agile/Scrum practices:

The agile coaching team is a core part of the GM IT transformation to deliver software faster, and with strong business focus. The team of agile coaches supports this historical transformation by developing agile best practices, providing training and active mentoring on projects. We are the “How To” team for Agile development... 

I’ve written numerous blogs here about Agile practices and methods that go outside of software development such as my recent one about the government adoption of Agile, to orchestras that are run without conductors, and even baby planning using Scrum.  Another example I just found is an article about how the news radio channel NPR is using Agile, to develop and release radio programs faster and cheaper.