Don't Stand in Line for Mediocrity

Drink CoffeeI had 5 minutes to spare, so I walked into popular coffeehouse to grab a quick cup of joe.  I didn't want a mocha-latte-hooya-watcha-ma-call-it. I wanted a good cup of black coffee. I saw a line 5 people deep. I stood there for about 30 seconds and then turned around and walked out.  The image the coffeehouse wants to project is that they are this hip place where the popular and successful are seen.  This image is greater than the taste of their coffee.  The reality is every person and their grandmother walk through the door buying into the lie.  More importantly, the coffee isn't that good. It's actually pretty mediocre.  I'm glad I walked out the door. Life is too short to stand in line for mediocrity.

Judging an Agile Book

I'm in Grand Rapids, Michigan, to speak at the Great Lakes Software Excellence Conference.  If you ever imagined what an "Agile" company looked like, I think I am looking at it right now.  I'm blogging today from Atomic Object.  The exterior of the 100 year-old building is very unassuming.  Upon entering the building, I'm greeted by several dogs.  Yes, like in man's-best-friend dogs.  They give me the once-over and allowed me to pass.  I walk past a wall with mountain bikes and walk upstairs to discover a truly Agile workspace.

The floors are a light wood and the workspace is wide open.  There is plenty of natural light.  In the middle of the room is a functioning stop light.  It's exactly what I thought it was.  It's an information radiator to indicate if the build is broken or not.  Fortunately, the light is green.  I'm now sipping on a freshly brewed cup of black coffee and enjoying web access.  There are almost as many whiteboards as there are approachable friendly people.

I know you should not judge a book by its cover.  But, if I'm looking for a book on Agile, I would have a few expectations.  This place and the people working here exceed those expectations.

When I return to Washington DC tomorrow night, I'll take with me the first hand confirmation that Agile workspaces (and companies) are so much more inviting than those with cube farms or offices.

Agile is in the PMBOK so it must be true

Yesterday, I was having coffee with Jesse Fewell and we discussed, among other topics, how the PMP® or Certified ScrumMaster (CSM) credentials legitimize many in the eyes of stakeholders. This is a sore spot for many, particularly for me.  Experience and project leadership trumps a certification any day of the week.  But, for those of us who believe we know what we're talking about, a credential is sometimes a necessary evil.  As I advise a Federal PMO on a multi-year project, I have grown to accept that progress can be slow and expensive. Things can be so slow and expensive, we rarely get to see actual value delivered.  Rather, successes are measured with earned value. Sometimes, I think it's just the nature of the beast. But, it doesn't have to be that way.

You can only imagine my excitement when a vendor proposed using Agile to deliver the next (year) software increment. The PMO I advise has many PMPs but only one  I'm not going to go into the details of the project.  But, how could the opportunity be seized to leverage Agile?  Rather than answer that directly, I'll ask a question.  If you believe in the Agile Manifesto, how would you convince people with no experience with Agile or Scrum (but lots of experience with the PMBOK and Waterfall) that you know what you're talking about and that Agile is a viable option? I would propose that you make sure you can communicate with stakeholders in a language they understand. If you start using terms like Sprint, ScrumMaster, and Burndowns, when they understand contract periods of performance, project managers, and EVM reports, you may lose that essential stakeholder buy-in.

One of the first things I would recommend you say is "Agile is actually in the PMBOK". If your stakeholders are PMPs and they believe the dogma of the PMBOK, you'll have their attention. It's not called Agile but it is there. In Chapter 2 (Project Life Cycle and Organization) of the PMBOK, you'll read about Project Phases, specifically phase-to-phase relationships, and then even more specifically the iterative relationship.

...only one phase is planned at any given time and the planning for the next is carried out as work progresses on the current phase and deliverables.  This approach is useful in largely undefined, uncertain, or rapidly changing environments such as research , but it can reduce the ability to provide long term planning.  The scope is then managed by continuously delivering increments of the product and prioritizing requirements to minimize project risks and maximize product business value.  It also can entail having all of the project team members (e.g. designers, developers, etc.) available throughout the project or, at a minimum, for two consecutive phases.

