Constant change is necessary. Innovate or die.

Disrupt the industry.  Quickly respond to customers needs and desires, or else your competition will destroy you.  We know the classic stories:

• Netflix wiped out Blockbuster video with their DVD-by-mail service, and then further disrupted their market with video streaming.
• Amazon changed how people buy books, then everything retail.  Walmart and every mom-and-pop retailer — now grocers — have been trying to react and even save their businesses.
• Uber and Lyft are disrupting taxi service.
• Airbnb is changing the hotel and lodging industry.

This is especially true in technology industries, where disruption is the norm.  Stay flexible, responsive, ready to change course and turn on a dime.  But when it comes time to execute on constant change, we hit a wall.

Constant change kills productivity.

Innovation is hard work, and hard work requires focus.  This is a problem:  the more dynamic the environment, the more interruptions and distractions sabotage the necessary work we must do to make the change happen.

This is not just theory; current research highlights constant change as one of the biggest barriers to actually getting things done:

• American Psychological Association (APA):  Multitasking and “goal shifting” can decrease personal productivity by 40%.  (It can also kill you! Avoid the multitasking of texting and driving.)
• Psychology Today:  Multitasking is actually a myth.  It’s really task switching, and that is highly inefficient.
• New York Times:  Fixing this problem of mental juggling tops the list of things to deal with to improve personal productivity.

Focus v. Flexibility for Teams

How do we embrace this paradox?  Constant change is what every company must simultaneously embrace and avoid in order to get the right things done.

Agile frameworks tackle this issue head on, and in different ways.  Scrum is an agile framework used most often by development teams, and Kanban is an agile framework used most often by operations teams.

The Scrum approach:  sprints

To move a team quickly in the same direction, Scrum uses sprints.

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.

Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.

During the Sprint:

• No changes are made that would endanger the Sprint Goal;
• Quality goals do not decrease; and,
• Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

In my experience, the most common duration for a sprint is two weeks.

Two weeks is enough time for a team with uninterrupted focus to get something substantial and beneficial done.

A two week cycle allows frequent, meaningful course correction so market opportunities and changing business needs are not missed.

The Kanban approach:  work in progress (WIP) limits

To prevent bad task switching, Kanban uses work in progress (WIP) limits.  With Kanban roots in lean manufacturing, WIP limits started out as an inventory management concept.  By minimizing the number of units in production queues, a manufacturing system could reduce waste, eliminate bottlenecks and increase efficiency.

The concept translated quite well into knowledge work.  Limiting the number of tasks being worked on helps individuals and teams “get to done” more rapidly, and — bonus —  eliminates some bad multi-tasking.

The Docks Metaphor

One of my favorite ways to illustrate this concept is to draw a picture of five docks on a whiteboard.  Picture yourself running a shipyard, with room to dock five ships.

Monday morning you arrive to work with five captains eager to get their ships unloaded.  Each ship takes one worker five days to unload, and you have five workers.   How do you partition the work?

The captains will be happiest on Monday if you put one worker on each ship, and they will be ready to pull back out to sea at the end of the week.

But suppose you put five workers on one ship, and it gets unloaded in a day?  Unloading one ship per day will get all five back out to sea by the same time, but one ship is making money four days sooner, another three days sooner, two days sooner, and one day sooner.

The team focus buys you flexibility to hire a team to clean the docks or even dock another ship to unload.  But it also means thinking of a good way to calm down the captain who sees his ship sitting with nothing happening for four days.

Finding ways to integrate focus and flexibility takes conscious work.  Just like the shipyard manager, agile practitioners often need to explain their focus and why they do it differently.