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.

Not the only one who thinks constraints are required

An older post by Obie Fernandez speaks to the constraint thread I find running through many disciplines. I've now spent almost 8 months trying to bring agile to a traditional design agency and we've had some amazing success and terrible failures. I went back and read through all my blog entries I created at the start of this journey and I never explained what my thoughts and perspectives are on constraints.

When solving a problem in a problem space with almost unlimited possible solutions, such as architecture, graphic design, or software engineering, the use of an over-arching design principal is absolutely required for success. Really good solutions often rendre the underlying principal invisible. The visitor to the solution site (words, websites, code) may not be able to immediately artiuclate what the principal or principals were, but they can immediately tell a well-ordered paradigm. The Kool-Aid crowd of the RoR scene has embraced a very strong design principal in Rails. What are some other examples of this principal at work?

Graphic designers have to tell a story when creating their portfolio. There has to be an arc to the story they tell. It's often useful to think, ok, this portofolio is going to evolve along the color wheel. The start of the book will be red, then green, then blue. I will tell a story using color. The solution is transparent, yet the visitor feels a smooth sense of flow to the book without knowing why. It doesn't matter whether they identify the arc or not, its existence and the book's adhearance to the rule makes it coherant.

Usability is the study of creating a coherant language in your software site. The use of personas and stories with a "so that" clause are great examples of creating a well-defined guiding principal that leads to a condition of self-contained coherance. It is very much a semoitic practice. Well designed software contains a very easy to grasp completely consistent internal logic. It may be for grandma instead of Skippy Jr., but it doesn't matter; when the logic is consistent (due of course to rigid adhearance to a simple constraint), the user is able to explore and map out the semoitic rules of the system. The surface of the software is discoverable and the way through the rabbit hole quickly becomes well-known.

OOAD uses this same technique. A well designed object has multiple constraints: closed for modification but open for extension; clearly defined responsibility; encapsulation; loose coupling; etc. When you read code that follows these prinicipals, you always already know what it does when you read it. The more you read the good code out there, you start to absorb the zeitgeist of patterns subliminally, and you start to try to factor your own code to follow these well known best practices.

Biggest take away from trying to do things right: It takes constant, ceaseless, undying devotion. The difference between doing right and doing wrong is not the amount of work or the intensity factor. It's just that you get a lot more high quality work done in less time. Desiging good OO code is really hard and coders under pressure will always revert to desperate perl hacking with arrays and hashes. Doing a stand up every dayis hard because something more "urgent" (but less important) will always come up. Tracking velocity is brutal because every day it tells you that you and/or your management (or client) is full of shit and you're not going to get it all done on time (probably because most of what you're doing is not valuable anyway and you haven't thrown out the junk with enough constraints - you were driving to get the dollar rather than being driven by a well defined ROI MMF business reality).

Biggest Failures

• No code review, whether by pairing or old school diffing code check-ins
• Letting ruby kool aid drinkers baffle me with bullshit when i should have seen the desperate perl hacker array and hash smash from miles away (badly named classes with no clearly defined responsibilities, more spaghetti than the tower of pisa, etc).

Biggest Successes

• Creating a true build and deploy cycle so that bad code doesn't escape into the wild
• Pivotal Tracker - it is a relentless pain to constantly drive a whole team, from business leader stakeholders down to developers to all communicate in terms of business value, but the moment you let the devs go off into implementation details or the business owners look for short cuts and quick cash, you will lose your guiding principals, all benefit and value of simple constraints and SDD goes out the window. You can't ever stray from the noble truths.

Ok this post is like a mega brain fart that has books worth of ideas in it, but i just needed to blat some of this out and get on paper so to speak. I need to really develop this idea of design constraints as a critical component for success. My unique experiences in both the design and software fields, combined with my philosophy background, gives me an interesting perspective (or the ability to endlessly romance the sound of my own keyboard clacking, you decide).