Steve Neiderhauser

Into The Storm

If you’re going through hell, keep going.

— Winston Churchill

 

Author Dennis Perkins pens his latest leadership book, Into the Storm. The author tells the story of the 1998 Sydney to Hobart sailboat race in a concise and entertaining fashion. I found myself flying through page after page to see how the story ends.

 

The author paints a picture of turbulent storm conditions: 80 foot waves and 105-mile-an-hour winds. While many boats decided to sail around the storm, the crew of the AFR Midnight Rambler choose to head into the storm and sail through it.

 

The decision to go through the storm along with the crew’s talent and teamwork enabled the Rambler’s team to beat professional sailers on larger and better funded boats.

 

After studying the treacherous 1998 race — and the Midnight Rambler’s journey of victory —Mr Perkins delivers enlightened lessons on teamwork and self organizing teams.

 

The author divides the book into two main parts. The story, and the strategies for teamwork at the edge. The teamwork section refers to examples from the story to reinforce concepts. Mr. Perkins’ concept of self organizing teams aligns with concepts from the world of Agile software development.

 

The author is spot on with his view of self organizing teams, their need to practice and create real options. He also debunks the notion that teams can simply grow and organize without leadership. Teams need a leader. Teams need a skipper.

 

The author describes several strategies for teamwork. Let’s look at two of them.

 

Prepare, Prepare, Prepare

 

Teams facing challenges need to prepare for every contingency.

 

The Rambler had multiple systems in place for planning and preparation. While the skipper is focused on steering, other crew members are thinking about sea conditions and the next leg of the race.

 

Successful teams master the art of bifocal vision. They have the ability to focus on current challenges while preparing for longer-term opportunities. They know how to prepare and race at the same time.

 

Agile Development teams know how to plan and sprint at the same time. During a two-week development sprint, they also prepare the product backlog for the next sprint. Being Agile is a trait that even the Marine Corp embraces.

 

The author tells the story of the US Marines assault on Fallujah in the fall of 2004. After several days of intense fighting, the battle was not going as planned. About the battle, General Richard Natonski said, “Plans very seldom survive their first contact with the enemy. Fallujah was no different.”

 

What was different? The planning team had prepared a contingency plan. Like a quarterback calling an audible, General Natonski dialed up the new plan and won the battle of Fallujah.

 

To capture the spirit of flexibility, General Richard Natonski uses the phrase, “Semper Gumby.” Gumby was a sixties flexible clay cartoon character who could be twisted in any manner imaginable.

 

For the Marines, Semper Gumby means always flexible.

 

And having flexible systems increases the team’s speed and creative capacity.

 

Tenacious Creativity

 

Teams that win under extreme conditions share two qualities: determination and creativity. Innovation comes not from a brain trust seated in Semi Valley, instead the team doing the work sparks a new idea.

 

Under adverse and limiting conditions, the crew of the Midnight Rambler often invented ways to continue racing. When they lost a wind instrument, they created a device to detect wind speeds. The crew was determined to finish a race or win the whole thing by innovating.

 

Ed Psaltis, skipper of the Rambler, said this about the team’s attitude, “There is always another move, and another option.”

 

Summary

 

I’ve briefly touched on two of ten strategies for teamwork. After reading the book, I thought about how much the strategies could help Agile teams, or anyone who believed in the power of teams. This is one of the few books I've found that gives practical advice for leading self organizing teams.

Definition of Ready for User Stories

Roman Pichler provides a concise definition of what "Ready" means for a user story. He also shows what a Ready Story looks like.

Why is ready so important for Agile teams? Ready allows the team to immediately implement the story.   

Self Organizing Teams

Ruben Ortega summarizes research that explores the benefits of self organizing teams.

Self organizing teams perform a balancing act along three different beams. For example, teams must balance between freedom and responsibility.

Scrum Best Practices

In a series of video interviews, Jeff Sutherland shares his secrets of Scrum.

In one interview he talks about the definition of ready. "Ready" means the team can immediately act on the user stories in the sprint. The team is not discussing requirements or trying to figure out the architecture, instead they instantly start to implement the story.

Mr. Sutherland estimates that only one percent of Scrum teams have a definition of ready. And being in the ready state, increases velocity by 50%.

A couple years ago I coached a team that started sprints and completed few stories. They often called meetings and discussed requirements, thus they completed only a fraction of the stories. How did we smash this roadblock? 

We created a definition of ready. The team pulled stories into a sprint only when stories satisfied our definition of ready. The result? We increased velocity by 56%. 

Joe Justice and WikiSpeed

Joe Justice gives a presentation about how WikiSpeed uses Agile to create cars that get 100 miles per gallon.

From an Agile process perspective, two points resonate with me.

Test Driven Development — Teams at WikiSpeed create tests first before they develop. These tests make the teams think in a lean fashion, and often drive innovative designs.

Modular Design — The entire car body can be replaced as easily as changing a tire. Flexible products mean your team can respond to change. If teams write spaghetti code, the Scrum process become null and void. Another word for Agile? The software craftsmanship movement. 

Experiment Small to Win Big

Jason Fried of 37signals searches for a person to create iOS prototypes.  From the job description, I focused on this sentence because it reminds me of Peter Sims’ wonderful book, Little Bets.

"This job is primarily about prototyping, not shipping. Some ideas may ultimately ship, but the main goal here is to explore. You have to be OK with that."

In Little Bets, Peter explains how some creative thinkers conduct small experiments to learn quickly and innovate.

"Based on deep and extensive research, Sims discovered that productive, creative thinkers and doers—from Ludwig van Beethoven to Thomas Edison and Amazon’s Jeff Bezos—practice a set of simple but often counterintuitive experimental methods—such as failing quickly to learn fast, trying imperfect ideas, and engaging in highly immersed observation—that free their minds, opening them up to making unexpected connections and perceiving invaluable insights."

Write to Learn

Does learning how to write better, help you write software better?

Some people think so. To communicate in writing, you must organize your thoughts and make design decisions about the words you commit to paper.

Here's one way that writing words is similar to writing software. Roy Peter Clark serves up these tips for becoming a faster, stronger writer.

Consider this common complaint from editors: “Why is she so slow?” 

Sounds like a software manager. "Why does it take that team so long to write software?"

Roy Peter Clark gives this tip for making a deadline.

"I feel very strongly about this: that writers wait too long to begin drafting their stories. So I no longer wait until the research is done before I begin writing. I will write after an interview. Or I will write in anticipation of an interview. I write early to help me understand what I know, and what I still need to learn. It's not even a first draft -- it's a zero draft."

In Agile development, there's a technique called a "Spike." The developer writes code to better understand the feature, to provide an estimate, and to make a deadline.

The very act of writing makes you a stronger writer. If you want to deliver communication arrows straight to the heart… Write.

If you want to enchant an audience with words… Write.

If you want to create better software… Write.

Write on!