Bimodal Explained – A Release Management View

1
Bimodal Explained A Release Management View

2
Bimodal Explained
From a Release Management Perspective

• The Hare and the Tortoise is Aesops most
  famous fable. In it, we find two characters one
  fast (the hare), and one slow (the tortoise).
  They run a race against each other, both hoping
  to get to the finish line first. However, they
  run in different ways.
• The super confident and super fast hare is all
  over the place, bragging and taking naps along
  the way. The tortoise, on the other hand, is
  steady, predictable, and persistent, even though
  hes slow. In the end, the slow, persistent
  tortoise wins the race. But the fast hare shows
  us that even in a race, speed is not the only
  important factor.

3

• Oftentimes in software development, we have two
  modes for releasing software. Mode 1 is rigid,
  predictable, and safe Mode 2 is agile, fast, and
  risky. While its certainly not a race between
  the two, releasing software on these two
  different paths requires special handling. This
  situation is called bimodal IT, and its common
  in todays enterprises.
• Gartner defines bimodal IT like this
• Bimodal is the practice of managing two separate
  but coherent styles of work one focused on
  predictability the other on exploration.
  Marrying a more predictable evolution of products
  and technologies (Mode 1) with the new and
  innovative (Mode 2) is the essence of an
  enterprise bimodal capability.

4

• In this article, well explore bimodal IT from a
  release management perspective and see how to
  make it work for your organization.
• Mode 1 Is Safe and Predictable
• Mode 1 isnt bad. Its neither obsolete nor
  unnecessarily slow. This mode is optimized for
  predictability and well-defined areas. It focuses
  on building on what is known and maybe renovating
  a legacy IT environment into a more modern state.
• Mode 1 software development and release requires
  a clear understanding of the requirements up
  front, as it aims to deliver predictable and
  precise results.
• Many highly regulated industries rely on Mode 1
  software release methodologies, like waterfall
  and iterative. Systems supporting the financial,
  defense, and pharmaceutical industries operate in
  Mode 1 for most system development. Why? Because
  Mode 2 introduces new risks and doesnt guarantee
  predictable results.
• Mode 2 Is Agile and Riskier
• Mode 2 is neither the only option nor is it
  magically fast. It is, however, exploratory and
  allows experimenting to solve new problems. Its
  also optimized for areas of uncertainty. These
  initiatives often begin with a hypothesis thats
  tested quickly. When test results are good,
  theyre implemented in short iterations.

5

• Mode 2 is called agile because it allows for
  software requirements to change as the software
  development progresses. Its a more fluid process
  that can respond quickly to pressures from the
  market and development efforts.
• Many times, Mode 2 software development releases
  include functionality thats based on a
  particular theory that isnt fully defined. This
  means that validating and testing the
  requirements is passed on to the user. This
  approach introduces additional risk and
  uncertainty, but it provides a quicker time to
  market.
• Now that we understand what bimodal software
  release is, lets take a look at some common
  scenarios that exist in bimodal organizations.
• Bimodal Scenarios
• Many organizations operate using a Model 1
  software development and release model when
  development must be steady and predictable. This
  is especially true in highly regulated industries
  like defense, pharmaceutical, and financial,
  which require clearly defined requirements at the
  beginning.
• However, your organization may decide to add Mode
  2 software development to explore and integrate
  new technologies into your Mode 1 product.
  Another possible reason for Mode 2 operations is
  to eventually replace an existing Mode 1 product
  with one that uses new technologies.
• In these two scenarios, youre mixing both modes
  of software development and release in order to
  move your organization further. So lets take a
  look at how we can start a bimodal software
  development operation.

6
Clearly Define Objectives and Expectations

• Before adding a new mode to your organization,
  you must clearly define the objectives. Everyone
  needs to know what the organization is trying to
  achieve.
• Lets say your organization has been working in
  Mode 1 (slower and predictable) for a while, and
  you need to add Mode 2 (faster and more agile) to
  explore new technologies. Heres where you need
  to spend some time Why do you need this new
  technology? Do you want to integrate it into the
  Mode 1 product youve been selling? Do you want
  to create a new product that will eventually
  replace the existing product? Or do you want to
  offer both products to your customers?
• Certainly, time and business climate changes will
  also change your objectives. Therefore, clear
  communication is very important every time such
  changes happen because they will affect peoples
  daily work habits. Sharing the main development
  metrics you look for will go a long way toward
  making things clear. Having a unified place to
  track and share release details will also bring
  your development efforts together.
• The keywords for making bimodal software delivery
  work are separation and integration. These may
  seem like opposites but bear with me as I make my
  point. In order to make bimodal software releases
  work, we must talk about separating resources and
  integrating results.

7
Integrate Releases

• The most complicated bimodal scenario is when
  Mode 2 releases deliver new functionality for
  your existing Mode 1 products. As we focus on
  this specific scenario, lets zoom in on release
  management.
• When operating bimodally, you must focus on
  planning detailed features for each release. This
  is the only way to plan for integration between
  the releases of two different modes of software.
  So once you have software development running in
  two modes, release management becomes your focus.
• How do you determine which features go into each
  release for each mode? This is the million-dollar
  question in every software development project.
• Before starting Mode 2 releases, you must be able
  to envision the final product with the new
  functionality working in your existing Mode 1
  product. How does your improved Mode 1 product
  look when you integrate Mode 2 functionality?
  What will your users be able to achieve?
  Answering questions like these will give you a
  clear vision of the finish line. Or at least the
  first finish line you have to cross with both
  Mode 1 and Mode 2 release models.
• When you focus on the releases produced in both
  modes, clarity comes along. So developing user
  stories that focus on integrating features will
  help you plan your releases.

8
Bring Both Modes to the Finish Line

• You must never portray the two modes and the
  teams that support them as being in a race with
  each other. You need both software release modes
  to move your enterprise systems forward. So to
  ensure that your bimodal software development
  doesnt become a fable, remember that your
  organization only races against time, budget, and
  its competitorsnot each other.

9
Contact Us

• Company Name Enov8
• Contact Person Niall Crawford
• Address Level 5, 14 Martin Place, Sydney, 2000,
  New South Wales, Australia.
• Phone(s) 61 2 8916 6391
• Fax [phone]
• Website - https//www.enov8.com

10

• Thank you