How I Learned To Stop Worrying And Master Project Management

In a previous blog post I talked about task management, in this post I talk about managing projects: especially software projects; especially software projects in an Agile development environment. Project management, is of course, a topic near and dear to the heart of all developers; it is the part of our jobs we like most and the only greater joy in life is spending six months in the dentist’s chair.

What I’ve been looking for is a way to manage a project timeline and a project’s specification in a way that won’t lock me into early decisions, that has a chance of being realistic, that captures the way I actually work and that conveys priorities and time dependencies without becoming a project in and of itself.

Put All The Dependences In and Out Pops Your Completion Date – Yeah Right

When I started at Ziff Davis (later AT&T) we hired a project manager who broke out Microsoft Project (circa 1992).  He explained that if we thought through all the tasks and subtasks we had ahead of us, and we put in all the dependencies (I can’t start b until a starts, and I can’t start c until b completes) then out would pop our finish date.  We spent about six years (or was it days?) working this through and out popped the elapsed time until completion: 15 years.  Uh… no.

So we did what everyone does, we ignored the stupid project sheet and got to work.  For a while the project sheet served to tell us what the subtasks were, but soon that broke down (it wasn’t that requirements didn’t change before Agile, it was that each time they did everything broke). The next phase was to use the project sheet to record what we had already completed. Then we used it to line the wastebasket.

Aside from the fun of tossing around words like Gantt Chart, we didn’t get a lot out of the experience except Post-Traumatic Spreadsheet Disorder, in which we all kept track of what we were doing as best we could in Excel.

Breaking Out Of Jail: Agile / Test-Driven-Emerging-Design

I won’t take you through second and third attempts except to tell you that when I was consulting, I was actually told by one client that we couldn’t change the spec, even though he wanted the change, because it was too much work to change the project management software entries.  No joke.

The real answer, for most of this, was Agile: short development cycles, continuous releases, test-driven emerging design.

The premise of agile programming dove-tails neatly with the approach I’ve been using for two decades: get it working and keep it working.

I don’t claim this is the right approach; just that it works for me.

And I also claim that we’ve been lying about doing design. We say we’re designing the application before we start coding, but I don’t believe it.   I suspect the number of programmers who actually design the entire project before coding it, and then code that actual design, and then are actually happy with the results, is about the same number as people who read all of Ulysses by James Joyce and understand it all.  I admire them, but I don’t aspire to be them.

The simple fact is that design-first never works because

• I learn more about how I want the design to be as I write code
• Requirements change
• The bigger the design, the more likely I am to get it wrong
• Requirements change
• Design documents are incredibly boring to write
• And, oh yes,  requirements change

The old argument was “don’t paint yourself into a corner.”  On reflection, what I found was I was always painting myself into corners, but if I only painted for a few minutes before fixing the problem I was a lot better off than if I’d spent all day at it.

Kanban

So how do you create a spec, let alone manage a project, if the design is going to emerge as you go?  The answer is you need an incredibly flexible approach that is not fighting agile development, but is embracing it.  The answer, for me, for the past year has been Kanban.  Josh Holmes (Evangelist extraordinary) introduced me to the folks who were creating LeanKit Kanban, and they in turn were incredibly kind; helping me to understand how well Kanban fits with Agile development, and giving me a vision of where their software was going (and they weren’t kidding, just about everything they said was coming has been implemented in the intervening six to nine months).

Here is a mock up of myKanban board (click on the image for full size)

On the far left are controls for moving in and out of administrative functions, and three tabs:

• Options
• Backlog
• Archive

The backlog holds items that are not yet ready to be built.

The lanes (horizontal and vertical) are entirely under your control; you can set this up anyway that makes sense to a specific project.  What you see here is how I might organize an open source project.  The three principle productivity lanes are ToDo, Doing and Done.  I’ve opted to break the ToDo lane into two sub-lanes: Ready to Develop and OnDeck (for various participants).

The Doing lane will typically have a number in the upper right hand corner (e.g., 2) and that is the limit of how many cards you can put in that area (e.g., I can only work on 2 tasks at a time).  Any such limitation can of course be taken away or overridden (by adding a note as to why).

Cards move from left to right, coming out of Backlog into ToDo and from there to Doing and then to Done.

I added “swim lanes” (horizontal lanes) for some of the principle developers to track how cards are moving along for them, with occasional contributors all aggregated in the (not visible in the illustration) bottom swim lane.

The bottom of the image is taken up by the pop-up Add New Card.  You can see how you can add a title and a description. As cards are modified a “History” tab appears.   Cards can be created with different “types” such as feature, bug, task, etc., and if you choose each type can have its own color.  Tasks can have due dates (or not) and priorities.

There’s a good bit more to it, this is an incredibly flexible system with lots of options but you can get up and running and productive in about an hour.  In a reasonable size software project, I’d expect to spend about 10-15 minutes a day fussing with the Kanban board – which is great.

What Kanban Does For You

What is not obvious in looking at the board is how quickly it reveals bottlenecks, where I’m wasting time, and how to be as effective as possible.  The fact that it is all very visual, that you are moving these cards around and can see at a glance all the relevant information, makes it very easy to see what is stuck, and what is moving nicely.

LeanKit Kanban has a number of features that I don’t personally use, but would have killed for in previous projects, such as advanced analytics that include diagrams for Cycle time, cumulative flow, process efficiency, work distribution and more.  The analytics allow a team to answer such critical questions  as “what is holding the project back?” and ”when will this item be ready?” with high confidence.

I do use the notification capabilities, which turns what is usually a “polling” exercise in frustration into an “interrupt-driven” management approach; much better.

The bottom line, for me, though, is that each “card” carries its entire history, its description, its priority, its due date and everything else I need to know about a sub-feature.  That is very clean and it fits well with the way I work.