Dependencies – Break Them, Not Manage Them at SKILup Days 2024

Hi, my name's David Thompson to my friends and colleagues known as Tomo. Welcome to this short session where the mantra I'm using today is, one, familiar to anyone coming from the Prince to agile world. Don't manage dependencies, break them as we go along.

If you have any questions or comments, please post them in the chat and I will do my best to answer them there. But before we start, it might be reasonable to ask what experience I've had with dependency management. Well, over the decades I've built and delivered a range of digital products and as, uh, almost a career long Prince two practitioner, I was around in the early days of Prince two Agile, leading the very first public scheduled course in the uk.

I've always been acutely aware of the challenge of change in large complex PRINCE two environments and how we could address them. We used to think that heavy and draconian dependency management was inevitable, but we discovered that new ways of working required new ways of thinking, as well as restructuring both ourselves and the solutions differently. This would allow for us to use new techniques rather than the tightly controlled top down approach that guides like Prince 2, 2 7, and specifically increasingly seeks to give an alternative to.

Firstly, we will look at the dependencies that exist logically between products or tasks within a schedule, and how we can address them, reducing those that we cannot remove to an absolute minimum. Uh, time is the fire in which we all burn. As Captain John Luke Picard of the Starship Enterprise once put it, having timely and effective access to resources is not just a case of key dependencies.

They may consume a considerable amount of a project manager's bandwidth. Indeed, in some organizations, securing and mobilizing resources is seen as the main job of a project manager. Scarcity or expense can drive specialist teams or restrict pots of subject matter expertise.

Now, the resulting silos cause delays and constricts the flow of value, but they also introduce dependencies between them. Print two recognizes not everything can be contained within the project environment. They may be other pre-existing external or business as usual, or indeed other projects.

Input on which we rely program management such as MSP may alleviate some of this responsibility for us. If we're part of one, however, we should be able to go it alone and manage them effectively for ourselves. And lastly, two, recognizes that we can exist in a range of environments, uh, some of which more tightly regulated than others.

Good governance and compliance are two of the benefits of project management, particularly in a respected and well-known methodology like Prince two. However, as we shall see, um, there may be more latitude than perhaps we at first anticipate. So whilst our mantra is, uh, don't manage dependencies, break them, we should recognize that this is an aim rather than a stipulation.

This brings us to the age old project manager's plea crying out into the wilderness. Let us see then if we can bolster that courage, uh, draw on that patience when we need, but hopefully also build a little wisdom as we go flow or network diagrams, therefore may be familiar to most of you, whether those dependencies will start to finish, finish to start, start to start or finish, to finish the project swept along, unerringly and predictably towards its date with destiny. Indeed, until the start of this century, uh, many early digital products, uh, software and websites progressed in a similar fashion.

I won't ask, uh, for a show of hands who remembers structured systems analysis and design method. SSA as we affectionately called it as, I wouldn't want to embarrass anyone, um, particularly if you delivered software, uh, projects in the last century. Okay, just kidding.

Of course. Uh, I used it for the first 15 years of my career myself. However, we are now in the digital world.

We now have cloud native applications, microservices, immutable infrastructure, infrastructure as code. And all of this means that many of those logical dependencies either no longer exist or can be managed quite differently. Traditionally, our infrastructure had a, you know, a client server model relying on specialist servers that had to be maintained, uh, and configured manually with huge numbers of criteria in settings.

It was therefore a herculean task to keep everything in synchronization. And when it went wrong, of course the cry went up. Well, it worked on my machine.

Modern systems of course, describes infrastructure as code, meaning that it can run, uh, as a virtual machine and it can exist on, you know, multiple ones on a server. Or indeed one virtual machine can span more than one server. So rather than maintaining a standard system for each, we can now package that container with just enough as we see here, uh, for each application or product to run effectively.

This is safer and more secure because it leaves fewer exploits and these containers don't need to be patched or maintained. You simply kill the container and build a new one from the latest image or library. This is what is known as immutability.

We don't need to track so many dependencies, just maintain the playbook and use always the latest. This is an illustration made famous by Henrik Berg showing the difference between, you know, phase delivery and true iterative and incremental evolutionary development. Each iteration aims at producing something, but although it isn't the final product, he still has value that would lead somebody to be an early adopter to use it.

