These are the set of commands to checkout a branch of a repository from Github, which is not immediately obvious the first time you try it.

First clone the repo if you haven’t:

git clone url-to-repo-you-want

Clone has already checked out the branches, but it only initially creates the master branch. You have to tell it to create the other branches you might want.

To do that:

git checkout -t origin/branch-name

This will checkout and create a branch that has the name branch-name and that tracks the remote branch at origin/branch-name.

If you want your branch to have a different name from the remote branch:

git checkout -t -b your-branch-name origin/branch-name

This creates a branch with your-branch-name that tracks the branch at origin/branch-name.

Because these commands uses checkout you will then have the new branch as your current working branch. You can use git branch with the -t (–track) flag to create the branch without switching to it.

If you’re working in a repo you’ve already cloned and want to checkout a newer branch, it maybe necessary to do a git fetch first to make sure your local checkout knows about the remote branch before you create a local branch.

It’s easy to think that the agile movement has been around forever. It certainly feels like it has in the raging torrent that is software development time. Yet if you read the Agile Manifesto that started it all, at the bottom, in small letters, you’ll notice the copyright date.

© 2001.

Only ten years ago the agile movement formally started. I’m sure it was around informally before then. Now it’s an institution that is embodied in methodologies and programs from XP to Scrum.

It good to read the manifesto that started it all. To see the simplicity that launched a movement. Because overtime, as is human nature, we keep adding on facets, until we forget what the original item looked like. This can be for better or worse (think a person from the 50s would recognize a TV today as a TV, if it wasn’t on?).

One facet we’ve added is the concept of velocity. Jim Highsmith details nicely how the concept of velocity has been stretched so it chokes the agile process. A key quote:

Compounding the problem, the Agile movement has focused on high levels of customer involvement—basically a good thing—but we’ve gone too far. A large number of Agilists decry that they can’t get organizations to focus on technical practices—but why should that be a surprise when we encourage product managers/owners to make all the priority decisions and then measure performance using velocity?

This point is spot on. In my experience, product owners are often given complete control over priority, so technical optimizations or necessary muck work aren’t prioritized. Going back to the agile manifesto, read over the names of the original signers. They all have experience in the technical and the business sides of the equation. They intuitively know how to balance both. Now that agile has gained widespread adoption, teams do not necessarily have this experience.

The idea of the self organizing team needs to return to the agile movement. The team doesn’t have to be self organizing in that team members constantly change. That becomes too disruptive. The team needs to be self organizing in that the team picks the order of the work they will complete. The product owner might set priority, but it is the team that takes on the work and the order they complete it. There is obviously back and forth between the team and the product owner, but as the manifesto says: people over process. We trust that the team will organize itself, taking into consideration the wishes of the business, so that the work gets done as quickly as possible with the highest quality.

I think people often forget that agile is not a rigid system to be followed. It is simply a belief that change is constant, so we should favor a way of doing things that makes change easy.

In short, do what works for you so that you develop quality software on time. That’s the definition of agile, with all the trappings stripped away.

And so development starts / CC License

It’s certainly true that you can’t guess the path your life will take. When I was a child I remember looking at my father, who was a career military man, and thinking that I’d go to college, graduate, find a good company to work for, and stay there the rest of my working life until I retired.

It turns out that in my fourth year out of college I am already working at my fourth job. I intend to stay at this one for a while. While I enjoyed my time at iContact and thank them for everything they did for me, on October 17th I started work for Opscode, the company behind Chef.

The Opscode team is an amazing group and I lept at the chance to go work for them. It’s a change to go from scaling email sending to infrastructure automation, but I’m excited at the challenge. It’s yet another interesting problem to vex me until I conquer it.

It’s time to further sharpen my skills and help companies Rule the Cloud.

Knives / CC License