reading

This publication is listed in the Deutsche Nationalbibliographie of the Deutsche Nationalbibliothek; detailed bibliographical information can be accessed under www.dnb.de

Printing, Production and Publishing: BoD – Books on Demand GmbH, Norderstedt, Germany

Illustrations and Cover: Juliane Pilster, Stuttgart, Germany, http://agile-ready.org

Foreword by Jurgen Appelo

I once invited my team to do a code review in the sun. The weather was beautiful; we had a habit of discussing source code each week; there was a nice patch of green grass just outside our office, and I was in a joyful mood. So why not?

I also organized lunch meetings where employees shared their vacation photos. I invited colleagues to cook dinners in my kitchen. (Food is a recurring theme in my work-life.) I convinced our office manager to put up a bell that we could ring to mark celebrations (with cake or cookies, of course). And I used my office chair as a wheelchair while visiting teams across the entire office, a practice that I consider naming Management By Rolling Around (MBRA). Some people thought I was a silly manager.

Several years later, when I quit my job as a development manager to become a writer and speaker, one team member told me that I was “the best manager he had ever worked with”. Another person said I was “the first manager who didn’t suck”. Some experts say that, when employees quit, they usually do so because of their managers. But not in my case. I had evidence that, in my part of the organization, turnover dropped to nearly zero. Sure, I was probably a silly manager, but my team members stayed! And my CEO was pleased.

Whether I was indeed a good manager, or just the first one who didn’t suck, it was clear that I managed things differently compared to others. I had no fear of experimenting with unconventional ideas. I wasn’t interested in implementing management practices just because they were the norm in other organizations. I cared much more about practices that had a positive impact on people’s happiness, engagement, and productivity.

When I started writing about my alternative approach to management, which I named “Management 3.0”, some managers in other organizations started copying my practices with their own teams. A few of them even wanted to know all the details, variations, and exceptions for each practice. I received questions similar to “How long does it take to do a code review in the sun?”, “Is it OK for the team to sit in the shade?” and “What do you do when it’s raining?”

As a writer and speaker, I share management practices that worked for me (and some practices used by other managers and their teams). What worked for me could work for you. But there are no guarantees. And I cannot share all the details, variations and exceptions, because I don’t know them. You will have to try for yourself and see if you can replicate the successes. Every good practice for me is an experiment for you! That was always the best advice I could give to anyone who asked for more.

It was with great pleasure that I learned about this new book written by Dominik Maximini. Dominik has been experimenting with nearly all Management 3.0 practices as described in my works. With many of them, Dominik succeeded. With some, he failed. But when Dominik failed, he figured out how to change the practices and make them work in his situation. And with other ideas, he was able to venture far beyond what I had experienced or even imagined myself.

Managers are like chefs. (I warned you about my food obsession.) Chefs use standard recipes from books, but they always change things depending on their guests and the environment in which they need to cook. Great dishes should first be credited to the chefs who prepared them, and only second to the original recipes that they used while cooking.

In this book, Dominik shares all he knows about experimenting with Management 3.0 practices. Managers (and chefs) are best advised to improve their work, not just by reading more recipe books, but by learning how other managers have experimented with and improved upon those recipes.

A New View on Management

Our economies are changing rapidly. Product life cycles are getting shorter, market and customer demands are constantly changing. Customers are no longer looking for a product but rather for a specific solution which best fits their own specific needs. New technologies arise and offer radically new approaches for solving existing problems as well as offering new options. Old competencies are losing relevance, new competencies are in demand. When working with students, committees and leaders these topics are dominant, and lead me to the insight that these changes are significantly impacting the work of today’s managers.

This creates conflict between employees and managers, especially when considering established management structures and styles. Employees no longer want to be “traditionally” led, as the demands upon them are soaring. They demand the right to have a say in more matters and expect their own needs to receive a central focus.

Adapting the organization to increasingly important external influences, namely organizational change, also requires the active role of management. Without active leadership, successful change will not happen.

Dominik’s new book is based on many years of experience in management consulting, and with applying new management techniques in agile environments. He is focusing on successful change management especially highlighting the principles of building teams, as well as the necessary changes in organizational structure, leadership and focus of the organization. These changes also have to be supported by other systems, for example those used for performance measurement or reward distribution. His book is an integrated, holistic approach covering all the relevant aspects necessary to achieve successful modern-day change management. He excellently describes how the role of leaders needs to evolve in our rapidly changing business world.

