PMI and Kanban

How are you? My name is [author] and I'm a writer for PM Network magazine, the official publication of PMI. I'm doing a piece about e-kanban systems and their role in Enterprise Resource Planning (ERP). Would you be interested in doing a quick interview?

So begins my hope of spreading the positive impacts of Kanban in a PMI publication, only to feel betrayed.

Let's go back a few years

Back in 2009, when I was first learning about Kanban, I saw both David Anderson and Jim Benson write about AgileZen on their blogs.  That's when, in addition to using a physical Kanban, I started using AgileZen to manage my personal work.

Fast forward to June 2010

After reading David Bland's blog post about creating virtual story boards with Google Docs, it inspired me to create a DIY virtual Kanban. What I discovered was, yes, you can do it.  But, why would you do it when a physical Kanban works so much better?  For me, it's all about visualization and simplicity.  If you're dealing with distributed teams, in addition to a physical Kanban at each location, I would recommend using AgileZen to bridge the 2 physical boards.  AgileZen is my personal preference.  It's clean, it's easy to use, and it's free if you only have 1 project.  I never used my Google Docs hack because it was too easy to use a physical Kanban and AgileZen.

Now fast forward to just 2 months ago

A writer for PM Network magazine writes me, asking to interview me.  I agree and we spoke at length by telephone two times.  During the first interview, I got the impression that he had not used Kanban before.  He didn't get visualizing workflow. He didn't get limiting your work in progress.  So, I threw out my L.A. Freeway analogy and related it to activities at work.  The author had done research about JIT lean manufacturing but I got the impression he was unable to bridge the gap on how he could apply it to his world.  I couldn't understand why he kept pushing the virtual Kanban.  Because I wanted to answer his questions, I said he could go so far as to do it in Google Docs.

A few weeks passed and I was contacted by a research editor.  She said she was fact checking and also wanted a high resolution headshot and introduction to include in the article.  Her "facts" surprised me.  What the author had written was sending the wrong message!  He was pushing the Google Docs (hack) and not AgileZen.  He clearly had not even tried the Google Docs hack, based on what he wrote.  The last sentence made me cringe.

...but you have to see if this will work with your culture before you try implementing it, even for yourself.

No, what I said was, you can leverage Kanban on an enterprise level, like for portfolio management, but you need to verify if this approach will be accepted by the organizational culture.  It doesn't even make sense to say "...even for yourself".

I sent back edits to what she provided.  The following is my additional responses to them.

Is there a way I can proof the entire article?  I've been leveraging Kanban for several years now.  Based on a few of the edits I made, I have a few concerns.  Though I don't want to take anything away from [Author], I want to ensure your readers get the highest quality and most accurate information possible.   To be clear, I recommended AgileZen, hands down as the virtual Kanban of choice.  But, IF you wanted a (very limited) DIY virtual Kanban, then you could do it with Google Docs.

I finally picked up the phone and called them.  I stated, if I could not proof the entire article or could not be assured my changes would be incorporated in full, I did not want to be associated with the piece.

Yesterday

I received my March copy of the magazine.  On the front cover, I read "Kanban goes digital".  On page 66 and 67, I find that I am quoted but with no introduction as a technical contributor or headshot.  To set the record straight, I didn't choose the images used in their article nor did I write it.  I am merely quoted.

...and this is why I write my own blog and tweet.

Will Agile for Food

Will Agile for food

By close of business yesterday, we lost 10 people. No, we didn't lose 10 resources. We lost people.  They came to work every day, doing their jobs, thinking they provided some kind of value to the organization.  Unfortunately, some saw the costs outweighing the benefits.  The positions have been eliminated.  I get it.  Business is business.  Times have been tough, even for the Federal Government.  Everyone has to tighten their belts.  Even with the Reduction In Force (RIF), we're still dealing with a very probable government shutdown in a week.   I'm in a weird situation here.  This is the first time I've been the one who survived the first round of a RIF.  Some 20 years ago, I worked for McDonell Douglas.  In one day, over 10,000 of us got RIF'd (lost our jobs). At that time, the organization didn't care who you were.  The longer you had been with them, the longer you lasted in a layoff.  It actually made me quite angry.  The union members who had been there the longest, who did the least amount of work, got to keep their jobs.  The newer employees were the first to go (LIFO).

