A dependency chain is where you have a number of functions that all need to do some part of a piece of work in order to fully deliver it. These functions complete their part and then pass it along to another.
In my last article I showed why your IT requests were likely taking so much longer to service than you expected. But what if you have multiple dependencies chained together? How can you get a rough idea of how long something is going to take when you have a disconnected dependency chain rather than an end to end view of the system. In this article, I’ll explain the process of getting a rough statistical idea of how long something is going to take when you have multiple dependencies all linked together. I’ll explain this through an R script, but the concept is easily transferable.
You’ve got a quick job to do so fire it off to an IT team. It should only take around half a day of effort so you expect to hear back by the end of the week. Three weeks later and you’re still waiting. So why is this happening? What is the deal with IT delays?
Apologies in advance to all scientists, engineers, and mathematicians.
This is going to be another opinionated piece on the ideal line management reporting structure for an Agile team. I’m not going to get into organisational hierarchy or connections between teams, instead just focusing on the Agile team itself. This does, however, relate to the concept of dependencies.
Over this series, I’ve spoken in detail about the organisational impact of IT dependencies in your system. I’d like to take a diversion and discuss how it can impact the individual.
I posit that even without the work benefits you could derive from eliminating dependencies, the quality of life changes you could bring about would more than pay for the effort.
This isn’t an article about workplace stress, we’re all pretty familiar with its cost to our economy. Nor is this an article about the cost of employee churn. It’s not even about the cost to productivity through disengagement. Let’s move forward knowing the impact of people not being happy.
After some of my recent articles on building a dependency map, a few people got in touch asking for tips on actually creating them. Here’s a quick way to get started.
You might have noticed the following example in my previous posts.
I created the graphic above with an amazing bit of kit called Neo4j. It’s actually an incredibly sophisticated graph database technology, so it almost feels a little sacrilegious to be using it for this.
I’ve written a few heavy articles recently, so thought I’d take a step back with something a little lighter. I absolutely love retrospectives and am going to take this time to highlight some common retrospective pitfalls that I frequently see people falling into.
Why should we care about facilitation for introverts? What does it actually matter? Let’s run through it.
“[…]someone who prefers calm, minimally stimulating environments.”
I sat there in the audience, gazing up at the exuberant figure breathing life and energy into the room. New to facilitation, I felt anxious just watching him play the room. I could see how the content was broken up with quick questions to the audience, group activities helped to encourage engagement from everyone. Engagement, that seemed important. If I was going to be good, then I needed to get everyone involved somehow.
For the past few years, I’ve sought to hone my craft at facilitation. Engagement has been a driving force for how I structure my content and a measure for how successful I feel that I’ve been. I felt that if everyone was active in some way, then that’s a quantitative measure of success, right?
If you’re not up to speed on the concept of dependency mapping, then I’d suggest taking a look at my previous post where I talked through how to go about building a dependency map.
So what happens now? You’ve gone through the workshop and now have a bunch of data that’s telling you what? Something about your system? I’m going to run through some of the actions I take when attempting to understand a dependency map.
There’s been a deluge of advice on how to survive working from home recently. I almost didn’t bother, so as not to add to the noise. But I figured what the hell, even if one other person can be helped then maybe I should.
I’m a consultant, so work from a variety of places. Home is a common one, often for extended periods of time. Working for an excellent company that is remote first, DevOpsGroup, has given me plenty of time to perfect my pattern. Here are my tips on looking after yourself when confined to the house.
Recently, I published an article where I discussed the concept of dependency as a proxy for complexity. I also tried to show that complexity is the biggest aspect to consider when attempting to improve the flow of value. This is all part of a concept I call Dependency Mapping.
Following publication of the article, I had a few people who read it on LinkedIn reach out for some advice on actually doing it in their place of work. In this article I will dig deeper into the process by which we can start to map out dependencies. With the map completed, we can then work to remove them.
Dependency maps are going to be messy as they try and convey a huge amount of information. We’ll aim small, and then offer some suggestions for improvement from there.