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!

Two vs Three Column Planning

Two_vs_Three_Column_Planning
brought to you by Livescribe

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...

Gift wrapping tip for golfers

If you're like me, you keep your putter or two in your home office with a decent home putting machine. I just realized golf clubs are perfect for holding the wrapping paper down as you're trying to cut it to size.

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.

Software is like Tic-Tac-Toe

We just taught our three-year-old son how to play tic-tac-toe. I was in the beginning stages of the very lengthy porcess of putting him to bed the other night, and we were taking turns drawing on a little refreshable drawing pad when I drew a tic-tac-toe board. We played a few games. Then it was his turn to draw and he decided to draw a "better" tic-tac-toe board with more lines on the playing board so you would have to get five in-a-row to win instead of three. I chuckled because I remembered doing the same thing as a kid. But it occurred to me that traditional tic-tac-toe where three in-a-row wins was, in fact, the best (and maybe only really usable) version of the game. There is an optimal point where you hit "enough" and putting more complexity into the game makes it worse and sometimes not even worth trying to play.

The company 37signals has been an advocate of this same idea in software for some time: a given application should be about getting certain things done. The developers should find the easiest, fastest, most intuitive way to do just that and stop. Adding more lines (in this case, lines of code) to the game does not make it better. It buries the core functionality so that the software becomes too complicated, too hard to find the function you need in all the drop down menus, too much of a hassle. And we wonder why user adoption is so hard. I think the winners are those, like 37signals, who find that point of "enough" on the curve and deliberately stop while they can.

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.

The genius of Ken Burns

I've just finished watching the Ken Burns film Thomas Jefferson. In my mind, Mr. Burns is the preiminent historical documentarian. In the special features section of the DVD I found two short films on him and his work. Here are some notable excerpts:

Listen to the photos
One of Mr. Burns' trademarks is taking a still photo and either zooming in or out or panning across it in some way while the viewer hears an audio track. It's now even called the "Ken Burns effect" in filming jargon. There's a whole lesson in just this point on embracing constraints (see a chapter on this in 37signals book). But Burns says he would stare at a photo and "listen to it." He elaborates by saying the trees in the photo had a rustling sound, the boat going by, the people walking and chatting in the background all would have been making sounds. He even goes so far as to ask, "What did the dust sound like?"

Find an emotional connection

My work is not just interested in the dry dates and facts and events of the past, but the emotional archaeology--and I call myself an emotional archaeologist--because we know that's the glue that makes these complex past events stick in our minds and in our hearts and become permanetly a part of who we are now.

This is very similar to the approach author David McCullough takes to his work.

History is

History is, not was. We're never going to change what happened...But the way we engage our questions now about it tell us who we are right now. (now quoting Harry Truman) The only thing really new is the history you don't know.

Meaning accrues
When asked about the length of his films in general and his slow, gliding shots in an era of quick frenetic cuts:

We realize that all meaning accrues in duration. The things that we are all proudest of, the work we've done, the relationships we have, accrue in duration. It's the things we've given our best attention to, and we realize in the end the only thing we have is our attention.

Think wrapping paper is a commodity? Think again...

I'm trying out some premium wrapping paper we bought off a school fund raiser. It's maybe a tad thicker than the Walgreens cheap stuff, has the snowflakes on the front, yada, yada...but wait...flip it over to start actually wrapping and what do we have here? One inch dotted gridlines are lightly printed across the whole roll. Now, even though I graduated from pre-school many years ago, I can actually cut a straight line so my packaging doesn't look like it was done by a bonobo. It's remarkable how simple and yet useful that is.

Just set up new twitterfeed

I place short "what I'm doing" updates along with quick thoughts and observations on twitter. Things that take a bit more explaining make it onto this blog. I've now added a twitterfeed so that blog posts are mentioned in twitter. Regardless of how you follow what I'm saying, I thank you.

Moving away from PowerPoint?

After reading The Back of the Napkin I'm giving serious thought to moving away from slick PowerPoint (and my actual preference, Keynote) presentations and moving toward real-time diagramming of my ideas on a white board, flip chart, or piece of paper. I just did an experimental film using simple hand-drawn pictures on a series of index cards and laying them in a rough prototype of a proposed workflow for a client and it seemed to have worked just as well, if not better, than trying to do the same thing in a more polished, "professional" way. I'll keep experimenting with this notion. But I'm more inclined to move toward this intuition of mine based upon this great blog post. I love this representative quote:

[Speaking about others showing up with portfolios of their past work and him showing up with a paintbrush...]

It not about the past; it’s about the future. It’s not “build me something like you’ve already done” but “build me something from your imagination.” Calatrava came with a paintbrush and a vision, not a PowerPoint of his projects.

The challenge isn’t putting together the slickest presentation. The challenge is having the imagination and the ability to converse with clients about what their future will be. Those are the paintings that will win commissions.

Thinking with your hands