I think I understand the government's approach to this first round.  The "positions" eliminated were too specialized or too generalized.  Either the person only took notes in meetings or only dealt with risks, only dealt with EVM or only wanted to work part time.

Though I'm the only one here who has any background with Agile, perhaps that was to my benefit.  I think I'm still here because I made it my business to know as much as possible about what was going on, on a Program level.  I stepped up at every turn to see if I could help with something, regardless if it was my specialty.  I could wear a Product Owner hat if asked or switch hats between a ScrumMaster and a Project Manager.

But, I can't help but feel that my time here is coming to an end.  In one day, the culture has changed.  In one day I went from servant-leader to job counselor.

If the right opportunity comes along, where I can help people deliver more value or increase Agile adoption, I will certainly consider it.

Like the drawing?  Get the original one from Pictofigo

Brooks' Law

I was looking for something on the SEI website and came across a piece about Brooks' Law that caught my attention.  Brooks’ law is a principle in software development which says that “adding manpower to a late software project makes it later”. It was coined by Frederick P. Brooks, Jr. in his 1975 book The Mythical Man-Month.  You may have already experienced it but never put a name to it. I would fall under that category.  I've seen Brooks' Law happen first hand but didn't know it had a name.

The vendor was doing predictive versus adaptive planning.  They did a very poor job of estimating.  Since the customer accepted the estimate, it was just a matter of time that the house of cards would come crashing down.  As time progressed through the period of performance, we saw the vendor reach each milestone later and later. (They were following a waterfall approach)  At each status meeting the vendor was pressed for an answer to the question of how they were going to recover the schedule.   When it was painfully clear that the vendor could not complete the scope of work (within the alloted time), even if they convinced their people to work nights and weekends, they proposed to bring on more people to take care of the backlog of work.  That's right, they were going to bring on a small army with no experience with the customer, the program, or the product.  They were going to blow the budget, in the hopes to recover the schedule on the currently agreed upon scope of work.

One stakeholder was very candid when he said, during a status review

It sounds like the plan is to throw as much [something] at the wall as you can and see what sticks.

It's rather sad that the vendor looked at this as such a simple equation.

Team A (Input) + Team B (Input) = Team A + Team B (Output)

In reality, the equation looked more like this:

Team A (Input) + Team B (Input) = [(Team A * .75) + (Team B * .50)] Output

Have you seen Brooks' Law on your project?  What was the outcome?

Agile Certification Survey Results

Fewer people fear change more than a traditional Project Manager.  Should I add Agilists to that list as well? Well, now it's time to accept the facts.  Though some of us in the Agile community knew this certification was in the works for quite some time, it seemed to take some by surprise.  Though I don't know if the results of my survey could be considered a representative sample, it is what it is.  I only wanted to ask two questions.  Will PMI adding an Agile Certificate be good or bad of the traditional Project Management community and will it be good or bad for the Agile community?  I think the only other question I would have asked was do you consider yourself traditional or agile? As I attempt to read the tea leaves, I looked at my survey results and realized there was a relatively mixed response.  There were no outliers.  I'm just going to publish my findings and let others prognosticate against it.  Though this may not be a correct statement, this is how I see it.  Those with the will and the money have the voice.

The Will

First, you have to want something.  I think PMI sees Agile, not as the future of project management, but rather it recognizes it as a viable practice. On PMI's homepage, they state their mission:

We serve practitioners and organizations with standards that describe good practices, globally recognized credentials that certify project management expertise, and resources for professional development, networking and community.

