One of the keys to project man­age­ment is know­ing and embrac­ing the lim­i­ta­tions of a project. One of the other keys is being able to help others see and embrace the same limitations.

In soft­ware devel­op­ment there’s been a lot of talk about “Fast. Cheap. Good. Pick two”. But I think the most common iron tri­an­gle we face is actu­ally “Scope. Sched­ule. Qual­ity. Pick two.”

Very few clients would ever actu­ally pick Scope and Sched­ule, and say “Meh. To hell with quality.”

So the real lim­i­ta­tions of our dis­ci­pline are Scope and Sched­ule, because almost no one wants an on-​time piece of garbage, or an incom­plete piece of garbage.

There are two strate­gies that I use to embrace these limitations:

Kanban (fixed scope)

If you haven’t heard of Kanban, I rec­om­mend you read up on it as it really is a great system. Here’s just one quick tuto­r­ial, and my run­ning list of links.

For me, the essence of Kanban is fixed scope, but flex­i­ble sched­ule. Sure, you can quote a lead time — an aver­age of how long it’s taken fea­tures to go from the back­log all the way to done in the past — but that’s an esti­mate, not a commitment.

This works great if you’ve got clients who are flex­i­ble enough to accept a fairly open-​ended deliv­ery date.

Scrumban (fixed schedule)

Scrum­ban is a great tran­si­tional step for teams and clients when trying to go from Scrum/Agile or, shud­der Water­fall, to Kanban.

In Scrum­ban you’ll fix a sched­ule, a release every two or three weeks sim­i­lar to Scrum. But unlike Scrum you don’t fix the scope for the sprint.

Instead you work with the client and the team to come up with a pri­or­i­tized back­log of items for that sprint.

Work during the sprint is popped off the top of the back­log stack, so that the most impor­tant work (as judged by the client) is done first.

If the back­log stack gets too small, then, aside from cel­e­brat­ing your pro­duc­tiv­ity, the team and client can regroup and fill the back­log up again.

If the back­log isn’t com­pleted by the end of the sprint, that’s OK because we decided to fix sched­ule (and qual­ity), not scope.

In con­sul­ta­tion with the team and the client, you can take the remain­ing items and start the next sprint with them, or throw them all out if pri­or­i­ties have changed!

If you can find one who thinks it’s a good thing, then you’ve got your­self a bad system admin­is­tra­tor. A good sysad­min knows that if a box is pegged at 100 per­cent, then it can’t handle any more traf­fic and it’s likely to fall over at any moment.

Show some man­agers an employee work­ing at 100 per­cent. Many will say, while pat­ting them­selves on the back, that must be a great worker who’s been prop­erly motived by a good manager… wink.

But some, myself included, would think “there’s an employee who can’t handle any more traf­fic and is likely to fall over at any moment.“

Machines can’t run at 100 per­cent all the time, and nei­ther can humans. That’s why we have slack time.

Slack time ben­e­fits employ­ees by giving them time to cool down and recharge their cre­ativ­ity between projects. Man­agers ben­e­fit by con­stantly having a pool of refreshed, ready talent to han­dling incom­ing work.

Good man­agers should have a pool of low pri­or­ity, deadline-​less, “it’d be nice if” projects and tasks.

That way, when higher pri­or­ity work has been com­pleted and there’s down time, there’s some­thing for folks to work on that can be easily set aside should an emer­gency arise, or new work arrive.

Editor’s note: This is the first in a series of posts where I’ll try and espouse on the some of the prin­ci­pals and prac­tices of Kanban.

1. Stop the repetitive announcements

How many times do we need to announce over the PA system that “the white zone is for load­ing and unloading”, “passengers are only allowed one car­ryon and one per­sonal item”, and “the national threat level is orange.”

These announce­ments appear to be on an inter­val loop and never actu­ally rep­re­sent a change in state. Tell me when the threat level goes up, tell me when it goes down, tell me when the white zone is for breakdancing.

Until then, stop with the damn “announcements” and print it on a sign.

2. Mute the TVs

I don’t know about your air­port, but Harts­field, espe­cially the C con­course, always seems to have the TVs turned way the hell up.

Why not offer a couple of options for watch­ing TV:

• Broad­cast the audio on an FM chan­nel, and let those who want to, tune in with a radio.

• Turn on the closed cap­tions so folks can read it if they like

• Sign a spon­sor­ship deal so folks can use air­port WiFi free, or at least free if they want to watch stream­ing video on CNN or Hulu or such.

3. Seats

Again, it may only be a Harts­field thing, but clearly the gate seat­ing capac­ity was scaled for a time when secu­rity lines were shorter and folks could race to their plane right before takeoff.

Air­ports should add more seat­ing beyond the secu­rity check point. I’d envi­sion a large lounge in each con­course, sur­rounded by shops and dining with large status boards.

Even better than status boards, let me sign up for SMS noti­fi­ca­tions for my flight. Alert me when there’s 15 min­utes to go before board­ing, or if my gate changes, etc.

4. Bring your own bin

People doff­ing their shoes, taking their lap­tops out, undo­ing their belts (is this secu­rity or striptease?) cause a bot­tle­neck at secu­rity lines.

Why not give away/sell re-​usable heavy-​duty plas­tic bags that are TSA-​approved — I’m think­ing it’d be sim­i­lar to the Idea bag.

Then folks could stop any place before the secu­rity line, do the secu­rity striptease shuf­fle, put their items in the bag, and walk up to the line ready to go.

After the secu­rity check­point, people would don all their gear again and fold the bag up and be on their way.

5. Sit, then board, then fly

This is my cra­zi­est idea. But hear me out.

Instead of a seat­ing area out­side the gate, imag­ine if you actu­ally sat down in your assigned seat, in your assigned row, and could put your lug­gage into the over­head com­part­ments before your plane arrived at the airport?

Then when your plane arrived, the seat­ing com­part­ment would slide out — allow­ing the arrivals to “deplane”, and the depar­ture seat­ing sec­tion would slide into the plane with every­one and their belong­ings stowed.

It’d reduce turn­around time and garner the air­lines more money — quicker turn, means more flights, which means more fares per day.

Of course it’d require redesign­ing not just all the air­planes, but all the air­ports to make it happen, but hey wouldn’t it be cool!

I was think­ing, in a bad way, about all the TV shows — some good, but most bad — that I watched in my childhood.

And then for some reason unbe­knownst to me, I thought I’d start a blog and inflict this trip to nos­tal­giav­ille on the rest of you.

There’s more about why I started it over at tvofmylife.com

At the time I forked nose itself, but I wasn’t happy with the solu­tion. Folks rightly wouldn’t want to use my fork; I don’t want to commit to keep­ing up with nose’s devel­op­ment; and duh, they have a plugin archi­tec­ture.

So I’m happy to announce nose-​xcover. Install it and it’ll add the –with-​xcoverage option which you can use along­side the built-​in plugin like so:

#nosetests --with-coverage {{ coverage options }} --with-xcoverage
nosetests --with-coverage --cover-package=myapp --cover-tests --with-xcoverage

I updated my Django and Hudson guide to use this instead of the fork.

I hope you find it useful!