Jonas Elmqvist and Daniel Franzen

Jonas Elmqvist: Thank you so much for being here. This is our second time here at DevOps Enterprise Summit, and we are super happy to be here again. We had a great time last year, and this is going to be an awesome year again.

Last year, we presented a journey that started three years ago. It did not start in a cafe like the Adidas guys. It started over lunch, a couple of guys talking about how we wanted to change the way we developed software and how we did business development.

That presentation is there if you want to see the journey from three years ago. Today, we are going to talk about the methods that we used and how we composed this into a framework that we have used to start new teams, which is a Phoenix framework.

Daniel Franzen: Yeah, and we call this Phoenix as a little tribute to "The Phoenix Project" book, which has been a lot of inspiration for us. But to be honest, it is not a real framework. It is just a couple of what we think are good methods that help us during the BizDevOps journey. And there is no certification. There is nothing to buy. So we just wanted to see if there is something here that can help you in your journey, and then we are very happy.

Jonas Elmqvist: My name is Jonas Elmqvist. I work for the Swedish Migration Agency. We help people come to Sweden if they want to work, seek refuge, or study, for example. I am head of one of our software development units, and I have a background in safety-critical systems and IT security. Now I am really passionate about DevOps, leadership, and the human side of technology.

Daniel Franzen: And I am Daniel. I am an enterprise architect and digital strategist, and I have worked with Jonas for the last six years. I am really passionate about seeing the final words in the digital strategy being real-world execution.

There is a transformation going on. The world has changed. We, as humans, have changed. You might have seen last week there was news about young people growing horns on their skull. Did you see that? The Washington Post. These are the things that digital transformation does. It is due to phone usage, they think. It is crazy, but it is true.

My dad, when he gets an important email, prints it out and puts it in a ring binder. But my son, when he receives an important paper, takes a photo of it and stores it in his mobile phone. There is a digital transformation going on.

Software is eating the world, and many of the services that have provided value to customers for years are now eaten by software. I am getting used to turning on the lights in my living room by speaking to my watch, and I am getting used to being able to book my journeys by using my phone and having the hotels, the flights, and the car rentals in one and the same booking.

At the same time, even if software is eating the world, what remains is the world. As Paul Ford wrote in Wired, "Yeah, software is eating the world. Then the world remains." Software is like electricity. It is the thing that remains when software is eating the world.

When everything gets software, everything gets connected with everything. But this is not done by itself. Thousands of startups are disrupting and innovating larger businesses by innovation. If you are a larger business or a government organization, maybe it is hard to invest in innovation because you are out of competition, and then you can be fat and happy.

This is an example from Germany, where they use a lot of faxes. But this is not about Germany. I am sure you have similar stories to tell where you are non-digital. Their customers also turn on the lights in their homes with their watch. They expect the same kind of service as with other services. In government organizations and in large companies, we expect the same kind of service as we expect from others. If there is an app in other kinds of services, you expect an app from the government, too.

All this adds up because not only are possibilities and expectations increasing, the speed is increasing. This is the time it took for different services to reach 50 million users. For cars, it was 62 years, and for mobile phones it was 12 years. For Twitter, it was two years. And for Pokemon Go, 13 days. Sorry, 19 days. So not only are expectations higher and higher, and there are more and more innovations, they are also faster and faster.

With this comes complexity. As Jennifer said earlier, you cannot analyze this kind of situation, because if you are trying waterfall and upfront analysis, chances are that you are trying to predict things that are non-predictable. It is difficult to predict the future, of course.

Another thing that is very hard is that in traditional project management, you are trying to do most of the upfront analysis in the beginning of the project, and that is when you know the least about your business. You are trying to do things where you do not know things. All the time you spend trying to figure out things makes you further and further from how it is.

Another thing we normally do in projects is try to mitigate risks. This is because we do not like uncertainty. But uncertainty has two sides. Uncertainty is both opportunity and risk. When you early on try to mitigate uncertainty and risk, you also mitigate opportunities. This is the other part of why this is so hard.

Lastly, most organizations are organized like silos because you want to have the people who know a certain kind of knowledge in the same silo. This makes it hard to execute on the strategy. Even if the strategy is fine and says all the right things, the way you are organized makes it impossible to do digital transformation. More on this later.