Dominik’s approach is unique for that matter and transports an integrated agile management approach. This integrated approach is especially important in times of dramatic change and helps managers to shape a new vision for their role. All stakeholders are integrated and become partners in the change process, forming a robust foundation for future profitable growth.

Prof. Dr. Claus W. Gerberich, University of Lucerne, Senator of the European Economic Forum (EWIF – Europäisches Wirtschaftsforum e. V.)

Foreword by Konrad Pfeilsticker

In October of 2008 I started at NovaTec as Business Unit Manager (back then a totally undefined role) for the specialist area of software architecture. Up to that point in my professional career I had worked as software developer, software architect and IT consultant, ten years of which with IBM. My expertise and experience in management was unfortunately limited. After successively taking on management activities and ultimately becoming a NovaTec board member in 2015, it was very valuable for me to have colleagues like Dominik Maximini in the company, who focused fulltime on company cultures and management practices as their specialist consulting area. Over the years a synergy has developed between the idea generation in Dominik’s specialist field and the experimentation with these new approaches within NovaTec itself. As decision maker it was my responsibility to understand these good ideas and implement them together with the management team.

This book before you now, describes the long change journey we have taken together with Dominik. I have learned a lot, and am very pleased to have taken part on this journey. This journey however is far from over; we regularly encounter new potential for improvement and creativity. Amongst other things we want to increase transparency within the company, and allow our employees more space for forming something new. One of the next steps is to improve the working environment within NovaTec under the catch word “agile workplace”. As part of this we want to enable and support the best possible creative and collaborative working conditions. I am certain that during our implementation process we will continue to encounter new ideas for improvement that will serve our company even better still.

Our path to this point was not always easy, but looking back on the journey, it was a good decision to make the effort to implement the Management 3.0 principles. Today, we can already see that the changes have had a significant positive effect. In the meantime we have established diverse metrics, that we now regularly monitor, and which have continuously improved over several years. One might assume that the agile values and Management 3.0 practices, e. g. employee satisfaction, only show benefit internally. It is however clearly obvious to us now, that these changes also show a positive influence on traditional external business metrics like customer satisfaction and profitability.

One point that should always be kept in mind, is the speed of change in connection with potential fatigue created by changing too quickly. Here you need to constantly find an optimum between the rate of change and the increased demands on those involved. I would be really pleased if other leaders could learn from our successes and our failures, and integrate these findings in their own future decisions and actions.

What You Should Expect From This Book

This book is an experience report, based on the last seven years of my work in a single company. Although I am a consultant, this book does not tell you anything about my customers. Even though our customers influence many of our decisions, this book doesn’t tell their story. It is purely focused on telling the story of NovaTec, a 200-person Germany-based IT consulting organization. While the descriptions of what we did are accurate, their interpretations represent my personal opinion, or the opinion of the people cited. You should not conclude that everything that worked for us will work for you. Your situation is unique; what you read here could help, on the other hand it could create chaos!

I strongly recommend running experiments. If something appeals to you, figure out how to run an experiment in a contained environment. If that succeeds, go ahead and try a larger one. At all times make sure you are engaging your primary agile tool: Namely, your brain.

Please do not expect this book to be a blueprint for your own journey towards Agility. Take it for what it is: A collection of stories, experienced by somebody else, that might inspire you, but were not designed for your own individual environment.

List of Contents

List of Tables

List of Figures

Figure 16: Complexity Domains, Based on Stacey (1996, p. 47)and Schwaber & Beedle (2002, p. 93)

Context is Everything 1

Before we dive into the details of our agile journey, you should understand our context. Only when you understand the circumstances, will you have a fair chance of judging the use of what you read for your own situation.

1.1 Organizational Culture

Introducing agile methods into an enterprise almost always causes the existing organizational culture to change. If you want to understand the details of culture, you can find a multitude of authors who talk about it. For example, you can read my book “The Scrum Culture” (2015), upon which this chapter is based.

Personally, I prefer Schneider’s brief definition: “Organizational culture is the way we do things in order to succeed” (1999, p. 128). Ed Schein goes into more detail and specified three levels at which culture manifests (cf. Schein 2009, pp. 39-40):

The external survival issues are everything an external visitor can observe in the enterprise: Company mission and vision, strategy, goals, and the means to implement them. This involves organizational structure, the systems and processes being used, including error-detection and correction.

