Finding A Development Process For a Small Startup Team(stuartkhall.com)
stuartkhall.com
Finding A Development Process For a Small Startup Team
http://stuartkhall.com/posts/finding-a-development-process-for-a-small-startup-team
4 comments
I totally agree. Not only that, tools can vary depending on which industry you are shipping product in. If it has anything to do with finance or healthcare, PCI and HIPAA compliance can certainly impact what tools your security/compliance officer may or may not restrict. Many frown heavily at "cloud", which means more than half the tools in this blog posts could not be used if he decided against it.
I've been in all sorts of startups from small <$80K to $150M; the tools we used always changed, but post-it notes and whiteboarding were universal no matter the size. :) I know this post is about small startups but just for perspective...
The most consistent processes, which a lot of startups misunderstand when scaling up hence why MBAs fit in well here, are the ones that flow between the various departments like business, sales, engineering, marketing.
How each project is then executed within the various teams will change greatly based on the business. For an engineer at a previous bank I worked for, you have to consider audit trails, PCI compliance, two-person authentication for deployments, etc. It took 8 people to make one deployment to a production server with less than 1,000 uniques per day.
To most tech startups, the inefficiency is appalling and frustrating. That's why I left. But to federal regulators, it's necessary processes in place to maintain integrity.
I've been in all sorts of startups from small <$80K to $150M; the tools we used always changed, but post-it notes and whiteboarding were universal no matter the size. :) I know this post is about small startups but just for perspective...
The most consistent processes, which a lot of startups misunderstand when scaling up hence why MBAs fit in well here, are the ones that flow between the various departments like business, sales, engineering, marketing.
How each project is then executed within the various teams will change greatly based on the business. For an engineer at a previous bank I worked for, you have to consider audit trails, PCI compliance, two-person authentication for deployments, etc. It took 8 people to make one deployment to a production server with less than 1,000 uniques per day.
To most tech startups, the inefficiency is appalling and frustrating. That's why I left. But to federal regulators, it's necessary processes in place to maintain integrity.
In theory, I agree with process over tool, and I have seen tool-fetish harming collaboration before. On the flip side, I welcome processes that are naturally evolving with the use of some tools, I don't think we should be too rigid on whether the tool or the process comes first. Whiteboards and post-its may be great if you are working alone, or with people in the same physical space. If you are scattered across different time-zones, these simple tools are not sufficient to mediate collaboration remotely. You have to figure out ways to emulate being in the same physical space to begin with, in order to be in the same mental space. That's when different tools become relevant. And as we figure out best uses of new tools, we might witness the emergence of a new process that was not around or relevant 10 years ago. For this reason, I enjoy these type of posts where people share their collaboration setup, I find them inspiring.
Worth throwing in my article about this topic: http://swombat.com/2011/10/24/people-processes-tools
Processes definitely come before tools. People come even before processes, though.
Processes definitely come before tools. People come even before processes, though.
Process process process, Jesus fucking.christ. it's around every.corner now. You know what process works? The ones your developers will do. It's no the same for every developer. I.can't function in Scrum, but my own process works great for me. Some people can't work in my process but function great in Scrum. Whatever the system is just work with your.developers to figure out.how they become happy. So sick of these posts detailing.complicated solutions when sitting down and having a few fucking.conversations with your developers would solve it.</rant>
We use Pivotal Tracker, Skype group chat, TeamViewer, Dropbox, and email. I'm pretty happy with this setup for daily/weekly product development and planning. I do want to give Trello a try though, to keep track of hi-level tasks (e.g. doing research) and on-going brainstorms (e.g. strategic product decisions) that are not immediately tactical/dev tasks. Would love to hear thoughts from people who use Trello or other tools for these purposes.
Well, for us "Asana + Facebook chat + Email + Dropbox + Google Docs" works right now. Although, I know that we don't have "a process of a dream", in fact.
I liked this talk about distributed team in Treehouse - http://vimeo.com/47271938 - of course, it's about rather a big company but has interesting points for anyone, I guess (I also liked 4-day workweek idea).
The thing that struck me immediately was focus on tools. Process is not about tools. Tools do not solve problems (believe me as you grow they'll cause many problems).
Figure out* process, only then look for or make the tools that you need. Best to start out with the simplest thing that could possibly work. Which for many is whiteboards or some similar low tech solution.
* you (should) never stop evaluating and improving process. One of the best processes to adopt is "iteration" with bits of evaluation and planning in between.