Is Santa Agile?

Tony Askey of Post-it Projects asked  "[Are] Santa's elves using Kanban in the toy shop!!?? I can see it happening.  But doesn't it sound a little disturbing hearing about Santa controlling his WIP?  What are the elf labor laws like at the North Pole?

Brian Bozzuto at Big Visible asks, does Santa draft his "naughty and nice" list up front and implement change control or is he Agile?

I hummed a few bars and thought "Making a List, Checking It Twice..."  My answer: Santa isn't necessarily using any kind of Agile process for this.  I do think it's a draft.  He created the (draft) list, it's tested.  Since the song says he does it twice, perhaps he is doing both a unit test & acceptance test.  Once the list is baselined, I bet he does use change control.

Brian's response was then: If he's checking his list twice, why doesn't he automate?

Oh man, I think Brian has just stumbled onto something.  If Santa isn't using automated tests, I bet he's delivering a lot more presents to kids who should be getting coal.  I think the automated test scripts should be ran daily, right up to deployment.  Even if Santa is not doing automated testing, he should be leveraging some kind of automated deployment. Seriously, you think Santa should delpoy all of those toys around the world in one night without some kind of automation?

Though you don't think "Lean" when you think Santa, the guy has be to be leveraging some kind of Agile processes.

Agile Shopping List

I was over at the AgileScout website and found a humorous post. The title was Agile Products for Sale - What's Worth Buying. Eric Laramée from Agile Partnership made a comment and got me thinking.  Why aren't more retailers jumping on the bandwagon to offer "Agile" products?

What got us started was a listing on Amazon for a ($12.50) pack of 50 pack of Story Cards. Now, I'm not going to say anything bad about this product. I actually think it's clever they are offering a product like this.  Those who have been doing Agile for more than one iteration probably have multiple packs of ($1.95) 100 pack 3x5 index cards sitting on their desks.

In no particular order, here is a list of "Agile" products I found on Amazon.  Yes, all of these links are going to an Amazon affiliate account.  I figured I would give it a try.

Agile Shopping List

• Index Cards, 3 X 5 Inches I have 3x5's in my pockets, in my desk, on my desk...
• White Dry Erase Board The white board at my desk is used as my personal kanban.
• Pomodoro Timer I opted for the piggy timer because I have skin in the game
• Post-it® Notes I love my post-it notes!
• CoffeeYou can never have enough coffee or Mountain Dew around the office
• Lysol Disinfectant Spray If you work in an open workspace, you need this

Not on Amazon, are Mountain Goat Software planning poker cards.  What can I say, I love these cards.

So, what's on your Agile shopping list?  Feel free to add a comment.

Like the image?  Find them at Pictofigo

Agile Traffic Analogy

The post today was brought to you by... my hellish commute and those in the Washington DC metropolitan area who help create it.  Thanks! Today, I'm going describe Agile concepts by using my commute as the analogy.

Goal

During any given day, spend as much time working or at home and as little time commuting as possible.

I'll write a User Story because I'm weird like that

As a project management advisor to a government PMO, I want to travel 55 miles in the shortest period of time so I can spend more of my life delivering value than wasting time sitting in traffic.

Predictive Approach

How long will it take to drive 55 miles to the office in the morning and 55 miles to my home in the evening?  We've all had to estimate our commute time.  Sucks, doesn't it!?  We're all terrible at estimating.  Why?  Things change...constantly!  You can spend as much time and energy as you want, trying to think of all of the possible scenarios.  You can break your commute into "chunks" and estimate those.  That could give you a better estimate, taking into account variances in each leg of the commute.  But, until you get on the road and actually start your commute, you just don't know.  We've got weather we need to deal with.  We've got that knucklehead in the far left lane, driving 10MPH under the posted speed limit (with his blinker on).  We have to deal with the occasional traffic accident.  Work on a project is no different.  You can try to estimate your time, up front, but when something happens (notice I wrote WHEN not IF) your original estimate is going to be wrong.  What are you going to do?  Are you going to try to make up the lost time later in your commute?  Is something else going to be sacrificed like hours of work or hours at home?

Do I personally think there is a more accurate way to estimate a commute, as the commute happens?  Yes.

Adaptive Approach

