Plan to Fail

We live at a lake property so we're pretty far in the sticks.  We have an HOA, which contracts work for snow removal and stuff like that.  Last year we had several snow storms in the Washington DC area.  The HOA was not prepared for several snow storms in succession and we found ourselves stranded for 4 days.  Yes, 4 days!  But, it wasn't all bad.  After the first storm got us, I reached out the HOA and recommend they keep the community informed of what was happening.  Though we may not see a plow for a day or 2, we would at least know it.  Each time we had a storm, the HOA got better at informing us of what they were doing. Here we are, a year later.  The forecast was for 6-12 inches of snow.  I was curious if the HOA had refined their communications and snow removal practices from the year before.  I kept thinking to myself.  People don't plan to fail; they fail to plan.

We certainly did get the snow.  It's close to 12 inches.  I left the office early to get home before the snow (thunderstorms) arrived.  As the snow stacked higher and higher, we began hearing reports of people abandoning their cars on the roads leading to our house.  (They clearly failed to plan accordingly)  We even saw one of our neighbors get stuck at the bottom of our hill, blocking the plows from getting to our neighborhood.

So, how did the HOA refine their communications process from last year?  Did they fail to plan accordingly?  To the contrary, I feel they did a great job.  They designated community representatives.  We are encouraged to have an open dialog with them.  The HOA did send out emails informing everyone when the plows were going to arrive.  This year they took it one step further, by creating a feedback loop.  When our neighborhood was not plowed, due to the abandoned car, I contacted my community representative.  Though I had to leave a voicemail, she called me back within 30 minutes.  She assured me our neighborhood will be plowed this afternoon.  Without the feedback loop, they would have not known there were any issues.  And so, our HOA process improvement continues.

Communications vs. Customer Satisfaction

Communications Level	Customer Satisfaction
0-Way (None)	Very Unsatisfied
1-Way (Email distribution)	Satisfied
2-Way (Telephone conversation)	Very Satisfied

---

Blending Scrum and Kanban

Though I frequent the LeadingAgile website, I have to do a little more than just retweet a link in support of this post.  I've known Mike Cottmeyer a while now.  The guy just gets it!  For those who are new to Agile, Scrum, or Kanban, you need to carve out 10 minutes and watch this video.  In his own words, Mike says he 

blends concepts like Epics, Features, User Stories, Story Maps, Minimally Marketable Features, Scrum, Kanban, RUP, and even traditional SDLC to create a scaleable agile enterprise portfolio framework.

I wouldn't doubt that pretty much anyone who watches this video is going to have a light bulb moment. Recently, I've had quite a few people asking me about Kanban. Though I'm excited to tell them what I know and my approaches, Mike does an awesome job of both blending Scrum and Kanban and then communicating the approach in 10 minutes.

Head over to LeadingAgile and read some really great stuff. Also follow Mike on Twitter at @mcottmeyer

Manipulate or Communicate

I'm always looking for ways to communicate with team members, vendors, and customers.  When trying to understand the range of communications, I recently reassessed what I thought the opposite of communications was.  I no longer believe it is silence. Rather, I believe it is manipulation.

2 Examples:

[1] Buying a Vehicle

You go into an auto dealership. You want to purchase a new vehicle.  You want to pay the lowest price as possible and the dealer wants to make the highest profit possible.  Rather than coming to the table and negotiate based on this mutual understanding, both sides try to remain as silent as possible.  Both sides are trying to manipulate the other, in order maximize the outcome in their favor.

[2] Getting a New Job

You apply for a position with a new company.  You are interviewed and the company believes you are a good fit.  As soon as salary is discussed, the manipulation traditionally begins.  Both sides are trying to manipulate the other, in order maximize the outcome to their respective favor.

How it should be

In the case of the auto dealer, they should be honest about their cost of the vehicle.  They should explain how the dealership and sales person will be paid.  They should ask the buyer what their needs and wants are.  Is it cost or is it the make/model (scope)?  The key here is everyone needs to be honest! I'm not a pessimistic person, but with a (sales) relationship like this, I feel there will always be manipulation involved.

When negotiating salary with a new company, the relationship is different.  Hopefully, both parties want a long term relationship built on honesty.  I propose the applicant tell the potential employer exactly what they are currently being compensated, including benefits and bonuses.  The applicant should explain their motivation for seeking new employment.  Were they being paid too little; Were their benefits too expensive; Was their work/life balance all out of sorts?  Was the previous job just unfulfilling?  The new company should take this into account before making an offer.  They should explain the range of compensation to be offered.  Both sides need to be frank and honest. I recognize this is one of the most uncomfortable conversations you ever have.  That's why I believe both sides should be honest and over-communicate.

How it applies to a project or program

In the previous two examples, both involved negotiations and communications.  From my perspective, these can all be win-win scenarios if we are honest and over-communicate.  Over the weekend, I participated in a live web interview with Peter Saddington from AgileScout.  I stressed the need for over-communications on projects and gave 3 examples on how to do it.  You can over-communicate by using information radiators, daily stand-up meetings, or by having an open-door policy (with rules) with other meetings.