Jonas Elmqvist: As Daniel said, we live in a fast-paced world where we find uncertainty everywhere and complexity everywhere. The software that we are building in our enterprises is a complex system. But we also need to look at the humans: the people using the software, and the people building the software and operating and interacting with the software. They are also a complex system.

This means that we need to manage our enterprises depending on this. The issue is that the traditional models we have in management, the methods we use, and the mindsets people have are based on old assumptions. They are based on 100 years of manufacturing and production and Taylorism.

That might work in that type of environment, but it does not work in software development. As we know, business development and software development is not a factory. It is knowledge work and creative problem-solving, where information is important, ideas are important, collaboration and communication are important.

When we look into our legacy organizations, we are not organized for that type of problem. We are often designed in hierarchies, functional silos where command and control is present. But we are facing a problem that is complex and fast-moving. This creates some issues when we try to become digital.

For example, it creates information hierarchies. Information does not flow from the top to the bottom or from the bottom to the top. The effect is that we might take decisions at the top based on the wrong information and make wrong or bad decisions. Or we might execute in the line organization based on wrong or incomplete information.

Also, if we organize in silos, we create filtering on the way. In a traditional development organization, you might have a group of people working with the business, with the customer, understanding the business problem. But then, in the end, you have an IT delivery team trying to build the right things without the correct purpose.

As we heard this morning, purpose and motivation are really important. Purpose is one of the four key factors to drive motivation. You need purpose, mastery, autonomy, and belonging in order to feel engaged at the workplace. We also heard figures from surveys around the world showing how it actually looks inside our organizations. Only 16% of the people working are fully engaged. So we have a lot of improvement here that we can do.

This means we need to change the way we look at people and humans inside our organization. If we look at Frederick Taylor, for example, he had a pretty pessimistic view of people. He thought they were lazy, they needed to be controlled, and he wanted to divide the people who were doing the thinking from the people who were doing the execution or the doing.

This cannot be done in our new world. We need to have a growth mindset where we believe in the potential of every employee inside our organization, that everyone can have a seat at the table and bring up new ideas. We need to focus on the human side of technology as well. We cannot forget that. We need to build trust and transparency and focus on learning.

In a knowledge-intensive environment where information is valuable, we need to maximize the good ideas. Every time a person does not speak up inside our organization, we must see that as a missed opportunity for improvement, innovation, or learning.

So how do we create this type of environment? There are a lot of resources you can read. You have probably heard about the Google research, Project Aristotle, where they looked at all the teams that they had and saw that the fundamental principle to create high-achieving teams is a safety culture. There is a great book by Amy Edmondson that was released this year, "The Fearless Organization," that is really inspiring and gives both good and bad examples when this actually works.

Going back to motivation, there is actually one thing these studies show that doubles the chances of people being engaged, and that is putting them in teams. All the surveys show that if you are not in a team, if you are working individually or in a silo, you are not going to be as engaged as when you work inside a team. So we must look into our organizations and see how we can create this environment. How can we create teams that work together for a shared purpose and a common goal?

Daniel Franzen: We know that the world has changed, and we now think we have to have a new way of working. We think that we should be risk mitigating by experimenting. We need entrepreneurship and innovation to be part of the daily work, and we have to organize for flow, not function silos.

Jonas Elmqvist: We believe that teamwork is the future of work, where we can bring business and IT together in the same team, in the same value stream. In our world where knowledge is important, we need to create a fearless culture where we can increase motivation and engagement and maximize the good ideas.

As we started out by saying, this is a journey that started three years ago. We did a small pilot. Now we have extended that to a larger context. We have a bigger team that works within Swedish citizenship, trying to improve that process.

We do not believe in the exact tools and methods we use or a strict structure or framework. We believe that the mindset, the principles, the way of thinking, and the culture are more important than the specific tools. But we try to combine the tools, methods, and processes that we believe in, and that other people have proven work, in the Phoenix framework.

Daniel Franzen: The base for this, the ground, is that we try to sustainably minimize the time from idea to business value. The bottom plate, the base, is Lean and flow. We think Lean provides a couple of nice mindsets and practices to optimize the flow in an organization, including both kaizen and kaikaku, the daily innovations and the disruptive innovations.

We also think that strategy and governance have to be part of the daily work. Sometimes you hear that agility and architecture are opposites, but we do not think so. We think that an empowered team is the only reasonable way that you can have strategy being executed in an organization.

Jonas Elmqvist: DevOps is a fundamental part of Phoenix. We believe in the continuous flow of value in the pipeline. We believe in fast feedback loops from customers or users and the business. We believe in continuous improvement inside the team.

We also, of course, include security. We all know how important security is in today's society. So we want to build these empowered teams that have competence within security as well and have the shared understanding of why this is important and how you build secure applications.

In terms of teams and leadership, we want to foster a "we" culture inside the team. We want to see the team as a small startup that solves the business problems: a cross-functional team with a growth mindset.

We also see different types of culture hacks that we can use in order to create a behavior or create space for a behavior we want to foster. For example, we have show-and-tells inside our organization where people can spread good ideas. We have hackathons in order to improve engagement or inject some innovation into the team.

Daniel Franzen: We also think that most innovations come from startups and small companies. We have to inject the startup culture and startup mindset into larger organizations. We base much of this on Eric Ries' work with "The Lean Startup" and "The Startup Way," which we think gives a lot of good practices for bringing entrepreneurship into government organizations and larger enterprises.

Jonas Elmqvist: How do we organize, or what type of organization do we have? We mainly focus on three things: the teams, the coaches, and the growth board.

The team is built on an end-to-end value stream where the team has full responsibility for everything inside it. This means the team can change anything. It can change the business process and it can build IT solutions. So we need to build a team that includes all the competencies they need to do this, which means developers, testers, architects, designers, security experts, legal experts, product owners, and business experts.

This means that our teams become quite large, maybe 15 or 16 people. Some of them might not work 100%, but they are maybe larger than the average IT delivery team. We do not see this as a big issue. We see this as a strength. They have a shared understanding of what the problems are and how they should solve the problems and bring value to the business.

The coaches are important, of course. There is a lot of theory behind Phoenix. Lean, Agile, and DevOps are based on foundations that we need to teach. We believe we need to teach the teams as well during this journey, so they can get the right mindset and choose the right tools when necessary. The coaches also coach in digitalization, becoming digital first, because this might be something new for the business. They need to learn this new way of thinking.

We also teach and coach in leadership because we believe that leadership is not something just one person in the team should have. Leadership is something everyone should step up and act on when necessary. So this is something we need to coach the team on as well.

In terms of the growth board, instead of a traditional steering committee that focuses on budget, functionality, and time, we want a growth board that focuses on growth and learning and funds the team in periods of time.

We have created a small movie, a trailer, of one of the teams we are talking about, the team that works with Swedish citizenship. So sit back and enjoy.

Daniel Franzen: That is how Phoenix looks when it is executed. These are the real heroes, right?

Jonas Elmqvist: Yeah.

Daniel Franzen: But how do you get started? As we said, first off, your organization has to be suited for this. If you are a silo organization, like most are, you have to do something first. The easiest thing is to break out one value stream first to try with, because you have to have an end-to-end value stream. You cannot do this kind of digitalization and value-stream optimization in one silo, because the other silos will only be disturbed.

As Joe said earlier today, there will be resistance. So expect and allocate some time for lobbying and for training, because there will be people who think that this kind of work is not so good.

Jonas Elmqvist: How do we start with the new team? We need to choose the first value domain or domain that we want the team to work within. As Daniel said, we choose a value stream.

In our case, we chose Swedish citizenship because this was a domain where we had a lot of improvements that needed to be done. We also had a lot of applications coming in because we had the big refugee crisis almost five years ago, and now people have stayed in Sweden for five years and are eligible to apply for citizenship. So the applications are in a big backlog.

When you have the value stream, you need to find the right competencies for this team. You also have to speak with the business and get them on board, on track with this new way of working. We have to set up the growth board with people from IT and business together.

Then we plan what we call the boot camp or startup event for the team because we want the team to have a good start. We gather the team for a two-day off-site event. For some of the people, it may be the first time they meet.

The purpose of this event is first to teach them a little bit about the theories, to get them to start to understand the theories behind Phoenix, Lean, Agile, DevOps, and value-stream mapping. We also want them to get to know each other because we want to build the team and the culture in the team.

Then we want them to start to understand the business and start to talk about the business problems. We use one key activity for this: value-stream mapping. We get the team starting to do the value-stream map on the first day of this event to get hands-on with the business problem.

Daniel Franzen: We have got a lot of inspiration from design thinking. Design thinking has two phases, more or less, the double diamond. The first phase is understanding the business, and the second phase is doing improvements of the business.

The first thing we do is execute this value stream, trying to visualize it so that you understand the business. It is an end-to-end value stream, and you know exactly what your business is going to do. This is to get everyone in the team on board with what is most important and what the business does.

It is also a great way to find constraints, because what we try to do is find the shortest time, and we will do improvement on the lead time. The only way you can do that is by addressing the constraints from theory of constraints.

When we know the business, we can go into the other part, which is finding solutions. We do this with the team, where they brainstorm and come up with ideas, and every idea is formulated as a hypothesis. This hypothesis is structured and measured so we can see what business impact it could have.

We are also changing the language from doing requirements to instead talking about trying things. So we are trying the hypothesis. If we try a hypothesis and it is a fail, it is okay because then we have found the easiest way to fail a hypothesis. We think of other projects that have found this after several years and several million dollars. If it works, of course, we celebrate.

Another important thing here is putting in strategy, because these teams are complete business development teams. They have the responsibility to change the business process, the organization, and the IT systems. They can do whatever they want to make this value stream really fast. One of those things is that we try to digitalize things. We try to move as much as possible from human processes to digital processes, where the machine owns the process.

Then we go into development. I will push one thing here: it is very important to teach the team that failure is okay. It is not only okay, it is crucial. If you do not fail now and then, then you have not used all the opportunities. In uncertainty lies a lot of opportunity, and if you always succeed, then you have not found every kind of opportunity. So it is not only okay, it is crucial to fail now and then.

Jonas Elmqvist: Now we have the team. We have them started up, looking at the value stream and building MVPs to test hypotheses. Now we want them to deliver, of course. We want to celebrate early successes. We also wanted them to try their deployment pipeline to see that it actually works.

Another crucial part is that we want them to deliver value to the business as soon as possible, so the business can see the positive effects of having this new team that works close with the business. It also starts the interaction with the business: they can come to demos and see what the team actually does.

We also need to prepare the business for this new type of working, because they may not be used to having value delivered in small iterations often. Maybe they are used to waiting a long time to get anything done. So this is an important step, to get the real feedback from real users as soon as possible.

As I said, we have some small culture hacks that we can use. In this case, we scheduled a hackathon because we wanted the team to disrupt the way of working and disrupt their architecture. We actually had them think about a completely new architecture to move ownership of the application process from the case handlers to the computer and the system. They did that in one day to try it out and have the feeling that they can innovate in their day-to-day work.

Daniel Franzen: This looks a lot like a waterfall process, does it not? That is true, because the first time we do this with a team, we do it sequentially. But after the first time, we are doing all the steps all the time. We see this in different horizons. We have short-term and long-term activities, and a hypothesis that can take hours and hypotheses that can take months. For example, when we have a procurement process that we have to do sometimes by law.

This is a natural consequence of the team being responsible for the complete value stream. They are doing everything from maintenance to business improvements all the time.

So this is basically the framework that we have: how we scale with one new team. We start with the planning and the boot camp, and we have the team starting to work in this continuum.

Jonas Elmqvist: This is our story. It started three years ago. We have learned a lot. We have tried it in a small pilot, as we said, and now we are trying it in a full-scale business environment where the Swedish Citizenship team is working with the business.

Hopefully, actually this summer, we will introduce the first fully automatic decision in this domain, or at least this year. We have things we need to develop before we can do that, but this will be the first automatic decision that has been made inside the agency, if that comes true.

We see the engagement in this team has gone up as well. When we talk to them, no one wants to go back to the old way of working, because now as an IT developer, you sit with the team and understand the business. You know the purpose of coming to work. You see the value that you deliver all day long. And the business starts to understand IT and how IT can help them improve their process and, in the end, minimize the time waiting for an application.

This event is great to share our knowledge. We are happy to share it with you. I hope some of you have learned something. If you have questions or just want to discuss with us, feel free to contact us on Slack, Twitter, or LinkedIn. We will also be at the Speakers' Corner this afternoon, so please drop by if you have any questions or just want to listen more to what we have to say.

Our challenge now is how we can scale this even more. We are talking about new value streams. We might scale with a new team this year, but we have not really gotten the decision yet. So if you have any ideas about how to scale this when you listen to this, come by and ask us this afternoon.

With that, we will just conclude with a big thanks for listening. Thank you.