PMI can't rightfully bring the Agile community completely into the fold, unless they offer a certification.  Because the Agile community has not yet offered its own certification, now would be a perfect time to develop one.

The Money

PMI brings in some serious revenues.  First, there is revenue from the membership fees of over 340,000 members.  Add to that the money made for renewal fees of the over 400,000 PMP certifications and you have a nice revenue stream.  For the sake of brevity, I'll stop there.  The Agile Alliance, on the other hand, basically has the Alliance membership fee.  I have yet to find publicized data on how many members they have or if they have any other main revenue streams.

The Voice

I honestly do not believe PMI is an evil empire or that there is some kind of plot to destroy or pervert Agile.  Hell, some of the best and brightest from the Agile world are involved.  PMI sees an opportunity and they are seizing it.  By offering the APP certification, they just purchased a huge megaphone.  This booming voice will aid in a much more rapid adoption of Agile, compared to allowing it to continue its current organic growth.

APLN DC with Lyssa Adkins

Lyssa Adkins at APLN DC

Last night I attended the monthly Agile Project Leadership Network (APLN) DC event. Once again, the organizing team was able to get a really great guest. The guest last night was none other than Lyssa Adkins, known in Agile circles as an amazing coach and inspirational force. She's also the author of the book Coaching Agile Teams (link goes to Lyssa's website ).  Lisa's presentation was titled "What is an Agile Coach, Really?" Listening to Lyssa made me think about where I am and where I want to take Agile with my current or future customers and teams.  She stated during her presentation

Excellent agile coaches know how to help their teams get more and move from the mechanical application of agile into a world where teams deepen their experience of agile practices and principles and then go further, to take up their deliberate and joyful pursuit of high performance.

Yes, you read the right "deliberate and joyful pursuit of high performance"

A big shout out goes to David Bland, Richard Cheng, Manoj Vadakkan, Max Keeler, Nimat Haque, Dave Nicolette, and all of the others in the DC area who came out last night, had some pizza, and talked Agile. You don't realize you're part of a tribe, until you come to an event like this and see those familiar faces.  

Teaching Agile to a 5-Yr-Old

If you ever thought it was too early to teach your children Agile terminology or good management/leadership skills, you can stop now.  I wanted to teach our 5-year-old son a few new concepts.  If you can teach a 5-year-old, you should be able to teach a 45-year-old....right?  Well, let's not get ahead of ourselves.  I actually think kids grasp these concepts better than adults.  They don't have years of baggage to contend with. Now, let me preface the bulk of my post by saying, that at age 5, I could not read at all!  I think our son's teacher has done an amazing job of getting the kids in her classroom reading at the level they do.

So, what is our goal?  Our son's Kindergarten teacher sent home a "by the minute reading log".  She identified how many minutes of reading she wanted each student to read in a month.  For February, the target was 50 minutes.  At first, our son acted very overwhelmed.

Oh Daddy, 50 minutes is SO much!

I assured him, he had a whole month to get there.  Let's call this month a timebox.  In the timebox, the teacher wants you to finish as many stories as you can in the time given.  That's it!  Now, some stories are going to be harder than others.  But, let's focus on doing a little bit at a time and getting each story done.

To really understand the complexity of these stories, they were written for a 5-year-old.  They only take about 5 minutes to read.  So, each story will equal 5 minutes.  To make it fun, let's use story points instead of minutes!

story_velocity2

The last concept I wanted him to grasp was velocity.  Velocity is the number of story points we can get in the timebox.  Just know, you don't get credit if you don't finish a story!

feb_reading_log

If you look at the "reading log" image, you'll see our actual total velocity was 120.  The stakeholder in all of this, his Kindergarten teacher, would be happy if our velocity was a mere 50.

What was really exciting was telling our son, by the end of week 2, that he had met his goal.  If the stakeholder is satisfied with the 50 point velocity, I think we will start having a FedEx Day once a week.  Just like my teams, I don't want to burn him out.  We need to find a balance and a stable velocity everyone can be happy with.

