A couple of weeks ago I gave a presentation entitled Agile for Startups to the companies in Startup UCLA, a startup accelerator program run by UCLA. I actually gave this talk a week after my colleague Lane Halley presented her talk to the same group.
The talk went well, and I think it was well received. The content is targeted at folks, both hackers and hustlers, who don’t have any experience with Agile techniques. I tried to focus on techniques that can have immediate value to startups.
Here is a summary of the eight techniques I described:
Story Writing – Describe your features as fine-grained user stories, always illustrate requirements from the perspective of the end user. You should use the “As a… I can… So that…” pattern.
Prioritization – Rank each user story in order of importance. If some stories fall off of the bottom of your backlog, make sure they are the least important ones!
Estimation – Apply a level of effort for every story. This is done by the developers. Then as you deliver stories, tools like Pivotal Tracker can learn your velocity, and start to predict when specific milestones will be completed.
Standing Daily – Spend five minutes every morning having each member of the team say what they did yesterday, what they are going to do today, and what (if anything) is blocking them. You should physically be standing up for this meeting – it’s just a trick to keep them short!
Reflection – Spend an hour every couple of weeks talking about the things your team is doing well and the areas where improvement is needed. Use the I like, I wish technique. Don’t forget to tweak your process based on this feedback. That’s the whole point!
TDD – Test drive your code and have good test coverage. This one is very important and always sparks the most discussion. We have lots of posts on our blog about this stuff.
Pair Programming – Two keyboards, one display. One person drives, the other navigates. Switch often. It sounds non-intuitive to those who have never done it, but it is a very powerful technique.
Refactoring – Before you implement the next user story, modify your code to prepare it for the change. Basically, adapt your architecture just enough to handle the next feature. It will keep your design clean without forcing you to over-architect up front.
You can read a little more about this on the Dish Daily.
Thanks for the good write up Chuck!