Dealing with dependencies

Dealing with Dependencies

[00:00:00.570] - Pawel Felinski

You welcome to Agile Encounters. My name is Pawel Felinski and today I'd like to cover the topic of dealing with dependencies. Last time, my guest Pete and I were exploring the topic of a broad topic of dealing with overload in your team, in your organisation and one tiny threat of that conversation were dependencies. What kind of dependencies you have, how you can manage them there were a lot of questions, a lot of comments that we received from you and I thought it would be helpful if we dig a little bit deeper into the topic. Now, important note my purpose for that session is not to tell you in detail how to manage dependencies.

‍

[00:00:47.650] - Pawel Felinski

I will not tell you everything that exists. Instead of that, these are Agile encounters. It's been always like that. I'm going to share just a few Practises or approaches that work for me and my customers in my Practise something that I can say definitely do way of looking at the topic. The general flow of the presentation is I'm starting with basic definition of the dependencies what are the dependencies?

‍

[00:01:17.440] - Pawel Felinski

How can we look at them? Then a broad topic of mapping dependencies and finally how to deal with how to deal with them at the very end of the webinar I have a tiny surprise for you so stay tuned please I will start with dependencies so typically if you attend a class, if you ask somebody what kind of dependencies do you manage? You will hear something oh, we have a lot of technical ones, right? Technical dependency means I cannot deliver. My team cannot deliver something because earlier somebody else have developed something else.

‍

[00:01:55.270] - Pawel Felinski

There's a simple technical dependency. You hear about functional dependencies. So technically it's feasible, for instance, if you are building Ecommerce online shop technically it's feasible to first build the payment and then the shopping cart. But it doesn't make sense, right? I would rather release an ecommerce with shopping cart without any payment.

‍

[00:02:20.760] - Pawel Felinski

You can always do it manually. If this is an MVP if you're a startup and you really don't know if there are any customers for a business but I wouldn't do it differently. So functional dependencies, you would hear about business dependencies. Same part on the business level, you may hear about people or personal dependencies. So we would love to develop this feature that set of functionalities in November but Key database architect is off till Christmas and because of that we will not do it many other because I think we could speak about a few more categories.

‍

[00:02:57.110] - Pawel Felinski

And I decided not to go deeper into this topic because these kind of dependencies types of dependencies are absolutely correct, but in my personal experience, absolutely not helpful. The fact that, you know, this is a personal technical dependency doesn't bring anything to the conversation. Right. What is the consequence of that? Perhaps some of it is a picture from internet some of you heard about big room planning one of the Practises in the so called skilled Agile framework.

‍

[00:03:29.750] - Pawel Felinski

The idea of mapping dependencies over here is pretty simple. In the swim lanes you have either products or feature sets, maybe teams, depending on what your structures are. Each cart is a feature story functionality. Each column is a sprint or some time period. It could be a sprint.

‍

[00:03:50.980] - Pawel Felinski

If you are using Scrum, it could be a release, it could be month, whatever. And with this red string you're mapping dependencies. As you can see, feature of team One in the first period of time depends on something that has to be delivered by team Two or actually is dependent on something that team Three wheel will deliver in three months from now. So this is a very nice map. And I'm not saying this Practise is strong.

‍

[00:04:23.910] - Pawel Felinski

I did use it several times with my customers. It's time consuming, especially if you do it for the first time. It allows you to map a lot. You can use different colour of the string to map different kinds, different types of dependencies. And it triggers conversation because this is the majority of that Practise is conversation.

‍

[00:04:43.550] - Pawel Felinski

So I saw it in several places special big corporations, they're using it. I didn't see any progress of this organisation in terms of dealing with dependencies. Okay, they were visualised. And today for the next period, let's say sprint or a release, we have a conversation of people involved in this big group planning what we can do about dependencies. Next time we will have same spaghetti on the board.

‍

[00:05:11.570] - Pawel Felinski

Next time and next time next time. Same kind of picture, same kind of conversation. Is there a better way? Is there a better way? That was always a question I asked myself.

‍

[00:05:22.550] - Pawel Felinski

