[core-workflow] workflow types: agile (gameplay) vs rigid (process)

[Tal Einat]

Hi Anatoly,

This is getting long and very "meta", but I feel I must reply and
explain further so that there is a chance that useful discussion can
later happen in this forum. One important member has already said that
he is considering leaving in light of your post, so obviously some
action is required to save this forum, and I choose to do so openly
and in the relevant context.

I do ask that if you have any specific points you'd like to clear up
on this subject, please let's discuss them privately before bringing
them to everyone's attention.

To everyone else, this here so that you can read it if you like, and
for future reference.

On Thu, May 15, 2014 at 12:09 PM, anatoly techtonik <techtonik at gmail.com> wrote:
> On Thu, May 1, 2014 at 11:21 AM, Tal Einat <taleinat at gmail.com> wrote:
>>
>> First of all, your post is off-topic for this list. We are here to
>> discuss the workflow of core Python development and related tools, not
>> to have general discussions about workflow.
>
> It is the same as saying "We are here to discuss the structure of objects
> of our program, not to have general discussions about classes".
>
> Don't you think that discussing structure of objects without touching
> classes is a little bit weird? You do realize that everybody should know
> at least what kind of possibilities are available.

Are general discussions about OOP are relevant on python-list? Despite
Python being a programming language, they *are not relevant* unless
they are somehow *directly* related to Python.

A discussion about whether "agile" or "rigid" workflows would be
better suited *for core Python* could be relevant on this list. In
such a context, giving references to relevant sources of background
info could be useful.

However, starting a *general* discussion about types of workflows is
not *directly* relevant. I am not saying that it could not possibly be
useful to discuss here, but there was no previous discussion in whose
context it became useful and relevant *now*.

To phrase the above differently, the discussion here should assume
that common concepts are understood by the participants. If someone
doesn't know a concept, they can ask or do their own research. If,
during a *directly relevant* discussion, there is a reason to make
sure that the concepts are understood to mean the same thing by
everyone, that would be a different matter. Even in such a case,
though, a few pointers to good reading sources should be the start,
and discussion should only arise if there is disagreement with those
sources. That is usually quite rare.

>> Next, using a title such as "agile (gameplay) vs rigid (process)" is
>> inflammatory (= will make people angry) but uninformative and
>> unhelpful.
>
> We are speaking about some imaginary angry people or it made you
> angry? If it is so - say it to me. I don't understand why it makes you
> angry and I won't if you don't tell me. You can use private email.

I am not angry at all. From previous experience from posts with such
subjects, I have learned that they tend to cause tension and anger.

A remark can be inflammatory even if it does not succeed in making
anyone angry. For example, "vim rules, Emacs sucks" is a subject which
may cause heated debate -- it is inflammatory because that it what it
tries to achieve. This can be true even if the author didn't mean for
it to be inflammatory.

> About being uninformative - I am waiting for questions. And note - it's
> not me who is starting offtopic.

Uninformative does not mean I need more information. It means that you
wrote something which does not convey much information. Your subject
is like "virtue: good (north) vs. evil (south)" -- not much
information in there, and also confusing and mixing up unrelated
concepts.

I do insist that "gameplay" and "process" are confusing and out of
place in your subject. I've done "classic" work planning with "games"
and I've done "agile" without them. And both "agile" and "rigid" are
different kinds of processes, so calling one of them "process" is a
mistake.

>> Furthermore, to the extent of my understanding of the relevant terms,
>> you show a complete misunderstanding of them. Here are some specific
>> examples:
>>
>>> Agile workflows often take into account
>>> personalities, habits and environment of people
>>> involved in a process.
>>
>> I have never encountered a workflow which specifically takes into
>> account personalities and habits. In my opinion it is silly to say
>> that agile workflows take personalities and habits into account while
>> other workflows do not.
>
> It is said that agile workflows often take personalities and habits into
> account. Not that all agile workflows do this. If you take personalities
> and habits into account and adjust your workflow accordingly, then it
> is flexible. If this workflow can also adapt to other factors dynamically
> - it can be named agile (usually "agile" means that your workflow is a
> combination of well-known patterns that are combined - kanban,
> iterations, backlog, othergameplayhere, etc.).

And here is the source of the problem -- "agile" is not a very well
defined term, and different people understand it differently. From my
understanding, "agile" is not about combining several patterns from a
pool of well-known ones such as Kanban or "planning poker". And even
if that is your understanding of the term, that has nothing to do with
the personalities of the people involved.

> It will help to understand it better if you compare it to usual corporate
> workflow, where you have a "position" and a set strict actions that this
> position can do and what responsibilities it has. This is not adjustable,
> so it is a rigid workflow.

"Corporate workflow" can be just as adjustable as "agile". I've seen
teams do "agile" without changing their process over time. On the
other hand, I've seem teams do "classic" development but adjust their
positions, responsibilities and processes very often. Whether the
workflow is adjusted over time, and how often this happens, is
unrelated to whether this workflow is considered "agile".

"Agile" usually means that the work plan is flexible -- not the
process itself! The plan is changed often to meet changing
requirements, customers or other needs and limitations. Even in
"agile", the process by which the work plan is created and changed can
stay the same or be changed over time, but that is a different matter.

> Workflows also have an indicators that they are rigid. If there is a
> formal paper that regulates interactions, then there workflow is most
>  likely rigid (hard to change).

No, that means that the process is rigid. I can write a formal paper
describing the different roles and interactions for SCRUMM (an "agile"
methodology), enforce those in an organization, and have as a result
an "agile" workflow with a rigid, highly-specified process.

