# Don't sleep on Portfolio-level Agility: transcript Automatic transcript of the published podcast audio. Recognition errors are possible. Speakers are unlabeled; do not attribute a passage to Yuval or a guest without checking the audio. Episode: https://yuvalyeret.com/scaling-ai-podcast/dont-sleep-on-portfolio-level-agility/ Source RSS GUID: substack:post:169670823 Source: published Riverside RSS audio enclosure Transcription: faster-whisper base.en, English ## Transcript [00:00:02] What's the right timing for using portfolio-level agility? [00:00:07] Either I move all welcome to a skilling with agility, where I talk about [00:00:15] nuanced ways to [00:00:17] bring agility to [00:00:19] your organization at scale. This is a [00:00:24] question that I often get asked. What's the right timing to [00:00:30] introduce portfolio to [00:00:32] your ways of working portfolio perspective? [00:00:34] And the answer is kind of similar to the when to plan wins the best time to plan to treat. [00:00:43] The best time to start talking about portfolio in my view [00:00:48] was, you know, when you started your agile journey, if you already had, then the best timing, no. [00:00:57] Most organizations wait way too long to adopt portfolio-level practices. [00:01:04] They've been told you can't scale what's broken, so they wait until they nail away the team and product group level. [00:01:12] But what I've often seen in my work with organizations is that fixing what's broken requires [00:01:20] focusing on the upstream, that's shaping the work and the context for these teams. Whether you call that portfolio or [00:01:28] just a higher altitude or flight level, I don't really care about that. But [00:01:35] looking upstream and intervening at that level is a [00:01:40] pretty powerful pattern that I've seen work [00:01:44] pretty often. [00:01:45] Let me give you an example. [00:01:47] Back in 2012 or so, I met a senior VP [00:01:52] responsible for a thousand-person delivery organization. It was working in a traditional waterfall. [00:01:57] It was a critical chain optimized waterfall theory of constraints, case study for how to optimize all of the [00:02:06] projects. Over the years, by the way, I met several organizations that all claimed to be [00:02:12] world-class at managing projects and still [00:02:17] something was missing. [00:02:20] And in this case, what they were facing was a lot of component teams. [00:02:26] So a lot of heavy coordination and integration costs across products [00:02:32] and build the takes two weeks to integrate. And whenever they get to the end of a release, a lot of [00:02:39] risk timing scheduling risk around will that really work how long would it take us to stabilize this. [00:02:47] Because of those risks, they were working very hard to try and control change. [00:02:55] They recognized that in order to successfully release, they need to control change. [00:03:00] They cannot really access future requests from their customers during this. [00:03:05] And this was a successful and profitable shop, but Tricky, who was the leader for that team, [00:03:14] was looking for ways to make it better. [00:03:17] She didn't really like [00:03:20] the fact that she was saying no, that the team was saying no to customers. [00:03:24] We cannot do your things right now. [00:03:26] We'll do it in the next cycle. [00:03:31] What they realized was that in order to [00:03:34] welcome change for their customers, they often had to accept change out of cycle. [00:03:39] They started to do that because they were focused on profitably and this created the constant fire. [00:03:46] So that was the beginning of the conversation and we started to discuss options. [00:03:51] The option that the team, like the most, was starting with visualizing, understanding and managing flow [00:04:00] across this delivery organization. [00:04:02] You might call it the portfolio of deliveries. [00:04:05] This organization was driving again. [00:04:07] It was a thousand people strong delivery organization with a lot of component teams. [00:04:13] Several development groups focused on different aspects of the solution. [00:04:19] This visualization board, we got it going within weeks. [00:04:23] This team was very experienced, highly motivated, operationally focused. [00:04:28] So it didn't take long to start to see work flowing or not flowing. [00:04:34] And once the team started to see what's going on on this conman board, [00:04:40] they started making changes. [00:04:43] They started thinking about how could we integrate more often? [00:04:48] How could we have conversations about pulling work in more often? [00:04:54] They started to see the effect of the waterfall and they started to break through it at their level. [00:05:03] We've seen how much cross product work this portfolio delivered. [00:05:09] Then we started to explain ways to reorganize around value. [00:05:13] We started introducing more and more agility principles and practices. [00:05:19] Like continuous integration, like breaking the work to smaller pieces [00:05:24] and feeding it into the cycle rather than waiting for, we were just batch sizes. [00:05:30] Eventually they did reorganize to stream-aligned cross product groups, [00:05:34] focused on the real product from the eyes of the customers and leveraged team level edge [00:05:39] of working, but that took time. [00:05:42] The thing that I've noticed in this case and in other situations where we've used that approach [00:05:49] is that starting at this altitude, what you might call the portfolio level, [00:05:54] gives you as a leader tons of leverage to make an impact on the agility [00:06:00] and product orientation of your organization. [00:06:04] By tackling the systemic constraints to product thinking, flow, empiricism, [00:06:09] and allowing you as a leader to learn and model the behaviors you expect from your team. [00:06:15] If you're interested to learn a bit more about how to go through this cycle [00:06:21] to use this portfolio agility intervention, [00:06:25] I wrote this portfolio agility trail map, which is a free email course [00:06:30] based on the lightweight common first approach I described above, [00:06:34] combined with modern concepts such as the product operating model evidence based name. [00:06:40] This is kind of the playbook that I use with enterprise level organizations [00:06:46] that I'm helping today and in some cases also for smaller businesses [00:06:51] where we use this approach for bringing agility to the whole organization. [00:06:57] Delivery projects or features or product initiatives, [00:07:02] it's actually all of our company bets, bets that could be related to our products, [00:07:08] they could be related to internal capabilities. [00:07:11] And before we go and implement edgel in the trenches, [00:07:17] let's start with organizing and thinking about the flow and the outcome orientation [00:07:25] and steering with evidence for our biggest initiatives. [00:07:30] What I like about this is a management consultant is that this provides the surface area [00:07:36] to have exactly the sort of conversations that are moving the needle for how leaders think [00:07:42] about their operating system. [00:07:45] And once we have these conversations, once you start to see the VP starting to ask their people [00:07:51] about stop starting, start finishing or the COO asking people to describe outcomes [00:07:59] when they talk about the initiatives rather than what's the actual work. [00:08:03] When that starts happening, it's like a tree tag for the organization. [00:08:09] When these leaders become the heroes of the agility journey in the organization, [00:08:17] everything else becomes much easier. [00:08:21] A lot of the time the constraint for organizations is the system around the teams. [00:08:27] So instead of waiting to work on the system around the teams until the teams are working great, [00:08:34] why not tackle this system? [00:08:37] Thank you for listening to this episode of Scaling With Agility.