Well, perhaps let's take a look at it. My proposal is to offer you a slightly different perspective whenever we talk about dependencies. Whenever I think about dependencies I don't think about feature deliverable something that I have to deliver or somebody has to deliver to me. I'm thinking about parties involved. Definitely my team or my organisation.

‍

[00:05:47.170] - Pawel Felinski

I put it here in the centre and I have customers and customers asking me to do something called a calling party, calling team, customer, whoever the customer is internal, external asks me to do something so they depend on my delivery. It could be a different situation. My team depends on any other team. So I'm actually asking a team to deliver something to me because I needed to deliver value, deliver my part, my output to my customer. This picture of course very simple.

‍

[00:06:21.530] - Pawel Felinski

In reality it's slightly more complicated. I have multiple customers and perhaps I am dependent on multiple teams. And I wrote customer and I wrote team over here. But it doesn't necessarily have to be external customer or other team. In my company.

‍

[00:06:39.140] - Pawel Felinski

Typical situation would be I have two clients but external ones, but also people from business, from my company and maybe a team, a peer team that is developing something else sometimes they also ask me to deliver something to them. My team can depend on other teams, peer teams, completely different department. Still my organisation or a vendor external company with different agreement SLA and that also creates some troubles to me. So this is the picture I typically see even in small organisations. Step one, in my opinion, is to identify your customers.

‍

[00:07:20.910] - Pawel Felinski

Why customers? You say? Let me come back to that picture. Dealing with dependencies have two sides. On the left hand side, what we can see is, technically speaking, demand.

‍

[00:07:31.960] - Pawel Felinski

Demand for your services. If you are a Kanban person, perhaps the service lens is something that is typical to you. But even if not, if you're solving a problem, if you ask for your team delivers product, we can put service lens at it with no big problem. You provide value to your customers. So on the left hand side, you have demand.

‍

[00:07:54.630] - Pawel Felinski

These are customers clients our teams asking you to do something, coming with requests, feature requests, whatever kind of requests and my Practise, the left hand side part of this chart is easier to control. Although technically very often these are external people to your team, it's easier to have a conversation with them if my work depends, I'm talking about the right hand side right now on a vendor or other team, well, I can put pressure. I can ask, hey, could you please speed up? I'm waiting for it. But even if it takes a lot of time to build this kind of capability, maybe I don't need that vendor.

‍

[00:08:35.260] - Pawel Felinski

It will be easier for me to have these vendor competences in my team. I can invest in building competence. I can hire more people, I can send my people to training but it's nothing that will make a change in a moment. It takes months with clients on the left hand side, I can have the conversation faster. So first part of my talk today would be about the left hand side part how to deal with demand.

‍

[00:09:05.910] - Pawel Felinski

As I said, I would start with identifying your customers. It's way easier to map your dependencies to map demand as well. If you start with customers, not with kinds of requests that they have to and then on the map the dependencies. Let me show you how to do that. So over here there's an example of a map.

‍

[00:09:33.580] - Pawel Felinski

Let's say I have three, four customers identified the business. So an organisation of my company, a support team in my company legal department, also in my company and perhaps completely different teamwork on different application. So my team is not facing facing direct end customer. And that's okay. When I have customers identified, it's very easy to create such a map.

‍

[00:09:56.870] - Pawel Felinski

Looks like a mind map. Also visualising what kind of requests arrive from them. So from business they come with feature requests for example. But also defect reports, customer reported. Or they find out there's a defect and I need to fix it.

‍

[00:10:12.960] - Pawel Felinski

Support Team completely different unit in my company also comes with defect reports. Maybe legal department comes with change requests. Something changed legally in our country, we need to implement it our system. A different team may have a question. They may need to consult my team, especially if we are sharing same platform, software platform.

‍

[00:10:33.900] - Pawel Felinski

And we need to operate together. And very often in my Practise, I save this. So that's the end of the mapping. I think there's an opportunity absolutely missed in here because just the fact that you map visualise who comes with what kind of requests to you doesn't bring a lot of transparency. Maybe increases a transparency.

‍

[00:11:00.040] - Pawel Felinski

Maybe you will see. Oh, I didn't know that. Actually, legal department is one of customers. By customer, I mean anybody coming with a request to your team. Not external customer, obviously.

‍

[00:11:11.290] - Pawel Felinski