And we can therefore use the learning of how they use it, the feedback into later iterations. It's worth noting the top illustration would have several hard, logical dependencies from components made in the first phase that have to be incorporated into the last, the mineral viable product or MVP design Philosophy means iterations only have to be consistent or dependent within themselves. As we could deliver first and re-engineer later, they may be few or indeed know components from an early iteration that makes it into the final one.

The design of volts indeed note that the bottom result is still a car, but a different design because of that MVP feedback. Now, whilst many find this diagram informative, some have criticized it for being a little unrealistic or even glib. Of course, I'd counter the fact that you know, many of our current car manufacturers started out as, um, bicycle manufacturers as indeed did, uh, the Wright brothers.

Um, so before we dismiss the, for example, the humble skateboards, a means of transport, I should point out that recently I was in London, um, and was nearly hit by a commute to me from Tower Hill Tube Station on his, on his way to work. Um, so another source of dependency of course is resources. Now resources are not just availability, but of course they're timing.

Um, and the effective resources allocate over time to projects. So here's a working week and developer A is available on Monday and Wednesday mornings and Thursday afternoons. Developer b midweek afternoons only.

The tester only does Tuesday and Friday mornings with the product owner only having an hour or two on Mondays and Fridays. Now these are the core hours. Any meetings, of course would have to be outside of these, would have to be diary negotiated.

Now if this sounds familiar to anyone, uh, please comment on the chat. The other problem of course, is if the tester had a question for the product toner on a Tuesday, you wouldn't get answered until they came in on the Friday, but it might take a week later, therefore to be picked up. And action.

Likewise, developer B's question, uh, for the tester won't be available until the following Tuesday, either the turnaround time for just about everything seems to be a week and we schedules this county. It might take several to organize a meeting or a workshop. Again, posting the chat if this sounds familiar to you.

So let's take a slightly less dependent approach where instead of thinking in daily columns, we apply these more like stripes with overlaps. So developer A, um, and developer B have some key overlaps. If we then add in the tester still two afternoons, but again, respecting the overlap and if we now persuade the product owner to keep the 30 minutes before lunch free and a session early Thursday afternoon, we have removed a great deal of that dependency.

Uh, we can of course insert our daily standup meeting of 10 or 15 minutes into that shared overlapping slot when the maximum number of people will be available. This means the cycle time to get an answer is usually no more than a day, occasionally two, we are also far more aware of each other's workload whilst removing a whole layer of dependency note that we have not expended any more time. Okay?

Ideally there'll be more developers, maybe somebody dedicated to full-time, but this illustrates I think the principle. We also might have dependencies not just between team members, but between teams. So imagine we have two teams, TAA also team one normally looks after product A, meanwhile, team two normally looks after product B.

Now we know from the development interfaces of the Prince two work package that there is a dependency between A and B. In the normal course of events, uh, we would have noted that dependency, but the appropriate time, ask team two to action it. Now, let's assume team two is busy on higher priority work.

Now we could wait for 'em to become available, but we hate waiting. Not only does it mean we have to manage that dependency, but it also means potentially it backs up others. So rather than respect that cross team dependency, we break it, we carry out the work directly and then ask team to, to merely check it once they've integrated it into their support and maintenance plan.

Um, we now can say that the dependency has been satisfied to be removed. This means of course that teams must be more multi-skilled. Um, this includes general skills and knowledge, um, perhaps over a range of products or techniques, often called soft skills, including collaboration, analysis, prioritization.

We think of that like the top bar of a t. We also have spastics and in-depth technical knowledge, we think of that as being like the downstroke of our t. This room can use the top bars to collaborate and support others while deploying our technical skills in concert with everyone else.

If we have acquired more than one specialism, uh, we could think of ourselves as being more pie shaped. And of course, in this world of portfolio careers and lifelong learning, we might even be considered comb shaped. Indeed, if we had to minimize our dependencies, there is no room for either the pure generalist or the sole specialist, but rather people who can combine and collaborate together.

