pmStudent

I've realized something lately.

Or rather, been reminded of it.

Sub-Optimization Sucks

The only way to acheive a truely lean organization or even a lean project is for the entire value stream to be bought into lean thinking.

Because of this fact, senior leadership in any organization must be fully supportive and invested in moving an organization to lean and agile thinking and process.

My teams are gaining clear benefits from the methods we've implemented with Kanban. However, because we are the only teams running this way, the benefits are also very limited.

Blocked

For example, in some cases my team members need external validation from other teams before we can move a particular feature forward in the value stream.

When those external parties are not bought into lean thinking (single-piece flow, limited WIP, continous deployment) they can very quickly become a block, causing a bottleneck in the value stream.

Pushing For Change

So, I am trying to develop interest from the other teams we interface with. Who knows, maybe I'll be successful in 'converting' them. Perhaps not.

Even better, I'm formulating plans for a method of convincing senior leadership that for our next program, a lean/agile approach is superior to our waterfall SDLC.

We'll see.  Wish me luck.

Tweet

 What level do you track earned value for your projects? Too high is a problem, and trying to decompose work packages prematurely is problematic too. So how do you get the best of both worlds?  Here's how.

I suggest you view this in 720 HD, full screen so you can see everything in the tutorial clearly.  Note: Around 5:30 you'll notice in Step 3 I mis-labeled the last column.  It should be PV (Planned Value) and not EV (Earned Value).

Tweet

Tweet

Tweet

Tweet

One of the videos I've enjoyed recently over at Kanban School is this one with Pawel Brodzinski.

Pawel makes the point that Kanban does not replace software development methodology or project management methodology. I agree.

In the video he said it's more of a change management process (I think that's what he said) and I don't think he meant it quite like that.

To me, Kanban is a method of execution. On my teams, it's about the day-to-day execution and all the benefits that come with the Kanban process for that execution. The visualization really makes continuous improvement possible, almost inevitable. 

So what do you think about all this? If you are new to Kanban, check out Kanban School.

Tweet

One of the things I'm constantly surprised by are project managers and writers who seem to ignore The Mythical Man-Month and Brooks' Law.

"adding manpower to a late software project makes it later" -Fred Brooks

Don't Call People "Resources"

They are people. They make up teams.

I've been guilty of this, but maybe calling people "resources" in your schedules and plans has a negative impact.

People aren't widgits, and teams aren't perfect systems where you can add another widget and get everything done that much more quickly.

I think using the term "resources" instead of "people" may allow tool-savvy project managers to get more and more detached from the reality of their project team and the work to be done.

You Can't Add People Like Widgets

I hear it more often than I would like.

Project managers see a shortfall in the amount of staffing available on a particular part of a project, which is going to cause missing a milestone date.

Then the exclamation "I can just take .2 of an FTE from John Doe down the hall and it all works out on paper!" (FTE = Full Time Equivalent)

Brilliant.

You know, there are some cases where you can do that. Perhaps the person has previous experience with the product your team is developing, or the type of work is generic enough that someone from outside the team can come in and pick it up without training.

But more often this is a big mistake. You are going to leach out .2 FTE from your current team (maybe more with multiple people helping the new guy) in order to get him up to speed.

So unless you are going to have a long-term commitment from a new team member and have considered the time and effort involved with bringing someone up to speed, their lowered productivity level until they are fully immersed, etc. don't even think about adding new staff.

Especially not temporary staff.