Information Radiators

Use burn-up, burn-down, kanban, or task boards in both executive work areas and team work areas.  I would recommend displaying enterprise (program) level information where all of the executives can see it.  I would recommend displaying team (project) level information where all the teams can see it.

Short Feedback Loops

Have daily stand-up meetings for each of your teams.  Have daily "scrum-of-scrum" or "team-of-team"  meetings to roll information up to an enterprise level.  There is no excuse for anyone to NOT know what is going on every day.

Open Meeting Policy

For all of your meetings, have some simple rules.  Understand that some people are allowed to talk and some are only allowed to listen.  But, all should be informed.  Now, I recognize not everyone should attend a Retrospective meeting or Executive Board meeting.  But, everyone should know what the outcomes are.

Let's face it, the enterprise wants to get as much productivity out of its employees as it can, in order to reach its tactical and strategic goals.  In order to do that, you need empowered teams who trust each other.  You need free-flowing communications.  I'll say it one more time. Be honest and over-communicate.

Web Interview Retrospective

Today, I was the guest for a live web interview with @AgileScout.  I'll admit, I'd never done a live (video) web interview before.  I did recently do an audio interview with @tykiisel & @RaeLogan.  I enjoy interacting with people but I usually do it one-on-one.  I rely a lot on audio and visual feedback to steer a conversation.  So, that made both interviews a bit challenging for me.  Since I had no visual feedback for the audio interview, I literally closed me eyes to stay focused.  To help me stay focused during the video interview, I closed all screens with the exception of the one of me on camera.  No, I'm not vain.  I just wanted to make sure I was centered on the camera.   So, let me say, I really enjoyed the interview.  Peter made it seem effortless.  There is a lot going on behind the scenes.  We talked before the interview to resolve technical issues and roughly go over the scope of the interview.  When you watch the interview, know two things.  [1] I was pretty excited and anxious.  I had already drank a pot of coffee.  [2] I was staring at a live feed of myself, not Peter.

ASL002 - LIVE with Derek Huether 2011.01.22 from Agile Scout on Vimeo.

The Retrospection

While we were doing the interview, my wife was in the other room watching the live feed.  After the interview, she said she thought I drank way too much coffee (during the interview) AND I moved around too much.  You know what?  That's not bad feedback!  If she had walked into the room and told me what I was doing (during the interview), I would have probably stopped (drinking my coffee).  Though it would have been a momentary interruption of the interview, it would have been a perfect testament to the need for short feedback loops.  THIS is a perfect example of why you want co-located teams.  THIS is a perfect example of why you have daily stand-ups.

Shorten the feedback loop and you will have less waste and deliver more value.

Thank you, again, to Peter Saddington for being an independent voice democratizing Agile.

Zombie Procurement Strategy

The last few weeks I have been advising a Federal Procurement team as they refine a Procurement Statement of Work (SOW).  Unfortunately, I see the existing version as being very heavy and I want the final product to be much more lean.  A perfect example is the current program has 29 documents that are contractually required to be delivered.   Do these documents provide value?  No, most of them to not.

Opportunity 1

Instead of writing the SOW with statements like "Contract holder will deliver this document" and not provide why or how it will help the customer accomplish their goals, I think we miss an opportunity.  I believe we need to advance the conversation with the potential vendors, by structuring the future work as Epics.  As long as the customer quantifies "reasonable", we give the potential vendors an opportunity to think outside the box.

As the owner of the production system, I want to be able to know the average wait time when a customer calls, so I can ensure they are receiving a reasonable level of customer service.

Opportunity 2

Rather than using practical wisdom to create a new SOW, some would rather rely on past policy, procedures, and governance, regardless of current and future needs or if they ever made sense.  I've challenged some by saying there are no procurement requirements stating that we must have these 29 documents.  One Zombie response was  "I found management plans and documents referred to in the PMBOK.  We should require the vendor to deliver all of them ".

Before I emptied a full can of Zombie Away on him, I said that wasn't the most efficient approach.  The PMBOK also says to use "expert judgement".  If you are not prepared to use expert judgement, a vendor is going to take your Zombie money and walk off with it.  All you'll be left with is an empty wallet and 29 documents.

I'm all for looking to the PMBOK for guidance.  But remember, it is a guide, not commandments.

Like the image? Find it at Pictofigo

2011 Resolutions WIP

Last night I submitted my speaking proposal for the Great Lakes Software Excellence 2011 conference.  The title of my talk is Breaking the Law of Bureaucracy. A little back-story:  One of my "Epic" stories (Resolutions) for 2011 was: As an agile proponent, I want to articulate the values, principles, and methods of the agile community to the traditional project management community, so there will be more mainstream adoption of agile.