So I think very important, very valid step that should follow this kind of mapping is identification of the identification of demand. Let's take a look at it. For instance, I can write down that nature of feature requests from business is typically five per month. In case of defect reports, way less one or maybe twice a month. But these are high severity defects reported.

‍

[00:11:38.170] - Pawel Felinski

Support Team well, it's random nature of demand, however severity is low. That gives me an idea how to treat them. Change of customer. Got you. They are rare, but they're important.

‍

[00:11:49.000] - Pawel Felinski

And actually, the requests for consulting from my fellow team, these are massive. And by massive I may say, for instance, 40% of all requests coming to my team are actually not from business or support, but from different team. Different up team. And perhaps when I visualise this, that may trigger interesting conversation within my company. Fair enough.

‍

[00:12:18.350] - Pawel Felinski

This is a real map that few months ago was done by us for one of our customers. Department of ten, maybe twelve teams. Altogether less than 130 people. And that's a map created just for one team. One team.

‍

[00:12:38.280] - Pawel Felinski

Technically single discipline teams. They have two, three, maybe four external customers. But as you can see, there are many, many more visualised massive. Indeed, massive demand were actually caused by other teams within the same department or other parts of the organisation. Visualising dependencies or visualising your demand in such a way that immediately triggered a lot of conversation.

‍

[00:13:09.520] - Pawel Felinski

Whether we should support that team, shouldn't they do this kind of work on their own? Why they're asking us for support? They should be competent in doing it. Maybe there's a procedure to be changed. Where are the priorities when you have such a map?

‍

[00:13:25.150] - Pawel Felinski

It's way easier to facilitate this conversation. So what to do whenever I map dependencies on this left hand side of my chart, I start with identifying customers. Then I'm mapping these dependencies. But I'm analysing the demand and put it on demand. That's very important.

‍

[00:13:46.970] - Pawel Felinski

And I think it always worked. I don't do it on my own. As an external consultant, I always engage the managers of my customer in doing it. In that case it emerges on their own. I did several times did interview my customer and prepare a map on my own.

‍

[00:14:07.020] - Pawel Felinski

But my experience is the impact of the message. The message is always way more powerful if we do it, if we do it together.

‍

[00:14:18.850] - Pawel Felinski

Now, last time during the previous webinar I told you that you can actually call us. We have started a new initiative ask Meirik if you have a question, any kind of question, lean Agile Management consulting question, go to this website, Meirik.com and just ask the question and we'll answer. It would be most likely one, maybe two minutes long video, a few questions already arrived. We are preparing the material. If you have a question, for instance, about this and you want to know more, want to know how to start it, how to make this kind of mapping in your case, go for it and ask your question and we will tell you more.

‍

[00:15:06.690] - Pawel Felinski

So we have our demand visualised what to do next. Very important quote. I'm convinced this is mine, but perhaps somebody said it said so way earlier there is no single practise of delinquent dependencies that's very important. It's not that I can offer you one or two, maybe three very good techniques. If you use them, dependencies will disappear.

‍

[00:15:38.350] - Pawel Felinski

There's absolutely no way in dealing with that because the nature of dependencies is also tricky. There are a few hints I can offer and these are the ones that I think work typically very often for me. First of all, I do verify the scope of my team. If my team and I have it visualised, I have it mapped. If my team receives a lot of requests from different parties, I sit down with my team or my manager, or if I am a manager, I'm having this conversation and I say hey, do we really need to support legal department?

‍

[00:16:20.590] - Pawel Felinski

Really? Is that our job? Maybe they should go to business and business should deal with them and if they really need something from our team to be done, they should do it. How about this different app team? Shouldn't they have their own competences in doing whatever we are doing?

‍

[00:16:38.530] - Pawel Felinski

Or they should come to us? So this kind of conversation typically, especially if you look at the real case, the spaghetti that I showed you a moment ago, this conversation immediately intrigues management. And they say no, no, you shouldn't do that or you can do that, but not 50% of your capacity, maybe 5% only. That's very, very useful and typically solves the majority of problems on the demand side, demand side of our mapping. Secondly, obviously you need to agree with your stakeholders on prioritisation.

‍

[00:17:12.910] - Pawel Felinski

