Re.vers.ify Organizations with Scrum – interview with Gunther Verheyen

An interview with Gunther Verheyen by Paulina Szczepaniak

You are a renowned international agile expert, with particular expertise in Scrum. Why do you think this framework became so popular?

Probably because of the growing need of what I like to call “agility”, meaning flexibil­ity, responsiveness, and not just from an IT perspective. IT is where agile sort of emerged from, but companies have to survive and thrive in very turbulent markets, a lot of business changes, market competition, but also internal changes, stakeholders and so on. And the way that organizations are struc­tured and therefore how they organize their IT work and their software development, because that follows from the way they are structured, is just not fit for the agility re­quired today to thrive and prosper. Structures are very rigid, very fixed, and need to become more dynamic. Adopting Scrum can deliver that level of dynamism. That however is a huge challenge. A lot of companies that start adopting Scrum, and that’s maybe a bit odd for the PMI, regain a focus on their products, the services they deliver to their customers, the products that they build, create, evolve. So there has been a movement from projects actually to products. Maybe you should re­name the PMI to the “Product Management Institute” [smile]. But it is an important evolution. Agile and Scrum were too much IT-driven for a long time. And agility doesn’t increase by delivering faster from IT to busi­ness, within an organization. An organization should be creating an impact on their market. And that’s where the real changes are. And that is why companies start with Scrum.

I recently wrote about my observations on the global adoption of Scrum¹. Looking back at history, Scrum was created in the early 90’s and for the first time officially present­ed in 1995, imagine – 22 years ago. Then, in 2001, Scrum received a boost, with the cre­ation of the Agile Manifesto². But it was only around 2005-2006 that we saw Agile, and Scrum as the most adapted Agile method, “crossing the chasm”, becoming an accepted way of working. That surely was an indica­tion of that growing need for agility. And then for the next 5-6 years, what I call the first Scrum wave, people were just getting to know Scrum, often from an IT perspective. And it wasn’t until about 2010-2011, the start of what I call the second Scrum wave, that huge organizations discovered Scrum. They actually discovered the need for agili­ty, and they felt like “Oh here is this magical solution called Scrum”. So “scale” became an important theme of this second Scrum wave. And another characteristic of what I call the second Scrum wave is a bit fascinating, be­cause that characteristic meant that people didn’t want to call Scrum, Scrum anymore. There were movements like Continuous Delivery, DevOps, Continuous Deployment, there was SAFe and Spotify types of models. All of them are big frameworks, and some of them are rather complex, but underneath it was still Scrum. Just nobody wanted to call it “Scrum” anymore. “Divergence” is the sec­ond characteristic of the second Scrum wave. And again, that second Scrum wave took 5-6 years.

And what’s happening now? Do you see any further changes?

What I observe happening in Europe and around the world from 2016-2017, so anoth­er 5-6 years have gone by, is that people are grasping for simplicity. And not just simplic­ity of their IT processes. Simplicity because that divergence of that second Scrum wave took organizations and teams in all directions and people are discovering that it’s not really helping. The world becomes more and more complex and you can’t fight com­plexity with complexity. So people are dis­covering that those huge frameworks in the end are not really increasing their business or enterprise agility. So I see not a new, but a renewed interest in Scrum, because people are discovering that the simplicity of Scrum is really helpful and valuable.

And that’s what I will be talking about to­morrow, on the subject of “re.vers.ify” [edi­tor’s note: at the 4th Project Management Conference by PMI PC Wroclaw Branch]. I will introduce how to move from using Scrum for the product development of an organiza­tion to reinvent or redesign the organization around Scrum. Because that second aspect is much overlooked. To put it in a negative way – you can’t do Scrum properly without reorganizing or without revisiting and rede­signing the organization. Scrum reveals many opportunities to improve our organizational structures but it seems we are very good at hiding ourselves from that and ignoring that aspect. So you’ve got the high complexity, its highly complex internal structures of an existing organization. It’s not really a great fit for Scrum, so we try to impose Scrum on it, bend Scrum, break it a little bit so that Scrum fits the existing structures. And that upfront limits what an organization will get out of Scrum. And that is where I try to help people with re.vers.ify.

Let’s focus a bit longer on re.vers.ify and re.imagining Scrum and the organization. How should we understand it and what levels of organization will this touch the most?

