« Happy Startup Holidays| Main | Logic Lunch Counter »

Agile Startup Tricks

| | Comments (0)

I've been busy working on my startup for the last month, and as an agile-big-corp guy, many of you are probably wondering: how am I doing in the micro-team startup field?

Very well, actually.

Here's a brain dump of things I've learned over the last month. As always, take what you can use and leave the rest:

  • FlipCam standups - Like team members everywhere, I need somebody to report to, to make commitments to. I've found the best way of doing that is taking out my FlipCam each day and doing a "daily stand-up", 2 or 3 minutes where I explain what I did the day before, what I plan on doing today, and what kinds of obstacles I might have. This sounds so completely stupid that I'm amazed at how well it works. Every day I know I have to "report in" at some point, and it helps keep me on-track and motivated.

  • Find advisers - I'm very lucky in that I have about a dozen advisers, many from HackerNews, a place known for startups. These guys don't participate at all in day-to-day work, but every week or so I send out and email with status, demos, and asking for advice. It's a great feeling to have such expertise in my back pocket! And all I had to do to get them was just ask. Once again, the things that sound completely simple and totally obvious many times are the most profound.

    I don't think it matters who your advisers are. Obviously people who do something like you want to do are great, but the point is having outside eyes look at your work. Quite a few times my weekly updates have kicked off discussions about how my project and product looks to somebody not programming it every day. You can't pay enough for that kind of good feedback.

  • You gain attention span by practice - The hardest thing I found when moving from Agile Coach at BigCorp to agile startup team at me.com was being able to focus. Even though I have a deep technical background, I find working with people intensely leads to "interrupt-driven-attention-span", where you're always hopping from one thing to another. This way of thinking becomes so ingrained that eventually you start interrupting yourself, moving from one trinket of activity to another. At first I had a very difficult time settling down and fully engaging mentally in a problem.

    Oddly, it's not always an attention problem. The second half of this was being able to realize when my brain is stuck. Immature programmers usually just bulldoze through their code when confronted with these feelings. I've learned that when this happens I've learned to......


  • Get out - I make it a point each week to get out of the office for a lunch or two. This probably sounds strange to those of you in the city, but in rural areas it's possible to literally lock yourself up for weeks on end. And as fun as that sounds, at some point your brain needs time to digest what you're doing. What better way of doing that then having lunch with somebody? You get to make smalltalk, see the sunshine, and get immersed in interesting stories. Plus, as I said earlier, any outside eyes are a good thing.

  • Google Wave collaboration - I've been trying Google Wave as a form of collaboration. So far, results are mixed. Perhaps Wave just hasn't penetrated deeply into my circle yet. But it looks like an awesome collaboration tool, and I'm going to give it a year or so before I make a judgment one way or the other. For now, I think it's highly flexible and open to add-ons. Can't wait to see how it evolves.

  • Weekly drops - Each week I have something to show. My product does something of value it did not do the week before. Oddly, sometimes it does something completely different than I had planned, but it always does something new. Progress is always being visibly made. Not only does that give you a good feeling, it also gives you a sense of momentum. You begin to realize that no matter how big the problem, it's really only a matter of stringing together enough weeks with positive results.

  • Sharpen the saw - This past week I was feeling overwhelmed by cruft -- you know, the stuff that builds up in your code as you work towards a drop. So I decided to do something very anti-agile: I took the week and just worked on finding how cruft was getting in my code and eliminating it. As a result, I made more progress this week than in the two weeks prior! No matter how hard you work on sawing the tree, you get much more done not by sweat, but by sharpening the saw and letting it do the work.
  • Auto Code-Gen is good, up to a point - As part of my "sharpen the saw" week,. I pulled out my old standby code generator, CodeSmith. CodeSmith is the crack cocaine of architect astronauts. Once you start doing code generation, you can fall into this world where you spend more time on the code generator than the actual problem! It's a very bad place to find yourself, and it's all too common for architecture-minded coders. But, on the other hand, code generation also serves a very good purpose sometimes. I am working on the Microsoft stack, so there's a bunch of junk involved with getting things out of persistent storage and putting them back in there. This is the perfect thing for CodeGeneration, because all it's doing is being a code-writing monkey so you don't have to be.

    At the end of the week I have a project that generates about a five-hundred lines of F# to manage persisting data. Not only is this mindless code, it's also code where people have a tendency to make lots of mistakes. Plus when I change my data structures all I do is push a button and continue working on the larger problem. So auto-generation is all good -- up to a point.

  • Keep an open mind - I think probably the toughest thing I'm learning is how to keep an open mind. I've found that action comes first, then motivation. What that means is that the more action/activity you spend in your project, the more motivated you're going to get about it. Especially in the beginning. This is a good thing because it keeps you working long hours, but it's also a bad thing because it can prevent you from seeing vital pivot points as you encounter them. However you see your app, the customers are going to have another, unexpected view of it. When that happens, you have to be able to hear the customers and respond quickly. My strategy to deal with this is to keep things as absolutely simple as possible I have a theory about the need for my product. My program should address that need and that need only. In this fashion I don't get attached to all the other little things that are not important

There's the brain dump from the past few weeks (unedited). Hope it helps some of you other guys out there like me leaping into the startup-world.

Leave a comment

About this Entry

This page contains a single entry by DanielBMarkham published on December 16, 2009 3:53 PM.

Happy Startup Holidays was the previous entry in this blog.

Logic Lunch Counter is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Social Widgets





Share Bookmark this on Delicious

Information you might find handy
(other sites I have worked on)





Recently I created a list of books that hackers recommend to each other -- what are the books super hackers use to help guide them form their own startups and make millions? hn-books might be a site you'd like to check out.
On the low-end of the spectrum, I realized that a lot of people have problems logging into Facebook, of all things. So I created a micro-site to help folks learn how to log-in correctly, and to share various funny pictures and such that folks might like to share with their friends. It's called (appropriately enough) facebook login help