Mr. Kandel, what does the term “hybrid organization” stand for?

Hybrid organizations combine two different work models: the traditional process organization that functions like a waterfall and where the end goal and project steps are communicated top down in great detail and with a defined structure. Then there is the agile process organization, where only the general direction of a project is defined. The specific requirements are implemented and realized in sprints and teams work on a result-by-result basis.

It is not uncommon for organizations to need both models. The waterfall model does, however, remain the dominant model and process organizations tend to be organized around it. Consequently, the challenge lies in harmonizing these two very different philosophies – and that is precisely what makes a successful hybrid IT organization.

So, is a hybrid organization a compromise between the vision of a having a high-grade, agile organization and a “waterfall reality” that is stuck in the past?

Yes, exactly. Both methods have their upside, depending on the goal that has been set. With a Windows 10 rollout, for example, where you know exactly what you are doing and can plan it in detail, there is no benefit to agile project structures. In the case of complex environments, on the other hand, where there is significant uncertainty – goals and roadmap of the project are unclear or depend on too many last-minute developments – an agile work method is much more suitable. Short intervals with interim reviews make sense here as they give you the chance to quickly change course or to even go back a step, such as during application development that is based on user experience or user requirements. When doing so, you have to work agilely and produce MVPs (minimum viable products) that can be quickly shared with users to see if you are headed in the right direction.

The point, however, is that the agile method is needed much more often today than it used to be. This is a result of digital transformation, growing customer-centricity, as well as of how leadership has changed in the context of our VUCA world. The organizational structures in place at most companies do not do enough to address that. Yet, it would not make sense either to dictate textbook-style agility when major components do not even need agile work methods, or not yet at least. That does nothing to satisfy requirements and could even paralyze an organization, while also creating fear. Since the transition to agile methods can cause so many changes to technological, organizational, individual and cultural factors, it is important to proceed with caution and to take a measured approach. A hybrid organization facilitates the transformation of work structures without any of the usual actionistic buzzwords.

How do you typically proceed?

What is important is to initiate operative improvements along the entire value chain right from the start, yet without significantly interfering with the structural organization. Doing so generates too much friction and is counterproductive. That is why we begin by focusing on the process organization and trying to bring the two worlds together to achieve a constructive balance. To ensure employee needs are taken into account, we work hand-in-hand with our clients when defining the details of the hybrid organization. Within that context, starting with a pilot project has always proven to be effective.

Could you provide an example to help explain what you mean?

Let’s take your typical energy supplier, for example. In their case, the central divisions, sales, mobility, networks, production, new business and other departments all access IT resources independently of one another. Meaning, you are dealing with the classic silos: demand management, the DevOps application areas, infrastructure, etc. That might be one place we would start: we would introduce the central management, administration and prioritization of requirements and define a portfolio roadmap that includes backlogs.

This would create a transparent pool of resources and would allow the IT division to support end-to-end projects. A step that both simplifies management and prioritization, as well as enables agile and traditional implementation. Here, prioritization is based on the strategic relevance of and customer benefit from projects and is set by a committee made up of management and representatives of the different divisions.

To what extent does the organization benefit from all this?

This approach results in valid, objective decisions that better reflect the company's strategy. Furthermore, resources are not just prioritized to go to those who ask early enough or to those who cry loud enough. This is compatible with an agile work method, as well as with a waterfall organization.

That this type of process affects the structures, the structural organization, is clear. Although you do start with the process organization, which is more fluid, so to say, and easier to change. You also model processes that could support either agile or traditional projects, fully in line with the motto of “form follows function”. The extent to which the focus shifts toward agility later on does not have to be decided right away. This keeps things flexible, while avoiding irritating the organization too much.

Does this sort of process-based change influence leadership and culture as well?

Yes, of course. People come together in cross-disciplinary project pools; leadership is decentralized by necessity, meaning it is functional versus disciplinary; and, depending on the project, both traditional and agile methods are needed. Added to that is the fact that technology has to be provided very quickly. An agile work method does no good if it takes six months to set up a server landscape.

Furthermore, agile projects focus on achieving an MVP as quickly as possible in order to determine whether the approach holds water or whether additional resources are needed. The path is paved as you go. With waterfall projects, you have to take a different approach. They focus more on milestones and opportunity cost considerations, because the path is already clear.

Which “Lessons Learned” from your projects should companies take into consideration as well?

Key here is for management to have a good feel for what “agile” really means. “Agile” does not merely equate to “faster”, that is a misconception. However, when discussing MVPs, we do talk about faster initial results.

Moreover, applying different ways of thinking depending on the context and challenge is not unimportant. That is a pretty big ask for teams. There is a huge need for coaching here – for both employees and management. To that end, we collaborate with, for example, Scrum Inc., a global training and coaching expert whose founders are among the inventors of agile methods. We also rely on holistic organization development and structured transformation management, which is backed by a strong commitment from top management.

What might this type of incremental introduction look like?

Let’s stick with the example of IT. In this case, we might review the existing roadmap and work with those in charge and the top management to discuss which capacities could potentially be combined to achieve the aforementioned end-to-end support. That is the basis for defining central priorities based on the backlog, setting up a project portfolio and also taking an agile work approach to projects.

The experiences you gain in doing so may cause you to apply these principles to your plans right from the start during the next budget and planning session, causing the roadmap to change accordingly. A suitable agile pilot could – to go back to the example of energy suppliers – be a self-service portal. Or even developing a new kind of customer app, perhaps an electricity cost configurator, a consumption calculator or a smart home app.

Looking back at your projects in recent years – how sustainable are the effects that were achieved by implementing a hybrid organization?

Naturally, project success depends directly on how rigorously and disciplined the transformation is approached and how sound the methods are. However, this alone does not ensure success. What is truly decisive is to identify the reality of the organization, structurally and culturally, and to acknowledge it as well. In short: to learn and to understand.

We cannot determine the right tempo for transformation or what degree of transition is necessary and reasonable until we do. The necessary resources must also be provided and goals explained and discussed openly and intensively. That is a huge leadership task. The people in an organization tend to know that certain changes are necessary. With that in mind, they are able to join the path to change with dedication and curiosity.