There are two sides of a software project that are critical for success: the tactical side (the how) and the strategic side (the what). Trading one for the other may result in short-term gains, but will cost your project in the long run. Project success depends on meeting both. This is similar to Sailing where we need to have both great teamwork and an excellent strategy to win.

Achieving a strategic victory means building the right product. This means a product that will give you a good return on investment, be it market share, cost savings, or increased sales. This is essential, but not sufficient, to a successful project. Building what customers need without good technical quality will ultimately result in product failure. Whether this is due to customer complaints, maintenance costs or slowed future velocity, inattention to technical excellence will be paid in spades later and is seldom worth sacrificing for quicker time to market. A short-term win at the expense of quality or team morale may be tempting. Hitting a trade show deadline may allow your company to increase sales or become an acquisition target sooner. And it will severely limit future options for capitalizing on this success. Your teams won’t have the flexibility or speed to change course when you need it most. As military strategists say “You’re always preparing for the last war you fought.”

The tactical side focuses on the means you use to build your product. Did you reach your scope, schedule, quality, budgetary goals? Is your team intact or burnt out? Achieving a tactical victory does not mean you’ve succeeded. How many of us have been on projects where the teams have delivered high quality software on time, under budget, on scope and the product was poorly received in the marketplace, or never even used. Tactical victories, while necessary, are not sufficient for project success.

This concept is similar to a term that I heard when racing sailboats. When you are sailing “inside the boat,” you are focused on the tactical aspect of sailing: making clean tacks and jibes, hoisting and lowering sails, working well as a team, and generally handling the boat well.

But if there is a lot of noisy communication, missed tacks and jibes, confusion and timing issues, you are not going as fast as you could. Not only speed, but your ability to change course is compromised. This is arguable even more equally important than straight line speed as conditions change so often. If you can’t tack or jibe in 30 seconds or less you are closing off options for the skipper to respond to the changing conditions on the course. I have been in races that have been lost because we did not tack fast enough on a 180 degree wind shift. Had we been a better team, we would have seen the change in conditions and responded.

If these issues are happening to your sailing team, old salts will tell you that you need to focus on teamwork. You need to practice together as a team every day and routinely reflect on what happened after every practice. Whether you have green sailors or a boat full of “hot shots,” if they have never sailed before, there is a going to be a certain amount of chaos that needs to be worked through before there’s a chance for a strategic victory. And when you work through that chaos,  build your team and you understand each other, it is a beautiful thing. Team members speak their own language incomprehensible to outsiders, rely on verbal and non-verbal queues to get the job done quickly and quietly. The skipper is free to look outside the boat and see where the fleet is, where the wind shifts are coming from, what the distance is to the mark.

This sailing “outside the boat” means you are paying attention to external conditions: the wind shifts, puffs, headers, lifts, and the ebbs and floods that may within minutes change the whole outcome of the race. Only when you have mastered teamwork can you play in the high seas of the strategy.

Software is similar to sailing. Both environments are hard because they have constant change. Peter Vaill, organizational development expert, calls it “Permanent Whitewater”. Our businesses, like a yacht race, are constantly changing due to new markets, competitors and acquisitions. Not only that, but the pace of change for technology is ever ratcheting up. Both sailing and software attract the best and the brightest, because of this difficulty. If software were easy, then everyone would be doing it.

In Scrum, we adapt to this change by focus both on the how and the what simultaneously. We put the team in charge of the how. Are we living up to our working agreements, meeting our definition of done, delivering working code each sprint? Are we working through our divergence to convergence, whether it be coding standards, design, testing? Or are we sweeping team issues under the rug only to have them blow up later? We put the ScrumMaster in charge of helping the team jell, to see the teamwork issues that are hindering top performance. The ScrumMaster does this through paying attention to the daily scrum meeting, facilitating team retrospectives and listening for problems. This is identical to what a good crew captain would do on a sailboat.

But what about the strategic side, the what? Who is paying attention to that? This is the role of the product owner. The product owner is in charge of watching the competition, monitoring the burn rate, assessing the recent demos and watching for release opportunities like a master tactician would be watching the fleet during a race.

Does the product owner intervene and tell the developers how to implement the software? Does the navigator help hoist the sails or direct the crew how to coil a line or fold a sail? Such activities have marginal utility. While the team may need some assistance with this, they will learn through their frequent retrospectives on what works and will not work for them. Once they have these maneuvers down, they are depending on the product owner to help them win the race by looking “outside the boat” at the ever-changing market conditions, competitive threats and opportunities and quickly change course so they can win.

Does achieving great teamwork, technical excellence or on-time projects mean that your project will succeed? Not necessarily. Even your ability to change course quickly does not ensure success. But if you don’t have those, then you will surely fail as new market opportunities present themselves, and you are powerless to take advantage of them.

So what do you do? As a delivery team and Scrum Master, do everything  is make your Product Owner look great, deliver on time and with high quality, so they can focus on achieving a strategic victory by releasing early, getting customer feedback and making a great product. As Product Owner let the team own the how, giving them plenty of time to inspect and adapt and learn from their mistakes. Focus on early release opportunities so you can get market feedback and be open to changing course if you need to. This will help ensure project success.

Tags: product owner, Scrum, strategy, teamwork

Permalink

This entry was posted on Sunday, February 8th, 2009 at 7:54 pm and is filed under Scrum. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.