Internal integration issues cover the parts of a culture only an employee of the company can perceive after some time in the organization. External visitors most likely will not be able to identify these aspects. They include the usage of a common language and common concepts as well as the answer to the question who is an “insider” and who is an “outsider”. Essentially, group boundaries and identity are defined on this level. The internal integration issues also describe how status and rewards are allocated, how authority is distributed and how work relationships are established between people. For example, authority could be distributed based on technical knowledge (the one most knowledgable on the issue at hand is followed) or based on position (the one with the most stripes on the shoulder has the last say).

The deeper underlying assumptions are difficult to name even for people who have been with the company for many years. They contain basic assumptions about what makes the world go round, including questions like:

These questions are rather more philosophic than economic. In a business context, you only encounter them on rare occasions. However, they do have a huge impact on our everyday actions. Imagine two people coming from different cultures: One person believes it to be absolutely true that time is absolute and static. Once gone, it’s over and lost. The other person is absolutely sure that time is elastic, moving relatively compared to the situation. A sentence like: “The project must be finished by date X”, will be interpreted significantly different by these two people …

I will not go deeper into the theory of organizational culture. This book is also not structured using the three levels Schein defined. Instead, you will find spotlights on specific things we tried and changed. With the knowledge about organizational culture in the back of your mind, you will be able to recognize the impact this had on our culture.

1.2 Management 3 0

Management 3.0 is a term coined by Jurgen Appelo in his book of the same title. It is a toolbox of agile management practices along with a set of principles that these practices must follow to qualify. All Management 3.0 practices are free to use and can be found at https://management30.com or in Jurgen’s books, in particular in “Managing for Happiness”. Whenever you read “Management 3.0” throughout this work, you know that we used one of these practices, and you know where to look it up for more information. You also know, that the practice was taken from Jurgen’s work.

You probably still wonder where the name comes from and what the number means. After all, we are talking about industry 4.0, so why do we still use Management 3.0? The answer is that Jurgen defined Management 1.0 as “Doing the wrong thing”, which is basically tayloristic top-down management. In today’s fast-paced world, you simply can no longer succeed with this type of management. Management 2.0 is described as “doing the right thing wrong”. This means, having great ideas like focusing on employees, teams and quality, but using systemically flawed methods that do not look at the overall system to achieve that. Management 3.0 instead tries to look at organizations as complex adaptive systems and offers methods that are adequate for this kind of environment. Therefore, Jurgen defines it as “doing the right thing”. If you prefer another name, that’s fine. Personally, I prefer “agile leadership” as a general term. You will also notice throughout this book that we tried other methods that are not described by Management 3.0. That’s fine. Management 3.0 is not a methodology that sends the process inquisition after you to throw you into purgatory. It’s just a toolbox. Extend and adapt it, whenever you feel the need.

1.3 The Market

Economy is great right now. It’s September 2017 and the unemployment rate in Germany hovers around 5.9 % (Statista 2017a). It has been declining steadily for years and new jobs have been created in many sectors, and in particular in IT. In southern Germany, where NovaTec is based, the unemployment rate is even lower at 3.6 % (Statista 2017b). That means we have more open job offers than people applying for them. This also leads to a very high demand for consultants, which is good for NovaTec. Also, the biggest industries in southern Germany, namely automotive and engineering are faced with the biggest challenges since they came in existence: Everything is digitized, even physical machines are starting to communicate with each other in the “Cloud”. Cars, reconfigured to electrical engines, connected with all kinds of digital systems, will be driving autonomously in the near future and will be shared amongst multiple users (instead of being used by only a single person as today). This is all new and requires a huge amount of IT and process knowledge. To achieve this, almost all German companies are trying to “become agile” or “introduce agile methods”. All this leads to an ever-increasing demand for agile consultancy. As a company focused on IT consulting, it is almost impossible to fail in this environment – as long as you have able employees to satisfy the demand. The challenge during the last years was to get and keep skilled employees who are happy in the company. Starting a business unit for agile consulting seems like a natural fit here.

1.4 The Playing Field

In September 2017, NovaTec is a 207 employees strong Germany-based IT consulting company, conducting business mainly in southern Germany and generating a revenue of roughly 24 million Euros per year. We have several branch offices, the most important ones being located in Frankfurt, Munich and Granada. The goal is to deploy people near their home location, but it is normal for us to travel if the customer has a need for it. NovaTec is organized in “competence areas” (CAs). These competence areas are fully accountable for their revenue, contribution margins, hiring and firing since 2017. They are basically autonomous business units. We are divided into the units of agile methods, agile quality engineering, application performance management, business process management, enterprise application development, enterprise architecture management and IT architecture. So this structure is based on technical competence rather than industry or other focus.

