Descaling organizations interview with Jurgen De Smet

Tomek Wykowski: Certified Scrum Trainer, owner of ProCognita Company

We were going to talk about working in large scale organizations but you said that you are helping executives in descaling their organization. What is the descaling of the organization? 

Jurgen De Smet: Certified LeSS Trainer with 20+ years of experience in implementing Scrum, with 10+ years of experience in implementing Large Scale Scrum into organizations, co-founder of a Co-Learning company.

Most probably due to past problems that organizations experienced, people apply quick fixes. Quick fixes mean adding processes or rules on top of existing ones to prevent some things from popping up. For example, if there was a production issue, and they don't want this to happen anymore because it disrupted an environment too much, then a quick fix might be: “Let's initiate some kind of extra step between creating software and putting it in production so that we are reassured this is not going to happen.” And most probably, we do this with other people, so we initiate another department on top of that. Over time lots of those quick fixes had been applied due to time pressure, or some imaginary pressure, so they built quite a complex structure. Agile requires simple structures with fast decision making, so if you truly want to reap the benefits of doing an Agile adoption, it means we need to descale the organization by reducing complexity - horizontal complexity, vertical complexity, spatial complexity, technical complexity. That's tremendously slowing down the organization especially in receiving true feedback on whatever the organization wants to put into the market feedback. Is it valuable or not? Does the top-line grow? We don't know. Having long feedback cycles increases the risk of building stuff that might not even be successful.

The bigger the organization is, the longer this feedback cycle is. Why is it so hard for those bigger organizations to descale then? 

There are many different aspects to this question. First, I would mention Craig Larman's laws of organizational behavior which is saying “organizations implicitly don't really want to change the first level manager positions, poor structures, and specialist positions.” So, implicitly, we want to keep it like this. Many organizations start to apply Agile practices, they use the Agile terminology, but they don't change the real behavior. If they don't really address the real root cause of certain issues, they are not flexible and Agile. 

New labels on the old stuff?

Or avoiding doing the real structural changes that are needed. Not really benefiting from the Agile culture as it is intended. Also, we need to really go inside the teams, into the dirt of the misery that most probably has been built over the years because of pressure - cleaning this up. Because if they change organizational structures or they put new roles expected because it's on paper, that it's immediately applicable but behaviors don’t change. They forget about one of the major aspects of Agile or agility at an organizational level. Their technical agility. So the misery of the monoliths, very ugly architecture, coding, that they had in the past. We need to work on both domains.

So, delays are caused by technical problems and by the current structure?

Many of the technical things come back. Like dependencies. I don't see dependency as an issue, it's just an opportunity for improvement, getting rid of it. Most of the dependencies come from bad architectural decisions or organizational structures. We need to work on both at the same time. This is where organizations misinterpret lots of things. They work on one, but not the other, and then you get constrained by those things. 

How do you start the transformation?

If they approach me, it starts with doing a tour of the assessment of the context. I don't believe in a “copy-paste approach”. There's no one way you can just copy/paste somewhere else. you need to understand what is the business domain you're working in, what are the market constraints, what are the technical architectural constraints, how is the current collaboration and organizational structure set up, what are the processes there? You need to assess the organization from lots of different perspectives - technical, organizational, business-related - to get this kind of understanding. Does it fit or not? What fits? Where do we need to start? And, I think this is a crucial part: where do we actually start? The first thing that we try, is we do a pilot - or proof of concept, or whatever you want to call it. In the past, we used to look for something which is not that highly prioritized. So if we fail, it's not that bad. But because we choose something which is not highly prioritized, then we don't get the attention and deserve to make it successful. These days I'm looking for high-impact related domains where we can do a proof-of-concept. Then if we ask business people and users to participate in refinement reviews, they’re entitled and are willing to come. If it's not a high-priority item, then your business users and others will just refuse to come over. They have the right to say no because there's more important stuff. Then you don't reap the benefits and then things go just backwards - back to the old structure. 

In high priority areas, you have management support and it's easier to remove all those constraints you mentioned?

I think this is crucial. You need to have top-down support that allows for bottom-up volunteering. We tend to work with volunteers. If they choose to be part of it, people want to make it a success, they are going to be more coachable, willing to use new practices and techniques. 

