BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles The Computest Story: The Transformation to an Agile Enterprise

The Computest Story: The Transformation to an Agile Enterprise

Key Takeaways

  • Put your customer first and improve your organization by smoothing your value creation process.
  • Help everybody to understand him/herself in the context of this process, i.e. how s/he is supposed to contribute to your company's overall success.
  • Foster self-organization by having the right people in the right place, supporting open exchange and providing clear boundaries.
  • See leadership as something that happens throughout the organization and create a system of coaching to encourage this.
  • Apply visual workflow management to create transparency and learn to see what you are currently doing and where to improve.

Computest is a fast growing company, currently with about 120 people, based in the Den Haag (NL) area, specializing in performance testing, security testing and test automation.

At the beginning of 2016 Computest started out on an ambitious mission: "towards a self-managing organization" as CEO Hartger Ruijs, 2017 entrepreneur of the year in the Den Haag area, pointed out in his first blog on the topic towards a self managing organization.

This article describes how Computest followed this mission, and provides facts and figures on:

  • The key drivers of this mission: why foster self-organisation in the first place?
  • How the journey got started: from functional silos to multi-disciplinary teams, from a traditional to an agile approach, from hierarchical management to coaching services.
  • Why Computest called in external expertise and how a cultivated a co-creative sparring partnership was established.
  • Why focusing on value streams is essential for the new organization Computest is striving for.
  • How we aligned roles and responsibilities and applied Kanban to operationalize ideas.
  • Lessons learned so far and what this means for the next steps to be done.

What have been the key drivers of this mission?

Reaching 50 employees around mid 2015, it became clear to the Computest Board that the current organizational and managerial model needed to be changed.

The organization was structured in functional teams with dedicated line managers, headed up by the CEO.

Various models had been discussed, with the CEO not willing to extend a hierarchical structure with just another management layer. Instead, he was convinced that a substantially different approach would be necessary to master the following challenges:

  • Handle future growth

    The company's ambition to continue to grow 25-30% every year required a scalable organizational model without the need for an additional management layer or more staff, as this would increase overhead and reduce agility.

  • Preserve company culture

    Computest's success has always been driven by its entrepreneurial spirit and its informal, amicable culture. Any new organization needed to preserve this culture.

  • Become more market and customer driven

    Having a very technical DNA with a strong inside-out-view, the company wanted to extend its current strengths with an increased outside-in-view. The new organization should encourage a continuous focus on the market.

  • Encourage leadership on all levels and a higher degree of self-responsibility

    To utilize the full potential of all people in the organization we aim to maximize the degree of self-responsibility and to enable leadership as a service instead of a hierarchical function.

  • Become a truly agile enterprise driven by self-organization

    Already experiencing the advantage of working agile on an engineering level, the CEO was convinced that becoming a truly agile enterprise would be a key competitive advantage and self-organization is the only way to get there. Furthermore, Computest's customers can potentially also benefit from our organizational innovation.

  • Speed up innovation and shorten time-to-market

    Being closer to customers and more agile in responding to their needs will allow to develop new solutions for evolving demands faster and bring them to market in a shorter period of time.

The starting point

Our journey started out from a traditional management model. Figure 1 shows our initial matrix with the usual disadvantages of a huge span of control for the CEO and a separation between 'revenue generation' and 'revenue delivery'.

Like in many other organizations, sales, marketing and product management were organized in functional silos, whereas the delivery teams were separated by deployment type and not organized by industries. The lack of any integrated work flow management was more than obvious.

[Click on the image to enlarge it]

Figure 1: Computest's initial matrix

Inspired by Henrik Kniberg & Anders Ivarsson's famous article on how Spotify scaled their development organization we decided to put multidisciplinary teams in the center, supported by a group of people outside the teams focusing on coaching and fulfilling company-wide responsibilities. As Figure 2 indicates, the major difference in the first transformation step was to integrate as many central functions in interdisciplinary teams as possible, to structure them by industries and to differentiate the leadership group in 'captains' and 'coaches'. Whereas the captains took over social leadership for the teams as well as responsibility for resource and account management, the coaches formed a group of thought leaders with a broad variety of subject matter expertise, responsible for both policies and solutions.

[Click on the image to enlarge it]

Figure 2: First step of transformation

