As we are now creating open source tools for doing the sort of iteratively-improving, asynchronous planning that we do, it has occurred to me that we need a name for it while marketing.
My feeling is that this process, if we are successful at marketing it, will eventually become much like Agile: Everyone will say they are doing it but most will be implementing it poorly, some will do it well, and some groups (such as ourselves) will be making good money consulting in its implementation.
While we are still some time off from being able to do a serious push in consulting services for this new manner of working we intend to export to the software community at large (and perhaps beyond), we do need to come up with a name for it. After all, as we get things like the Sprints app ready for public contribution, we may want some marketing materials made naming the overall process that birthed it.
I feel like this name should stress its asynchronous, iterative nature-- the way that we continually refine it as we go along while avoiding a lot of the traditional management features like long synchronous meetings, and give power to the individuals in their own hands. It might also riff off of the name âAgileâ somehow.
Iâd caution against such terminology: even the âfoundersâ of Agile regret calling it that because itâs perceived as being universally better, which leads to everyone wanting to do it, watering it down and it eventually becoming meaningless.
That being said, I would describe it as Distributed Scrum; itâs not really an option because Scrum is almost certainly trademarked, but I feel it conveys the Scrum structure we use while making it clear itâs modified for use in distributed teams.
I know this is not what youâre looking for, @fox, but I just call it ârunning a globally distributed team successfullyâ, and the bible is the handbook.
Thinking aloud here: we distinguish ourselves by running a fully distributed and self-managed team, using mostly asynchronous communication and standing by open-first principles.
Weâd rather take a bit more time to plan something, but the end result is that we do it really well, most of the time.
For a second I thought of the term slow Agile/Scrum, like in slow living, slow food, etc. Slow as in sustainable, better. But the term already kind of exists, and the stuff I saw was very esoteric and far from what we do.
Distributed Scrum already kind of exists too, and does not really focus on asynchronicity (itâs just about having a remote scrum team, with the usual daily standups etc.).
We might be doing smarter Scrum, but I donât like the word.
Our processes provide great flexibility: we can work on our stuff whenever we want, we have plenty of uninterrupted work time, and the time zone differences are not an issue.
When I read âdistributed and self-managed team, using mostly asynchronous communication, with an open-first approachâ the first thing that comes to my mind is a comparison with the history of distributed systems and how it became âcloud computingâ.
Indeed, in such systems, the paradigm, the âway of doing thingsâ, transitioned from synchronous and coordinated interactions between modules to a network of distributed nodes managed independently over unstable channels. To do that, they cannot rely upon the state of each other. They cannot rely on synchronous communication, although it can be used when reasonable. Messages can be lost. Nodes can come and go. But they do coordinate successfully to achieve a common goal and get the job done. And they can scale.
Interestingly, this is reasonably similar to the transition our industry is going through right now, which I believe we are one of the representatives, being an open all-remote company.
Anyway, I want to suggest something like Open Cloud Methodology. But, for some reason, I donât think it sounds cool or marketable⌠maybe I am just not giving the credit it deserves. In any case, I hope the ideas above can at least be food for thought.
I agree that one of the key elements is the asynchronicity.
Another one is the fact that itâs organized asynchronicity with workflows, defining clear responsibilities and expectations. âLetâs handle everything via emailâ is also async, but itâs a mess â the âhyperactive hive mindâ described by Cal Newport, and is also quite opposite to what we are doing.
I got the chance to review Scrumâs components/methodologies and was surprised just how many of our processes do come from there. I thought we invented the Sprint Retrospective, for instance, because I never saw it used anywhere else I worked.
Anyway, the async methodologies weâre using seem to be a key factor here. Weâve eliminated the standup from our workflow. I donât think we ever used it-- we just had a mid sprint meeting back in the day.
This is a challenging thing to name. âAsync Workflowsâ seems more generic. I feel like we should find some analogy. âScrumâ was in sports-- Rugby in particular. I feel like word-picture would also be useful here.
OK. We probably will want to use both âTimeshiftâ and âTimeshifted Agileâ in a context-dependent way. âTimeshiftâ could be the headliner/modifier, and it could be the way we describe things like our process. Hereâs some examples of how it could be used:
âWe need to Timeshift this process so weâre not waiting on everyone to be available at the same time.â
âOur company uses Timeshifted Agile.â
âThis tool allows us to Timeshift our reviews.â
OpenCraft specializes in supporting Timeshifted workflows.
I think the term should be consistently capitalized to make it more clear its intended meaning as a discipline of making processes that are traditionally synchronous into asynchronous ones, kind of like how Agile the term is separate from the traditional definition of the word.