Raising the Water Level

A phrase you commonly hear in the Agile world that comes from Toyota is that you want to "lower the water level" in your value stream so that you can "see the rocks" that disrupt flow and, to extend the metaphor, could damage your boat!  By exposing the rocks, you can then deal with them appropriately and thus reduce or eliminate the disruptions to the flow of value.

This is a wonderfully evocative metaphor, since practically everyone has seen a stream or river with water flowing around rocks and they can visualize the effects those rock have.  However, long before I ever heard of any of this Lean or Agile 'stuff', I read a story about how raising the water level was the more appropriate way of dealing with those rocks.

A Little History Lesson
I live in Ottawa, Ontario which is the capital of Canada.  It wasn't always the capital, in fact originally it was a rough & tumble lumber town along the Ottawa river which acted as a highway for transporting logs from many kilometres upstream.  Ottawa is also where the Rideau River flows from the south into the Ottawa river, and is the general route for the Rideau Canal that connects Ottawa with the St. Lawrence River and Lake Ontario at Kingston.

The Rideau Canal owes its existence to those pesky Americans who live to the south.  In the 21st century, Canada and the U.S. are close friends, allies and trading partners, but it hasn't always been this way.  During the War of 1812, the threat of invasion from the south or at least a blockade of the St. Lawrence River forced the British to consider an alternative route from Montréal to their naval base at Kingston.  A canal from Ottawa to Kingston along the Rideau and Cataraqui Rivers was approved and construction began in 1826, led by Colonel John By.

Today, a large portion of the land in which Col. By had to work is open farmland but that wasn't the case in the late 1820's.  Work on the canal was at best a very tough grind made worse by malaria-carrying mosquitoes that infected the workers by the thousands.  Another aspect of the local geography that presented challenges to Col. By was the tough granite of the Canadian Shield.  This required blasting in many areas which, since this was decades before the invention of TNT, meant the use of black powder.

When you consider the conditions and the era in which this took place, construction flew along at a quite vigorous pace until 1829 when construction had reached Rideau Lake.  This was a key area since Rideau Lake was the source for the Rideau River that flowed north to Ottawa, and nearby Mud Lake (now Newboro Lake) was the source for the Cataraqui River that flowed south to Kingston.  The original plan was to dig a 1,500 metre (4800 foot) channel between Mud and Rideau Lakes, but the construction workers discovered that they weren't dealing with the mud & gravel they expected but rather with the hard granite bedrock of the Shield.  Costs began to spiral out of control, and the local contractors even quit the project.  Col. By had a problem and needed a solution quickly.


He examined the area's geography more closely and came up with a novel plan.  Rideau Lake had a narrow section, and By decided to build an extra, unplanned dam there as well as a lock station.  This split Rideau Lake into Upper Rideau and Big Rideau Lakes and raised the water level in Mud Lake by 1.5 metres (almost 5 feet).

Doing so dramatically reduced the amount of excavation required to connect the two watersheds and construction of the remainder of the canal continued it's brisk pace until completion in 1832.

Raising the Water Level with Your Team
We talk quite a bit about Agile being the "art of the possible".  If your team is one of the early adopters of Agile in a company it's quite likely that "possible" in your context may not be what you read in Agile literature or are taught in courses.  I'm a firm believer in lowering the water level to expose the rocks but I also know that in some cases, like Col. By, raising the water level may be the best way to proceed for the time being.

For example, coming from the XP world I advocate for very short iterations, ideally 1-2 weeks.  When you're dealing with just software, I have yet to encounter a situation where a team couldn't produce work with meaningful business value in that time frame.  Indeed, those very short iterations will expose many rocks that can and should be dealt with immediately.

When you start working with physical hardware, though, it simply may not be possible to complete a piece of work into a short iteration.  In fact, it may be quite inefficient to force fit some physical board or card design work into a fixed length iteration, or to deliver it incrementally - if a card requires 5 heat sinks, what value does delivering the design of the first 3 provide?

In that case, a longer iteration length or a process such as Kanban where cadence is decoupled from the size of the work items is likely more appropriate.

Another example of raising the water level to deal with the reality of the situation is with a team's Definition of Done.  New teams have a tendency to put a lot more steps or items in their DoD than they actually can complete in an iteration.  This isn't a big problem, and actually is a very good exercise at showing all the work required to deliver something.  After the end of the first iteration, though, many teams realize that their initial DoD was too ambitious and they may need to pare it back somewhat in order to deliver work.  That isn't to say that they don't report and deal with the impediments that prevented them from achieving their DoD, but it may mean raising the water level temporarily until the team or their organization is capable of meeting the more expansive version.

A third example is when a team is dealing with a large legacy code base (to which you respond, "Who isn't?!").  It may be very, very difficult to create microtests and use Test-Driven Development at a low level from the start (although there are plenty of resources available to help team eventually do that).  In that case, you may choose to raise the water level initially and start doing Acceptance Test-Driven Development instead.  This would provide automated test coverage at a higher level where it may be much easier to create the tests, and thus provide more overall value than spending the time doing the remedial work to clean up the code to make it more amenable to TDD at the microtest level.  Again, though, books such as Working Effectively with Legacy Code will help you to deal with that Big Ball of Mud and introduce low-level TDD which will improve the overall quality of the system.

So, you may need to apply some outside-the-box thinking like that of Col. By in order to deal with the rocks that you encounter in a team's transition to Agile.  As a coach, I constantly advocate for teams to push their limits of "possible" in order to gain improvements in how they work and in the quality of the work they produce.  However, sometimes raising the water level may be an appropriate way to achieve the art of the possible.