The future of delivery processes and ways of working (ablauforganization)

The word agile has hit mainstream in the German market. What used to be exotic 5-6 years ago is now in the minds of IT leadership at all levels. Unfortunately, the word agile is being interpreted in multiple ways.

We are finding that most organizations immediately jump into “doing agile” – learning what SCRUM is, experimenting with SAFe. All this is well and good as it brings in an appreciation for the techniques and basics.

However, the enterprise IT and the world of applications is more complicated, and good intentions of trying to do agile are often rendered impossible because of years of historically grown application landscapes and architecture. And organizations are then completely flummoxed.

There is only one speed of IT – the speed of the business

In the meanwhile, organizations are getting smarter and moving beyond the fallacy and buzzwords of two-speed IT and bimodal IT. The truth lies in multiple speeds of delivery.

The CIO of a global automotive OEM has recently announced that their goal is 100% agility – one digs deeper one could see that agility here was defined as the ability to deliver at the correct speed. Not unnecessarily fast where it makes no sense, and not too grindingly slow where speed is required. The focus was not on being fast – it was on getting the right speed. It makes no sense to create high performance continuous delivery platforms for software that is at the end of its lifecycle. At the same time, the organization should use all the opportunities for the next greenfield project & digital application to do it the right devops way from day 1. But unfortunately, 80% of the application landscape lies in the different shades of grey between these two extremes.

The goal therefore is to go beyond the debate of whether there is one way or two ways of doing things – and instead think about how can one deliver at exactly the required speed.

The CIO of a global bank recently used the analogy of a gearbox very effectively – “applications are driven only at the required speed via gear-shifting without having the need to change the motor. And there will always be the need for race-cars, family cars and trucks”. We believe that this is the right direction of thinking. And it will have profound implications downstream – for example, will this mean that a service will have different SLAs based on the “speed”?

Going from doing agile to being agile

And as we have seen above, leading organizations are slowly giving up the search for the elusive One-Size-Fits-All Framework that fits all situations in the perfect way. Such a framework does not exist since situations are too diverse.

In our work with leading organizations, we find that a more helpful way to look at this topic is go from “doing agile to being agile”. If one interprets enterprise agility to choosing the right set of methods, techniques and ceremonies to suit the situation, then the pressure eases – you go from trying to find the “perfect way of working” to “multiple ways of working” and the agility then is the freedom to choose which way of working suits your situation best.

A few years ago, Brian Henderson-Sellers (amongst others) suggested the concept of Situational Method Engineering (SME). Situational method engineering is the construction of methods which can be and are tuned to specific situations of development projects. Methods are created flexibility from a repository of reusable method components, these components are then tailored, and then integrated together to form a new situation-specific method. Think of this as SOA meets Delivery Methods.

A large chemical and life sciences company is now experimenting with Situational Method Engineering (SME) to define the multiple ways of working possible. The large SAP landscape is interconnected to almost 2000 other applications. The focus of delivery is now shifting from SAP expert teams (FI, CO, SD, MM…) to Core Business Process facing teams. Each of these teams owns the SAP Modules and interconnected systems that satisfy the needs of a particular business process. At the same time, new business ideas from the edge of the organization are leading to exciting new Digital products in the area of farming and paints. The organization has given up trying to find a methodology that fits both worlds, and is moving towards 3-4 situation based methods. The methods are engineered in pilot teams, and successful methods are then incorporated into a fluid software delivery methodology which is situation driven (technology, software footprint, global vs local usage, lifecycle of the product). A new method engineering group has been established centrally within the IT organization – which focuses on capturing successful ways of working into specific methods, techniques and ceremonies.

While SCRUM and agile works well at the level of teams, we see that approaches like SME capture the essence and complications of large scale enterprise application delivery better.

The rise of continuous services

The advent of devops has continued the journey that agile started. As organizations go beyond just developing software in an agile manner towards deploying it more frequently, the focus of process shifts.

Suddenly processes involved in Releasing and Deploying software become more critical than ever. And the success in these processes lie in how repeatable these processes are. The devops community is building this awareness more than ever.

What then gets interesting is how this manifests within large organizations. A large manufacturing firm has used the drive towards devops to create suites of continuous delivery scripts for its key technology platforms: Java/LAMP, Microsoft and SAP. These continuous delivery suites are now run to perfection by a central team. The head of IT Infrastructure took this onus upon himself to upgrade the Middleware team in the organization towards planning, managing and operating this continuous delivery suite.

So, while organizations go towards freedom in choice of delivery methods, they still standardize the technology of delivery – because only through standardization comes repeatability and speed.

Multiple consulting organizations come with best practice process frameworks but fail miserably in implementing the change because the delta is too large. In our experience, Value Stream thinking helps more than just tweaking individual processes – or even starting to define them newly from scratch. Value Stream Analysis and a Kaizen-driven agile implementation of change takes the current situation as the starting point of implementation in a natural way.

Waterfall budgeting does not help agile IT

The journey towards enterprise agility does not stop at IT (and should not).

The CIO of a large bank has turned around his organization and is now able to execute up to 30% of its projects in an agile manner, but further progress is trapped due to annual budgeting cycles. The art then lies in predicting and distributing how budgets are planned and allocated. Interesting patterns are now emerging – for example, the shift from allocation of budgets to programs to instead being based on products, or business processes. This drives accountability better and encourages the right behavior: now teams can use budgets to reuse existing software components to achieve different purposes instead of being forced to live within a program which has a start and end.

This move towards Product-aligned budgeting and responsibility has profound implications on how IT organizations are structured. Multiple organizations in the Netherlands, Sweden and Germany are moving towards product-aligned IT to better deal with this issue.

Leading organizations are rising beyond the hype of the next new methodologies and are embracing the reality of multiple speed delivery. Approaches like situational method engineering and product-aligned delivery show a lot of promise in dealing with the complications of large and complex application portfolios. The attempt to standardize ways of working are leading to new shared services that go in the direction of continuous delivery environments and platforms. And IT leaders are realizing that the enterprise agility does not stop at IT alone and spills over into other areas like controlling, budgeting and procurement.