A hybrid model is the combination or integration of two separate but coherent delivery models. Two (of many) reasons for an organization to use a hybrid model are:
- The organization is transitioning from one model to another and is using a combination of models while making the transition.
- The organization is very large and therefore has to organize the collaboration of a great number of teams.
In this section we discuss two hybrid models. One model is focused on predictability and the other on exploration. The first model is optimized for areas that are well-understood and well-known. The second model is optimized for areas of uncertainty.
Combining a more predictable evolution of products and technologies with the new and innovative ones is the essence of a hybrid approach. Other terms used for this phenomenon are bimodal or blended IT delivery model.
There are several combinations possible. The first is a sequential IT delivery model combined with a high-performance IT delivery model. Such a combination, described in the next section, is the demand/supply combination in which the demand party uses a sequential model (e.g. waterfall) and the supply party a high-performance model (e.g. Scrum).
The second combination described in this section is about implementing Agile in a large organization, often called "Agile at scale" or "Scaled Agile". Examples of Agile at scale are Large Scale Scrum (abbreviated to LeSS, see www.less.works) and Nexus (developed by Ken Schwaber, author of the Scrum guide).
We have chosen to describe the widely used Scaled Agile framework (abbreviated to SAFe®) as an example of implementing Agile at scale.
This figure shows both hybrid IT delivery models and how they relate to the other IT delivery models.
An often-seen demand/supply combination is the combination in which the demand party (often referred to as "the business") uses a waterfall approach and the supply party (usually the IT organization) uses a Scrum approach. In IT delivery, a separation can be made between the responsibilities of client, user, manager, and operations on the one hand (demand party) and system developer and supplier on the other hand (supply party). This separation is indicated in the figure by the dotted line.
The supplying party could be both an internal IT department and an external systems or services supplier. The exact location of the dotted line is different for each situation. For example, the user stories etc. can be drawn up by the demand party in one occasion and in another by the supply party. One time the supply party carries out the acceptance tests; the other time this is done by the demand party. Depending on the number of Scrum teams, the complexity of the system and the dependencies between applications, the integration of the software is sometimes done by the supply party; the other time by the demand party. The same applies to, for example, integration tests and E2E tests, etc.
Both the demand and the supply party will have some responsibility for quality engineering, the exact tasks will differ from situation to situation.
When the demand party works according to a waterfall approach, a project manager and a test manager are often assigned to the project. The supplying party working with Scrum will have a Scrum team with a product owner, Scrum master and a development team. This setup will often lead to tensions, for example when the project manager has a clear end date of the project but the Scrum team determines what to deliver for every individual sprint.
At a general level, you could distinguish the aims of the demand and supply party as follows:
- The demand party establishes what is required and validates if that has actually been received and whether they actually achieve the pursued business value.
- The supply party delivers the IT system and demonstrates that what should be supplied is actually supplied.
In this situation there are two clear quality gates: one where the demand party hands over their requirements to the supply party, and one where the supply party delivers the IT system to the demand party.
In practice, the distinction between demand and supply party is often less strict. For example, the members of the development team (from the supply party) help the demand party in the requirements elicitation, when writing the epics and in the acceptance test. And vice versa, the expertise of users and operations people may be deployed for the building activities.
However, it is also often the case that the demand party and the supply party do not cooperate properly, especially when there is a strict contractual separation between the parties.
It is important to define the various responsibilities clearly. This certainly applies to testing. Who is going to act as the client of a test, who accepts the IT system, who wants advice on the quality and who will test what, and when? In other words: what should someone in the role of test manager consider?
- Define the expected quality.
What is the expected quality of the IT system delivered by the supply party? The test manager and the demand party should think about this upfront and share the expectations with the supply party as early as possible.
- Define the additional tests.
What has already been tested by the supply party and with what coverage?
- In a well-organized situation, the supply party will show the test manager of the demand party their test strategy and test reports. In this situation, the test manager would establish an acceptance test strategy covering the still outstanding risks.
- In a less organized situation or when the supply party isn't willing to share their testing information, the test manager should think of another approach to establish the quality of the delivered software. The test manager could, for instance, start with an intake test (for example as an exploratory test) to gain an initial assessment of the quality of the software and take it from there. Software that shows significant faults at this point will probably need additional system testing, although this actually would have been the responsibility of the supply party.
A few characteristics of the hybrid demand/supply model are:
- At least two parties are involved, a Demand party and a Supply party.
- A combination of a waterfall approach for the demand party and Scrum for the supply party.
- Roles such as project manager, test manager, product owner, Scrum master and developer have been filled.
- Tension between end date of the project and sprint length and number of Sprints.
- Clear and measurable acceptance criteria must be established in advance for the transfer from the supply party to the demand party.
The Scaled Agile Framework (SAFe®) is a structured hybrid IT delivery approach that helps large enterprises implement Agile at large scale. SAFe (version 4.6) operates at four distinct levels [SAFe 2019]. The first configuration is mainly for small or starting organizations. The subsequent configurations are more complex and for large(r) organizations.
The configurations are:
- Essential SAFe: the building blocks and simplest starting point for SAFe implementation.
- Large Solution SAFe: for developing complex solutions, without the need for portfolio management.
- Portfolio SAFe: aligns execution with strategy by organizing developments around value streams.
- Full SAFe: the most comprehensive version of the Framework that supports enterprises in building and maintaining large integrated solutions.
SAFe for Lean enterprises (© Scaled Agile, Inc.) is a knowledge base of proven, integrated principles, practices, and competencies for Lean, Agile, and DevOps. Version SAFe 4.6 introduces the five core competencies of the Lean enterprise that are critical to achieving and sustaining a competitive advantage in an increasingly digital age. These core competencies are shown as circles in the Full SAFe picture and are read starting from the circle in the middle at the bottom of the picture, followed by the circles on the right, from bottom to top. We present version 4.6 of SAFe here. Scaled Agile Inc. regularly releases new versions of SAFe, for the up-to-date version please refer to the official SAFe website: http://www.scaledagileframework.com/
- Lean-Agile Leadership
Advancing and applying Lean-Agile leadership skills.
- Team and Technical Agility
Driving technical practices including Built-in Quality, Behavior-Driven development (BDD), Agile testing, Test-Driven Development (TDD), and more.
- DevOps and Release on Demand
Building the Continuous Delivery Pipeline and implementing DevOps and Release on Demand.
- Business Solutions and Lean Systems Engineering
Building the largest software applications and cyber-physical solutions.
- Lean Portfolio Management
Executing portfolio vision and strategy formulation, chartering portfolios, creating the Vision, Lean budgets and Guardrails, as well as portfolio prioritization, and road mapping.
A few characteristics of the SAFe model are:
- It is a layered framework .
- SAFe works with recognizable organizational layers and responsibilities are allocated per layer for coordination, governance and alignment.
- All aspects of a value stream are aligned to the broader business goals.
- Organizations might achieve greater transparency.
- Cross-functional teams can collaborate more effectively.
TMAP defines twenty quality assurance and testing topics. We have plotted these organizing and performing topics to the SAFe levels in the section "Hybrid IT delivery models (especially SAFe)".
If you want to learn more about SAFe, we refer you to www.scaledagileframework.com.