Lessons from West Coast Customs (Part One)

I don't get to watch much TV, but when I do, I enjoy the show West Coast Customs. I love watching craftsman of any kind bring their considerable skill and creativity to a new project that has its own unique requirements and constraints. There is so much to learn about project management from this show.

The point I'd like to make today is how important one word can be: what they call their final deadline.

But for those who are not familiar with the program, essentially people bring their (often very expensive) vehicles to West Coast Customs to have them customized in some way--they are definitely one-of-a-kind when they drive away. The customer drops it off, West Coast works on them, the customer comes back to see how it looks and to pick it up. The show documents the steps, the challenges, and the process to get from drop-off to pick-up.

Everyone in the shop calls the final deadline for the project "The Reveal" knowing the customer will be at the shop on a given day to see and pick up her/his car--and they will want something truly amazing.

I like to encourage my clients to use a lot of outside vendors in the projects I manage for them. When I'm setting up the ground rules for a new vendor relationship I like to schedule a weekly status update call where we get on GoToMeeting or a similar product and talk about what was accomplished last week and what we'd like to get done the coming week. We talk about priorities, who is responsible for what, any internal pressures we need to consider, etc. Most importantly, we ask the vendor to be prepared with an on-screen demo of what they accomplished last week.

This helps keep the vendor focused and on track in several ways. It also helps them remember we're business users and often only see tangible business value through interacting with an interface--coming back with a demo of a bunch of database tables or infrastructure they built without tying it to some button we can push to make something happen makes for an awkward phone call that usually doesn't happen again.

I think I'm going to start calling the weekly calls "Reveals" instead of status updates.

(Note: I will now also require all current and future vendors to read this blog post [and watch one episode of the show?] before we begin working together.)

Spening Too Much Time on the Backlog

Spending Too Much Time on the Backlog
brought to you by Livescribe

Books mentioned at UTC CTO P2P Forum

I mentioned two books at the recent UTC CTO P2P Forum--both from the company 37signals:

The first is Rework which just came out and is already a bestseller. This is more focused on running a business.

The second is Getting Real which is their first book and talks primarily about how they build software. You'll find Agile principles all throughout both books. Enjoy!

Agile and Critical Chain Similarities

In my previous post I shared slides from my recent remarks at the Utah Technology Council CTO P2P Forum. I used a three column planning model with "Backlog" on the left, "Work in Process" or "WIP" in the center, and "Done" on the right.

One of the principles I outlined was to keep the WIP column "clean" so when project work comes in, all (or at least sufficient) resources are deployed to get it completed ASAP. I mentioned that too often we load up the WIP column with as many projects as humanly possible thinking that's a virtue. Author, speaker, and consultant Alistair Cockburn who taught me this model believed (as do I) that getting things to the "Done" column is what really matters--not how many plates we can keep spinning. How many staff meetings have you sat through where the PM essentially itemized the baby steps he's taken with all 23 projects he's juggling but he has nothing to demo, nothing Done!

I was watching a video, recently, of a speech author, speaker and consultant Lawrence Leach gave at the 2009 Continuous Process Improvement Conference. He pointed out how counterintuitive two tenants of Critical Chain Project Management are:

1. Waiting to start some projects actually helps them get done faster; and
2. Reducing the WIP increases overall project throughput

Obviously, Agile and TOC have some very similar philosophical roots. One of the first principles of Lean Project Mgt (LPM) and even Covey's Four Disciplines of Execution is to provide those you manage with the luxury of clear focus. Tell them that for a given period of time they can just put their attention on this module, this problem, this functionality and at the end of that period of time we'll be demonstrating it live in production to a client.

This principle works for a number of reasons which I might attempt to enumerate in a future blog post, but suffice it to say, when you provide clear focus on who needs to get what done by when, and you give your folks a transparent scoreboard where everyone can see how everyone is doing, things get done. When you tell your team to work on these 12 "priorities" all at once, you paralyze them and create what David Allen calls a rapid refocusing nightmare for them.

I'd like to clarify (as they do in the Four Disciplines seminar) that this principle applies to each team or resource in an organization. If an enterprise has a dozen teams, it will have a dozen or more projects in its collective WIP. But if you were to ask a given team what they are working on, their three columns are very clear--with only one or two items in WIP.

I'll post another time about what happens when an organization tries to matrix individuals to multiple teams and implement this model (hint: not pretty). I'll also post in the future about how giving each team a secondary item and sometimes even a third relates to the "buffer" concept in TOC production theory.

#UTCAgile Presentation

First, thank you to everyone at the UTC who invited me to speak alongside with Chris Marsh at the recent CTO P2P Forum on March 12th.

Second, my thanks to Chris Marsh for being such a pro about collaborating and presenting.