At this early state of change we broke up the functional silos and created multidisciplinary teams focusing on different markets. The purpose of the latter was not fully understood by our employees in the beginning but turned out to be one of the key decisions in our transformation to a truly customer-driven organization. Nevertheless, we still struggled with our workflow management as we tried to foster agility by scaling our structure. Although the model in figure 2 was still dominated by organizational structure rather than customer-oriented process, the arrows indicate the first movement towards a value-driven model. We also struggled with the pitfalls of a matrix organization with unclear leadership responsibilities. At this stage, we were mainly preoccupied with two questions: 1) how to organize people executing company-wide tasks, and 2) how to distribute leadership responsibilities between captains and coaches.

Why external help?

Although we realized the positive effects of customer-oriented, multidisciplinary teams, we could not find appropriate solutions for the remaining challenges. As a matter of fact, we started to lose energy by thinking more about how to organize our work than doing it. This held especially true for clarifying roles and responsibilities outside the core interdisciplinary teams. Taking not only the opportunities but also the risks of our organizational transformation into account, we decided to look for some external advice.

Searching for case studies around leadership and self-organization, we came across the InfoQ article on 'Leading Self-Organizing Teams'. We realized that other people had been thinking and dealing with our current challenges before and our first meeting with the article's author, Sigi Kaltenecker, was just one phone call away. "It's a sign of strength and confidence to know when you reached the limits of your knowledge and know enough to enlist outside help", Kathleen Sutcliffe and Karl Weick point out in their classic about "Managing the Unexpected".

Dealing with the unexpected at Computest, we agreed on a first onsite meeting to get to know each other and learn more about where outside help was actually needed. Although Ruijs and Riedl surprised Kaltenecker by calling themselves "coaching skeptics" and "consulting resistant", the meeting was defined by a culture of mutual respect and openness. Professionally, we agreed on the following expectations for the external support:

  • Providing guidance to the overall change process.
  • Encouraging what works.
  • Detecting areas where we have potential blind spots.
  • Delivering expertise wherever it is needed.
  • Sharing good practices from other companies.
  • Acting as a sparring partner who observes, listens and provides feedback.

Time-wise we agreed to address our issues iteratively, in a series of onsite "sprints" of 2-3 days every 6 to 8 weeks. In-between those sprints we used various updates via mail, phone or Skype to keep us in the loop and clarify open questions. Later on, we even established a so-called hotline for the core transformation team to pull external expertise whenever it seemed needed.

Content-wise it was crystal clear from the very beginning that our still matrix-like structure was rather an impediment than a catalyst for business agility. Therefore, we decided to focus our attention exclusively on the big picture: what should the organization look like? How to encourage a culture of sensing and responding? What kind of leadership was needed to enhance self-organization on all levels?

Looking for answers, there was little doubt that we had to start at the top of the organization. The commitment to do our management homework first was reflected by the impressive amount of time and effort invested by Ruijs and Riedl. As it turned out, sharing some basic assumptions about organization, change and mutual help was very important for the collaboration between Kaltenecker as external consultant and Ruijs and Riedl on the company side. It didn't take us long to establish a common understanding that:

  • Organizations are social systems with their own "natural" ways to do things around here (aka culture).
  • Any system is not the sum of its parts, but the product of its interactions (aka agile dynamics).
  • Neither systems nor people can be changed just liked that. It needs a decent amount of time to get informed, understand, become involved and finally commit yourself to the proposed transformation (aka winning people over).
  • At the same time, this transformation was also subject to change since we were continuously inspecting and adapting our initial "plan" (aka evolutionary change).
  • Coaching is a catalyst for continuous improvement. Thus, the coach has to provide both expertise and process guidance in order to jointly tackle the big challenges (aka agile and systemic coaching).
  • Any change in a system has to start at the top. The level of chief executives and/or owners is responsible for setting the right boundaries and modeling the behaviors they want to see in place throughout the organization (aka prerequisites of self-organizing systems).

Why focusing on value streams was essential

Building on those assumptions, we applied lean thinking to overcome the problems of scaling organizational structure rather than process. That's why we identified value and value streams and reshuffled our model by putting value-generating activities in the center with a surrounding circle of special leadership services supporting the interdisciplinary teams. This way, the stream took the lead. In the best sense of sparring partnership, Ruijs, Riedl and Kaltenecker incrementally co-created the current Computest model.