This was my Adaptive commute this morning.  My wife told me that the traffic report on the radio stated there was an accident 40 miles into my commute.   Good to know, I thought.  Information is good.  Communications is good.  So, did I change my estimate at that time.  Nope!  Why, you ask?  I was armed with my handy Droid X.  My Droid X has GPS and Google Maps with a traffic overlay.  Now, I still broke my commute down into chunks.  I still had the basis of estimate there.  But, the magic happened after the commute began.  I did see the traffic slow down (on the map) that my wife referred to.  But, the radio was still reporting that the lanes were blocked.  The map indicated that traffic was getting by slowly.  Good to know I thought.  Information is good.  Communications is good.  But now, I saw (on the map) that traffic was stopped much earlier and they were not saying anything on the radio traffic report.  By the way, the radio station only reports the traffic every 10 minutes.  By getting realtime feedback from the Droid, I was able to know when I was going to have take a different route, to bypass the delay. I took the next exit and my commute route and the map refreshed.  I could see, by the map, where I could get back onto my original route.  I actually arrived to the office, 20 minutes from my optimum commute time.  If I had not had the Droid and the constant feedback about the traffic conditions, it would have added a hour.

I still lost 20 minutes.  But that was unavoidable.  But I think I minimized my delays by getting real-time feedback.  I had opportunities to adjust my course based on information.  I was able to adjust my commute estimate every minute, not every 10 or 20 minutes.  If someone from the PMO had called me to ask when I was going to get to the office, at any time along my commute, I could have given them a pretty good estimate.  But that telephone call isn't necessary.  Here comes the kicker.  I share my location with Google Latitude.  They can see where I am at any time.

Here are some things to think about for your next commute

• Know where you are and where you want to go
• Break your commute into chucks
• Get traffic conditions as often as possible
• Be prepared to change direction
• Be prepared to reestimate your time of arrival, the closer you get to your destination
• Give people a way to know your location so they don't have to ask you every 5 minutes
• Feedback is good
• Information is good
• Communications is good

Like the image? Find them at Pictofigo

Zombie Culture

How do you refer to your company or team culture?  Do you refer to yourself and your immediate team as "we" or "us" and to your company or extended team as "they" or "them"?  If you do, do you think this is a problem?  I do. For arguments sake, let's refer to you as a non-zombie and we'll refer to your extended team or company as the potential zombies.

Though it was fun back in the 5th grade to play a game of tug of war with your classmates, it's not so cool when you're working in a corporate environment.  Projects can be challenging enough.  You shouldn't have to be distracted by other groups who don't have the same high level goals or values as yourself.  You should be working as a team in order to be successful.  But, does your team or company have clearly defined goals or values?  I'll ask it a different way.  Does your team or company have them written down; you know what they are; and you know what they mean?  If not, you and your group are at risk of being part of the zombie culture.

Zombie culture is a lot more common than you might think.  Zombies have no specific goals, other than to eat your brain.  They're not trying to make you a zombie.  Becoming a zombie is merely a byproduct to having been bitten by the undead.  They really don't care.

I've said before, don't do something unless it's applicable to meeting a goal.  But I bet you're asking yourself right about now, "Derek, if my coworker doesn't smell like rotting flesh or isn't squatting in a corner knawing on a foot, how do I know they are a zombie?"  I've compiled a list of a few indicators of zombie culture.

Zombie Culture Indicators

