Agility as the subject of conversation has today become as popular as the topic of digitalization. Nothing is safe from the agility wave anymore. Only a short time ago, a priest announced: “We have now organized our church to be completely agile.” In the meantime, there is not a single organization anywhere that would not like to attach the label agile to its name. In the same vein, no organizational unit is being spared from obligatory scrum training. Fed by various agile saviors who wave the agile manifesto around above their heads, the issues at stake concern the individual, thinking in terms of concrete products, collaboration with customers, and the ability to change. Regrettably, however, in many cases they never go beyond the paper stage or take the form of a schematic one-to-one implementation of the method – a kind of “method for the method’s sake,” so to speak. The questions we should ask ourselves are different. How can an organization really set itself up to be agile? How can the level of ambition of the unit be raised above the usual mediocrity? How can we succeed in creating a “marketplace of opportunities” or an “optimal place to grow” for talented people with potential? And: Does a one-to-one realization of the method make any sense at all? Or isn’t it necessary for every company to find its own individual way?
There was plenty of motivation for our new team, which came together at the start of the year when the Practice “Company ReBuilding” was newly created, to explore the subject itself. The goal was to find an agile method for the successive development of our products by realizing a faster time to market.
Our Approach
We combine a traditional agile steering model with objective and key results (OKR). It enables us to establish a clear focus (one of our values, by the way) as well as really to process only those topics that contribute to our overriding collective goals. It is a means of setting objectives that can be made measurable by using concrete key results and that can be broken down to the level of specific topic teams.
The advantages of an organizational and working form based on agile values and principles was obvious to us because, if it is done properly, we can then:
- Respond more quickly to changes, e.g., to new customer requirements;
- Raise the delivery speed of new products and services;
- Create a work organization that adheres to these principles side by side with a New Work working environment.
Our agility team’s idea behind this was to connect the high degree of planning variability and ambition level of the OKRs with the advantages of an agile approach. In theory, a good and practical idea – in practice, it involves a number of challenges.
A traditional agile approach as well as the OKR logic foresee iterations and/or a definition of the OKRs over different periods of time.
Our solution: an iteration is set for 3 months while the Community objectives are valid for a year. But be careful! This implies that the general objectives are defined to be correspondingly broad. One example: “We are a high-performing team.”
Tip No. 1
The length of an iteration or a sprint must not collide with the validity duration for OKRs.
The length of the iteration also determines how long the planning of resources and topics remains in effect. In our example, this means that we define precisely what and how many resources work on what topics over a period of 3 months. There is practically no capacity for additional tasks here. Detailed planning, however, is the most important element in an agile steering model and consequently indispensable! For a consultancy, a business that often has to deal with ad hoc topics popping up, this is definitely a major challenge.
Our solution: the creation of a team for ad hoc topics. This team (or as we call it: the pilot and his crew) stay together for about 1 year and are independent of the topic teams. In contrast to the interdisciplinary and changing topic teams, continuity is important here. People with experience, e.g., in the preparation of quotations, are especially important for tasks that repeat over and over again. The teams are supported by scrum masters, who we call “masters of ceremonies” in our corporate context (see Tip 5).
Tip No. 2
Leave room for capacities for handling ad hoc topics that are time-sensitive and cannot be planned.
Another elementary component of our combination of agile procedure and OKRs is the Communities of Practice (CoP). Originally, they were not much more than a leftover from our previous structure, but could nevertheless not be tossed aside. The Communities of Practice are the repositories of our knowledge: e.g., Design Thinking, agile organization, business ecosystems, customer excellence, future communications, New Work, future trends. They have a special responsibility. And the challenge was to transfer this previous structure over to the new logic because their initial task has undergone a fundamental change. They no longer select their topics themselves and work up new concepts in their silo. From now on, they actively contribute their knowledge to interdisciplinary teams. Their primary task now consists of sharing their knowledge (and continuing to develop it, of course) and to serve as topic experts. They still meet regularly to exchange knowledge, but the work is done on interdisciplinary teams! You can imagine that this was a major change for some employees.
Our solution: we explain why we are re-organizing and prefer to solve issues on an interdisciplinary basis instead of in silos. Once the spark of understanding took hold, the rest of the Community was itself completely hooked on the new model.
Tip No. 3
Have good reasons for your actions, and describe them plausibly.
As most “agile” readers undoubtedly know, the word “planning” has a special meaning in the context of agile steering models. The core of the planning is namely the backlog or topic inventory that we call “old fashioned.” All of the important activities of an iteration are entered here. Yet the topics do not follow a hierarchy. They may come in from CoPs, individual Community members, the Practice Council (we will describe what this is later), or even be derived top-down from corporate strategy. In itself, a simple principle, but it must be communicated first! When the Practice has just been established and its members do not all join at the same time and subsequently do not have the same level of knowledge, this is a challenge.
Our solution: regular communication. From the very beginning, we introduced various communication formats, whether a major summit meeting at the start of every iteration, a regular newsletter, or the bi-weekly every 2 weeks. The information must somehow be delivered to the right people! The group meets at regular intervals to take a look back and reflect on what has happened. The reflection aims to achieve iterative improvement of the collaboration.
Tip No. 4
Set up a communications strategy from the very beginning. You can never have enough communication during change processes.
The topic inventory is one thing, but much more important is its prioritization. For every iteration, a new iteration topic inventory must be drawn and set up from the general topic inventory. Handling this task is the job of the Practice Council, a mix of experienced employees from every career level. But before we look more closely at this and other roles that are gradually becoming necessary for the construction that has been developed, let us consider the prioritization of topics – a difficult task because everyone would preferably like to see everything realized at the same time.
Our solution: we brought our agile coaches to the table. Strict facilitation and focus on the results were as valuable as gold during the lively discussions about the importance and urgency of specific topics.
Tip No. 5
Have the planning facilitated by experienced agile coaches, especially at the beginning.
It became clear to us at a relatively early point that the steering model we had developed would not be a sure-fire success. With this in mind, we introduced the following roles in addition to the pilot with his crew previously mentioned: product owner, master of ceremonies, and the Practice Council.
The product owner is in charge of the preparation of the initial description of requirements and definition of acceptance criteria at the end of the iteration and is ultimately accountable for the quality of the results; the acceptance of the results is his/her responsibility. Prior to acceptance, he/she continuously supports and challenges the heterogeneous team of the topic that has been staffed interdisciplinarily from the various CoPs. In addition, we introduced the role of the master of ceremonies; this person is in charge of the operating excellence of the steering model and its implementation. Content management and overall responsibility for the Practice has been assumed by the so-called Practice Council. It was important to us to avoid terms such as “leadership” or “management” because we wanted to create a procedure with as little hierarchy as possible that would follow the agile model. The first Practice Council comprised eight people from various career levels and backgrounds. This was an innovative feature for our organization – and the experience from the first iteration also taught us several things about the ideal working size of a steering team.
Our solution: we still don’t have one. We are not yet one year old and must still do some experimenting in this respect. We are now trying out the approach of using a Practice Council consisting of only 4 members so that, in particular, discussions can be shortened and decisions can be made faster. In addition, we have introduced a Sounding Board to which the former Practice Council members belong. One person from the Sounding Board with the appropriate professional expertise is invited to specific Practice Council meetings; this person is expected to bring a different perspective to the issue and serves as a representative of the Sounding Board in making decisions.
Tip No. 6
Various roles and responsibilities are a “must” for agile steering models. But do not just copy one-to-one the roles that are described in the textbook; adapt them to the specific circumstances of your organizational environment.
Once the pillars of the agile steering model and the required roles had been set in place, the question about the modus operandi arose. The process, the planning cycles, and the meeting structure (planning, bi-weekly, demo, retro) have now been established, but one thing is still open: the tool!
It is especially important to be able to use the tool to model clearly the topics and the OKRs. The decision as to which tool we would use was a relatively easy one. Our San Francisco office recommended our cooperation partner Workboard to us. Besides being extremely user friendly, this tool digitalizes essential components of the model: OKRs and kanban board for each topic team. The procurement of a completely new tool and the related clearance through the corporate IT and security processes proved to be a very tedious and complex procedure, however, with the consequence that we were not able to introduce the tool until much later than planned.
Our solution: Option 1 (ideal case) – before you begin with the first iteration, make sure that the tool is ready to go and that the agile procedural model has been clearly thought through and communicated. Option 2 – if the tool is not ready at the start of the first iteration, do not introduce it until you are ready to start the second iteration. Avoid introducing new tools and process steps during the iterations. This demands too much of employees and is not effective.
Tip No. 7
Select only one of the aforementioned options and avoid any mixed forms to the extent possible.
Tip No. 8
Decide on a tool that mirrors your needs optimally and digitalizes the process simply, making it transparent for everyone.
Please do not try everything at once. Put your trust in an introduction in small steps that are easily understandable to all employees.
