Ok I know I promised that I would post some videos. I am working on it. It has been a crazy week at work this week. We had forecasts due and this month they asked that we get as accurate as we could get on the 2011 forecast.
We did our best but our Capital vs. Expense was way out of whack. We found though that Project accounting had posted a lot of items as Expense that really should have been capital. We found about 150K in just May and June. For the next round we will do January through April and I hope to reconcile our Expense budget.
In addition the developers on the project are being poached by other projects. It really seems odd to me that anyone would dare take my resources. Yes, their projects are important but if my project is not successful, the company will go under, end of story. So…”Let my people go!”

Let’s see, what else. Well We had a no-holds-barred open and honest conversation about our project status.  Which of course was bad. Why is it that no project is ever in good shape when you ask for the honest assessment? (I am doing a video post on that)

At any rate. It has been a heck of a week.  I will try to do my video posts very soon.

Peace

Jospeh

What would happen if we took agile Values, Principles and Practices and applied them to the PMO?  In this podcast you will hear how Sanjiv did just that.  In this episode Sanjiv shares with us how he has been using these techniques on agile PMO applications since 2002. (published in ACM

Sanjiv Augustine has been an agile thought leader for over a decade, and is the author of: Managing Agile Projects and The Agile PMO: From Process Police to Adaptive Governance (audio CD), discusses the Agile PMO.

More about Sanjiv and his consulting here.

In response to a recent post Alan Shalloway of NetObjectives responded you can read his response here.

His response got me thinking.  Please share your thoughts:

What is it that makes a person, team, project, or company agile?

Agile has been around since the mid 1990s but the principles and values go way back.  As a matter of fact, I believe that the Pyramids were the first iterative development project.

A pyramid, as you may know, is a tomb for a Pharaoh.  We learned this in grade school.  But did you ever consider how they were able to be sure to have the pyramid done when the  Pharaoh died? One theory is that they did it by building the pyramid incrementally. They started with a small pyramid, just a tiny little pyramid.  Then they added a layer of stones around the outside of the first layer, then another, and another. Each layer of stone laid around the next to basically “skin” the pyramid with another layer.  Building this way the Ancient Egyptians could have the pyramid ready anytime.  If Pharaoh died – Viola- The pyramid is ready.

I wish I could take credit for making this observation but I read it somewhere a few years back.  If you know who made this observation first please let me know so I may credit them for their astute observation.

If you lead teams you need to watch this video. Period.

In 2001 a group of programmers wrote the Agile Manifesto later in 2005 a broader group of product managers, project managers, team leadership experts and other wrote the Declaration of Interdependence(DOI), a document with a broader vision than the Agile Manifesto. Alistair Cockburn was one of the original signatories and in this edition I ask him about the DOI.

Read the Declaration of Interdependence here

And

Learn about Alistair Cockburn at Here

http://gallery.josephflahiff.com/podcast/AlistairCockburn.mp3

If you are keeping up with trends in software project management you are likely familiar with the concept of Kanban.  You may have even used Kanban to a greater or lesser degree in your own projects. Although you might not have known you were using Kanban.

Kanban literally means “card.“  In a Lean manufacturing environment A Kanban is used to signal to an upstream provider that the downstream needs to be replenished.  For example: at an automobile manufacturer, when a fender is put on the car on the line, a kanban and empty cart are sent up to the fender shop to replenish the fender supply so that the next car can be built. The Kanban (card) tells the fender  shop what fender to put in the cart and send back to the assembler. This exemplifies a “Pull” system that supplies materials “Just In Time”.

Kanban is being used more and more by software developers and software project managers.  When used in software it is really more the concept than the actual kanban that is applied.  A kanban board is created with multiple columns for each processing step in the process.  For example columns are created for:

Whew that was a really long list. But it represents a summary of the Kanban that I am using on my project.

I like Kanban but I want to be perfectly clear, it is JUST one tool.   Many people today are looking at Kanban like it is another methodology. Since Scrum hasn’t worked for them they are looking to Kanban to solve their problems.  When what they really need is not an other methodology to slap on their development, but a fundamental shift to a different way of thinking.   Kanban is one tool and a relatively small one in the grand scheme of things, in a Lean company.

Like Agile you can implement all the tools of Lean and never really  be lean. You will find some success because both Agile and Lean surface problems and help optimize your organization. But if you don’t go to the core of these management philosophies and change your culture, you will never see the long term results for which you are looking.

Culture change is hard. Let’s explore culture change in more depth.