One of the very popular approaches is doing the transformation of the whole organization at the same time. You hire consultants; they come in and you end up with the new structure and a huge bill from those consultants. But you want to build awareness - we want to find the volunteers instead of just telling people that they work in a different structure. 

The main reason to work with volunteers and to make sure we have these top-down supporters is to have a big enough piece of the puzzle to show impact in a short enough timeframe. So that we generate some bumps or dumps somewhere in business-relevant metrics. If you only do this as one team in a large setting, then you cannot generate impact. If it's volunteers, they want to make it successful, so the impact of your change will speed up. If you can generate impact, you acquire more mandates - more insights from the executives. Deciding if to broaden up product definition from a LeSS perspective, or move towards other departments, which initially might not be part of this kick-starting setup. 

So why not the whole company at the same time?

Skills, knowledge, and understanding of the system. Every company has a different system, aspects, and different market constraints. You need to be able to explore this. Even within the same department, the same company but different departments or different sites, even in the same country, will have different system dynamics playing out. Most probably you don't have enough experience and skills in-house to actually support this kind of big, huge change at once. Another thing is, by doing an Agile, Scrum, Large Scale Scrum adoption you get a very high level of transparency. You see more of the things which you never expected to see before. So if you do this with a whole company and suddenly this kind of huge rock hits you in the face, then people don't take the time to figure out better ways. They immediately revert back to the old structures and that's a pitfall of Agile adoptions. If you take a piece of the puzzle, like for example, Base Company we work with Tech Mahindra, a huge consulting company for the CAPEX-related project contract that we had. We just added an addendum to exclude a certain area so that we could work with this area. You create a kind of a small black spot because it's a small thing in a huge pillar, and they give you time to figure out better ways on how to collaborate. Then, later on, they saw this actually is a lot better now and are open to renegotiating the complete contract and moving forward. If you immediately want to change the complete contract for everything, this is going to be most probably too risky and too much money involved. So by creating a small spot where you can uncover better ways in their context, this is where you cut quieter learning. It also gives you the opportunity to grow more of the Scrum Master or Agile coaching skills within the organization. People tend to rely too much on consultancy companies. 

So the goal is to kick yourself out of the company. 

My goal is to get out of the company as fast as I can so they can rely on their own skills. If they want to grow, they need to grow skills rapidly. They don't grow experience as very good Scrum Masters just by being there when someone else is doing the job. So you need to build skills entirely, you need to make sure that people acquire practices on how to rebuild or educate others in that skill. Not only build skills but also be able to mentor and coach others in that skill so that if you go to the next step, they actually can grow it within the organization. If you always need to rely on externals, then this is for me a recipe for failure. As soon as the externals go away, it’s collapse and goes back. 

Is there anything else that needs to happen to make this transformation successful? 

Something we already mentioned before is technical excellence. It’s going to be crucial. Otherwise, this becomes a constraint. For example, if you still work with long live branches… We create a branch and for months people cannot touch the same code or you risk going into integration hell again. This kind of behaviour is not really helpful in an Agile environment where you want to acquire fast feedback and also evaluate if whatever you're building is truthfully impactful to the market. This is something we need to address and, even if we do a small part, it means as well the surrounding teams will need to be involved. The refactoring, setting up built pipelines and deployed pipelines - they will be involved in this kind of thing to grow the technical excellence to a certain level. I don't say it needs to be perfect, but to a certain level where it's not a constraint for the business agility anymore.

Talking about technical excellence. You said, “the moment when we get the wrong architectural decision, we end up with an overcomplicated system”. We often hear is “we can’t let every team change the architecture because they don't understand it. We need to have one architect. You can do Scrum down there, but still needs to be architecture up here”. 

One architecture on the top it’s not necessarily a good approach. I work on multi-team setups. I have a big bunch of people and architecture is a core skill within the teams. I don't say it needs to be one person or two persons; it's a skill within the teams. Also, if it's one area, they need to understand how does it fit the full product. For that, you can do architectural workshops; where you, for example, do Event Storming because it gives you a sense of what should the domain model really be, not what it is in the organization. People suddenly understand this is the kind of architecture we need to start moving to, and then, by doing small steps, they can reevaluate. 

We move the architectural responsibilities to the team, but how do you convince top-level architects that used to make all architectural decisions? 

