How Newstex Gets Things Done (GTD)

Newstex is a very fast-paced company, developing and deploying new products in weeks, not years. We often find ourselves pumping out several updates to our systems every week, sometimes even daily.  In order to keep up with this fast paced work environment, we don't use a typical development methodology. Often when I ask potential developers what process methodology they use, they simply say "Agile".

Agile is not a methodology, it's a type of methodology

The term "Agile" actually just describes the type of methodology. So if you say you're using "Agile" as your process methodology, you really have no process. There are a few typical Agile methodologies that are used, Scrum being the most popular. If you simply have no process of what order things get done, or how new development tasks, bugs, improvements, or other issues get into your system, and you have no standard for how changes are reviewed and deployed, you don't have a process methodology at all. This can lead to a lot of potential issues, especially if you have a large number of developers all working on code at the same time.

Newstex is a completely virtual company, with no physical offices. This means that Process methodology is even more important, as you can't simply walk over to someone's desk if you break something and beg for mercy. Process is important to keep everyone on track and prevent flailing. However, it's also important to prevent from adding so much process that you don't get anything done.

Getting Things Done (GTD)

At Newstex, we use an modification of the Agile process Getting Things Done (GTD) pioneered by David Allen. The concepts behind this process are simple, yet very effective. The idea is that you are most effective working on a day-by-day basis, at what you feel you can accomplish during that day. If you don't feel like working on a certain task, then you'll be less effective at doing that task.

At it's simplest form, GTD requires you to maintain 3 queues; Today, Soon (or "Tomorrow"), and Someday. At the beginning of every day, you add items to your "Today" list; items which you want to accomplish within that day. At the end of the day, you review your list and cross off everything you completed, add in and cross off anything from any other queue you may have also completed, and anything that's left on your Today list to one of the other two queues.

The "Soon" or "Tomorrow" queue is for items that need to be done soon. These are items that you can't get done in the current day (or wont be able to start), but things that are high priority and need to be addressed soon. These are the items that you should pull from in the beginning of the day when choosing your list of tasks to complete.

The "Someday" queue is for items that you would like to get done, but aren't high priority or mission critical. If you have extra time here or there, you can use these to fill in. The idea is that you don't pick items up from this list unless it's very convenient to do so; such as already working on a particular part of code and the change being very close to where you are working.

Tools

Once you get beyond just yourself working off of your queues, you start to realize that you need much more then a simple list of post-it notes or notecards. At Newstex, we went through several different ticket management systems until we finally settled on Chili Project. It doesn't really matter what ticket management system you use as long as it can handle tracking time, priorities (for queues), and assignments. 

We use slightly more then a Today, Soon, and Tomorrow list, allowing actual scheduling of due dates, more levels of priorities, and dependencies. The most important thing to remember is that each Task is an action item that must be closable. For example "Add date to headline" is a good ticket, but "Improve Headline" isn't. Anything that is subjective and doesn't have a clear defined end-point shouldn't be a ticket. 

Another good thing to do is to try to keep each ticket as a small one-day task. If a ticket is too large, we try to split it up into separate discrete tasks. Since some things simply aren't able to be split apart, we also use the built-in progress tracking to make sure we can keep up with what we are working on, how far along we are, and add any notes about what we've gotten done. It's very important to make sure to do this at the end of every day so everyone knows exactly what's being done by everyone else, and to prevent two people from attacking the same task at once.

More important then process is hiring "A" developers

No matter what process you have (or don't have), everything can come to a horrible crash if you don't have all top-level developers. More important than any set of rules or procedures is making sure your developers all have common sense. That means testing code rigorously before deployment, and making sure to verify all changes are correct. This is often the hardest part, and it's one of the reasons that Newstex has a very small development team, and continuously goes through developers, keeping only the best. 

At Newstex we hire roughly 10% of the candidates that apply, and only 1% of those candidates are kept after their initial trial period. During this trial period developers are not given access to any production systems or code. They are presented with several major tasks to complete, and all of their code is reviewed by several team members before it can be merged into production. Their code is evaluated both for correct behavior, and for proper styling and methodology. Newstex has a set of coding standards that dictate how code is formatted, as well as how certain tasks are to be completed. This is very important to maintain so that any developer can pick up and fix any part of code no matter who wrote it. Documentation in a large system like Newstex's is absolutely key.

The average day in a GTD Process at Newstex

The average developer at Newstex starts off the day by sitting down at the list of tasks assigned to them (or unassigned tasks if they have none). If they already have tasks In Progress, they review what they've accomplished and what still needs to be done, and then go to work on those tasks. If they do not have any In Progress tasks, they pick a few tasks out by priority that they feel they can get done in the current day and then mark them as In Progress. From there they begin working on their task list in whatever order makes sense to them. This is different for every developer, but usually involves what they are most familiar with or have freshest in their memory. They keep track of their total time spent on each individual task, and mark completions as they finish them. At the end of the day, they finish marking up anything they completed, and put down progresses with notes on anything not completed.

Newstex also mixes in a scheduled weekly meeting every Friday with all developers, which go over the list of tasks they completed in the previous week, as well as the list of tasks they plan to complete in the following week. This helps all the teams keep in touch with what everyone else is doing, and is very important for Newstex as a virtual development community.

The final piece of Newstex's development cycle is releasing code. We have development, testing, and production environments, but much of our work simply can't be tested properly without going full scale. The process of deploying new code is to go through our development and testing environments, and then deploy to production and always be ready to roll back in case of an emergency. We perform incremental deployments of our code, often developing, testing, and deploying code within the same day. Quick testing followed by full scale deployment and monitoring are our best allies in keeping up with all the changes that need to be done every day. This helps us to prevent from our queues from becoming too backlogged over time and preventing any forward progress.

What do you think?

Do you work at a company that follows any process methodologies? What tips and tricks do you have for working at an "Agile" company?