One Agile process to bring them all
…forged in secret by the Dark Lord?
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?
Our team has happened to stumble into a process that is working really well for us. We have been trying to create a simple way to communicate and share our ideas with our fellow teams, and it follows that we should also share with anyone. If you are like us, I’m sure you’d rather spend your time building value, than Yak Shaving. Hopefully, at the very least, this could be a place to start from.
Here’s a diagram of how our team works:
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
Like the quote above about economists, the primary goal of our process is to create an environment that encourages our team to grow and become as efficient as possible. We want to spend the bulk of our time building and delivering value that matches the desires of our business. And to us, the sign of a good process is how little we think about it, fiddle with it, or meet about it.
Weapons of choice: Git and Pivotal Tracker
Our process makes use of two tools:
Git
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:
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 waffle.io), but the various states for issues in our diagram map directly to Pivotal.
Planning
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.
Estimates
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.
We now take the top most item in our backlog, and Start it.
Development
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:
feature/bring-all-boys-to-the-yard-8252013The 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.
No duplication of effort.
When the development work on an item is complete, we mark it in Pivotal as Finished.
Quality Assurance
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
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.