And I mean it. If you are the manager of the team. If you're a product owner, if you're using scrum, I would discourage you to prioritise only. I will encourage you do it together with stakeholders, guys, this is what we visualise, this is how I see the priorities, what you think about it? If you disagree with my priorities, maybe you would like to sponsor a bit of increase of competencies of my team of simplest data.

‍

[00:17:42.710] - Pawel Felinski

And finally having such a map allows us to allocate capacity. If I see there's one customer or one type of demand, for instance defects or exchange requests that need some investment, maybe I will allocate out of my team, two people just to do it. If you're using the Kanban method, perhaps a separate swim lane on your Kanban board to address these kinds of requests for these kinds of customers, it makes the interflow of work smoother. And I think that's it. And I think that's it if we talk about the video, but what about the other part?

‍

[00:18:25.360] - Pawel Felinski

Very often what I offer to my customer depends on other teams, other parties. And as I said at the very beginning, putting any pressure over here at them perhaps doesn't make sense, right? If this is an over team, different department, vendor, well, we can't do a lot. If it's a vendor, different department, maybe other team, we can have the conversation. And my approach as a consultant during digital transformations is pretty specific because this kind of exercise with demand mapping that we have just covered, I'm repeating it with all teams.

‍

[00:19:06.170] - Pawel Felinski

So I care about my demand, the other team cares about their demand, including demand from my team. And everybody does it. We have a network of interconnected teams, interconnected services, each of the services looking after their own demand. It's way easier, way faster. But if we don't, if we don't have such a situation, you are focusing on your team only or your organisation, and you simply want to do something with the parties that you depend on.

‍

[00:19:35.850] - Pawel Felinski

What can you do? Well, as I said, there's no single Practise of dealing with dependencies. However, for dependencies that you depend on, for teams that have to deliver something to you, there's a very big, I would say systematic view of dependency management. This is part of Camden maturity model and developed by Campbell University and David J. Anderson School of Management.

‍

[00:20:06.790] - Pawel Felinski

A big poster, but intentionally, I'm not zooming in. There's a lot of knowledge over here, a lot of Practises that you can implement, perhaps not all of them. If you want to manage dependencies, that works way better if all your services are using the Candle method because I think the model is optimised towards this kind of delivery. And as you can see or not on the left hand side, multiple different Practises offered on different levels. And it's fabulous and I love it.

‍

[00:20:45.970] - Pawel Felinski

And I encourage you to download from Kanban University website. However, if you ask me how often I use this in my Practise with my customer. I would say not often because it requires a lot of attention, attention to detail. It requires bigger transformation. I mean, all teams are using Kanban.

‍

[00:21:08.440] - Pawel Felinski

They're more or less in the same maturity level and we can do it together. So instead of going deeper into that model, I wanted to show you a few hints, a few things that worked for me in the past. A way simpler way that I would craft is three step way. First, what is important is to identify dependencies.

‍

[00:21:35.070] - Pawel Felinski

You are not starting with your customers over here, you are the customer, but identifying the dependencies. I mean, when you receive a request from your customer. So the demand part, it would be great if you have a step in your process where you actually identify early, identify dependency, external dependency. So if you are using this Scrum framework, for instance, way before your sprint starts with this particular feature during product backlog refinement, your team should be aware of the fact that, hey, in order to do that, we will need a help of a different team so we can reach out to them way earlier. And this is the one way.

‍

[00:22:22.220] - Pawel Felinski

If you're using the Kanban method, perhaps you would be interested in the upstream kanban where you decide exactly what to do when you reject all the options that you don't want to deal with. And you have a time here to identify early oh, to deliver this, we will need help of them. This is what I mean by identifying. In the majority of cases, it should be feasible then, when you already work on your feature, on your task, on your request, it would be great if you visualise the dependencies. However, visualise also the impact.

‍

[00:23:00.250] - Pawel Felinski

In Practise, it's done like that. If you have a board task board inverse a task write down this task depends on a team. It could be a visualised indicator. Both digital tools can do, but you can do it physically on a wall as well. If your item is blocked, your task is blocked because you're waiting for delivery of an external team.

‍

[00:23:25.330] - Pawel Felinski