We are earning money with three types of services: professional consulting, developing software for our customers, and training. The structure is primarily supporting the consultancy and training services. This is neither good nor bad, I just want to give you an idea of what to picture. Our employees usually work for our customers – either in our offices or at their sites – eighty to ninety percent of their time (e. g. Monday to Thursday). The rest of their time is used for learning and building up work relationships. All competence areas consist of dispersed teams, so not everybody is living near the same branch office. Since all CAs are autonomous, each one deals differently with this situation. Each competence area is led by a “competence area manager” (CAM) whose primary qualification is technical excellence in his domain. These CAMs are reporting directly to the management board. In fact, they are all reporting to the same manager. To support all this, there are central functions like central services, billing, IT administration, human resources, sales and marketing. These are reporting to different managers of the board. All CAs can use their services, in many cases this is even mandatory.

1.5 My Own Role

Today, my role has multiple facets. About three days a week, I am working as a consultant, helping customers to implement agile methods or providing training to them. The rest of the time, I am working on tasks as the competence area manager for “agile methods”. This means on the one hand people management, and on the other hand working on team tasks as part of the team. In addition, I am the primary change agent inside NovaTec, meaning I am expected to suggest changes, conduct experiments and work with the management board to implement good experiences on a larger scale (cf. figure 1).

Figure 1: Dominik’s Task Distribution

If you want to understand the context, especially about my own person, it is not enough to know what I do today. It is also important to understand where I came from professionally.

After studying Business Information Technologies in Trier, I worked for almost four years with Carl Zeiss. We founded a startup, by taking it out of the corporate Research Division. The goal was to create a product out of an idea and get it ready for serial production. Technically we were successful – but not so on the business side. In 2009 we even won an innovation award for “innovative business design”. This was the place where I first came into contact with agile methods. One sunny day my boss walked up to me and said: “Dominik, you will be our Scrum Master from today on.” While that certainly sounded like a cool title, I didn’t have a clue what “Scrum” was. So I asked for a training but was given a book instead, followed by the advice that trainings were expensive and I was certainly smart enough to figure it out all by myself. So I was now able to practice with three teams: One doing regular software development, one doing research and one doing hardware development. Of course we all tried our best, but without proper support or education we often stumbled and probably made every single mistake possible. During that time, I realized my interest for leadership and management. Compared to my boss I had fundamentally different views on many questions, especially business ones. We discussed them with great enthusiasm. I liked that, it taught me fact-based discussion and I am still trying to use this technique every day. We also had completely diverging management styles. I tried to leave decisions to the teams and stick to them for a while while my boss tried to make the decisions himself and tended to change them several times a week. It was a great opportunity that I could observe and experience these different styles myself, including their consequences. After three and a half years the relationship between my boss and myself changed. The discussions became more heated and less fact-based. In the end we couldn’t agree on the question if age per se had something to do with the quality of decisions, so I left. At that time I had learned so much that I had already qualified as a “Professional Scrum Trainer” with the recently founded Scrum.org. Helping and teaching others is a strong motivator for me, so I decided to become a consultant. My application at NovaTec was accepted and I have been working there now for more than seven years. The environment allowed me to thrive, to further deepen my knowledge and experience. I worked my way deeply into Scrum, organizational change and agile leadership. The feedback from customers and colleagues added additional motivation, allowing me to write two books and doing a part-time MBA in the evenings. Helping build a local agile community, supporting the Scrum. org trainer network and speaking on some conferences supplies me with a never-ending flow of new impressions and additional learning opportunities. These facts also created a level of trust with NovaTec’s management board that led them to ask me to build up the competence area of agile methods. This was a great opportunity since I could finally apply all the knowledge and experience from my customers’ teams to my own team. To support this, I studied Management 3.0 and became a facilitator. We live this leadership style every day, and are truly successful with it.

1.6 The Timeline

When we look at the last couple of years at NovaTec, there are three phases that are important for you to understand (cf. figure 2). All the experiments conducted and the decisions made fall into one or more of these phases and were influenced by them.

Figure 2: Three Phases

The first phase was relevant in my first years at NovaTec. I was a regular consultant. In my job interview, the COO told me that he wasn’t sure if he should hire me since I was not very experienced in JAVA development. Well, that wasn’t the job I had applied for … During that phase, I spent almost forty hours a week with customers. My title was “consultant”, later “senior consultant”, and my impact at NovaTec was restricted to the team I was part of. Even there it was small. We were three people: One competence area manager, one Competence Group Manager (comparable to a team lead) and myself, the worker.

