Download
1 / 10
100 likes | 109 Views
IT environment management is needed in every IT company . Here you can get information about Release management and how it is important for your organization.<br>
E N D
Bimodal Explained *From a Release Management Perspective “The Hare and the Tortoise” is Aesop’s 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 he’s 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.
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 it’s certainly not a race between the two, releasing software on these two different paths requires special handling. This situation is called bimodal IT, and it’s common in today’s 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.
In this article, we’ll 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 isn’t bad. It’s 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 doesn’t 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. It’s also optimized for areas of uncertainty. These initiatives often begin with a hypothesis that’s tested quickly. When test results are good, they’re implemented in short iterations.
Mode 2 is called agile because it allows for software requirements to change as the software development progresses. It’s 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 that’s based on a particular theory that isn’t 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, let’s 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, you’re mixing both modes of software development and release in order to move your organization further. So let’s take a look at how we can start a bimodal software development operation.
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. • Let’s 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. Here’s 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 you’ve 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 people’s 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.
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, let’s 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.
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 doesn’t become a fable, remember that your organization only races against time, budget, and its competitors—not each other.
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 : +61 2 9437 4214 Website :- https://www.enov8.com
