The Enterprise Transformation Sprint

In this article you will only read about the timebox (sprint) concept in organisation development.

Reading time about 4 minutes.

Change is not a long journey

We have some new insights in the communities of organisation-developers and agile coaches: We maintained the picture of change being a long journey for a long time. This is very helpful to make a lot of money, but it might not solve the companies problems in time. With Open Space Agility and Open Space Beta we now have two approaches with strict timeboxing to change the system.

What is development?

Development in the sense of R&D means doing something new and getting tons of data (learning/knowledge). We know, that we cannot guarantee to do new things right when doing it the first time. We have an idea (hypothesis) and need to test it somehow.

Developing an organisation is very close to that.

What is a Transformation?

Transformation means fundamentally changing the organisation structure to enable other (hopefully better) ways of interaction and value creation.

What is a sprint?

A sprint in sports means to run at top speed for a short distance. You prepare for it and within the sprint you try to deliver top performance. In business context it is a timebox to test if your system is able to deliver value in a short period.

Learning from Scrum sprints?

To understand the mechanics let us look at the timebox of a scrum sprint. There are two stable situations in a development-cycle: The beginning (planning) and the end (review). In between we have doing ... solving, testing, learning, fixing, implementing. Daniel Mezick called it “ecotone”, a nice word from biology, to describe what lies between the two stable points.

Start of the sprint (Planning):

The problem was collaboratively described and understood in advance. The solution space is still wide. Now we are clear about our hopes, wishes and guesses which problem(s) we are about to solve within the following timebox. In the task-breakdown we start making up the solution together and generate a first impression in what kind of team-constellation we will work and learn.

During the sprint:

We are in the learning phase. We discover what works and we will change approaches if we fail. No one works alone on complex tasks, we learn together. Actually learning together is the work, creating solutions comes second and making money with it is just a positive side effect. This is also our advantage on the market: We create knowledge and mastery no one else has. This is an unstable state of “ecotone” - something you cannot control, every try of command and control will lower the performance.

End of the Sprint (Review):

We are now clear about what was really delivered and about our fails in our wishful thinking. Not done is not done ... reality sometimes is a bitch.

The power of a timebox

Limited time creates urgency and focus. Normally there are more things to do than there can be done. Limited time forces everyone to prioritise and to be fast.

The Enterprise Transformation Sprint

If we now want to develop an organisation instead of software, we have to know that it will be a complex challenge - so approaches from the agile world might be suitable. Especially when going for an agile transformation it makes sense to run this transformation in an agile way (invitation, pull-principle, self-organisation ... and so on)! As this is crucial for success your top-management will need some external guidance in all phases of the transformation. They are not used to this.

Transferring the mechanics of the sprint means:

A preparation phase

Is not part of the transformation. the preparation phase is to describe and understand the problem and to create an invitation most people in the company will accept. We are not in solution mode yet.

The planning (start of the transformation)

for the transformation will be an one or two days Open Space. The Top-Manager (Sponsor) hands over responsibility and authority. A first ?transformation backlog” is filled and Groups emerge around the different challenges and agree on what and how to solve it.

Within the transformation sprint

In about 3 months these groups create solutions - test, learn, fix and implement the change. This is “ecotone” - we cannot control it, we only can support and observe what happens. The challenges might be reframed, the transformation backlog will change as the people working on the change grow in their learnings and mastery.

The review (end of the transformation)

Is a second Open Space to reflect and assess the delivered changes ... and thats it. Not done means not done. But that’s not a big deal. As usual when doing something the agile way you focus on the items of highest value first. That means the most toxic aspects of your system will be fixed!

Stabilise

In this approach your organisation is not in constant sprinting and developing mode. It can be repeated every year in case new problems pop up in the system: The most powerful person in the system has to admit “we have a problem and we cannot solve it without all of you”. Then invite everybody again and delegate authority to the crowd to solve the problem.

When & how long?

As we want everybody to participate there are only two timeslots during the year when most people are at work for a phase of about 3 month: Spring and Autumn. This also is the reason for 90 to 100 days - we need some capacity for the ?normal work“ to still deliver value to the customers, but we also can really change something within that timebox.

This approach is not radical. This approach is just consequent.

If you want to know more look up Open Space Agility (creating agile units) and Open Space Beta (transforming the whole system towards beta). Its open Source! You can take these approaches and develop them further, publish it and help companies and communities of org-developers become better.