What's my acceptance criteria for this Epic?  I must appear (speak) at no less than 4 conferences.  I must write at least 1 article to appear in a trade publication. I must publish my book (Zombie Project Management).

As you would expect, I broke the epic down to multiple (actionable) stories and prioritized them.  The GLSEC is number 2 of my 4 conferences.

Below is the abstract I submitted as part of my proposal.

Abstract - Breaking the Law of Bureaucracy

The law of bureaucracy exists in all organizations.  The larger the organization, the stronger the law. Examples of this law, in a business organization, would be those who work and sacrifice to bring value to the customer, versus those who work to protect policy, process, and procedures (regardless of use or value). The Law states that in all cases, the second type of person will always gain control of the organization, and will always write the rules under which the organization functions.

Top-down organizations are suffering from the worst case of egoism: When each person acts to create the greatest good for himself or herself.  When the organization and its employees make decisions merely to achieve individual goals (at the expense of others), they lose sight of the original organizational vision or goals.  The law of bureaucracy can be broken, through team empowerment and altruism: From this perspective, one may be called on to act in the interests of others, even when it runs contrary to his or her own self-interests.

This talk will introduce ten characteristics of servant-leadership, to help those who currently manage others, to break the law of bureaucracy.

Like the image? Find it at Pictofigo

Zombie Tug of War

This week I'm in an all-out tug of war with the zombies.  Just short of getting hostile with the lot, I figured writing a blog post would be more cathartic.  I'm going to rant about enterprise tools and how I see them fit into the world of business.  I've been asked many times what products I would suggest to satisfy different needs.  I'll admit, I'm pretty passionate about some of the tools I use.  I love Evernote.  Why?  My memory sucks!   If I can get my thoughts into Evernote, I know I'll be good.  I also love using AgileZen.  I know, you've heard me talk about them before.  I keep a physical Kanban and a virtual one.  It's what I describe as both lightweight and elegant. It just works!  One more little app you may of heard of that I love is Google docs.  I like the fact that I can edit my documents anywhere and then share or collaborate on them with other team members. There are 3 primary commonalities that I can note about these 3 applications.  [1] They are super easy to use,  [2] either free or very affordable, [3] they help me save time.

So, what are the zombies taunting me with?

I'm working with a customer who is on a Novell network, uses Groupwise email, and has the poorest implementation of Microsoft SharePoint I've seen since I was introduced to SharePoint 5+ years ago.  None of these applications are necessarily bad.  But, when it comes to this bastardized configuration I'm currently dealing with, I get the feeling the only reasons these apps are being used is because really good salespeople sold a few zombies on these half-baked solutions.

Before you spend tens of thousands of hard earned dollars on the next "silver bullet", ask yourself why you need the product.  Are you trying to fix a process?  If so, I think you'll end up with an expensive crappy process.  Let me be very blunt.  Enterprise software will not fix a crappy process! Enterprise software is for making a refined process more efficient.  When I started advising this customer over two years ago, a vendor had just sold them on a deployment of MS SharePoint with Project Server.   Why?  So the customer could internally track time being billed to different work packages.  That's it!  What I found odd was the customer didn't have an existing way of internally tracking the time.  So, instead of having people fill out Excel spreadsheets to get them started, they just went for a solution that would solve all of their problems.  Have you read that promise before?

The result?  A solution nobody uses.

Score: Zombies 1 / Humanity -$50,000

My apologies for the negative nature of this post.  Happier posts are on the way!

[VIA: Oxford Dictionaries]

Like the image? Find it at Pictofigo

Technical Debt

Technical debt and design debt are synonymous  metaphors referring to the eventual consequences of sloppy software architecture and rushed software development. Code debt refers to technical debt within a codebase. Ward Cunningham first drew the comparison between technical complexity and debt in a 1992 experience report:

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.

Ongoing development in the upstream project can increase the cost of "paying off the debt" in the future.  A team should take opportunities, on a regular basis, to pay back (or pay off) this debt.  Either reserve a percentage of your development cycle or dedicate an entire cycle to complete this work.  If you don't, it will come back to haunt you.  If your kludge of a solution doesn't come back to bite the development team, it will probably haunt the help desk, support team, or someone else downstream.

Just like regular debt, you're going to have to pay it back sooner or later.  As a former Manager of Software Engineering and now as an advisor to a customer, I've seen (and see) what technical debt can do to the velocity of a team.  It robs them of precious time, after the fact. The development team buys into the idea that doing things the wrong way, to save some time in the interim, is worth the risks and the overall cost.  This is a really short-sided thought process.  Technical debt is like getting a loan from loan shark who roles dice to decide what your interest rate is.  So, if you don't need to take the risk, don't do it.

Be honest with your customer, your team, and yourself.  Estimate your work and stand by your estimate.  Don't let someone else tell you how long it will take to deliver quality work.  If you have to, you'll just have to deliver less work.  That is, don't take on the debt in the first place.

[HT]: Wikipedia

Like the image? Find it at Pictofigo