[Click on the image to enlarge it]

Figure 3: Draft model from boxes to flow

Figure 3 may give you an idea what this co-creative collaboration looked like. Based on a high level of trust it was driven by the willingness to think aloud, visualize and build on each other's ideas. Step by step we boiled down our ideas to the essence: one value stream leading from a pool of ideas to value for happy customers, transformed by happy employees (Figure 4). Pragmatically, the value stream was divided in two major parts, later on represented as different flight levels of Kanban (see below). The 'Strategic Development Stream' focuses mainly on developing and improving our solution portfolio but also on strategic internal projects to improve our capabilities. The 'Bring to Market Stream' combines all activities within the customer life cycle from marketing and sales to delivery and cash collection. It materializes the results from the Strategic Development Stream. It is obvious that both parts of the stream can't exist without each other to transform ideas into customer value.

Figure 4: One end-to-end value stream

Roles and responsibilities

While thinking in flow rather than boxes was a huge step forward, we still had to answer a few essential questions: where were our employees actually supposed to work from an organizational point of view? How should we manage responsibilities which belong into the interdisciplinary teams but don't require a dedicated employee from a capacity point of view? And what is our idea for company-wide services?

Looking for convincing answers, we came up with three different settings our employees can operate in:

  • Interdisciplinary teams

    The majority of our employees is working permanently and 100% dedicated to one interdisciplinary team. Focusing on industries, those teams are the key link to the market and need to gradually build up sector expertise.
    Examples: Team Sales, Security Specialist, Performance Specialist, Functional Test Specialist

  • Multiple team services (MTS)

    Roles and expertise which in principle belong to and should reside within an interdisciplinary team, but are not required as a fulltime position. People working in a MTS role are dedicated to the team level only, but can be part of multiple teams at the same time.
    Examples: Team Marketeer, Team Recruiter, Partner Manager

  • Company wide services (CWS)

    Roles and expertise which are necessary to fulfill company-wide tasks and responsibilities and can therefore not reside within a team. CWS people act as subject matter experts in the strategic development stream but also facilitate and coach the teams in the bring to market stream.
    Examples: Tech Coaches, F&A Coach, Solution Marketing, R&D, Development

Figure 5 provides an overview of these three different settings in our value stream model. While CWS people have ownership of the strategic development stream, teams and MTS people take care of the bring to market stream. Once again, it is crucial that all employees know what their role is about and how they contribute to Computest´s overall success.

[Click on the image to enlarge it]

Figure 5: Overview of streams, roles and responsibilities

Value streams and visual work management

You might say that this sounds like an interesting theory, but what about our practice? So what did we actually do to make our ideas become organizational reality? Well, we decided to apply visual work management to make our ideas as transparent as possible. Kanban gave us the right means to operationalize what we were thinking of.

[Click on the image to enlarge it]

Figure 6: Kanban Flight Levels

Klaus Leopold´s flight levels provided useful guidelines to do so on a global level rather than limiting ourselves to local improvement. Fig 8 shows how you can apply Kanban to better operate your daily business, coordinate multi-team efforts or clarify what your portfolio looks like. It is not a maturity mode,l but a communication tool to optimize in all areas of your organization. In Leopold´s words: "If you want to make improvements in an organization, you must first be clear which level is best suited to achieve them. The flight levels should help identify the appropriate level. Generally, it can be said that the higher the flight level, the greater the leveraging effect".

Figure 7 shows the current state of our strategy board (Kanban flight level 3). It provides an overview of:

  • What Computest is busy with at the moment (see yellow and green "tickets" representing specific initiatives)
  • How much we do in parallel (limiting work in progress in order to stop starting and start finishing)
  • Typical types of initiatives (focusing on internal or external improvements)
  • Typical steps of our strategic development process (headline from "Ideas" and "exploration" to "development", "feedback" and "handover")
  • Explicit policies the CWS-guys agreed on (white paper sheets all around the board)
  • Who is working on what (small name tags on each ticket)
  • Which work is blocked (small red tickets)
  • How much work we have at each stage of completion (driven by the principle of stop starting, start finishing)
  • Where to focus on in the current standup meeting in order to encourage flow as much as possible (see those tickets that are moved by 45 degrees)

[Click on the image to enlarge it]

Figure 7: Computest's strategy board

