Effective cross-team collaboration is crucial for any organization, especially as teams grow in size and complexity. Without a structured approach, communication breakdowns, misaligned goals, and inefficiencies can arise. One way to ensure seamless collaboration is through Ordered Coordination, a pattern in which teams follow a mandated structure dictated by leadership.
In this blog post, we’ll dive deep into the Ordered Coordination pattern, how it works, its benefits and challenges, and best practices for implementation.
For the title of this blog entry, I was reminded of reading about a book by Chad Fowler titled “My job went to India”. I read its successor, The Passionate Programmer, as it was discussed during the initial days of the software craft movement on the mailing list. Why did so many jobs move to Nvidia, the graphic processor company? Or didn’t it? Let’s find out.
With the advent of what I call the second generation of scaling approaches out there, maybe it’s time to dive deeper into the patterns that larger organizations underlie.
I have been cooking this blog entry series for a while now in my head. Time to get some structure to it. This first entry deals with organizations that are oblivious to their need for cross-team coordination practices.
Back last year, I started a reflection on whether Agile might be dead, undead, or still alive and thriving. Ever since I saw my blog entry series popping up in Jurgen Appelo’s collection of blog entries on the topic, I was reminded that I still lack a wrap-up of my thoughts, after having gone through them. Let’s start this year with a reflection on my reflections.
P.S.: On a personal note, 10 out of 45 colleagues at it-agile have been informed last week, that their employment contract will end this year. That will include myself as well. You can see the more general announcement (in German) on LinkedIn. That said, if you’re looking for someone with my skills, talents, or know anyone that I might be a good fit for, I’d appreciate if you reach out to me, or gave me a hint in another fashion. Thank you in advance.
After I went over the various reasons why Agile may be perceived dead, or undead, it’s time to take a look on the reasons why Agile is alive – and I think it will remain so for some time. Maybe the goldrush times of Agile are over, but there are certainly some things that will stick. Let’s explore again.
Continuing our journey in the “Agile is dead” space, I thought Halloween was the perfect date to explore the ways in which Agile is actually not just dead, but undead in many companies. If you read my earlier entry, you might have come across the thought that this was where we were heading towards. Let’s investigate further.
This entry is a continuation of the discussion I started yesterday. Stick long enough in any community, and over time you will hear claims about the movement being dead. For some communities, there is some reasonable truth to the claim – at a certain point in time. To others, there is not. Let’s tackle some of the background on why I think that Agile might be dead.
Stick around long enough in the agile world, and sooner or later you come across the age-old discussion about whether agile is dead – as is the case at the time of me writing these lines. Just when I had that discussion again at two recent user groups, I recalled on my way back home that I had that kind of discussion about a decade ago. So, when I came home, I had to digest my old blog entries. To my surprise, I found something similar, yet, seemingly different in my blogosphere past.
Stick along long enough in software development, and you may have come along the ride for Agile software development practices, methodologies, and/or frameworks. Stick along long enough in that community – ok, that might be a reach too far, given that community only exists about 30 years or so. All of the above said, I notice some developments lately around the term Agile, and need to get my thoughts down. Not that I think I have a particular relevant perspective to start with. But maybe I can offer some perspective to one or another reader.
If you know me, you probably know that I have a tendency to look back on where did we come from to better understand things happening in the present. If you are not that kind of understander, maybe this blog entry might not be for you. So, be warned before moving on.
Since minqlx seems to stand for “Mino’s Quake Live eXtension” and I go by the player name of ShiN0 in QL, I thought an obvious name for my Rust implementation of minqlx would be shinqlx for ShiN0’s Quake Live eXtension.
But before we dive into the first steps I took, maybe a few introductory words and maybe some references in case you want to go a similar route.