I think we posted eight or nine topics we could speak on when we started. I have not seen the final list, but by the time everyone posted their own topic areas I'd guess we'd have about 20 or so. And I think we only covered two or possibly three areas in the time we had. If you'd like to do another session to cover additional topics please contact the UTC and let them know. In the mean time, I thought I'd post the slides I used to cover the first topic:

You'll recall this topic related to what to do when multiple stakeholders (e.g., divisions within an organization) need to use the same IT resources.

I sincerely hope Chris and I are invited back. But if not, I intend to cover some or all of the topics you posted that we didn't cover here. More to come...

Agile Project Management and Golf

I've just had two similar experiences: one working with a vendor on a software development project and another working with some of my wife's staff on setting up some hardware and software. In each case, what they considered "done" is not what I would call "done" and it's caused some problems.

In an agile approach, you bite off a piece of work for a given amount of time (a sprint), design it, build it, test it, make sure the user interface is complete, and that all the code is in a production environment. In other words, you deliver something that provides immediate business value. On the software development project referenced above, the vendor would come back with most of the code working, most of the user interface done, some system testing accomplished, and the code would still be in a development environment. They would take the approach that they had some "tweaks" to wrap some things up but "we get the idea...".

I tried to relate this to playing golf. Suppose you're on a 450 yard hole. The approach above would be analogous to hitting a 250 yard drive, then maybe a 185 yard shot from the fairway to put you within striking distance of the green, and then picking up your ball and walking to the next hole saying you got close enough. Looking at it from the distance perspective, 435 yards is obviously 97 percent of the way there. But depending upon how well you execute, those last 15 yards could take a chip onto the green and into the hole (if you are really good or really lucky), or multiple chips and multiple putts. From the number of strokes perspective, being 15 yards out could mean you're two-thirds of the way there at best or maybe even only one third of the way there if it takes you two more chips and two more putts.

The point is, you've got to do the detail work to get the ball into the hole before you move to the next hole. We don't play all the big driver and fairway woods shots for the whole course and then go back and do all of our short game work. I think project management works best when you play it the same way.

24 is Agile

The director speaking in a short film from the bonus DVD of Season 2 of 24:

In that 12 hours I gotta figure out how I'm gonna achieve everything I need to achieve in blocks of two hours and three hours. We do what's called a timeline, and we give ourselves a certain amount of hours to work on every scene. And we need to try to get to those hours to make our day--to stay within our 12 hours of shooting time.

Then as the day goes on you're constantly changing--things aren't working out, you look for a shorter way. A sort of more economic way to shoot a scene.

Keifer Sutherland speaking in the same short film:

When you actually put something on its feet, logic issues will come with the physicality of the scene that might not come up when you're simply reading it. Stuff hopefully is continually changing until the very last moment until we shoot it, and I think your ability to adapt in those specific situations and certainly adapt at speed in many cases is the difference between your ability to do something well and not.

Deadwood is Dead-on Agile (Part Two)

Elizabeth SarnoffProducer/Writer talking about being in the writer's trailer when David Milch is "writing" a scene (meaning he's slumpped over a pillow on the floor looking at a screen, dictating dialogue to an assistant who types the lines for display).

There's no way to know what's going on unless you're in there, because everything here changes 600 times a day. We change the actors that we need on an hourly basis, we change the scenes that we're doing, who is in the scenes, and if you're not in there with him you don't know. You're just helplessly behind.

One principle of Agile is "co-location"--meaning rather than the business sponsor staying in one office building and the developers staying in theirs and possibly the testing team and/or DBA's are in another set of cubicles on another floor, everyone moves her/his desk to a common "war room" or conference room or at least adjoining desks. It's not for everybody. But traditional barriers between silos (e.g., marketing vs. IT) come down, a team begins to form with a common purpose, symbiosis occurrs as you overhear challenges another member of the team is encountering, etc. It's very similar to the quote above--if you're not in the room, it's very difficult to grasp the complexities, the iterations, the need for changes, etc.

Deadwood is Dead-on Agile (Part One)

Quotes on the making of the Emmy award winning HBO series Deadwood:

We often start filming and don't have a script.

Stephen Tobolowsky who plays "Hugo Jerry"

The story doesn't get written in advance...past what you show the network executives. They say okay and then you start filming. It grows as one thing happens as a result of another. In fact, an episode may start with one single scene. How that scene plays out then suggests what's going to happen to the writers.

Jeffrey Jones who plays "A.W. Merrick"

Agile projects often start with "one scene" or a bite-sized deliverable to be produced in a short period of time: a week or a month. Then the team comes back to the table with a demo of a workable, tested, piece of business value. The landscape could have changed for the business sponsor in that time (and often has). Priorities could have shifted. Budgets could have been adjusted. An emergency could have emerged. A key person could have left. So the business stands back, takes into account the current topology and constraints, and decides what's the most important thing to work on right now for the next increment of time--the next "scene." Maybe that means stopping on this project and moving to another. Perhaps 80 percent of the potential business value is met within the first two increments and the opportunity costs associated with pushing for that last 20 percent just don't add up.