Applying Kanban on the strategy level has a few consequences: first of all, it shifts responsibility for a smooth value stream upstream. If we don't design for a professional discovery phase, make smart economic decisions and limit work-in-progress, we're doomed to failure from the very beginning. That's why we try to encourage both our strategic thinking and portfolio management. Secondly, visual work management allows us to better coordinate our work on different levels. Establishing a systemic view of what we're doing helped us to focus on the value stream end-to-end. By making the big picture transparent, it becomes easier to align the team's efforts with organizational initiatives. Working with a physical board also helps to improve our collaboration. It manifests a joint focus (i.e. we learn to see) and combines physical with mental fitness (i.e. we literally stand in front of the board, ready for an open conversation without the usual meeting blockers such as tables, chairs, PCs etc.) Last but not least, it helps to involve those affected by the change towards a truly self-organizing company.

The physical Kanban board is placed in our spacious canteen which is a central social place in our building. This makes it literally a visual workflow management of our strategic projects. Meanwhile, not only the core transformation team but all CWS people are working with the board and all kinds of meetings are increasingly held in front of the board. Even the Computest board decided that the regular update on strategic topics in the board meeting should be held in front of the Kanban board.

Lessons learned and outlook

It feels like it's time to review what we've done so far. Where is Computest on its journey to become the agile enterprise it is striving for? What did we learn so far? And how do we apply those insights to what we plan for the near future?

Here is a short summary of our key lessons learned:

  • Improving your organization (model) is not a purpose on its own but a means to better organize the value creation process for your customer
  • Every individual needs to understand him/herself in the context of this process and every activity needs to support value creation directly or indirectly. The Kanban board makes this very transparent with its tickets and the individual responsibilities attached to it. Moreover, using the board for more and more meetings value is becoming a more prominent issue on all levels
  • If you don't know where you are now, it is very difficult to improve.
  • Self-organization does not mean freedom for individuals to do what they want. It is not laissez-faire but clear guidance by systemic boundaries in terms of infrastructure, information, and decision-making authority of feedback loops. In order to encourage effective self-organization we clarified mutual expectations and agreed on explicit policies
  • Might sound trivial, but less is more! A visual workflow management is a dramatic improvement in making this transparent

Doing our best to keep those lessons in mind, we still have a lot of things on our change menu. What we want to do next is:

  • Implementing Kanban also for the operational part of the value stream, i.e. designing a flight level 2 board for better coordinating our team´s efforts
  • Inform, educate and involve all employees in order to achieve overall commitment
  • Train for better retrospectives in all areas of our company. Building on our own experience as well as on a number of expertise (for instance getting value out of agile retrospectives) we see retrospectives as a key format for learning and improving. Reviewing the basic principles, providing both a clear structure and encouraging methods and establishing a clever sequence of retrospectives in all areas shall boost company-wide inspection and adaption
  • Experiment with large-group retrospectives across service teams and with consultants to consolidate what we experience on the customer side and distill innovative ideas to approach the market
  • Meet other self-organizing companies to learn more from practitioners
  • Focus even more upstream: how to decide upon the right strategic initiatives?

 

About the Authors

Hartger Ruijs is entrepreneur by heart. Being convinced that technology adds value to society, he started his first company at the age of 23. In 2005 he founded Computest which meanwhile grew to over 100 employees. Ruijs is a very value driven person who constantly strives to improve himself and believes that self-responsible and happy employees are the foundation to create value for happy customers. He has been recently rewarded 'Entrepreneur of the Year' in the Dutch region Haaglanden.

Clemens Riedl is an Austrian IT entrepreneur who started his first business at the age of 19. He sold his company in 1998 to the Dutch Exact Group where he worked in various international management functions till 2010. Since then he invested in a number of smaller IT companies including Computest, where he usually takes an active role in organizational development and management coaching. Meanwhile he has also transformed his passion for fine wine and contemporary art into small businesses.

Siegfried Kaltenecker is the joint managing director of Loop Consultancy, based in Vienna. As an expert in lean and agile change management, Kaltenecker n has already been involved with multiple companies such as bwin.party, eSailors, Magna, RWE, Swiss Federal Railways, and Thales Group. He authored the InfoQ book on Leading Self-Organising Teams and co-authored Kanban Change Leadership

Rate this Article

Adoption
Style

BT