Imagine if this was you and your team.

PMI Stats for Jan 2011

The January 2011 Project Management Institute (PMI) statistics are in.  The PMI now has over 417,475 active Project Management Professionals (PMPs) and 340,232 members. So, what's new? We have a new certification announcement! In the event you were living in a cave for the last week, PMI announced the introduction of the Agile Project Professional (APP) certification.

With the announcement of the APP, I empathize with those people out there with PMI certifications other than PMPs.  I feel like they've kind of been left in the lurch.  If you sum all of the "non-PMP" certifications for the month of January, there were only 246 recieved.

I added the APP to the chart, merely as a placeholder.  But, I do not doubt that it's going to be PMI's new shining star, as soon as they make it available.

January 2011 Totals: Active PMPs: 417,475 PMI Members: 340,232 CAPM: 13,464 PMI-RMP: 622 PgMP: 521 PMI-SP: 418

Source: PMI Today

Parkinson's Law

When I was growing up, I was told the bigger the goldfish bowl, the bigger a goldfish would grow.  Keep the bowl small if you want to limit the goldfish size.  Thinking back, it's a pretty good metaphor for my understanding of Parkinson's Law.  The saying "Parkinson's Law" was first coined by Cyril Northcote Parkinson in his essay published in the Economist way back in 1955.

Work expands so as to fill the time available for its completion

This is what I see happening when developers or others have not decomposed their work to small enough chunks, in order to properly estimate their work.  The same goes with meetings if people don't stick to an agenda.

Yesterday, I saw a (vendor's) manager trying to break the Parkinson's Law.  Granted, I shook my head at his proposal but I admire the fact that he knows there is a problem and is trying to do something to correct it.

This manager has provided a (non-resource-loaded) schedule that has activities planned to conclude on September 30.  The customer is not happy because new work of higher priority has appeared since the vendor provided their 5,000 lined schedule, several months ago.  The customer does not have more money it can commit to new scope and they are unwilling to drop scope from the existing timeline.  Yes, we all know customers do this.  So, what was the vendor's proposed solution?  Going forward, all estimates of work (previously identified and baselined in the schedule) will now have 10% less time to complete. Since they never allocated any slack for activities in their existing schedule, this will become their schedule reserve. Don't ask me where they got 10%.  Tada!  Now they have time to complete more work.  Oh wait, you mean they shouldn't use schedule reserve in that way? No, they should not! And they shouldn't look at management reserve in that way either.  I know some out there are going to have a heyday with this.  It's not up to me.

I have to say, the vendor has done a very poor job with their predictive planning.  But who is to blame them?  It's not easy!  I've found adaptive planning to be much more accurate. That 5,000 line schedule was out of date the day it was published.  When I first looked at their estimates and later at their schedule, I new the efforts were grossly over-estimated.  But, both the estimates and schedule were accepted by the customer.  I do think the customer will now get more value for their money.

I got a kick out of the manager's response when someone in the meeting challenged him on the probability of people being able to complete the work in less time.  Though I'm paraprasing, his response was

It's surprising, if I tell people to have their work finished by Friday COB instead of Monday COB, somehow they just seem to get it done.

That is a clear indicator that people on his team did not do their own estimates and the original estimates were more on the level of a rough order of magnitude (ROM).  If it was my team, and I had made the same proposal, I would have had a revolt on my hands.  The difference here is my team estimates their own work, within a few weeks of actually doing the work, and we ensure the work is in small enough chunks that the customer can see something of value in a very short period of time.

What kind of goldfish are you?

1. Small goldfish in a small bowl? (small group, small timebox, small deliverable)
2. Small goldfish in a big bowl? (small group, big timebox, big deliverables)
3. Big goldfish in a big bowl? (big group, big timebox, big deliverable)
4. Big goldfish in a small bowl? (big group, small timebox, big deliverables)

Image: PPT Presentations