So something like this, our multi-skilled, um, t-shaped and better team could come together to combine an overlap and share their general specialist skills. What this means is fewer handoffs between team members, fewer dependencies to be tracked. If a team member is busy or on leave just like we did with the cross teams, then um, we could do it ourselves and just ask them to check it.

This approach removes many of the dependencies of waiting on a highly trained specialist to do some of them. That might be relatively simplistic work, but we wait for them just because it fell within their area. Now these approaches have covered those that are under our control, but what are those, um, that are beyond our environment?

Now, in most products or work breakdown structures, we would find external products the production of which fall outside of our control. This can be for a number of reasons, including that they already exist or indeed, um, it could be a fater complete take it or leave it. Traditionally in Prince two, these have been highlighted by, as we see here, a, a different shape or color on the diagram.

There are however, a number of steps we can use to minimize the impact of these external dependencies. As our breakdown structure makes clear that external dependency, we can use attempts by our code or systems to breach a firewall, uh, to detect or we're fetching data from outside or relying on other outside input on complex systems. We may have to deliberately disable certain functions to discover what its effects and what it's actually connected to.

Uh, this process of posing a hypothesis and then testing it, um, which isn't actually just, you know, randomly breaking them, uh, but rather finding ways to fix things on purpose. Uh, this known as chaos engineering and it's making significant inroads into resilience and anti fragility of complex systems. But we in projects can harness some of these techniques to detect legacy dependencies as well as areas in our own production of digital products.

Now, a dependency is an area of uncertainty and therefore, of course, a source of risk. They should therefore be assigned a risk out and mitigated using the print to approach to risk management, including regular identification workshops and reviews. Now, some mitigations are applicable to digital products, include the use, um, of proxies to simulate, uh, external dependencies, um, during development or even in limited circumstances can be used in line where it's critical.

We might also inject cash or dummy data to bridge dependencies at key points or make provision for recovery point objective so that uh, we have enough cash to be able to recover. So contingency plans must be made, um, and test it, but things should be deployed without a backup plan. And whilst test environments in the cloud can be very close reduction, there are always elements unique to the live environment.

We should then plan for fire breaks, uh, the chance of significant harm. And this leads nicely onto discussions around how governance risk and compliance can also, uh, result in dependency and some key questions to ask. So our first question is, you know, does this piece of work still have to be done?

I've worked on projects where we've diligently filled out mandatory reports only to discover the need for them, but long since passed and no one in authority really care. Don't underestimate however, the capacity though for for bureaucratic mind to carry on robotically doing some. By the way, just because we've always done it that way, it is not a sound reason and neither is because I said, so what actually makes it mandatory?

If no one is prepared to answer that question, I carry out my own chaos experiment. So, um, with a second question, I prepare the report or whatever and then just don't send it. You might want to share in the chat what you think probably happened.

Well, sometimes I fell foul, but more often than not, anyone care to speculate what happened. Hmm, I'd agree with some of you. Yes, sometimes that's right, nothing nada zip.

But if it's still needed, does it still need to be done by us? We've got better things to do called delivering the project. Is it recorded elsewhere, for example?

Um, is the technology and data structures as they move on, do we need to carry on doing it in quite the same onerous or labor intensive way? Remember, we use print two that has principles. So could we manage this by exception stand?

And with the rise of business process automation, uh, the widespread use of software tools, can this dependency be automated? Does a human being have to do it at all? So technology can be key in helping to eliminate or manage dependencies in a digital environment.

Let's look at the area of managing product delivery. Uh, in prints two, uh, teams using a modern DevOps style delivery approach. We'll probably using a number of tools in concert across a solar delivery cycle.

This automated pipeline will integrate changes frequently, often daily, and not only the new work, but would also test the remainder of the system to make sure it continues to function when it's been integrated. If our changes break the existing system, we can easily roll back to the last safe working version. It is perfectly possible to have an automated system to deploy something, detect a dependent failure, automatically remediate it, and then generate a report the next day.

Something along the lines of your last update failed because of the conflict with X, the previous uh, system was automatically restored. We have notified the team that looks after x, um, of the potential problem. So one of the ways in a Prince two agile project we can break rather than respect dependencies is to integrate and deploy all features frequently, but in order to make sense to that end user, we can switch off those things that are not required just yet.