The second phase was mainly influenced by a struggle inside the management board. During that time, there were three members of the board. One of them (the CEO) was finally ousted by the others, and two other managers (the CTO and the COO) were promoted into the board. Today, there are still these four members in the management board. This period of time was very volatile. On the one hand, everything was paralyzed for almost two years, no strategic decisions were made by the board. On the other hand, this experience created an urgency for change and opened ears for suggestions. In addition, our board members were content in high-level strategic alignment, so we were pretty much unconstrained in what we were doing inside the business units. This helped us to conduct more risky experiments and go a little bit beyond our competence area borders.

The third phase is still ongoing. The difficult process of parting with the CEO is now completed, and the whole board is full of energy working to create a thriving company. Even though some employees left together with the old CEO, this was healthy for the overall organization, allowing us to create a more homogenous culture – and again increasing the readiness for change. In this phase, we are trying experiments on a large scale, affecting the whole company. This is where the big wheels are turned.

It is important to keep track of these phases when reading this book. I constantly refer to them so you can easily understand why we acted a certain way in a specific situation. Without context, it is hard to judge if something could also work in your organization. At the end of this book in chapter 11 you will find a short description of these phases – you might want to refer to this for further clarity.

Building Teams 2

You now have an idea of our general situation and setup. The remainder of the book describes the experiments we tried and the results they yielded. Since building a team is always a good place to start with (and agile leadership relies on self-organizing teams), I will dive into this topic first. Please be aware that building a team is never over. While the effort you as the leader invest is higher in the beginning, it will never drop to zero. Even if no one leaves or joins the team, individual people develop and change all the time, causing the complex adaptive system called “team” to change as well. On top of that, all aspects of leadership are related to each other. For example, team- and trust-building are closely related to one another, as well as to basically all other areas of change in this book.

2.1 Getting to Know Each Other

Christian Richter, Agile Coach

Self-organization does not happen overnight. A self-organizing team continues to learn about each other’s strengths, capabilities, values and interests on an ongoing basis. The team also needs to develop a common mindset which helps them approach the variety of team challenges found in a complex working environment. To me, the main benefit of self-organization is to enable a team to continuously access and use this knowledge of each other to find better ways to work together towards a common goal. To foster a team’s self-organization the team needs to keep inspecting and adapting their relationships and interactions in order to stay healthy and continuously improve.

In our team at NovaTec we are still improving our self-organization. We have discovered that this is truly an ongoing activity. Goals and focus continue to change in our business environment, making constant communication crucial to keep everybody aligned and committed to a common goal. It is therefore key to have the right agile processes and tools to hand to ensure transparency exists throughout the team.

Self-organizing teams are something special. They don’t come into existence just by being announced, nor do they suddenly appear on stage after Scrum or another agile method was introduced. Many people aren’t used to self-organization. Even my team, after several years of practicing agile leadership and teaching agile thinking to others, isn’t fully self-organizing (I believe them to be at around 95%). However, before we can start thinking about self-organization, we must think about becoming a team. Teams are definitely not the same as workgroups. Teams are more than the sum of the individual performances of their members. Teams work towards the same goals. Team members care for each other. A team is not created by putting names into a spreadsheet and hoping for the best. It actually is hard work to get there. The ultimate ingredient for becoming a team is trust. The prerequisite of trust is really getting to know each other, because the average human being only cares for people she really knows. Think about it for a moment: What generates more emotions in yourself – when a person is killed in a remote country or when your neighbor has his lawnmower stolen out of his garage? Ethically, it should be the person who was killed. In reality, it is probably your neighbor. I am not a social scientist, so I cannot explain this phenomenon properly. When you are trying to become part of a team however, you should know about it and use it. The first step you have to achieve is to get people to care for one another. In addition, I purposefully wrote “become part of a team”. You can’t just “make them” become a team. You are either part of it, or you will fail.

The first thing we tried to get to know each other was working in workshops. We could fully focus on the factual level, working together on real-life problems. This worked well on many occasions, but failed miserably on others. After some time, we realized that we could not keep the relationship level out of the game. Workshop results were too low in quality and quantity. We discussed simple matters for ages to no avail. Working in workshops wasn’t enough. It was necessary though: The general format of a workshop allowed us to involve everybody, ignoring hierarchies and focusing on one question at a time. We learned about each other and observed ourselves at work. Even though it wasn’t enough, we were building the foundation for further action.