Remind me again how many software projects you've overseen?

It's probably wrong to judge one's ability to do their job based on how they pronounce a particular word, but I'd like to believe there exists a line at which one's inability to 'talk-the-talk'  should be enough of a red flag to prevent its being crossed. Unfortunately, we tend not to even see the line until it's too late.


Title: Remind me again how many software projects you've overseen?
Snarky: How many is a "jiggabyte"?

But we only have four developers.

I know there's a disconnect here, because the articles I find on the web refer to the fact that PMOs are understaffed and PMs should do less, not that it seems like there's a PM everywhere you turn.  Maybe it's symptomatic of what I'm facing lately and not the wider IT situation.  So instead, go read 100 lessons for PMs!

Snarky: We're adding a fifth PM as there are too few for the current feature allocation.
Title: But we only have four developers.

I see I have four of them today alone.

True story.  I know someone.  I won't say it's me.  Someone else.  Sally.  Her name was Sally N. Body, Team Lead.  See, couldn't be me.  Different name.  Different gender.  He...she...worked very hard to cover the gap left when the project PM wasn't involved in the release management work brokering fixes with the multiple business units, determining final deliverable list, coordinating with testing, ux, mobile, release management, upper management, and a number of other teams.  Not a bad spot to be, but in trying to ensure quality of the release, extending him...her...self a little further than was typical, and definitely stepping on the PMs territory, particularly as the PM couldn't say what was going into the release or what the communication was that was going on after hours.  The PM then scheduled multiple estimation meetings to plan feature work for future iterations that were almost impossible to attend given the time crunch.  Not only creating a time issue for Sally, who showed up, but additional work beyond the estimation meetings related to the business tracking down Sally after the estimation meetings for a full debrief because they couldn't show up to the ad hoc estimation meetings.

Lesson learned, say it out loud, "This meeting shall not come to pass!"  Particularly if the business can't attend.  That's Sally's job as the one who's going to be forced to regurgitate the same meeting several times.  We don't do meetings without the business, because then we have to do the meeting twice.  Or thrice.  By we, I mean Sally, and her team.  Picking up the extra work for the release is fine.  The coach's roll (the lead) expands toward release as the PM's role shrinks (there's a shift in the focus of the roles), so it's natural, and the coach with the technical chops is much better suited to the emergencies arising between layers, but that means the PM should acknowledge that their role is reduced, the team coach's role is expanded, and the meetings have to dovetail other priorities.

The lesson that should be learned by the PM, and anyone in the same situation, a golden business rule of sorts: if someone is making your job easier, don't take advantage of it to make their job more difficult.

Snarky: Thanks for picking up my work this week. It allowed me time to get all our estimation meetings on the calendar.
Title: I see I have four of them today alone.

I said yes. If we move to one day iterations.

I wish this weren't true and a personal experience.  This is what happens when your PMO says they're embracing Agile, but they can't get enough new expertise in the door, or they bring in the wrong, classically-trained, PM expertise, and everything Agile starts to get shoehorned right back into a traditional PMP-driven waterfall/BDUF model that gets all the bad bits of BDUF and none of the good bits (like an actual attempt at a big design - instead you get an "it's only two weeks to worry about" when it's really half a year).  And in the midst of all the confusion, you get the added benefit of trying to replan six months of work over and over and over while attempting to make everyone understand that it's completely unreasonable.  You can just say "I won't do it", and you should, but you have to have the corporate credibility to survive through the finger pointing that you're the only one not keeping up with the planning.

Ishikawa

Full size on Flickr...

* Our PM created an Ishikawa Diagram to show me where our product is going wrong.

Well...this is totally expertimental.  An Ishikawa diagram for the Snarky developer as created by his Project Manager.  I think it probably needs to be absolutely huge to read.  There's not really such a thing as an uncluttered Fishikawa Diagram.  This is what comes of a week in PMP training.  I thought about putting the Snarky developer in the center, but then there wasn't room for text.  And I thought about putting the grumpy thought bubble off the top of the fish, but that just looked like he was trying to breathe and failing and that's sort of sad.  If it doesn't allow click through to view the whole thing in a reasonable size, I'll Flickr it and make it huge and update.

If you're not familiar with Ishikawa Diagrams or Fish Diagrams or Fishikawa Diagrams, a simple search of Google will turn up many examples and Wikipedia has a good article.

Ishikawa diagrams (also called fishbone diagrams, herringbone diagrams, cause-and-effect diagrams, or Fishikawa) are causal diagrams created by Kaoru Ishikawa (1968) that show the causes of a specific event. Common uses of the Ishikawa diagram are product design and quality defect prevention, to identify potential factors causing an overall effect. Each cause or reason for imperfection is a source of variation. Causes are usually grouped into major categories to identify these sources of variation. The categories typically include [Wikipedia goes on to list the categories...]

Featurecreep is a myth

We should get reclining chairs

I think by "mitigation" she meant you...

I hope he doesn't get our strings tangled...

Featurecreep is a myth