>> On the other hand, regardless of workflow, any specific development
>> group should take into account many considerations, including the
>> environment and its members' personalities and habits. This has
>> nothing to do with workflow, so I simply cannot make any sense of your
>> above statement.
>
> Yes, it seems obvious that every development group naturally tries to
> take into account many considerations, including environment, but in
> parts of the world where most outsourcing takes place you often
> can not adapt environment - the environment filters and forges people.
> Many just leave. In remote teams you need to be extra careful about
> people and bus factor. Many competencies are unique and you don't
> have a community of developers on your project to filter from.

I read that several times but can't quite understand what your point is.

If the available personnel and their competencies are limited, that is
just one factor that should be taken into account when planning work
or defining processes. If you need to be careful not to drive away
potential contributors, that is another such factor. This last is
something you've been mentioning often so I'm guessing it is at least
part of what you're trying to say. And still I don't see how "agile"
or "rigid" has anything to do with this.


For anyone still reading: The following part is about Anatoly's
personal feelings about and experience with the PSF. There is nothing
remotely related to workflow issues.

>>> Just think about why different people don't feel fun
>>> contributing to Python overall, who are those people,
>>> why Python community needs them, and how you
>>> can help them by removing obstacles.
>>
>> This is precisely what the Python developers and the PSF have always
>> done. Specifically, in recent years they have been spending more and
>> more time and effort on this. Despite this you have repeatedly (now
>> and in the past) accused them all of not doing so, and you are simply
>> completely *wrong*. This just shows how distorted your view of the
>> Python developers is.
>
> I never said that PSF doesn't do anything at all. My main criticism is that
> what it does is insufficient, lacks visibility, does not have a feedback loop,
> and as a result - not effective. FWIW, I don't like that PSF protects
> legalese instead of defending open source values, it doesn't invest in
> researching and solving conflicts, can't set focus for community, organize
> collaboration and open environment for hacking, learning and
> cross-disciplinary exchange.

What you personally don't like about the PSF really isn't relevant here.

> I am saying it here, because PSF is major factor that affects people
> minds and as a result, evolution of workflow tools. Some people don't
> participate, because there is an organization that exists to solve problems.
> The hope that if somebody is active in doing something, this organization
> works with them in reaching their goals, help them, not limit them, ignore
> or ban. If there is an opinion, this organization counts that opinion, makes
> stats, provides something that this person can not provide.

The PSF's effect on the workflow is very indirect, especially as you
describe it. To claim that such indirect influence is reason to voice
your opinions of the PSF here is just an excuse. As is obvious, the
PSF is not dictating any process or workflow, and is hardly taking
part in the discussion as far as I can tell. This is all being left to
us, the community of developers. So leave the PSF out of this
discussion -- it isn't relevant.

> PSF is made for legalese. I asked many times to provide a short hacker's
> guide on CLA - why it exists, why the wording is like this, what every word
> means, why these specific words are there, what countries are affected,
> why some clauses don't work by default and what needs to be changed to
> make open source a better place like it was before.

Come on, really? "a short hacker's guide" ... "what every word
means"?! Your requests are not being granted simply because they are
not reasonable.

> Legalese if the primary
> function of PSF as I see it. Does anybody who can help to answer these
> questions tried to contact me? No.

Several such people have contacted you and tried to help you
understand these things. It is very annoying that you say that they
have not! They have invested more time and effort with you than they
should have and you ignore that completely. Your lack of respect
towards them is outrageous.

> What is the PSF workflow? How does it know that it does anything right?

How can anyone ever know that she is doing something "right"?. There
usually isn't any "right" way to do things. Your argument has no
merit.

>>> workflow types: agile (gameplay) vs rigid (process)
>>
>> This is ridiculous. Every agile methodology I have heard of includes
>> some specific process for development. From all of the development
>> groups I have been in or worked with, those which used "agile" methods
>> had much clearer processes which they actually stuck to and which were
>> usually more effective. "Agile" does not mean not taking work
>> seriously and it is not an excuse for lack of process.
>
> There is nothing contradictory with what you say. I completely support
> this. It is confusing use of parentheses on my side. Title undergo an
> evolution to become more clear, but final mutation changed meaning:
> -> agile vs rigid workflows
> (there are people who don't know about agile or who think that agile
>  is another buzzword)
> -> workflows: agile vs rigid
> (still there is no definition what is "agile" and what is "rigid", and I am
> the one to educate or coin one)
> -> workflows: agile gameplay vs rigid process
> (it is not about gameplay vs process, so accent should be on being
>  flexible and not try to make PEP that will filter people)
> -> workflows: agile (gameplay) vs rigid (process)

Regardless of how you came to it, the subject you chose is terrible.
I've already gone into detail about this above.

>> Perhaps you have met some developers who used "agile" as an excuse for
>> not defining processes, but you would be wrong to think this is true
>> of all other groups who use "agile" methods.
>
> Now it is crystal clear that "agile process" is also process, and the
> main difference from "rigid process" is that "agile" process includes
> a mechanism for changing itself as soon as it is necessary.

Perhaps some processes do this, but not all. As I've explained above,
"agile" is usually taken to mean that the work plan is flexible, not
the process itself. It is natural that people who choose a flexible
work plan as a solution to quickly changing requirements and needs
will sometimes also be flexible with their process as well. Still, you
should not confuse the flexibility of process by which work is done
with the flexibility of what is done using that process.

>> To summarize, this post is off-topic, inflammatory and contains
>> several grossly incorrect statements. In my opinion this discussion
>> should not continue here.
>
> Do you still think so?

Absolutely.

As I mentioned in the beginning, please take up any additional related
points with me privately. This discussion must not continue here.

- Tal