One of the core problems of the organiza­tions adopting Scrum is that over time, and it seems that it has been a historical way of growing our companies, we have creat­ed structures that are very silo-oriented, in terms of functional departments, groupings of the same functions in separate depart­ments. Like we have created silo’s in IT, we have similarly established a silo-way of orga­nizing business stuff – we have sales, legal, finance, marketing, all isolated from each other. But the worst separation is the IT side of the organization and the business side of the organization. That’s the biggest problem. The fact that it still exists means that peo­ple have not really used Scrum to redesign that, to transcend that counterproductive separation. Imagine that the Agile Manifesto already stated that developers and business people should work together on a daily basis throughout the project, throughout all the work. The difficulty is probably that, in a way, Agile and Scrum are agnostic about the way that enterprises organize themselves. That means that Scrum has no rules for organi­zational structures. Scrum introduces clear accountabilities to be fulfilled. And we were always hoping that once you start adopting Scrum, with the Product Owner and Devel­opment Team role clearly described, that people and organizations would bring those people and their skills together in Scrum teams. And that’s not generally happening. Organisations do Scrum within the silos, within a department often. Scrum how­ever was almost designed to help people transcend those silos and, in the end, even make those departments obsolete. Again, that’s not really happening. And that’s where I want to help people, to push people and or­ganisations a little bit, and shape the third Scrum wave.

In 2013 I wrote a book called Scrum – A Pocket Guide. And I ended my book with expressing my honest hope and belief that some day Scrum will be the normal way of working. Everybody will just do Scrum and maybe not even call it Scrum anymore, working in Sprints, with all people collabo­rating on solving complex problems in an it­erative-incremental way, together. And that in the future organizations will have re.in­vented themselves around Scrum. I think we can promote that a little bit stronger. Not just use Scrum for product delivery, but also for re-emerging organizational structures. And that is what re.vers.ify is about. “Re­versify” is an old English word, and its pure linguistic meaning is restoring the rhythm of an existing text, converting an existing text into a rhythmic, poetic format, bringing poetry back to an existing text. That is the metaphor for re.vers.ify, restoring, bringing back rhythm, cadence, a spirit of poetry into organizations, humanizing the workplace.

You mentioned your book Scrum – A Pocket Guide (A Smart Travel Companion). It focus­es on the purpose of the Scrum framework. What purpose did you have in mind while writing it and do you think, over time, that purpose has been fulfilled?

Strange things happened. I wrote my book four years ago as I was contacted by an IT publisher who wanted a book on Scrum. I was doubting whether I could do it, and whether it had value. There is already so much literature on Scrum. What I felt was potentially valuable was a book ‘just’ about Scrum, not about me as an author, my ex­perience, my war stories. Just a book to ex­plain the why of Scrum and its core rules. Be­cause a lot of books, which I dislike a bit, are just vehicles for authors to show off – “See what I’ve done and how complicated it was”. I wanted to go back to the simplicity of the Scrum, and demonstrate this simplicity. And in that sense, I tried to focus on the purpose and the rules of Scrum, as an elaboration of the Scrum Guide³.

Because we have The Scrum Guide, those 16 pages, explaining the core rules of Scrum and I wanted to build on top of that, sort of add a layer to that, not just repeat the rules. To really go into the WHY of those rules, so that people understand that it’s a light­weight framework, meaning it doesn’t have that many mandatory rules, but showing that those rules are there for a PURPOSE, for a reason. And I wanted to explain that reason.

I also wanted to show the difference be­tween the core rules of Scrum, the manda­tory rules of Scrum, versus good, but situ­ational, ways to play the Scrum, optional tactics or practices. Because over time, as Scrum became the most adapted method for agile product development, those things got mixed up a little bit. And it limits people, it blocks people in what they can achieve with Scrum. I wanted to liberate people from that limitation, arising from that misconception, core rules versus situational practices.

Coming back to your question, I have asked my readers why they bought it, what do they get out of it. Often people say that they have learned that Scrum is not just a process, not just a collection of rules, but a different way of working, a way of living, doing things. I am not saying that I wrote the book with that intention but I’ve been employing Scrum since 2003, so when I wrote my book I’ve been doing Scrum for 10 years, so that prob­ably did sneak in, in the book – my profound belief that Scrum is an amazing tool to use, if used against the Agile mindset. But it still is a tool, it’s not about the tool, it’s all about HOW you use it, WHAT you do with it. And if people see that there’s a mindset behind it, that’s something I like. So in that sense, I didn’t have any goals to reach with my book, but I achieved them anyhow [smile].

Is there a particular phase or moment in the organizations’ lifecycle when re.vers.ify and re.imagining Scrum are most need­ed or effective?