I'm working with a potential client right now that has as its top two priorities items that were not even on its radar three months ago. I venture to say that is not uncommon. Some say how can an Agile approach possibly work? Others say how could it work any other way?

Lessons in Agile Project Management from Big Wave Surfing

I just finished watching a great surf film called Riding Giants by Director Stacy Peralta. I had to stop the film a few times and transcribe some of the quotes because I thought they captured a few principles of Agile project management beautifully:

Big Wave Surfing Legend Micky Munoz on the first rides of Waimea:

Everything is moving. Everything is in flux. Nothing is constant. It's so dynamic that you can't pre-plan it.

Director Stacy Peralta on using a film printer to print hundreds of photos of archival film footage:

We wallpaper our offices with all these photographs. When I'm putting together a sequence I can go all over the office and say, "I need that photograph, I need this photograph, I need that photograph" and also by coming into the office and looking around these walls your constantly getting input from these photographs and it starts to get into your subconscious head. You know you kind of start to drink this stuff and it's really helpful in the making of the film.

Editor on using drawings to depict events for which there was no footage:

When you have a great story that you want to tell, but you don't have the coverage for it, was a lot of the things that we came across--especially with Macaha in 1969--and so, we use drawings; that's when we went to story boards.

Director on same topic:

One of the shots that we wanted to get in the film is we wanted to figure out--we wanted to see what it looks like--wiping out at Mavericks. Of cource we couldn't afford to get a camera down there, and even if we did get a camera down there we'd probably need a lot of light because the water's so murky and then I don't even know if we'd get the shot so we just thought, "Why don't we draw pictures? Have somebody draw pictures of what it might look like down there. Shoot the pictures on a motion mat camera, and cut it together. Just pure experimentation. Let's see if it works. If it works we'll use it, if it doesn't we'll throw it out. "

So I had an artist draw pictures like this. And he sketched them out at first, and these are all different pictures of what it might look like of a guy wiping out at Mavericks, and that led to more ideas of more drawings of, you know, sketches of guys holding onto leashes and
things like that. There was a process of experimentation--let's see what we can do--if it works, great, if it doesn't work it didn't cost us that much money to experiment.

Agile and Spaghetti Sauce

I recently discovered TED. I have no idea how it's not hit my radar until now, but I can't listen to and watch the talks fast enough. I was watching Malcolm Gladwell talk about a personal hero of his, Howard Moskowitz, and the role he had in discovering the value of providing calculated varieties of a product versus trying to find the one, "perfect" product that will meet the needs of the majority of the market. With Seth Godin's work and The Long Tail we tend to take this idea for granted today, but Malcolm does a wonderful job of taking us back in time to a point where this paradigm was uncommon and even revolutionary.

One of the many anecdotes that impressed me was when Mr. Moskowitz concocted nearly endless varieties of spaghetti sauce using variations on sauce thickness, amounts of various spices, introducing bits of vegetable chunks, etc. and then fed 10 bowls of various varieties to a number of subjects. When he worked through the data of people's preferences he found they fell into three groups: plain, spicy, and chunky. He concluded this latter category represented the preferences of about a third of the population--and there was no sauce on the shelves with chunks of juicy vegetables at that time. Prego went on to release such a product and make a fortune, but the lesson I want to focus on is one observation Malcolm makes in his narrative: no one had mentioned they would like a chunky spaghetti sauce in any prior focus groups. The lesson Malcolm draws from this is that people don't really know what they want until you give it to them.

This conclusion is reinforced in protracted software development projects that follow a rigid waterfall approach. The requirements analyst asks the business users what they want and their answers are often within an implicit and many times unconscious context or menu of what they've already got in an existing system or think would be possible based upon a limited understanding of possible system features. In other words, they say they want a good tasting sauce.

In Agile or more iterative, prototype-rich methodologies, the user would be presented with rough drawings of user interfaces, story boards, and HTML and/or PowerPoint mock-ups, over and over again throughout the very initial stages of the process. In other words, the developers spend a fair amount of time up front cooking up a ton of varieties and keeping the business users taste-testing. Now the possibilities are open and we're getting several quick cycles of real-time, visceral feedback. Now we can get from the 40-50% approval ratings Malcolm mentioned are the usual result of a homogenized solution to the 75%+ delight ratings of people who get what they didn't know they really wanted.

Tom Peters mentions how Ritz Carlton aims to "fulfill the unexpressed wishes of its guests" in a few of his books. The Japanese have a common practice of insisting on finding seven viable solutions to a problem or challenge before they select their approach.

It is incumbent upon those of us in the IT solutions field to translate what is really a collection of abstract ideas in the beginning of a project into tangible value and options in the minds and senses of end users as quickly as we can.