So let's have a look how that might work. Here we have four teams working with the arrows indicating deployments. Um, we often refer to them being like trains leaving a station and regular intervals, so they're known as release trains.

On the first deployment, we have completed the blue, um, purple and yellow features, so deploy them, um, but we switch, uh, them on for use. In other words, they form part of our minimal viable product. The red and green features are not yet complete, but we deploy what we've got to date but then hide them or switch them off.

Uh, but their backend can still exist using independency even if it's not yet live. By the next release we've completed the red features, so that can now be switched on and we've also completed the gray features, but of course the orange feature is not yet finished and the green feature construction is still ongoing. So they remain switched off.

The features shown, of course, still represent our current minimal viable product. On the third iteration, the brown, magenta, orange and green features are now complete and can now be turned on. They represent the next it's iteration, our minimal viable product.

Note that much coder infrastructure may be present satisfying dependency whilst remaining hidden. So this dark launching technique is suitable for a wide range of digital products, websites, mobile apps, software platforms, even whole cloud regions. Whilst this can be done manually, perhaps using nothing more than a menu system or some kind of front end, there are many orchestration or purpose-built tools, which may form part of an automated DevOps pipeline.

These can provide powerful controls themselves whilst providing for security and giving an audible trail, um, for governance and compliance purposes. It's one of the strengths of print two that incorporates approaches such as these as part of the managed project delivery process. This allows autonomous, uh, and empowered teams to use these specific flexible toolings tailored to the product in its environment.

It remains important though that project managers aware of these beneficial approach and the fact it has on how we have to think and manage dependencies. These technologies have the capable of producing a plethora of data, which needs to be translated into metrics, provide observability assistance with the rise of machine learning. You could argue that we're all data specialists now, um, but we should take and appreciate the dependencies are just one in a, if not a very important one of that data set.

Likewise, many dependencies can often only be served by repeated actions or we sometimes call toil, sometimes periodical or triggered by an event. Um, there are many platforms and tools that we can use to automate this as business process automation, the project manager be alive for possibilities of incorporating them to address those dependencies. It is one of the strengths of Prince two, but it's principle based rather than prescriptive.

We should therefore tailor accordingly and now think carrying out experiments to check our systems in the way we envisage, but also detect any unanticipated uh, dependencies. Indeed, some systems are so complex that those working on them find it impossible to adequately understand them at the detailed level. Pulling the plug occasionally might be the only way to surface these dependencies.

Ultimately, though, all this technology will not save you or make you successful on its own. We should harness technology to do the parts of dependency management that we're not good at consistent repetition of tasks, spotting trends, crunching data. But what we should not undervalue though is the power of imagination, insight, judgment, and creativity as a skill project manager can bring to the party.

By the way, that's you by the way. Um, ultimately delivery is your responsibility. So I hope you have found this, uh, fascinating journey through the potential minefield of dependencies.

Remember, we need not fear that indeed our digital products and engineering approaches mean that rather than expending energy on managing them, we can break them or find ways to mitigate or eliminate them. Remember though that this may be having to think differently yourselves and also evangelize that different mindset in others. And we will undoubtedly need to adopt new structures both within our projects and our teams, but also within our emerging solutions themselves.

In this short session, I've shared a few techniques and mentioned some tools in passing. Try some and maybe discover some more. Remember, every dependency removed is a saving, uh, made or a risk reduced.

Um, you can start modestly and build out from there the due date, therefore on learning something new has to be today. With that in mind, here is a selection of some further study. Um, but um, uh, I would suggest and amongst those, uh, standard tech, maybe you're familiar with, uh, there's some more member, um, any titles that you have found useful or other sources that you would like to share with the audience, uh, on dependencies.

Um, so pop any of those questions into the chat and I'll try to answer as many of them as I possibly can. Um, but if you want to carry on the conversation, please feel free to contact me on any of these means. Uh, you can use the QR code and follow me on LinkedIn or if you prefer to connect, please send me an invite mentioning, uh, this skill update.

I'll be delighted to welcome you to my network. I've been David Tommo Tomlinson and thank you for watching this session and I hope to be with you again soon. So until the next time.

Bye-Bye.