A Walk Along the North Shore of Oahu as a Metaphor of Flow-Based Development

April 12, 2010 — Posted by Al Shalloway

We're coming back from Agile Japan and we decided to stay at Turtle Bay Resort on the north end of the island. I just took a great walk along the beach and realized it made a great metaphor for flow based development. I've never been out on this end of the island – and must say I love it. We'd stayed in the Marriott Ihilani, which is also nice, but isn't as Hawaiian so to speak. Furthermore, at the Marriott, you can't walk along the shore for too long – there are rocks up against a private area on one side with an inlet along the other. In checking out the Turtle Bay Resort, I had seen that there was beach up and down both sides of the resort – so this looked like a good place.

Yesterday I had done my release (I mean vacation) planning for the day. I had two main products (er, activities). One was to walk to the northernmost tip of the island, about a mile east of the resort. The other was to snorkel a little in the bay between the resort and the tip (I had heard there was quite good snorkeling there). My wife likes to work out for about an hour and a half most mornings so when she went for her workout I figured I'd take my walk.

Although I had wanted to do both of my projects (activities) I realized that I might only get one in. Which would provide more value (um, enjoyment)? Walking to a place I've never been (and could then say I've been to the northernmost point of the island?) or snorkeling on an island I've snorkeled on before? Easy choice – particularly since my wife's reaction to my snorkeling would be "did you have fun?" while my pointing to where I hiked to would evoke a response of admiration (nice that after 22 years I still like my wife to coo over me). So, my product portfolio management (uh, choosing which activity) was easy – take the hike!

I had already done my pre-project planning (er. look ahead) by having looked at the satellite view of Google and noticed that there was beach along the entire way out there. My understanding is that on Hawaii, the beach is always public property. Although I would prefer a real path some of the way (walking 2+ miles on sand is tougher than you might think) I at least knew I it was possible. Seeing a publicly accessible route, albeit difficult, completed my high level risk mitigation.

Now, for release planning– could I get it all done in an hour (my wife had said she might take a shorter than normal workout this morning)? Not sure. I've done a 2+ mile hike in 35 minutes but this was on a beach and I wanted to enjoy it. But it seemed reasonable and I figured if it took 1.5 hours that'd be fine.

OK, so off I went (and, admittedly, some people would say I'm still off, but that's another story). I started along the beach because it looked like fun. I even met someone who had been snorkeling and asked him how it was – he confirmed pretty good conditions. I tested the water temperature (planning ahead for later in the day if I chose to snorkel). I continued on.

After about 10 minutes, it was very clear that at the pace I was going I'd tire out and not make it. I had three risks to attend to: 1) I didn't want to endanger myself (although I'm in pretty good health, I'm also 57), 2) I didn't want to get too tired, 3) I wanted to be back in 1.5 hours. Constraints 2 & 3 looked in doubt. I started looking for alternatives. I saw that I could walk on the rocks and started doing so. I'd look ahead to see what best path to take along the rocks. I had to look down carefully as I was walking as they were uneven and sharp. I couldn't just go forward without any planning as that could get me in a place I'd have to turn around. However, looking too far ahead wouldn't do my any good either because you really couldn't tell how hard any path was until you got close to it (kind of like coding?). So I went 20-40 feet at a time looking up to get a general path, then looking near my feet until I got to my retrospection place. It was like each 20-40 feet was a story, getting me along the rocks – with getting to the other side of the rocks being a feature. But,the rocks, although faster, were becoming too tedious as well. I looked for another alternative. Along the landside edge of the beach looked like there could be a path in the woods – so I went up there. Ah, while not firm, it was better and I moved along quite well. I skimmed the golf course and pretty much alternated between walking on beach, rocks, edge of woods or golf course making the best time I could. I noticed that I was moving faster than I originally thought I would have at times, but at others I moved slower.

If I had tried to plan this out with precision, I would have come up with the same estimate as the greater detail would have made me more accurate but my over-estimating and underestimating would have balanced out anyway – this is an example of the law of large numbers, btw.

Note that I was doing what I consider flow-based, not time-boxed development (er. walking).  In other words, I didn't say - "I'm committing to this 40' section in 3 minutes" but rather said - "what's the best way to cover this 40' section?" I was going for sustained movement without causing delays for this section or future sections. 

I made it out to the point, in what I imagined was 40 minutes. While I had wanted to relax out on the point for 15 minutes when I had originally set out, it didn't appear that I had time for this. Fortunately, this was not part of my minimum marketable feature (oops, I mean my minimal experience for me to be satisfied). I also decided not to go all the way to the point as the last 50 feet looked pretty treacherous and wasn't worth the last bit of energy, the time it would take, or the risk in falling. In other words, I evaluated my ROI and decided it was worth doing a little less (not quite Pareto).

I turned around, proud of myself for having accomplished my goal and turned back. I found I came back much faster. I saw some paths I hadn't saw before and was more adept on the rocks as well. I even jogged a few times as I now could tell I had energy to make it back.

Bottom line? I came back in almost exactly an hour. I had done the following steps:

  1. Vision
  2. Overall plan
  3. Risk mitigation
  4. a general plan of accomplishment (i.e., where was I after about every 10-15 minutes)
  5. adjusting my goals throughout the way while keeping the big picture in mind

In other words, while I was very agile, I would not have achieved this result without keeping the context of the bigger picture, without looking ahead, without adjusting my results to my goals. Had I tried to be precise and done more planning (e.g., Google maps at closest view) I would have really just wasted my time and not been able to finish the project (er, I mean make it to the point). Agile does not mean just do a little at a time and then go on to the next thing. It means be adaptable to what goals you are doing but to keep vision and purpose present at all times.

I hope you enjoyed this. Please let me know if you liked this type of blog. I, personally, had fun on my walk and in writing about it.

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban