Matthias Patzak - Portofolio Kanban, The Art of Being Loosely Coupled and Highly Aligned

[00:00:03] Hello everyone. I'm Matthias Patzak. I'm an enterprise strategist with AWS. No one really knows what an enterprise strategist is.
[00:00:10] We are former customers and we share with current customers our experience on lean, agile and cloud transformation. I was CTO of Auto Scout 24. I'm also an enterprise coach. some sometimes in my career I got this certification also a flight level certified trainer.
[00:00:32] for whatever it's worth. But actually, today I'm talking about portfolio loosely coupled and highly aligned.
[00:00:41] And I use the word portfolio as it's used in in, but actually I'm not sharing the official guideline. I'm sharing my experience as a CTO of a mid-sized German European marketplace, how we run the whole company with on the enterprise level.
[00:01:04] And we did so because we started to adopt agile in 2008. And what I see with many AWS customers, but with also people and companies in the community, that sometimes they're not clear why they are introducing certain techniques and certain methods. And this is why I wanted to start with why.
[00:01:27] And why to have portfolio, why to have lean, agile, DevOps, cloud in your organization. And from my perspective, I want to to quote the manifesto. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
[00:01:49] Or to make it easier, and what is also stated in the Agile manifesto, the primary measure of progress is working software. This was true 20 years ago. From my perspective, the primary measure of success for any product software development organization is happy customers. And if you want to introduce any methodology or technology in your organization and you want to convince your management or your leaders in your organization, no founder, no investor, no CEO wants ever to talk about any lean Agile tech password. They're not interested in Dynamo DB. They're not interested in serverless. They are not interested in. So what is their language?
[00:02:37] What is top of mind of any CXO? The first thing is outcome. It's not output how many feature you deliver. It's outcome, actually it's business value. The second thing is speed. How fast are you as a tech organization to deliver this outcomes to your customers? The third thing is quality. Actually, most of the time, quality is just interesting when it's missing. So, work carefully that the quality is not missing. They are also interested in attracting and retaining talent, so motivation is very important in your organization, and they are always important in growth. When I when I got my first CTO position, the CEO said to me, what I want from you, and I was it was a German startup, I want scalability. Scalability for my business, scalability for my organization.
[00:03:33] And so as a CTO, as a leader in any organization, and from my perspective, any person who wants to drive change is a leader. You need to combine people, process and technology to deliver business value. It's always interconnected. It's not just about the people and the culture, it's not just about the ways of working, it's not just about technology. And to deliver business value, the the tech community came up.
[00:04:00] I just wanted to say 20 year ago, but this is not true. I started to read books about the effect even if it as it was agile in the 90s with the books from Tom De Marco for example, people where or his other books. But the secret sauce of more than everything to deliver fast and reliable is autonomy. So we pushed autonomy as a secret sauce in our operational model to become faster.
[00:04:32] And actually, we talk about the autonomy of teams. And from my point of view, in my experience, and I would have loved to discuss this with you in person, the smallest cell in your organization are your teams. And at Amazon, we call them the two pizza teams. And the two pizza team is our indicator for size because we say no team should be larger that you can feed it with two American size pizzas. And I added my definitions, my characteristics to this smallest cell, to this team, to this charge. So what is important is you have dedicated team members.
[00:05:14] No team member is working on anything outside of the team. They're just dedicated to the team and this team has dedicated responsibility for a certain area of your value stream of your product.
[00:05:28] The second thing, the team members have all cross-functional skills that are necessary to deliver outcome from idea to impact. Not from our team committed to something in our backlog and then we shipped it to quality assurance. It's from idea to impact. From a size perspective, team topologies recommends 5 to 9 persons, from my experience 5 to 11 can also work. And I would rather have a larger team but having not all roles in the team that you really need to deliver from idea to impact. The people that you have in your team should be T-shaped. So they should have a very deep experience in a certain skill. But they also should be able to work on everything else that is necessary in your team and what is currently top priority on your backlog. Because and this is the point number eight, effectiveness, working on the right things is much more important than efficiency. And with T-shaped people you can put everything with the saying all hands on deck on the most important item on your backlog. The teams are self-organized and autonomous for sure in the boundaries of the competencies that they currently have and the boundaries of the wider organization. For example, your micro architecture and your technology stack.
[00:06:54] Such a team should also have a healthy ratio between internal and external developers. At Auto Scout, we had a split between 70 and 30. We said 70% of the staff should be internal, 30% should be external.
[00:07:09] You can have 100% internal teams, works quite well with some pros and cons. We also run some parts of the organization for a while with a 50/50 split because we were not able to hire as fast as we needed people. It's a bit more risky, but it's doable as well. You also need a healthy ratio between junior and senior people. Every organization I talk to have shortage of skills. And what are some organizations doing? They go to universities and hire juniors. But who should train the juniors? So having too many juniors in your team is not really healthy.
[00:07:46] The teams at Auto Scout and at modern organization also applied the most advanced version of with which is you build it, you run it. So the team, this cross-functional team builds and runs the products.
[00:08:01] What is also important that those team they measure certain criterias, their outcome, their speed, namely cycle time throughput, their quality, their motivation. They observe what is going on in the rest of the of the organization and they reflect on their behavior, their ways of working and the outcome. And then they optimize. And my preferred ways of working is for making things happen.
[00:08:28] So we have a two pizza team and this two pizza team is autonomous.
[00:08:33] But actually many cells make an organization.
[00:08:38] And so in this example we have the checkout team. It's an e-commerce organization, they have a a website and they have a mobile app for buying clothes or cars. But every every website or every e-commerce organization also have a back end, fulfillment organization or a retail organization, the organization that buys materials that sells materials, that handles the stock, that handles the returns. You also will have some teams about your corporate IT, handling your laptops, your office network, all the other systems that you have. The organization also have a small data organization and an organization for infrastructure. And for sure, we have a marketing department, we have a legal department, we have a finance department, and we have leadership. And leadership in my example has set a north star.
[00:09:32] The direction, a vision and a purpose for the organization, what is important.
[00:09:38] And now we have our autonomous checkout team. And the checkout team has to work on an epic. And we are an advanced product organization and it's just their epic. But actually in most of the organization, even the most agile ones, it's not as easy as this. Because the checkout team needs another web team.
[00:10:01] The web team needs to align and get features from the marketing team, and as marketing is just a bunch of 27 people, it's not really with a structure and 157 software service tools, it's more complicated to interact with them.
[00:10:16] The checkout team also needs two teams out of the retail and fulfillment organization. One team of the retail team also needs advice from legal because we are changing something in the terms of condition. And the other retail teams needs a data team. This data team needs another data team and because they have to change something in the infrastructure, they need an infrastructure team. So, just for this one epic, we have dependency to nine other teams.
[00:10:45] And the other teams, they have their epics as well. And as they are autonomous, each product owner of those teams runs and maintains their own product backlog, prioritized and probably aligned with the chief product owner or even even the CEO.
[00:11:11] And as an organization, you need to find the balance between local autonomy and local performance and overall organizational performance. With increasing autonomy, the performance of the teams increases, increases, increases and increases. And the performance of the organization does so as well. So with increasing autonomy of the teams and the performance of the teams, the performance of the organization is increasing as well. But there is a certain point, there's a sweet spot in any organization where with increasing autonomy, and we might then talk about anarchy, of the local teams, the performance of the organization is dropping. And as an organization, you need to find the sweet spot between the individual interest of the cells of the teams in your organization. And this is where and why we apply portfolio.
[00:12:09] But it's also about I just wanted to say every organization, but most organization have a high stake challenge that they need to tackle and they need to master to really have non-linear growth.
[00:12:29] Many some organizations just don't really have this high stick challenge, then it's just continuous operations, but if you really want to grow exceptionally, you need to overcome a high stake challenge. And you cannot overcome your strategic high stake challenge when you're not able to focus and align everyone in the right direction. And so to make big things happen in your organization, you need to somehow align, orchestrate and coordinate the work, actually not the worker, but you have to coordinate the worker.
[00:13:10] And this is an a very old diagram that I've taken out of talk about the Spotify model, but it explains what we want to achieve very well. And it's a two by two matrix, on one access we have autonomy and on the other we have alignment. And I've seen many organizations, especially traditional enterprises that move into agile, they pushed a lot into autonomy. But with autonomy without alignment, your teams are fast, but they are running in any direction.
[00:13:41] On the other side, traditional organizations very often have low autonomy in their operational model, but high alignment with a lot of rules and a lot of government. They run in the same direction, which is nice, but they are super slow. So actually they are they are coming nowhere. What we want to achieve is that everyone is running from a strategy execution perspective in the same direction.
[00:14:07] And so we have to provide autonomy at the same time, but we need to provide alignment. And low alignment and low autonomy is what no one wants.
[00:14:17] And if I would have to provide a visual for loosely coupled and highly aligned, this would it be. I would have loved to find a visualization at a photo with just with speedboats and not the tankers, but they are fast tankers. And they are aligned, but nevertheless every every one of this tanker is allowed to choose its own route and its own journey and hire its own talents. but nevertheless, they are they are aligned.
[00:14:48] So, how do you create this alignment in an organization?
[00:14:53] And software is peopleware. It's all about the people. And how how to bring people together in an organization? Campfire bring people together. You gather people in a common place and you you provide a place where those people can co-create, communicate and collaborate.
[00:15:12] What are campfires in in an agile organization?
[00:15:17] The best campfires I've seen are physical boards. And this is a draft I'm going to talk about later about the board that we used at Auto Scout for a longer period of time to really drive our organization.
[00:15:39] So, I was talking about and what Klaus Leopold did, and I'm sharing a link to his book later, is he applied from a from a theoretical and methodological point of view to the wider context of the organization. And he talks about three flight levels. And flight level number one is where most of us are applying lean, agile, Scrum, Kanban practices for for several years. It's the operational team level where delivery teams manage their day-to-day work. And in flight levels, actually it doesn't really matter if the teams do Scrum, Kanban or waterfall. And this is true at Amazon as well.
[00:16:19] So when I joined Amazon four years ago, I was really curious on what is the actual software development process of Amazon? And then I tried to find it. And there is not a single one.
[00:16:31] Whatever methodology you find out there, a team at Amazon is using it. Plus probably 57 or 157 other methodologies they invented themselves. So at flight level, it's totally okay to have every method that works for the team.
[00:16:49] Flight level two, it's about the coordination. This is where organizations coordinates the teams from idea to impact. It's just about managing their dependencies. We have dependencies. We have to reduce the dependencies as much as we can, but we cannot come down to zero dependencies. So we have to coordinate and align.
[00:17:10] Flight level three is the strategic portfolio. It's the few out of space on Earth where you see your strategic landscape with a map. This is where mapping can help. And this is where management teams make strategy happen.
[00:17:27] Coming up with a strategy is super easy, you just hire a McKinsey or you go to an offsite and then you come back with 150 PowerPoint slide. But executing the strategy in a large organization, this is really tough.
[00:17:42] So I provided this sample organization, and it's a quite easy organization, it's just 30 teams, probably 200 and 300 people. And the question is who may must participate in the campfire?
[00:17:59] And so not everyone can participate, so they have to send delegates. I would prefer to have cross-functional delegates. Very often when I ask organizations who would be the delegates, the first answer is the business people. Yeah, but what if you want to discuss technical issues? So you need to have cross-functional delegates. They need to have a generalist overview. They need to be experienced, so senior, subject matter expert or senior leaders in your organization. And you need to have a diverse perspective in the people that are attempting the campfire. Because you want to have healthy discussions and healthy conflicts to really execute fast on your strategy. and delegates. I would prefer to have cross-functional delegates. Very often when I ask organizations who would be the delegates, the first answer is the business people. Yeah, but what if we want to discuss technical issues? So, you need to have cross-functional delegates. They need to have a generalist overview. They need to be experienced, so senior subject matter expert or senior leaders in your organization, and you need to have a diverse perspective. in the people that are attempting the the campfire, because you want to have healthy discussions and healthy conflicts to really execute fast on your strategy.
[00:18:48] And as I said, the core of every strategy is to tackle high-stake challenge. And this is why it is important that you have the right people in this campfire and that these people are able to make decisions. So, the variant number one is you send a delegate from each team. In my organization or in the example organization, we would have 30 to 40 people showing up on a weekly check-up meeting or in a quarterly strategic meeting. 30 to 40 people out of a 200 to to 300 people organization is doable, but uh very inefficient.
[00:19:29] So, variant two would be you send delegates from each area or each domain. This would be then 30 people. And do we really need people from marketing, legal, finance, for sure we need the people from leadership, but from infrastructure and and the others, probably not. So, as you have in your domain-driven design, a core domain and you have secondary domains, it's totally valid that you also when you bring people to the campsite that you say, we have some core domains and these are people who really need to show up. with responsibilities and with decision authorities, while you have other people in this campfire who are just there for, yeah, for their information. At our scout, we wanted to have delegates out of each domain. And these were probably 20 people and we were a larger organization, but actually in this meeting 44 people showed up.
[00:20:26] In average, it was a large space, because it was the place where we made decisions, where we had discussions and then decided. So, many other organizations were there, for example, legal and finance because they said, yeah, this is where you're making decisions. If we want to know what you have decided on switching budget, swapping budget, this is the place where we would know. So, sending delegates is a good, good idea, but one delegate from each domain is not really cross-functional. So, another variant would be you send IT and product people. So, you always send a couple out of your core domains. This would be then 18 people. And not all of them really having an active part.
[00:21:12] Because just your core domains would decide, debate, and discuss, while the non-core domains would just listen. And this second variant might also result in flight level two sub-portfolio Kanban, because the delegates that you send, they need to have the information. So, you would end up with a Kanban board on the enterprise level, which I already showed and I will dive deeper in a few minutes. But for getting the real insights what's going on, the core domains, the web, the retail, the others, the data, the infrastructure, they manage their efforts with flight level two Kanban boards.
[00:21:55] When you introduce such a Kanban board and when you start discussing about, don't boil the ocean. Face uncertainty, it's, it's not clear. You bring people together onto the campfire to align and discuss. But observe, orient, decide and act and just in the right direction, but decide fast and you can change the direction that you made in, in this campfire. What is important is that you have a cadence. It's like time boxing or the the sprint in Scrum. But you have a certain cadence where you have a strategy review. Because we're talking about executing your strategy, so you need to review where are you in your strategy execution. At our scout, this was a one or even two-day meeting workshop every quarter. So, we we invested a lot of time in it, but for us it's very important to discuss, where do we put our efforts to execute on the strategy. And then we were acting just in the right direction. But during this quarterly cadence, we had done what we called an operations review. This is what in our, in a Scrum team or an Agile team would be a daily, we did it once a week, Tuesday morning for an hour, the delegates out of the domain came together and they had their operations review. And so we were executing on a company level on a weekly cadence with every decision maker in the room.
[00:23:27] What many organizations forget is what I mentioned several times that you need to observe and decide and act, they miss the reflection. So, before you start your next strategic review and act in the next right direction, you need to run a retrospectives. In this meetings, it's very important that it's not just knowledge sharing, it's not just discussing and we are, we, someone is deciding later.
[00:24:00] There you visualize, you decide, you act and the important thing is always in the context of the overall portfolio of your work. If you don't do this, what, what happens regularly? So, I can remember very well the time before we had this portfolio Kanban, we would have a management meeting on Monday and someone from the organization would come in, got 15 minutes or 30 minutes and they would propose a new project. And they prepared this proposal for six weeks, they had very sterling, very crisp and clear slides. And as a manager, when you got this this dog and pony show, you just have to say yes, this is a great idea, we're going to do it. What happens on Tuesday? The next person comes with an idea. Makes its dog and pony show. And as a manager, then, when it's a valid case, you again start new work. With Kanban and flight levels on the enterprise levels and just making decisions in this strategic review meeting, you're always deciding in the context of your overall portfolio. And all the other people who have a stake in the strategy execution, they are also there. So, the person who wants to pitch a project and wants to do a dog and pony show, it's not so easy to do a dog and pony show when everyone else is there. And you know if you if you would promise something that it's not really true, someone would raise their hand and would say, oh, I have a concern, I want to say something. And this is why just having this strategic meeting where you decide and where you share in the context of the portfolio is very important and it's reducing this fast decision-making, is reducing the cycle time on the strategic level. The question is, what is the work you manage there? Actually, it's up to you.
[00:25:59] You can decide what type of work items you're going to manage there. You want, definitely, want to manage your initiatives, the really important strategic things that need to happen to overcome the high-stake challenge. So, initiative and epics are usually work items that you there see on the Kanban board. Some organizations also manage or use these Kanban boards for large incidents, I prefer to have a dedicated incident board in a war room just for managing incidents. What I recommend, but it's up to you, is managing the development of your organization and large changes that needs the capacity of the leadership teams or what you know is going to slow down all the other initiatives, you could manage them as well in a dedicated line. What you should not manage is stories, parks, and tasks. If you start to manage this small items, this would be overkill.
[00:27:00] The beauty of flight levels and Kanban on the enterprise level is that what worked for your teams for over a decade will very likely work for the company too. And this is why what I liked and what was so easy for us even if we had some challenges with people of the leadership team who were not so involved in our way of working before. But what we have learned from a mechanic perspective, from a method perspective, but also from a psychological perspective and how to facilitate meetings, how to run meetings, how to convince people, it all worked very well also on the enterprise level. So, just take your Kanban guide, take your Kanban learnings, take your Kanban coaches and apply cautiously the learning that we made as a community for over a decade on the enterprise level.
[00:28:00] So, now I'm going to dive deeper in the enterprise Kanban board that I proposed. So, those were there just five columns that we used.
[00:28:12] I do regular reviews with other organizations and I had a review with a bank and they they brought me up in a room and it was a six-meter wall and they had probably 27, 27 columns from idea, business case, solution architecture, budgeting, a lot of columns and steps that were necessary in the organization. We had a very simple and downstream process, it started with its in ideation. So, someone really trying what is the idea about, then having evaluation trying to find a product market fit, then it moved into development. And then this is something that that we proposed in our organization and I've seen more and more companies adopting after development, the next column is not done.
[00:28:58] And this is what you see regularly, we are done, we shipped it into production, we shipped it to to a customer, and just imagine, we shipped it. Yeah, we pushed, we pushed a feature to a customer and we really don't care if the customer can use it. So, in in our organization and we learned it the hard way. in 2011, 2012, we were able to release 12 times a day on our Oracle database and on-premise data center. Um, and we came from a monthly release, but our KPIs did not change. So, we were shipping features, but we were not shipping value. And this is, this was also the time when the Lean Startup book came out, where we applied this build, measure, learn, um, thinking. And so, we said, no, no, after development, we have to measure and we have to adapt. So, we we had AB tested everything and then we adapted and optimized in production. And we were done when we said, okay, we've impact achieved. And we learned that probably just a third of the features that we carefully prototyped and ideated were really delivering business value. The other third did not change anything and the other third was harming other other KPIs.
[00:30:10] And then you can visualize in your process your current work items and even with this visualization, as you can do with a Scrum team or with a Kanban team. Just by passing this enterprise Kanban board, very often you can see issues in your, in your working flow.
[00:30:28] So, as an additional item what we have is we had each column was a strategic initiative. And these columns, each line was a strategic initiative. And these line were not ordered by alphabetical order or by date, they were ordered or even ranked by priority. So, the most important initiative from a strategic perspective was on the top and the lowest was at the end. And this had several effects, the most important was if someone was waiting on someone else. And this happens all the time, it was a pretty easy exercise. We went in front of the board and then we asked, okay, where's your initiative and the people were showing at line 14. And then I said, okay, and you are dependent on which team, which initiative and then they pointed on number three. And I said, okay, it's pretty easy. You're 14, they are three, so you wait.
[00:31:22] What you also can see in in the example that I've shown here.
[00:31:29] You see that the priorities here at the bottom, they are more advanced than the most important initiatives here. So, the most important company priority initiative is just in development by while number four is already in measure and adapt and the same is true with with the others. And this is some of the visual effects that why we observed while having this physical Kanban board, in my experience with most of the digital boards, they just hide this effect.
[00:32:04] What we also had on our boards was the domain strategy. I said every quarter we would reflect on what is the actual strategy of the domain and are we on on the right direction. So, we had a one-pager on what is the strategy on this board, because in some discussion it was very easy then to go to the domain strategy PowerPoint slide and said, but actually we wanted to achieve this and this, so please stop the discussion because we decided this is the strategy. And for sure, we had KPIs and OKRs reporting on the board as well.
[00:32:44] If you want to drive your organization in a common direction, it's important that you set a bold top-down goal that inspires and forces the organization to move faster than it would have organically. And if you ask leadership teams, they would say, for sure, we have such top-down goals and we we drive the organizations in the area of true competitive advantage. Actually, this is very often not true. And we learned this again the hard way, we did once a mapping exercise with all the items out of our strategic portfolio and we prioritized and it changed the way we prioritized by two criterias. The one criteria that many organizations prioritize with is business value, and we called it potential strategic value, potential, but one dimension is business value. And the other is not cost, many organizations decide on how much value is it and how how much does it cost. We said, no, no, the second dimension is probability of success. And then we started mapping our items in this two by two.
[00:33:57] And what you, what you would then will see is that you have some items that have a high probability of success, but low potential strategic value. This is where you need to apply a think big attitude. You need to try to find ways to increase the strategic value of this organization by a different pricing strategy, by a different rollout strategy, whatever it is. You will also find initiatives in your organization that have a high strategic value, but low probability of of success. You do not start to execute and implement these initiatives. What you need to do is you need to do ideation and experimentation to increase the probability of your customers adopting this initiative.
[00:34:41] If you have items with low probability and low value, yeah, you just kill it, you just kill it. And what we want to have, but these are very rare, are initiatives that have high probability and high strategic value. When we did the exercise in our organization, and this is what you see in in many organizations, is they have a lot of, a lot of initiatives with high probability, but low business value, because everyone is taking a safe bet and this is okay, just shipping features in time, in budget and quality. But this does not really help.
[00:35:16] What we actually want is we want the right mix, the right portfolio out of initiatives with high probability of success, maybe low business value, this is table stake features, these are just maintenance feature, but we also need to have some big bets in the organization. The high-stake challenge with which you can really make a competitive advantage.
[00:35:42] Many organizations claim that they are slow. And if you want to be as twice as fast, as twice as fast and this is possible. There are case studies out there, sometimes they are even older than 10 years, it's very easy to become twice as fast even on the strategic level. Everything you have to do, you just have to limit the work in progress. And the effect will be that you have the same throughput, but your cycle time can be reduced by by over 50%. And if we talk about strategic initiatives, we do not talk about weeks, we talks about months or years that it usually takes to implement and execute certain such a strategic initiative. But how do you limit work in progress on such a Kanban board on the enterprise level? And there are two ways.
[00:36:36] One is the very traditional way with having work in limit work in progress limit on every column, so six items should be in evaluation. We applied the second way, a constraint way, a whip limit on the resources, so certain resources, certain team would have certain capacity items, so magnets. And then we started when we did the quarterly, I wanted to say planning, actually it was not a planning, it was more thinking in scenarios, but we started with the most important item, and we we asked all the domains and the team what needs to happen to make this initiative happen.
[00:37:18] And then they put the magnets on the actual epics of their items and then we progress to number two, number three and number four. And sometimes even strategic initiative number two, we had an issue because some of the teams were not able to put any more capacity magnets on it. And what what happens in many organization, you you make a compromise, you take away some resources on Friday afternoon, please, could you work on this strategic initiative. We didn't, we then just didn't start strategic initiative number two, but we were adding and continuing with number three, four.
[00:37:55] What you do in such organization, you delegate as a leadership team a lot on the domain level and on the middle management. And then the question is, yeah, but what are the responsibilities of the leaders, of the top management? And there are four key responsibilities, the first one is that you attract and develop the talent. Second is, you define and drive and I would even say you enforce your culture.
[00:38:25] Third, you give direction. Create alignment. And the fourth and more most important thing is, you need to co-create a strategy with your domain teams and then drive its execution.
[00:38:39] When you introduce such a new methodology, be clear what you need, what your teams needs to learn, what they need to unlearn, but also what to keep. Very often change people do not really know what they should apply and this is going to slow you down and even harm your organization. And take care of your people. Learning new things and even if these things like Kanban just applied in a different way, might make some of them feel uncertain, unexperienced and vulnerable. So, listen to your people.
[00:39:14] And never forget, never forget, our highest priority is to satisfy the customer through early and continuous delivery of valuable software. If you want to dive deeper in this topic, I recommend three books, team topologies, sooner, safer, happier, and rethinking Agile from Klaus Leopold, who actually invented the flight levels. I would have laughed to have Q&A live session in this talk. We will have, we will have a Q&A session. Awesome. But if you want to discuss with me and get further insights, then feel free to reach out to me on LinkedIn, here is my handle, you can find me very well. Um, I'm also available for engagements in your organization when you are an AWS customer. So, thank you very much.
[00:40:07] Thank you, Matthias. I think we'll have some questions.
[00:40:11] Ah, we do Q&A right now. Okay, awesome.
[00:40:17] So, um, yeah, we have some questions. Um, first one is about road mapping, you said it was not really planning, but it's, you have kind of a forecast, and how long are you forecasting or planning some roadmaps in your system?
[00:40:40] It depends what you need, so we we always had a a plan or intention on a quarterly basis. So, what is what is the next quarter, but we also were thinking about when it's going in the terms of rollout, of marketing, what it really takes. So, we we were thinking in some kind of scenarios then not on the Kanban board but with on on other flip charts and brown papers to think through some scenarios what might happen and how would we react from a resource perspective, from a budget perspective, from a capacity perspective and if we need to act on on certain aspects, where would we need to compromise. And sometimes it could have been 18 months. Yeah, going into a new market, so we we operate in 18 European countries and if you wanted to go to Russia, other currency, other language, other other other fonts, totally different markets, it was a lot of effort and we were even thinking longer ahead.
[00:41:42] Good. What does not work at company level?
[00:41:47] Everything, everything can fail, everything fails all the time. Actually, what at the beginning what did not work, my my peers in the management team, they were not keen on doing post-its on a wall on a on a weekly basis. Um, and I did not come with the idea of hey, let's do flight level Kanban on the enterprise level, but they were constantly asking and challenging me about the capacity of the software development teams. And this is why or how I introduced Kanban on the enterprise level in a guerrilla mode, I visualized our current initiatives and I visualized the capacity, so the magnets of the teams, and then we met once a week and discussed capacity.
[00:42:33] And this is what we did for several weeks and then we tweaked the board and we optimized it and after two quarters I invited Klaus Leopold and then we did it the right way, but they they were hooked in by their question. Um, yeah, this was one of the the most important issue, how to how to start and how to convince.
[00:42:57] Thanks, Matthias. And nowadays, we can see that most software companies got some remote policies. So, my question is, how can the Kanban campfire at the company level works with this kind of policies, um, and if you get any tips on if it works online, do you have any tips on it?
[00:43:20] I'm not a big fan of of online having this campfires online. From my perspective, there are three types of work in an organization and these three types of work need three different environments. The first thing is focus work. And focus work very rarely work, um, in in your company facilities, so having focus work, having an individual contributor really in deep thinking about something, why not have this people do it at home.
[00:43:53] If this individual contributor believes it's done at home as best. If this individual contributor wants to do pair programming in the office, then why not? But the second type of work is collaborative creative work. And this is from my perspective, strategy execution, a Kanban board is very important, it's a creative work, where you need to see nuances in behavior, in the faces, in their communication. And this is worth asking people to come in an office once a week, once a quarter for a whole day to have this creative co-creation in a group. So, you need to find ways of working where they can have their own time, self-organize, but where also a group for fast decision making comes together. And the third type of work that I perceive is not actually work, but socializing. So, organizations need to have working space for focus work, for co-creation, but they also need to provide office space that looks like a Danish or a French coffee or a living room where people can just socialize.
[00:45:01] So, thank you, Matthias. Uh, we'll take some more questions. And we'll send them to you and, uh, we can have an exchange on that. So it would be really, uh, really good. And, uh, thank you for the talk and see you soon.
[00:45:16] Yes, thank you very much. It was a pleasure.

Transcript