• Hosts meetings...long meetings... several of them...with no agenda... with several invitees.
• Stops by your desk a lot to ask what'cha doin'?
• Withholds information for personal gain
• Just shows up for work and thinks they are doing you a favor
• Farts (Actually, thinking of a farting zombie made me laugh so I thought I would add it)
• Uses the "cc" email feature by default, when the recipient has nothing to do with the conversation
• Uses the "reply-all" email feature to continue conversations that don't pertain to the group
• Is disrespectful
• Is untrustworthy (with throw you under a bus)
• Does not lead by example
• Tries to impress everyone by how smart they are. (that's a more advanced zombie type)

I can go on and on but I really don't like negative posts.  Let's turn this around.  What values can you and your team have that will have zombies avoiding you like the perfume department of the local Macy's department store?

Values to Repel Zombie Culture

• Deliver WOW Through Service
• Embrace and Drive Change
• Create Fun and A Little Weirdness
• Be Adventurous, Creative, and Open-Minded
• Pursue Growth and Learning
• Build Open and Honest Relationships With Communication
• Build a Positive Team and Family Spirit
• Do More With Less
• Be Passionate and Determined
• Expect to deliver the extraordinary
• Treat others with respect
• Promote collaboration and teamwork
• Encourage creativity and risk-taking
• Make and meet our commitments
• Trust and support one another
• Be Humble

I'm going to admit, I didn't think up those awesome zombie-repelling values.  I got them from Zappos and VersionOne. I'm going to go out on a limb and say I don't think either of those organizations have zombie cultures.  Can you say the same for yours?

Like the image?  Find them at Pictofigo

Outdated Success Criteria

I know this is going to probably get me some "hate" comments.  It seems like if I write about anything but a zombie, that's what happens. But I do like to write about topics that make people stop and think. Think of this post a bridge between a historical project management and futuristic project management.  Let's think about success in both an objective and subjective way.

I'm seeing more and more topics about the measurement of success.  Geoff Mattie just wrote a post over at the PMI Voices site, titled Can Agile Conquer the Physics of the Triple Constraint?

Geoff refers to Triple Constraint and states

The "iron triangle" as some refer to it, defines three pillars: cost, scope and time. It asserts that you have to prioritize the three with an understanding that trying to have all of them at the same time compromises quality.

I applaud Geoff in his zealousness and hope this works for him and hit customers.  Being his blog post is on the PMI website, I want to point out the the iron triangle is not in the PMBOK.  Rather, on page 6, it states

Managing a project typically includes... balancing the competing project constraints including, but not limited to Scope, Quality, Schedule, Budget, Resources, and Risk.

I remember a few years back, when taking the PMP exam, I had a question about typical project constraints.  The answer was not limited to 3 or even 4 "pillars".  So, where am I going with this?

I'm curious why people continue to measure the success of a project, merely on the basis of an iron triangle.  I think this concept is outdated and perhaps created by a project manager to help an executive understand project management at a 100,000 foot view.  I am also curious why many continue to use the Chaos report, (which leverages triple constraint) as the de facto report of industry success or failure.  I am not debating that it has historical significance.  But, I am questioning if it should be the way of measuring project success.

Jeff Sutherland has a blog post about the happiness metric.In his post, he mentions Tony Hsieh of Zappos.  I recently read the book Delivering Happiness by the Zappos CEO.  Again, what's my point?  Perhaps the Chaos report should introduce happiness or customer satisfaction at part of its success criteria.

Too subjective you think?  I think not!

I recently saw a presentation by Sanjiv Augustine as part of the VersionOne AgileLive Webinar Series

One of the concepts presented in Sanjiv's presentation was a NPS (Net Promoter Score) metric.  Think of it as a customer satisfaction or "happiness" metric.

NPS is based on the fundamental perspective that every company's customers can be divided into three categories: Detractors, Passives, and Promoters. By asking one simple question — How likely are you to recommend [Company X] to a colleague or friend? — you can track these groups and get a clear measure of company performance through its customers' eyes.

So, what is the Zappos NPS?  In a YouTube video of Tony Hsieh at the NPS Conference  (1-26-09), Tony said Zappos offered random email surveys that resulted in an 83% NPS and phone surveys resulted in a 90% NPS.  Though they lose money on some of their customers, they are an overwhelming success.

Do you believe the Standish Group Chaos Report should include NPS to define success? Are the original classifications outdated?

(Zombie) Customer Service

I'm currently enjoying Delivering Happiness, the book by Tony Hsieh of Zappos.  In the book, his approach to customer service reminds me a lot of what Seth Godin wrote about in his book, Linchpin.  For those looking to map this to an activity in the PMBOK, I see this falling under Manage Stakeholder Expectations (Executing and Communications).

In any case, I can relate to my intent to communicate directly to people as people, not as mere customers, vendors, or colleagues.  Every day, I see people act as though they have no free will to make a decision.  They ignore what is right or wrong.  They act like they need permission to be honest and humble. They act like...wait for it...zombies!  Yes, zombies!

I recently sat in a meeting and heard how the vendor screwed up.  I'm talking completely-their-fault nobody-else-to-blame screwed up.  When confronted by the customer, their reaction was "I'm sorry you feel that way about [this].  I respect how you feel."

My reaction?  [expletive] YOU, man! I don't care if you respect how I feel or not.  And don't try to feed me that Dr. Phil line about me owning my own feelings!  What I want to hear you say is "I'm sorry we screwed up.  I will do whatever I can to make this right."

Another scenario that comes to mind was my wife contacting a credit card company about something.  The customer service rep was painfully unprepared to talk to a human being.  They could not deviate from a script one word without needed to talk to a supervisor.

Thank you for calling.  We appreciate your business.  Can we interest you in buying our credit protection plan? [my wife complaining] Oh, I'm sorry, can I put you on hold while I discuss this with my supervisor? [5 minutes later....click]

People, you want to provide great customer service?  Empower your customer service representatives.  Vendors, you want to provide great customer service? Empower your teams to admit when they screwed up and offer to fix it, not just cover it up.

I've always seen the best performance from my teams, when they knew what we needed to do but were not being told how they needed to do it.  I believed they would make the right choices for us all to reach our goals.  Those of you in the Agile community get this already.  Empower the team and communicate with everyone as much as possible.  Don't just communicate.  Talk to them.

So, as I step down off my rant soapbox, I want you to take a look at the Zappos core values (listed below). They actually remind me of the 4 values, 12 principles of the Agile Manifesto or Agile community as a whole.

Zappos core values

1. Deliver WOW Through Service
2. Embrace and Drive Change
3. Create Fun and A Little Weirdness
4. Be Adventurous, Creative, and Open-Minded
5. Pursue Growth and Learning
6. Build Open and Honest Relationships With Communication
7. Build a Positive Team and Family Spirit
8. Do More With Less
9. Be Passionate and Determined
10. Be Humble

If you had 10 core values for your project or team, how would you refine this list?

Like the image?  Find it at Pictofigo

---

Know Agile when I see it

I got all fired up today when I read some pretty outlandish statements by a company claiming it "helps through an innovative project management and development tool known as Agile Methodology" and they went on to write "Agile is based on a project management methodology known as SCRUM" I haven't heard something like that since someone told me Al Gore invented the Internet (urban legend). Thank you to AgileScout, who wrote the original post titled Agile is NOT a Methodology.  At last count there were 19 comments linked to the post.  Head over to the AgileScout blog and get caught up.

So, what IS Agile and what is NOT?

To answer that, I’m going to take a little liberty with Justice Potter Stewart’s opinion in Jacobellis v. Ohio 378 U.S. 184 (1964)

I shall not today attempt further to define the kinds of material I understand to be embraced within that shorthand description ["Agile"]; and perhaps I could never succeed in intelligibly doing so. But I know it when I see it, and the project involved in this case is not that. [Emphasis added.]

The fun part is knowing what Justice Stewart was really talking about.

Like the image?  Find it at Pictofigo

Communicating Effectively

When referring to communications and project management, you should be aware of what you do and what you should do.  A lot of issues we suffer from are caused by poor communications.  I can't stress enough how much of a positive or negative impact communications can have your project. What do I recommend you do?  Here is an ordered list of communications methods.  The first on the list is your last resort and the last on the list should be your preferred method.

First up is email.  Yes, email.  For most people, this is their preferred method of communications.  Actually, it should be your last.  Have you ever sent an email that was completely misunderstood?  Did you ever write an email that showed up in someone's inbox it shouldn't?  Has email become a complete time suck?  Well, stop feeding the fire.  Get your butt out of that chair and go talk to the person or people.  Go to the bottom of the list and work your way up.  You last resort is to send an email.  By the way, don't be checking your email every 5 minutes.  It's a compete time suck.  Check it, at the most, once an hour.  Make sure everyone knows you don't check your email that often.  It helps manage expectations and could even encourage one-on-one communications (if it's that important)