For the Agile pundits out there, does that sound a little familiar?  For those who believe the gospel of the PMBOK, is it reasonable to believe Agile is an approach that can be considered?  Agile is not a bunch of voodoo for the wild and undisciplined.  It's an excellent opportunity to deliver value.

Why You Should Use Common PM Language

I don't normally drink coffee from Starbucks but someone gave me a gift card.  I like black coffee, with no cream or sugar.  I like my coffee fresh so I order a small size.  So, why on Earth did the person behind the counter not listen to me? I ordered a small Caffè Americano. For those who do not drink coffee, that's nothing more than a small espresso and water.  My expectation was I would get a small cup of coffee.  When I looked at my receipt it said Tall.  I brought this to their attention and I was dismissed.  "Oh, it's the same thing."

Well, no, it's not.  Line up the cups and this is what you will see.  Extra-Small, Small, Medium, Large, and Extra-Large.  What does Starbucks call them? Tiny, Small, Tall, Grande, Venti. So, what I got was a medium.  I'm not going to split hairs here.  I'm trying to make a point.  There needs to be a common understanding between the vendor and the customer when you both define the same thing differently.  This is a financial transaction.  I want what I paid for.

How does this apply to Project Management?  From the customer's perspective, what is the definition of done.  From the vendor's perspective, what is the definition?  From every stakeholder perspective, do you all have the same definition of done?  You should!

It's important to note, it doesn't matter which approach you use.  Waterfall, RUP, Agile, or Kanban.  Everyone needs to understand and agree to what done means.

My Caffeine Fueled Rant

People who know me know that I drink a lot of coffee.  I'll drink it hot.  I'll drink it cold.  I'll drink it from the pot, 9 days old.  OK, not 9 days old.  That's just gross.  One of the places I like to drink coffee is a diner.  9 out of 10 times, diner coffee is good.  It's simple, it's basic, and...did I say it was good?  Don't tell me it's organic, fertilized with bat guano from El Salvador.  I really don't care.  The other think I like?  It's usually $1 for endless refills, printed with pride on the menu. This post isn't about cheap coffee.  It's about a pet peeve of mine.  It applies to me ordering drinks at a restaurant.  Here comes the rant.

Today, my family and went out for lunch.  At the restaurant, I plainly saw the prices for everything on the menu but one thing.  Beverages.  Yes, drinks.  Where the hell are the prices for the drinks?  Is this some kind of trick or tactic? Am I to be embarrassed by the fact that I am unwilling to pay $3.00 for a fountain soda or $8 for a beer?  Chances are, if you don't post the prices for your drinks, I'm going to order plain old tap water.  Screw you and your clever lack of information.  It's not my job to ask you how much my drink is going to cost.  You are providing me with a service and that includes prices for the food and drink I'm willing to have with my meal.

If you leave the post at that, I think it stands on it's own.  If you want me to put a project management spin on it, here goes.  If you are a vendor, and you're doing contracted work, don't make your customer ask.  I hate the big reveal.  If you're going to do contracted work, and you fail to inform your customer what the cost is going to be, you should eat it.  Yep, eat the cost.  Why?  Did you promise to throw in a pair of Ginsu knives when you delivered that product?  I'm going to go out on a limb and say no.  Then why would you expect a customer to give you more money for services rendered or product delivered?

I know there are always exceptions.  What if you, as a vendor, don't know how much it's going to cost?  That's fine.  Communicate with your customer.  Treat them like the intelligent beings they are.  They were smart enough to hire you, right?  Then keep them informed and guide them through the options.  Don't sneak that $5 cup of coffee onto the final bill and expect a 20% tip.

Takeaway? Vendors:  Keep your customers informed and don't make them ask. Customers:  Don't let vendors get away with the big reveal.  It will just leave you feeling short-changed.