What is strategy?

Strategy is the process of choosing a broad goal, creating measurable objectives, executing a plan, and seeing if your execution is driving towards the objectives. It sounds incredibly easy, yet very few people are capable of actually conducting themselves in this manner in a professional context. You could ask many reasons why, but that wouldn't help you make the change.

Agile development methodologies are all about coming up with short, concise, measurable objectives in the form of a lightweight spec, such as a user story. I don't know if it is beneficial for team members to really get their head around the mechanics of how an effective strategy works. I think one of the outputs of effective strategic execution is predictable results, such as being able to forecast a team's velocity.

I'll tell a little parable that illustrates how even in the simplest of situations, our emotions and other psychological inputs can distract us from executing our strategy. Anyone who knows anyone from New York City and its environs will be amazed to find that New Yorkers talk about trains the way people in other cities talk about traffic. And anyone who lives in the boroughs is required to understand the nuance and intricacies of the train schedules on the weekend.

My fiancee has been spending a lot of time with me in NYC and I've had to explain all of my strategies to her for effective train riding. Check out the system map if you're not familiar. Our apartment is in Ft. Greene right near one of the busiest subway stations, Atlantic-Pacific. From our house you are within 3 blocks of the A, B, C, D, Q, G, M, N, R, 2, 3, 4, and 5 trains! So the question is often, which train should I take? Well, the entrance that is closest to our house takes you right down to the platform where the B/Q can be caught, so we almost always take these two lines.

So that right there is an example of strategy in action: our goal is to wander the least and catch a train in the least amount of time that will get us to our destination in the least amount of time. The N and the Q are probably the 2 best trains that go through the station, but a stupid strategy would be to go downstairs and if the Q isn't there, go get the N - this is because in the time it takes you to walk to the N, you will probably miss the B or the Q. If I am trying to go somewhere that is only serviced by the Broadway line, I will still just wait for the Q (unless of course it is a weekend in which case I will walk over to the D/N platform since those trains, while requiring an extra walk, are more reliable on the weekend).

Now my office is over on 26th between 6th and 7th. The very closest station is in fact the 1 train station at 7th ave and 28th street. But the 2/3 is really slow and I have to transfer from the 2/3 to the 1, so this route is automatically out of the running. The next closest is the F train station at 23rd and 6th, so if I catch the B train, I have a strategy: if I pull into Broadway/Lafayette or West 4th, and the F train is pulling in at the exact same time, such that I can catch the F with no waiting, it is faster to take the F. Otherwise I just stay on the B and take it up to 34th street, the next stop after W. 4th. While this is a longer walk, waiting for the F is longer.

Does this make any sense? I've optimized my journey for the MOST important objective, which is to get to work in the least time possible so that I can sleep later and eat breakfast at home which is healthier than eating a bagel and cream cheese from the deli. The objective of getting to the station that is closest to my office is less important than getting to my office quickly. Doing the extra walk from 34th street also serves a nice-to-have objective of trying to get as much exercise as I can even when I don't go to the gym.

There are myriad choices to get from my house to the office, and all of them will eventually result in my arrival at work; however, I've clearly identified an objective, which is different from a goal since it is measurable, which is to get to work in the least amount of time possible for the least amount of money. There are many decision points along the way, but by limiting the number of branches in the decision-making process, I have arrived at a very consistent formula. If I take the B or the Q, I know I can be at work, door-to-door, in about 40 minutes. Taking the F may reduce this time by a few minutes, but the risk of sitting on the F train platform for 5 minutes (which happens maybe 1 out of 3 times I choose to do so) is not a risk worth taking.

Teams doing work need to limit their choices and come up with a consistent tactic to getting work done quickly by choosing the right goals and objectives. Over and over again, I find the most effective way to trim time off of projects getting done is to force developers to give me code that I can acceptance test on the build host. I generally don't consider any of the sub-stories of value, I only care about stories like, "As the public, I can see this website feature do something." Plumbing may have been required to get there, but the surest way to know if the plumbing, chores, sysadmin crap, and all other work required to get paid - because that is the mother of all objectives - is if I have a working website that lets me exercise the story in question. Letting broken untestable or unacceptable (meaning work that can not be acceptance tested) sit around is classic waste in the lean sense of the word.

Agile isn't easy

I'm sure other people tranistioning to agile have had this thought. Isn't agile supposed to make my job easier? Won't I have more time to golf and relax? And yet, agile seems to be harder, and require more work and effort, than doing things business as usual. Well, guess what? Executing great work at the highest level is hard! It's harder than business as usual. But it pays dividends. You delight your customers, you have a happy, satisfied team doing valuable work.

The moment the team stops doing work against stories its committed to, the magic leaves the room, quickly and dramatically. This is your fault as the product owner or business manager, not the teams. Business inputs will constantly distract you, customers will constantly derail you, personal issues will manifest in your team's lives. The world will never cease in its efforts to derail, and that's why you have the hardest job of all as the product owner. You're the glue holding the whole thing together, keeping the world at bay.

It actually reminds me a lot of skeet shooting. Shotguns are weird weapons, and skeet shooting is quite the challenge: you're trying to hit a moving target with an explosive burst of shot. You're not sitting there at the range, lying prone, taking as much time as you need to put the bead on the bullseye. You've got at most 2-3 seconds where the clay will be close enough to the target area where your shot will hit it with any force.

The magic of the shotgun is that you don't aim down a site. You line up your vision to the sites - you put your entire upper body and vision in alignment so that you can follow the target with your eye. You no longer aim. You see the target line up, you squeeze the trigger, and pow! it explodes.

This reminds me a lot of setting the goals for a sprint. It's all mental. You have to line everything up to hit the target before shouting "pull!" and if you don't, you're guaranteed not to hit this elusive target. Go down to your local clay shooting range and try it out, you'll find it weirdly identical to leading a software team. Take your whole team as a team-building excercise. There's something interesting that happens when you fire deadly weapons together safely.

Scrum requires teams

In order for teams to manage themselves, they need to be dependent on one another for direction. They can not look to the ScrumMaster or Product Owner for direction or orders. The team uses its abilities ranging from subject matter expertise to best gut instincts to make its own decisions. It is very much like a sports team where everybody has a role, but the team wins games as a team, not as individuals. In Hockey, you get the same amount of points for an assist as you do for scoring a goal and it is the same in work.

The reason Scrum and stand-ups never worked at my old job was because "team" members were pitted against one another. It was a Lord of the Flies, survival of the fittest, where progress was always reported to some kind of boss man. No one in the group ever had a stake in the success or failure of the work other team members were doing. It was much more like a World Rally Cross event, where team members all drove Subarus but were conducting their own race, competing with each other to win each stage of the rally. It was awful.