One Agile process to bring them all

…forged in secret by the Dark Lord?

Andrew Colclough
Apr 18, 2014 · 6 min read

That title sits on a throne of lies. In my opinion, there is no right way to organize your team if you are trying to work in an Agile way. I’ve seen as many implementations of process, as teams I have worked with. Perhaps a better statement is that the right way to be agile is what works best for your particular team. Furthermore — when discussing these ideas, it’s critical to remember that Agile isn’t really about tools and process anyway.

Fantastic. So what is the point of this piece?

Here’s a diagram of how our team works:

What are we building here…Beer growlers?

Our Ideal Process: The Invisible Hand

“He will therefore have to use what knowledge he can achieve, not to shape the results as the craftsman shapes his handiwork, but rather to cultivate a growth by providing the appropriate environment, in the manner in which the gardener does this for his plants.”
-Friedrich August von Hayek

Weapons of choice: Git and Pivotal Tracker

Our process makes use of two tools:


We use Git for versioning and branching our work. Our branching strategy is based around this classic post. You may be familiar with this diagram:

This phenomenal chart was created by the folks at

What we have done is merely distilled this idea down, and integrated it with our project tracking software.

Pivotal Tracker

For issue tracking we use Pivotal Tracker because it is straightforward, and requires very little mucking about to keep our work organized.

It doesn’t matter to me what tracking (or versioning, for that matter) software you choose (for instance, if you use github issue tracker: check out, but the various states for issues in our diagram map directly to Pivotal.

aka: Guessing.


The short sprint

We run a tight one week sprint. We didn’t start this way, but we always had this as a goal. The benefit for us with this is that it dramatically lowers the risk involved with planning. Our predictions for tasks are trimmed down and become reasonably accurate. In this way, we are able to adjust and adapt rapidly to changes, or unexpected delays and problems.

The downside to short cycles is that this does require more frequent meetings. With that said, we all loathe meetings, so we try to keep them as focused and brief as possible. If something can be achieved outside a meeting, or just between a couple people, we do it that way. With only a week of work, there is usually a lot less to discuss and estimate anyway.


We use a relative point system for estimating work, but the specifics of it will likely be irrelevant to your team. One important aspect: We do maintain a point value (our highest) that indicates a task must be broken down into smaller pieces.

The requirements for items and the priority of each is set by our product manager outside of our meetings. Bugs are typically prioritized above new features.

Development Cycle

After planning we enter our development cycle which combines our Git branching strategy with the states that can be assigned to Pivotal items.

Our daily work

We now take the top most item in our backlog, and Start it.


This is where the doing arts and haxxoring happens. Nerds gonna nerd.

Whoever is involved or assigned to a feature creates a new feature branch with Git. Typically we name the branch something similar to the task name (or something funny), but we always end it with the number that maps to the Pivotal item. Something like:


The developer(s) makes work commits to this branch until completed. We follow the Angular format for our commit messages like this:

"feat(yard): adds more boys [#8252013]"

A handy feature of Pivotal is that it can hook into our Git repository. Tagging a commit message with the tracker number attaches that commit message (and a link to the commit on github) to the work log in Pivotal.

A handy log of commit messages attached to each ticket.

No duplication of effort.

When the development work on an item is complete, we mark it in Pivotal as Finished.

Quality Assurance

Dev Builds. Q.A. Delivers

The next stage in Pivotal after an item is marked finished, is delivery. We don’t deliver anything until it has passed through Q. A. In fact, developers are not even allowed to deliver.

When developers finish a feature, we initiate a pull request to our Q.A. engineers. They then merge the feature branch into a Q.A. branch and begin testing. Anything that does not pass their testing is marked in Pivotal as ‘Rejected.

Rejected items are kicked back to development (in Pivotal, the action changes to Restart), and the changes are reverted out of the Q.A. branch in Git.

Items that do pass Q. A. are Delivered.

Management Review

Is this what I asked for?

Our product manager then reviews what Dev and Q. A. have delivered to see if it matches their requirements and the business needs. This is also done in the Q. A. branch so that our develop branch isn’t polluted with crufty cruft. (The idea is that develop is always clean so that a release branch could be cut at any time.) This item is either Accepted, or Rejected. Again, Rejected items are reverted out of the branch, and set to be restarted by development.

Ideally, an item delivered should be accepted or rejected as quickly as possible. This makes it easier for development to revisit an item which was rejected, before totally shifting gears to something different.

If an item is Accepted, it is merged into develop, and slated for release. And there is much rejoicing.

Next work item.

I know, right?

Seriously though, this approach has worked incredibly well for our team, though we continue to tweak and optimize aspects of it as we roll along. Our team has delivered on many promises, and had very few set-backs. This has allowed us the freedom to experiment with new ideas, like Mob Programming, because we have earned the trust of our business.

Remember, as I started — we don’t believe there is only one good approach to process. The process that is best for you will depend greatly on your product and what sort of people make up your team. We are sharing ours in the hope that it gives you someplace to start.

If you would like to steal our diagram, here is a full resolution version to print, or do with as you please.

    Andrew Colclough

    Written by

    Uh...had a slight UI malfunction. But, uh, everything's perfectly all right now. We're fine. We're all fine here, now, thank you. How are you?