You don't need as many tools as you think

I'm always excited to see someone else writing about lessons learned from their startup, and wanted to link today to Untitled - Startup Lessons Learned -- Take it with a grain of salt. Here's something I can relate to:

We used assembla for subversion, scrums, milestones, wikis, and for general organizational purposes. We had all the tools in place but we didn’t actually practice agile development. Scrum reports would come in once a month, nobody was actually responsible for anything ... No fancy tools needed here — it’s about the mentality, attention to detail, and the actions that foster agile development, not the tools & systems you set up in place to facilitate this.

It's a natural assumption that, in order to implement a new process, we need fancy new tools. This is generally false. And even when new tools are needed, my experience has been that you can only figure out what tools you need once you have done the relevant task by hand. It's another example of the refactoring principle in action.

My favorite instance of this is scheduling software. Now, there are some situations where scheduling needs to be incredibly complex, like when many teams are working on something that is heavily synchronized and where the consequences of failure are severe. But it's incredibly easy to fool yourself into thinking that, so it's worth being a little skeptical.

If you read Lean Thinking, you can enjoy numerous examples of companies that replaced multi-million dollar MRP systems with a simple white board. The lean manufacturing guys call this visual control and it's very powerful. When you make progress evident to everyone on the team, you allow for decentralized initiative, and foster a focus on team (rather than individual goals). If you've never worked in this way, you'd be surprised how many people can lend a hand in areas way out of their specialty, if given the opportunity. Most engineers are terrible visual designers, but if the designer on their team is struggling, maybe they can help out with an icon or two. And wait until you see a "non-technical" designer writing simple code to try and speed up a release.

In order for progress to be evident it has to be:

• Simple - everyone on the team has to understand what it means. A typical setup might be to have cards representing tasks (as in XP story cards) and have them move across a board from an "in progress" column to "complete." I usually recommend a three-part board, where the left column is where the scrum-style "product backlog" is maintained in priority order, the middle represents tasks in progress, and the right column is for tasks recently finished.
  
  
• Visible - the whole team has to be able to see the status, and not just when they are actively having a problem. A board posted in the same room as the team is best, because you can't help notice it when you come in. In continuous integration sytems, a single colored status webpage can work (it looks like this). But putting the status on a webpage only works if members of the team have a reason to check it all the time. For example, I recommend that you wire up your source control system to disallow checkins while any of your unit tests are failing. This has lots of benefits, but one strong one is that it causes everyone to check the status of the build all the time.
  
  
• Accurate - if you've ever been managed by task-tracking software, you'll relate to the feeling that you either have to spend ludicrous amounts of time posting updates or the information goes stale. It's exponentially more frustrating if some people on the team update their status religiously, and others don't. The more visible the status is, the more likely people will update it, but it's also important that updates be a natural part of your workflow.
  
  For example, I recommend a simple rule: each team member is allowed to have only one task "in progress" at any given time. This rule is easy to enforce; just look up at the board and count the cards in the "in progress" column. It's also a natural accuracy-enhancer, since when you want to work on a new task, you need to move your old task to complete. If the task is not complete, you force people to surface the issue quickly. (It also has the nice side-effect of driving down the batch size of work, but that's for another post)

This framework for making progress evident applies to more than just scheduling, of course. Acceptance tests can make the progress of your features evident, assuming they are simple enough for everyone to understand, visible to all, and accurately reflect the goals of your project. Cacti graphs can serve the same purpose for quality of service, and a good business dashboard can help with business goals.

In each case, though, think twice before you set up an elaborate automated system. I used to think a giant flat-panel screen that broadcast our company's key metrics would be what was required to get everyone to pay attention to them. I never tried it, but I recently got to meet a startup who did. The result: as soon as the novelty value wore off, nobody paid attention anymore. A much better solution, I think, would be to have each project leader be in charge of physically printing out a one-page report every week with the relevant stats for their project, and present it to the whole company. If they are going to be judged by the output of that report, you had better believe they are going to: 1) make sure it is accurate, 2) check it often, and 3) make their team understand it.