Software Configuration Management, tools and procedures.

[Marc Girod]

I note that this group is named 'comp.software.config-mgmt',
and that, according to Google Groups, its description is:
Configuration Management, tools and procedures.
I note again according to Google Groups, that the group
was created in 1994.

Several never ending debates there:
- the relation between CM and SCM
- the role of procedures and tools

One gets again and again thrown back to these, even if
nobody wants to deal with these wars anymore...
One such reference is the first principle of the Agile
manifesto:
(we value) Individuals over processes and tools.

Quite an innuendo! Pushing processes and tools back to
back and opposing them to the (obviously valued)
'individuals'.

What do I find dishonest there? That the agile movement
will in fact propose scrum meetings to 'value individuals'
and that this is a *process*, and is in no way neutral in
the context of the SCM (tools) vs CM (processes) war!

Meetings are a tool of power, submitting 'individuals', i.e.
devalued, anonymized, people to old strategies of
silencing and exclusion, in the context of old fashioned
organizations.

Politics.

1994 was a time of freedom, of a lost sophistication of
software. Taylorism has fought back since then.

Marc

[Jorgen Grahn]

On Sun, 2011-10-02, Marc Girod wrote:
...
> One such reference is the first principle of the Agile
> manifesto:
> (we value) Individuals over processes and tools.
>
> Quite an innuendo! Pushing processes and tools back to
> back and opposing them to the (obviously valued)
> 'individuals'.
>
> What do I find dishonest there? That the agile movement
> will in fact propose scrum meetings to 'value individuals'
> and that this is a *process*, and is in no way neutral in
> the context of the SCM (tools) vs CM (processes) war!

Well, what do you *want* them to say? As soon as you're working with
something which needs more than 2--3 people[0], you need /some/
structured communication. As I understand scrum meetings, they were
designed specifically to be quick, informal meetings of peers. I see
no dishonesty there.

/Jorgen

[0] You could argue that that's the first mistake ...

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Marc Girod]

On Oct 2, 6:52 pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:

> Well, what do you *want* them to say?

That you can pick tools so as to respect people.

>  As soon as you're working with something which needs
> more than 2--3 people[0], you need /some/ structured
> communication.

Structured, maybe.
Asynchronous, persistent, public: continuous!
You need to make communications manageable from
the end users' point of view.
This cannot work in meetings.
In fact, it requires tools. No such tools have proven
successful yet. But these tools would be SCM tools.

> As I understand scrum meetings, they were
> designed specifically to be quick, informal meetings
> of peers. I see no dishonesty there.

The dishonesty lies in pretending to respect people
by not considering tools a priori.

The efficiency of quick informal meetings is just naive.

> [0] You could argue that that's the first mistake ...

What? Working with more than 2-3 people?
I would never argue this is an error!
On the contrary, collaboration is a challenge, but
certainly worth the while.
Pretending that one can split any problem into chunks
to be handled by individuals is erring on the side of
upfront decisions: they will always be ultimately wrong.

Marc

[Jorgen Grahn]

On Sun, 2011-10-02, Marc Girod wrote:

> On Oct 2, 6:52 pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
>
>> Well, what do you *want* them to say?
>
> That you can pick tools so as to respect people.
>
>>  As soon as you're working with something which needs
>> more than 2--3 people[0], you need /some/ structured
>> communication.
>
> Structured, maybe.
> Asynchronous, persistent, public: continuous!
> You need to make communications manageable from
> the end users' point of view.
> This cannot work in meetings.
> In fact, it requires tools. No such tools have proven
> successful yet. But these tools would be SCM tools.
>
>> As I understand scrum meetings, they were
>> designed specifically to be quick, informal meetings
>> of peers. I see no dishonesty there.
>
> The dishonesty lies in pretending to respect people
> by not considering tools a priori.

OK. I can't comment on that.

> The efficiency of quick informal meetings is just naive.

I get the feeling SCRUM defines those meetings mostly as a way to
prevent management to set up other, long, top-down meetings. The
benefit of hearing N people say "I still work on feature FOO" isn't
that big.

>> [0] You could argue that that's the first mistake ...
>
> What? Working with more than 2-3 people?
> I would never argue this is an error!
> On the contrary, collaboration is a challenge, but
> certainly worth the while.
> Pretending that one can split any problem into chunks
> to be handled by individuals is erring on the side of
> upfront decisions: they will always be ultimately wrong.

I don't believe you can do that, either. Not in general. But I've seen
(several times) how management tends to want to to the opposite, by
lumping /distinct/ problems together -- the "One Unified Tool"
approach. That, in my experience, just creates /more/ problems.

/Jorgen

[Marc Girod]

On Oct 3, 3:15 pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:

> I get the feeling SCRUM defines those meetings mostly as a way to
> prevent management to set up other, long, top-down meetings.

A lesser evil, then?
Why not... Maybe you're right...

> But I've seen
> (several times) how management tends to want to to the opposite, by
> lumping /distinct/ problems together -- the "One Unified Tool"
> approach. That, in my experience, just creates /more/ problems.

Right. I agree there as well.
Marc