From CodeSprint

This is a(nother) planning tool for agile project development.

So why is it any better than all the other (failed) electronic planning tools? Because I'm the customer for this one!

Actually, I think this one is different because we're trying to make a tool for a different way of thinking about planning. This isn't a tool for the planning game. This is a tool to support Kanban development. As such, it is not a tool to be used once a week for planning & then the rest of the time for tracking. Rather, it supports fully continuous planning-and-working.

I (Arlo) made some significant changes in how we plan at BlueTech. We're supporting our process with whiteboards & index cards. And that works well.

David Anderson made some significant changes in how he plans at Corbis. He's supporting his process with Visual Studio, whiteboards, & index cards. And that works well.

His process and mine share values, but his was designed for a large group where he gets 10% of each person's time each week. Mine works for a small, fully co-located, dedicated team. And yet our processes share a lot more commonalities than they do differences. We're discussing these ways of doing planning (and tracking).

These techniques are, I think, more able to take advantage of a tool. The collaboration is not supposed to happen "in the meeting, during the planning activity", but continuously and ad-hoc. As such, a planning tool becomes not a replacement for discussion during the planning activity, but a shared blackboard that simply and constantly reflects the team's then-current knowledge of what it is working on.

The Context

First, the values of the process and the tool:

1. It should be harder to lie than it is to tell the truth, always.
2. Everything should be integrated.
3. Anything worth doing is worth doing continuously.
4. Anything not worth doing is worth explicitly not doing.

Really, the first of these values drove all the others.

I looked at the planning process, and found all the places we lie to ourselves, and thus place ourselves in a position where we can't help but lie to others:

• Estimates. All of them.
• Putting things into a backlog that we'll "come back to / review later".
• Claiming to do more than 1-3 things at a time (across the whole team).
• Claiming that work is done before the code quality / legacy code / whatever is ready.
• Claiming that a release is dependent on full work items being done - or that it can't happen at just about any moment.
• Claiming that we need high-resolution knowledge of the future.

Similarly, there are some constraints:

• We need medium- to long-range, low-resolution knowledge of the future in order to work well with customers and those who talk with them.
• We need 0-overhead packaging, deployment, installation and upgrades in order to support frequent (eg, ship live 2-3 times per week, per product), small releases.
• On my team at least, we're working with a lot of legacy code in some areas and work there has a random actual scope.
• We need fairly accurate, simple-to-interpret, and relevant historical data so that we can measure the effectiveness of process & team changes.

The planning process

...Well, I've got to stop writing this because Kim and I need to code. For more, including lots of drawings and vigorous hand-motion, come to the code sprint.

The vigorous hand-motion will result in several cards for us to work on in writing the tool...

IT

First, get Python. The directions are on the front page.

Next, mke sure you have a command-line svn client and that it is on your path.

We have created a script that will do all of your project-specific IT for you. Run it and you'll be ready to contribute to the project. It requires a network connection and 5-8 minutes.

1. Download and run http://svn.arlim.org/code_sprint/planningtool/_scripts/naked_planning-devel.py. You will need to give it one command-line arg: the location you want your sandbox. This location whould be an absolute path for now; I have not yet fixed that.
   • This will create a fully-contained Python sandbox. Everything it installs will be in that sandbox, and will not corrupt your machine.
   • It will also check out and configure our code.
   • To commit your changes, you'll need the username & password. We pass that around freely at the code sprints.

As an example, if you were to run

naked_planning-devel.py C:\temp\work

, then the code would be checked out to

C:\temp\work\src

. In order to launch the application, you would run

cd C:\temp\work\src
C:\temp\work\Scripts\python.exe start-naked_planning.py

or, if you're a Windows user, double-click on

C:\temp\work\src\start.cmd