No. The expression I use is “re.imagine Scrum to re.vers.ify the organization”. And why I say that people should reimagine Scrum? Because I work with organizations that want to start with Scrum, or that have been doing Scrum for several years. And there is not really much difference. I often go in talking to executive teams or manage­ment teams because I want them to be in­volved. I am fascinated about the fact that when I do workshops and explain the core basics of Scrum, even when they’ve been do­ing Scrum for several years, it seems to be highly innovative and novel what I introduce. Although it is the way that Scrum always been designed. People do strange things with Scrum. I go in and explain Scrum as it is, as it’s designed to be, and everybody sees the value in the ideas. But at the same time, it seems it requires a lot of imagination to picture how it might work in their specific organization, e.g. “Wow, one Product Owner, from the business. Oh, an actual ‘Owner’ of the product, from what is said to be the busi­ness side of the organization, with a man­date”. So whether they already do Scrum or not, they have to reimagine their Scrum, go back to the core ideas and principles. And then the goal of adopting, expanding Scrum, in an iterative-incremental way requires quite some imagination. Starting small and growing it. That is reimagining Scrum. And this is one of the aspects that companies forget during their agile transformations, that it actually requires imagination. It’s not just the process, it’s not just the tech­nicalities. It’s using imagination and then be driven by imagining what Scrum can do to really go there, or at least move towards it. The people and the organizations that don’t have that way of imagining Scrum are going to have a very difficult time. Imagination is so much overlooked. That’s why I call it re.imagining Scrum.

So, re-assess what you are doing with Scrum, go to those core rules of Scrum, the basics of Scrum, see the value in the ideas. In order to limit your risk or limit your effort, start small, do it on one product, one service, one system, one application, but do it with sophistication. And then grow again. And go through the adoption again. This time for real [smile]. But it depends on how people, man­agers, executives, teams, can imagine Scrum to work within the organization. Because if they can’t, it’s going to be really difficult.

When you think of the organizations that you have visited and helped, can you give us an example of what was actually happening within the organization before you came in and what happened after? Whether some metrics improved, management or teams were more satisfied? What happened after the transformation?

With re.vers.ify, although it’s against my principles, I try to look into the future a bit and look at the emergence of new structures. However, the core purpose of re.vers.ify is not to predict or prescribe how an organiza­tion should look like at some point in time. That happens enough already. I don’t claim to be able to give an end result of what is happening or what might happen. I show people a road, a path forward. And what I would hope we end up is building sort of an ecosystem around products, around services, and that this ecosystem would not just be IT and development but include traditional product management work, sales, marketing. But… all focused on the product. Along that path organizations grow internally flexible structures. Such product ecosystems might expand, shrink again, be replaced and so on, without those rigid silos hindering such adaptations. That is what drives me in help­ing people during that third Scrum wave, of which we are at the beginning. I help com­panies to stay away from overly complicated solutions and frameworks, falsely predicting an end result and not a path. I help compa­nies focus on a road forwards, not the belief that they can know what their organization will look like at some point in the future. I help companies start small. I advise them to go for one project, one service, one prod­uct, do Scrum and learn, expand, grow. And that’s the most difficult step for most of the organizations.

In the end, companies adopt Scrum be­cause they want to increase their agili­ty. In order to know that agility is actually increasing, it needs to be measured. As for measuring progress, I have co-created ideas like Agility Path and Evidence Based Man­agement in the past. I promote those ideas as Empirical Management, or Exploratory Management today. I bring in ideas on what good metrics might be and what areas of agility might be so that organizations can actually measure them. And that connects to the idea of empiricism again. Measure those metrics as a way to inspect and then facilitate, support the change, the adoption of Scrum and all that it implies, support the transformation as the way to adapt, instead of trying to pressure people top-down.

What would you say is the most critical el­ement of such successful process? Would it be a sponsor, company’s culture?

Let me explain it as follows. I only work with organizations on the basis of three con­ditions that need to be fulfilled. The first thing, it has to be some sort of personal thing, the ability to work with people that know, have heard about me, that I’ve met, not to make it about distant hiring processes, etc. Next thing, it has to be about Scrum. Because I come in to explain Scrum and help people, teams and organizations get the most out of employing Scrum, with the most sophis­tication possible. And the third thing, and hopefully that answers your question, I have to feel they are serious about it. There has to be some sort of seriousness. That is often reflected in the need or urgency expressed. Can the people that want to work with me express why they want to do Scrum. What’s the organization’s need, what’s the market’s need? Whether it is to get more control, more transparency, reconnecting with the users, with their own workforce – there has to be some sort of urgency. And that urgen­cy for me is partly reflected in management buy-in. In a very traditional way we used to say that Scrum often starts in a bottom-up way, with a lot of excitement from the teams, and then you need to have the top-down movement connected to that. I try to stay away from that language, because a serious adoption of Scrum really happens in all directions, top-down, bottom-up, left-right, inside-out, outside-in. And that’s also the idea of re.vers.ify. But it’s never going to happen if there’s no leadership/management buy-in, feeling the urgency. And that’s what I call – they have to be serious. They have to feel the need. Otherwise it’s probably not going to last.

I agree, the engagement and understanding the WHY are crucial. Thank you for the talk Gunther!

1. https://guntherverheyen.com/2017/01/12/scrum-a-forward-looking-observation-2017/

2. http://agilemanifesto.org

3. http://www.scrumguides.org/scrum-guide.html