---

Our second to last communications choice is telephone.  Yes, telephone.  It's a little better than email.  At least you can sense emotion if you're listening closely.  When communicating, use the senses you have available to get indirect feedback.  Try smiling when you talk on the telephone.  I bet the other person will know you are.  I know telephone calls can really dirupt you flow of work but it's better than someone showing up at your desk unannounced.  Timing of communications is almost as import as the method used.  Try to plan your telephone calls.  Voicemail is nothing more than audio email, as far as I'm concerned.  Make sure you leave your name and telephone at the beginning of the voicemail (and end).  Explain why you are calling.  Don't just say you'll just call back.  Voicemails are fragmented and can easily be taken out of context, if the relevant information is not included.

---

Next on our list is video-conference.  If you are working with distributed teams, video-conference is a really great way to communicate.  One-on-one communications is still our primary choice but this is a very close second.  As technology advances, so do our efforts to have good meaningful exchanges.  A picture is worth a thousand words and so it being able to look your colleagues in the eyes (or at least see their face).  When talking with someone, I believe body language communicates a lot.  Video-conferencing also allows a much more rapid exchange of "visual" ideas.  Image putting you hands in the air and saying "the fish was this big".  Now imaging trying to communicate the same idea via telephone or email.  Need I say more?

---

And so we arrive at my primary choice of communications... face-to-face talking.  Lisamarie Babik and Menlo Innovations refer to this as High-Speed Voice Technology™. When is doubt, get up out of your chair and into the face of another person.  Remember, the things you say and the things people hear are not always the same thing.  You can’t have agreement until the thing you say and the thing someone hears are the exact same thing.  So, what is a way to help ensure someone hears what you intended them to hear?  You need to ask questions.  The next time you are talking with someone, ask questions so you feel completely confident they heard exactly what you wanted them to hear.  Once you make it past that, things should go much smoother because you’ll both be seeing eye-to-eye.  Try that with email sometime.

Just because I'm advocating face-to-face communications, I'm not saying you should be having more meetings! Do what makes sense.  But, let's say there is going to be a meeting?  When inviting people to your meeting, choose High-Speed Voice Technology™ first and then move on down the list.  Imagine having a daily 15 minute meeting with 5 people.  Now imagine what you would do, and the level of effort and complexity, if you couldn't all meet in person.  It should make you appreciate a face-to-face talk just a little more.

Like the images?  Find them at Pictofigo