It's cool to write down to visualise this as blocked, but also visualise for how long it has been blocked. It has been blocked so far. That's the difference. If my task was blocked for a day or for 20 days, if you visualise it, you can see the flow of your work on your board. It hurts when you look at the site that gives you data.

‍

[00:23:48.330] - Pawel Felinski

And working with data would be the third step over here. Manage the dependencies. So, in other words, what does it mean to management? Make decisions, make decisions based on the impact. If I see, for instance, and I need to collect the data, this is the middle step, the truck step over here.

‍

[00:24:06.610] - Pawel Felinski

If I see that my tasks that are blocked because I'm waiting for somebody are typically blocked two, three days except for that one team. And for that one team I need to wait half a month for instance. This is a very nice opportunity for a conversation, what's wrong in the process? And I can have this conversation with the manager of that team, with my manager, with sponsor, with whoever. Maybe that team needs help.

‍

[00:24:32.180] - Pawel Felinski

Maybe my team needs help in growing capability and releasing the other team completely. Maybe we should do something about it. This kind of decisions could be kind of conversations could be involved. There's no one fit all solution over here. But I think that if we identify dependencies early, we already mitigate auto frisk.

‍

[00:24:56.470] - Pawel Felinski

If we track it together with tracking their impact, the severity impact on us, we have data that we can use in any kind of conversations. And that's the final step. Wallets there are three good Practises I'd like to share with you related to what I've just mentioned. The first one and it works pretty much pretty well every time. Focus on blockers approach a blocker typically if this is not a technical issue, it's caused by dependency.

‍

[00:25:32.260] - Pawel Felinski

I am waiting for somebody I'm waiting for somebody outside my team or even inside my team. If we focus on blockers, not deliver, we need more and more work. We need to be busy, busy, busy. But if we focus on blockers, on blocking blockers this kind of thinking, this kind of approach after a while makes our life way easier. Focus on blockers have two actually aspects.

‍

[00:25:56.910] - Pawel Felinski

One is well if you're using Scrum, you have daily Scrum meeting every day. How about adding focusing on blockers to everyday conversation? If you're using the Kanban method as the method of choice, actually adding this point, talking about blockers to each Kanban meeting helps team well, brings awareness to the blockers first of all, but also helps team swarm around unblocking these blockers, doing something about it. And that's not either or in my opinion. This is a parallel, parallel topic.

‍

[00:26:33.140] - Pawel Felinski

I also encourage managers to have a regular review with key players and these key players might be managers of other teams, maybe my sponsor, maybe product manager, my customer, depending on your situation. But if managers see the blockers and the managers can do something about it, can have conversation typically there's more appetite in the organisation to do something about it. Please mind that a blocker or an issue with dependencies in your team might be also a common thing, a common partner and other teams may have actually same troubles. So bringing this kind of conversation to the level of management, middle management typically helps invest in it. How to do that, how to talk to managers.

‍

[00:27:24.810] - Pawel Felinski

This is a completely different conversation and perhaps a conversation for a different webinar. Now I told you some time ago that we will have a special surprise for you at the end of the webinar and here it is. Because of time of the year in November at least here in the northern hemisphere it's quite dark. We thought we will give a gift. We'll present a gift to all of you watching us and to give our 30 minutes free consulting most likely with me versus link.

‍

[00:28:07.450] - Pawel Felinski

You can see it here on screen. If you type it, you would open a calendar. Please mind that we have limited number of free consulting opportunities. Only five during next couple of weeks. So first in, first out, the consulting is free.

‍

[00:28:28.630] - Pawel Felinski

We can talk about any topic related to management consulting, hopefully related to dealing with dependencies or dealing with overload in general. During such a meeting I'll be happy to listen to what your problem is and share my point of view or tell you what to do, what to read, which training to take, or maybe no training, maybe need a seed of inspiration. And that's it. Finally next Agile encounter. Agile Encounter number Ten.

‍

[00:29:01.560] - Pawel Felinski

It's in December and the topic will be a Christmas gift. We are looking into our social media. I am reading every comment that you're leading there. I'm trying to find something that everybody will be happy to look at. So December the 7th, same time, Azure encounter number ten for today.

‍

[00:29:28.130] - Pawel Felinski

This is all. Thank you very much and see you next time.

‍