Skip to Content

Draggin’ boat racing vs. Dragon boat racing

The trick with combining the Run Simple principle with the Agile engineering approach


Years ago when I worked for NCR, I agreed to be part of their dragon boat racing team. Years of childhood experience rowing a small metal dinghy around rocky coves in Maine made me certain I’d be an asset to the team. After all, I could row fast and straight, had a powerful stroke, and an eerie knack for steering clear of the hull-busting rocks that lurked beneath the surface. But while all these skills helped me as an individual row a dinghy, they didn’t mean much on a dragon boat team.

When I arrived to the first practice, the team captain didn’t ask about our rowing experience or ask us to show our ability. Instead, he arranged us by height and weight in a long wooden boat with a flat hull and shallow draft. Then he told us the only two things he wanted us to be good at: moving in synchrony and maintaining good form


At first I guessed these goals were to ensure a win. Soon, I learned it was about not getting your fingers mashed, back crushed, and not falling overboard. In a dragon boat, I couldn’t row as fast as I wanted; the drummer in the bow set the pace of my strokes. I couldn’t steer when I thought we should; that’s the job of the sweep, who stands in the stern and steers with an oar.  I didn’t  even get to see the finish line; my job during the run was to move in perfect synchrony with the rower whose back was inches from my nose.

Individuality compromises success when a group of individuals has to move as one like this. I could see that synchrony and form (working in parallel and following process) were the hallmarks of a successful dragon boat team. If you didn’t have these, you might not capsize, but you wouldn’t win either. The team IS the individual, racing other individuals to a goal.

Years later, as an information product developer nestled inside an Agile engineering team, the analogy of the dragon boat team doesn’t stay far from mind. Working in parallel and following process equates to moving in synchrony and maintaining good form. The team roles are engineers, authors, testers, translators, etc. Our dates and milestones are our course and finish line.  The whole team moving as one; the very stuff of Agile.

The wake of a boat tells the tale of its run

In a dragon boat, a rower can’t decide to skip every 10th stroke because it would be simpler for them. The drummer can’t suddenly play a recording of a drum beat because it’s simpler than banging a drum. The sweep can’t put a brace on the steering oar to simplify steering. If roles make unilateral decisions about running simple, members get bashed, the boat lists and drags its way though the course, and the win is lost.

You can tell a lot about how a boat run went by looking at its wake.

The Run Simple principle at SAP encourages us to look at the processes we are following, question whether they are adding or generating value, and consider if there are better ways of doing what we’re doing. If what we are doing brings little value compared to cost or effort, or if there is a better way to do something, we are encouraged to strive to change the process. If you had to shorten this description, it’d be something like: “Stop doing stupid stuff.”

This continual re-examination of processes aims to minimize the anesthetizing effects of the “we’ve always done that”, or “we’ve always done things like that” mentality that decades of process induces.

~~ Only the guy who isn’t rowing has time to rock the boat.   

– Jean-Paul Sartre      

The problem is, though, everyone has their own view about which stuff is stupid, and that view is usually pretty myopic. In an Agile development where the team needs to move like an individual, you can’t have everyone unilaterally changing process under the guise of Running Simpler. That usually results in someone else having to compensate for the decision. For example, if an engineer decides to skip communicating feature design (or later changes to the design) until the end of development, testers, UI designers, and authors can’t plan ahead. Work that should start nearly in parallel will start late, and chances are their work won’t be correct.

You can tell a lot about how a project went by looking at its post mortem findings.

Your post mortem will highlight problems in process. But it may also show you that some problems are about compliance to process and not process.

Inviting Run Simple on board

Applying the Run Simple principle in the context of Agile means making strategic changes to process that ensure an economy of effort for the *entire* team, not just one role or a few members. So how do you ensure that?

  • Involve the entire Agile team in the process of process. No unilateral decisions to change, ignore, or abandon processes mid-project.
  • Evaluate as a team how each process change impacts communication between team members (and Support and users!)
  • Evaluate as a team how each process change impacts synchrony for team members who have the same finish line to cross (GA date).
  • Again, use your post mortem to see where there were imbalances, processes that make things easier for some members but harder for others.

If members aren’t on board for moving as a team, well, there’s always sculling 🙂

Be the first to leave a comment
You must be Logged on to comment or reply to a post.