Agile transformation in four steps

You can count on it: wherever people from different IT organizations come into conversation with each other, it eventually turns to agile transformations. Many businesses have made their way, or plan to make their way to organization-wide agility. If you ask for the reason, it is often “Because the board decided on it,” or “because we can only master the challenges of digitalization with agility.”

The first answer is not inspired, and the second sounds like a set phrase. But actually both answers are pretty good. Because agile transformation means making a complex change that doesn’t just concern IT organizations but also the whole organization and possibly also cooperation with external participants in the value chain. The management’s commitment is a necessary prerequisite for a change of this magnitude to be successful. And: for traditionally run businesses it is increasingly difficult to implement innovations as quickly as required in order to replace the usual “brick and mortar” processes with digitalized ones. Agility has become an organization’s competitively deciding property.

The change process as a signpost

Agile transformation means implementing a sustainable, organization-wide, technological and cultural change – not as a big bang, but as a defined, iterative change process. In the area of change management there are multiple models that can be adopted for an agile transformation. John P. Kotter’s eight phase model and Kurt Lewin’s three phase model are amongst these. The latter is the foundation for the following iterative structure of a process for an agile transformation.

The process starts with a preparation step. It serves to:

• Develop a vision of the future agile organization (how will the business look in the future?)
• Define the scope of the agile transformation (who does it affect?)
• Ensure backing through management.

Four iterative steps then follow:

• Analyzing, planning and preparing concrete transformation steps
• Implementing them
• Anchoring, measuring and continually improving the imported changes.

The framework conditions for agile transformation can change over time. Before running through steps one to three again,

• Check the vision and scope

With each iteration, the agility inside the organization will be further scaled.

An iterative change process – cut for an agile transformation

Don’t get stranded on an agile island

Getting things moving is the central task for an agile transformation. Steps one and two serve to initiate learning processes that will lead to new organizational structures and to changing the behavior of individual employees, teams and the management. These behavioral changes are a measure for how advanced the transformation is.

So no wonder that many businesses, before they decide on an agile transformation, try out agile techniques on a small scale. In the area of software development there are even individual teams or people responsible for a project who try out Scrum, for example, by their own initiative. If the pilot project goes well, then further small projects are added – before a foundational change to an agile transformation is made.

If many central requirements for the pilot project are missing, then this process can create, as obviously as can be, new hurdles for the agile transformation. Scrum is a framework that can be developed differently. If freely left to a team, it can decide:

• How to manage their epics, features and user stories and which tools to implement in doing so
• Which priority procedures and estimation methods it uses
• Which metrics it uses to measure the speed and the progress of the product
• How it creates transparency and communicate it with stakeholders

Then islands arise with an agile culture. On one island, story points are estimated, on another, person-days. The “inhabitants” of one island work with post-it notes, the others use MS Excel. Yet another might implement an app or a cheap cloud-based tool to manage their user stories. Comparability and traceability of the projects – as these examples show – stay on track here. Expressions about how performant the entire organization is (for example figures on the number of realized requirements per time frame) are difficult to meet here. The change process sketched above therefore explicitly prefers to identify and dissolve the potentially emerging agile islands. Because: yes, pilot testing has to happen. But the steps

• From one to many agile projects and
• From small to large agile processes

have to be based on one unified concept for the methods to be implemented and the tool infrastructure.

Go hybrid for a while

Planning and controlling large projects presents a particular challenge in the process of an agile transformation. Businesses that approach the transformation step-by-step, for example, are just changing the software development for the time being, but if they want to use classical approaches for the rollout and service of software systems, the need arises for hybrid project management. In it, a large project is planned essentially requirements-based and is implemented with a fixed duration. But the project also includes tasks that are planned with work packages and milestones, activity-orientated. For these hybrid projects, an integrated planning technique and effective controlling instrument is required, for example charts and key performance indicators with a scope for multiple teams working in parallel and all planned releases and work packages.

A Gantt chart of a hybrid project in objectiF RPM

objectiF RPM as your guide on the path to an agile transformation

Businesses that are making their way on the path to an agile transformation will experience phases where agile, hybrid and classical activities are all happening at once. There will also be projects that model requirements based on forms, and plan classically with activities, and others that work with user stories, backlogs and user story boards. To generate a road map of all current and planned projects and gain insights into the performance of the entire organization, it is advantageous to control all projects, whether they are agile, classical or hybrid, with one tool that offers a scabable infrastructure for all projects.

This is the idea behind our ALM software, objectiF RPM. In our whitepaper, we have presented the instruments for the planning and controlling of agile, classical and hybrid projects that objectiF RPM offers:

Take a look and enjoy the read!

Sources:
[1] John P. Kotter: Leading Change: How to successfully change your business in eight steps
[2] https://en.wikipedia.org/wiki/Change_management#Unfreeze-Change-Refreeze