If this happens it means we don't have enough of the top-down support or the mandates are not big enough, even though we pushed for it and I'm okay with that. The first step is inviting architects into the multi-team refinement sessions where we discover what is the functional or behavioral demand, and then we build also architectural models parallel next to each other. Then they can give input, they can have a voice, just as team members. By collaborating, we will grow more trust. By doing collaboration refinement, also being part of review sessions, they will start to understand actually the teams are not that unskillful in this thing. Some of them, I have experienced, was actually asked to become part of the teams or show intrigue in further implementation of their architecture. They asked to become part of the teams, and then you can start building bridges. I think this is crucial - building bridges, showing them what kind of impact they can have if they would be part of the team. There's part of the impact in refinement sessions. If they want more impact, we invite them to join the team.

We see the transformation happening now. When do you know that it's not going to fall back the moment you leave? How do you know that you're okay to leave? 

I think you never know for sure. Certainty doesn't exist. I think the more appropriate question is: how can we prevent collapsing back to old structures? For this, we use a specific coaching approach. Initially, we show what we actually do together with somebody from inside the organization, to mentor somebody, to show them “this is how things are being done”. It's not just coaching, it's really mentoring. Then we switch seats - the internal person becomes the driving seat and we're in the back. So if they drive in the wrong direction or they make some mistakes, we can intervene. If this is okay, we step down and then we coach from the sideline. They can coach somebody else in the same domain again. We have a full one-year remote support. We do this through Slack with more than ten really experienced coaches, where they can have instant feedback. Those coaches are being paid to monitor and give fast feedback. Next to that, they have video calls every month. So this is like, “we go away, but we don't really go away - we’re at the back.” We're still there with formal and informal leaders driving that change forward. A year later we still follow up on those things and we understand what is happening. If we feel that the organization is really moving forward by themselves, continuously improving, and we see the mandates growing and the product definition is growing out not because we provide more transparency but because they provide transparency by themselves. That's the moment I think, “okay, yes, this is it.”  Now, this is really sustainable change, it's not going to end because Agile never ends. The first sentence, “Uncovering better ways…,” so there's no end to it. 

If people are struggling with trying to do the transformation in their organizations, what recommendations, can you give them? 

I think it would be: start reading books related to real code, coding structures, code craftsmanship practices and mindsets. In ProCognita you’ve Gojko coming over with Specification By Example. Impact mapping - those are great techniques. Go from business towards the technical. Read the book “Your Code is a Crime Scene.” Even for non-technical people, this would be a very useful book to make their Agile adoption more successful, because in my opinion, what is most lacking in today's Agile adoptions is the respect towards people being at Gemba, the real code. Getting more understanding of coding and architecture would be the best thing. 

I was hoping you would mention the system thinking. Anytime we do the change, people need to understand the whole system.

I used system thinking to come to a conclusion that the technical part might be the thing that is lacking the most because people don't understand it. System thinking would provide them with the understanding of how it is interconnected with their business agility.. It's about the people and the structures and the process. 

Do you see any changes in the organizational approach or how the organization changed over the last 10 years?

Ten years ago it was more of a bottom-up approach, and today everybody who wants to be Agile, needs to be Agile. They don't really acknowledge the learning that they need to have as an organization anymore today. That's where this Agile theatre comes from - so they applied Scrum terminology, but they definitely don't apply Scrum from within the principle, or as it’s intended to. I tend to call even some of the Scrum implementations “pure team torture.” I think this is the biggest change. I also think this is a challenge that is going to be very difficult to survive within the Scrum community. How can we preserve the true meaning of Scrum while there's so much theatre being played around by less experienced people or people not understanding Scrum from within the principles? I think one of the reasons for that is the “big bang” stuff you already mentioned before. We do the full organization change. We basically see the Scrum Master as the old team lead or team secretary in the worst case, and that's it. I hope LeSS (Large-scale Scrum) will be more like eXtreme Programming - it didn't really catch up as much as many other frameworks, but it's still there and is very successful. I hope with LeSS , you get into similar things; it may not be the scaling methods, which is more of a descaling practice. Not as popular, but I hope it's still there because it delivers the true impact that is intended, just like eXtreme Programming was doing on a single team.