I was listening to a TED podcast this morning from a gentleman from IDEO. He described a design session where an IDEO team was meeting with surgeon's to discuss a new surgical instrument they would like developed. Someone from the design team left the room and in a few minutes returned with a dry erase marker taped to an empty film canister that was taped to a clothes pin in the rough shape of a gun. The designer gave it to the surgeon's who passed it around and begin offering very constructive feedback on how the device should sit in the hand, how it should be shaped, what it should do, etc. IDEO calls this behavior "thinking with your hands" (and this eventually turned into a real device).

It typically involves making many low-resolution prototypes very quickly. Often by bringing many found elements together in order to get to a solution...And so this behavior is all about quickly getting something into the real world and having your thinking advanced as a result.

This dovetails precisely with the Getting Real approach advocated by 37Signals. Tom Peters has been an advocate of this for years. And it explains why the Back of the Napkin approach of visual thinking works so well.

IDEO takes this idea seriously and has "protyping carts" around filled with Play-doh, tape, Legos, colored paper, markers, etc. ("the stuff we all had in pre-school") so desingers can begin prototyping objects whenever they want. They also apply this approach to designing a service experience through rapidly jumping into role-playing various scenarios.

Do you think of what you do as an art form?

I just finished watching the John Adams miniseries from HBO (Adams is a hero of mine).  There is a wonderful short film about author David McCullough on the last DVD.  Here are my two favorite pieces of wisdom contained in the film:

I think of writing History as an art form, and I'm striving to write a book that might, might, qualify as literature.  That's the aspiration.  And I don't want it just to be readable, I don't want it to just be interesting, I want it to be something that moves the reader--moves me.

Mission accomplished.  

Next, in speaking about each of his writing engagements:

You've got to marinate your head in that time, in that culture.  You've got to become them, in effect.

The guy is a true pro.  If only more of us could have that same approach to our work. 

New way to think about tasks

• In the freezer: Stuff we need to get to at some point in the future
  
• In the fridge: Stuff we'll be working on in the next few days
• On the stove: Stuff we're actively working on right now

Is the teacher learning?

I just listened to a captivating TED talk from a gentleman who voluntarily did not speak for 17 years. As one would imagine, he has some interesting things to say about listening. During his silence, he was a college professor where he would write and use a make-shift sign language to communicate. He said many times as he would make signs and gestures the students would play a kind of guessing game trying to make out what he was trying to say. Many times they got it right. Sometimes they would not. Frequently, he would think to himself, "That's not what I was trying to say!" And then he'd catch himself and think, "...but it probably should have been..." as he realized the students had struck upon a critical angle or point he was overlooking. His point was that if you are not learning while you're teaching, you're probably not really teaching.

Seth Godin and Cosmetics

My wife is legally blind and often comes to me with a handful of frosted glass cosmetics jars of every shape, size, and color as she's getting ready in the morning asking what each of them are. I'm continually amazed at how specific (and frankly creative) many of these products can be.

At the same time, I'm reading Tribes--Seth Godin's new book. Seth is one of my favorite authors and a common theme of his (and Tom Peters for that matter) has been to find and dominate micro niches (or some small territory along the long tail) rather than taking on Ma Bell. Basecamp or Highrise from 37Signals (one of my favorite companies) is a much better bet today than trying to take on Word or Excel.

So that got me thinking: if Revlon can sell a cream for women of a certain age to place just around their eyes--only at night--how many possible creams/lotions/potions are there? And if they can do that with their market, why can't I do something similar with mine? How many ways can you slice and dice your target market? And after you've done that, you're sure to find at least one of those micro market niches is underserved at the moment. And Seth would say there's a "tribe" waiting for you to be their leader.

Time Management from the Inside Out: Julie Morgenstern

Organizing time is exactly like organizing a closet: there's only so much room for things to fit comfortably and you only need three to six categories.

Julie provides the following seven tools:

Tool One

Self-Assessment (be specific in precisely what is out of balance)

Tool Two

Ask "How long will this take?" for each task. Don't just enter a task on your To-Do list, block out the amount of time that task will realistically take.

Tool Three

Apply the "Four D's":

• Delete
• Delay
• Diminsh (Julie suggests we learn the art of "selective perfectionism" where we get okay with a "down and dirty" job on 80% of what we do and really go for perfection on the 20% of tasks that really matter)
• Delegate

Tool Four

Develop a Big Picture View

• Simplify life categories (Note: Covey calls these "roles") down to three to five
• Create a few goals for each category
• Plug in the necessary activities to accomplish each goal into your schedule

Tool Five

Create a Time Map/Weekly Plan (either horizontal [traditional] or vertical [with a different emphasis for each day]).

Tool Six

Apply the SPACE formula:

• S - Sort (put incoming items into their appropriate life categories)
• P - Purge (learn to say, "no," delegate)
• A - Assign a home for everything (Julie does not like master task lists. She suggests putting each task on the date and time when you intend to do it)
• C - Containerize
• E - Equalize

This works for both organizing a physical space and organizing time (Julie's key insight, in my opinion). With time,

Tool Seven

Choose just one planner/device. She suggests what she calls "visual/tactile" people use a paper planner and "linear/digital" people use an electronic version.

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.