Agile definitions

It is interesting to note that Agile and Apl share a lot of common
ground.
The Agile people have defined some factors where Agile will be useful.

Agile

Size
Well-matched to small products and teams. Reliance on tacit knowledge
limits scalability.

Criticality
Untested on safety-critical products. Potential difficultiies with
simple design and lack of documentation.

Dynamism
Simple design and continuous refactoring are excellent for highly
dynamic environments, but a source of potentially expensive rework for
highly stable environments.

Personnel
Requires continuous presence of a critical mass of scarce Cockburn
Level 2 or 3 experts. Risky to use non-agile Level 1B people.

Culture
Thrives in a culture where people feel comfortable and empowered by
having many degrees of freedom.

---------------------------------------
Disciplined

Size
Methods evolved to handle large products and teams. Hard to tailor
down to small projects.

Criticality
Methods evolved to handle highly critical products. Hard to tailor
down to low-criticality products.

Dynamism
Detailed plans and Big Design Up Front excellent for highly stable
environment, but a source of expensive rework for highly dynamic
environments

Personnel
Needs a critical mass of scarce Cockburn Level 2 and 3 experts during
project definition, but can work with fewer later in the project—
unless the environment is highly dynamic. Can usually accommodate some
Level 1B people.

Culture
Thrives in a culture where people feel comfortable and empowered by
having their roles defined by clear policies and procedures.

-----------------------------------------------
Personnel types
3
Able to revise a method (break its rules) to fit an unprecedented new
situation

2
Able to tailor a method to fit a precedented new situation

1A
With training, able to perform discretionary method steps (e.g.,
sizing stories to fit increments, composing patterns, compound
refactoring, complex COTS integration). With experience can become
Level 2.

1B
With training, able to perform procedural method steps (e.g. coding a
simple method, simple refactoring, following coding standards and CM
procedures, running tests). With experience can master some Level 1A
skills.

-1
May have technical skills, but unable or unwilling to collaborate or
follow shared methods.


------------------

Looks to me that many of these definitions could be used for APL
It might be a good idea to make a similar definition specific for
where APL is suited or rather what is suited for APL

On Sep 12, 4:35*pm, Gosi <gos...@gmail.com> wrote:
> It is interesting to note that Agile and Apl share a lot of common
> ground.
> The Agile people have defined some factors where Agile will be useful.
>
> Agile
>
> Size
> Well-matched to small products and teams. Reliance on tacit knowledge
> limits scalability.
>
> Criticality
> Untested on safety-critical products. Potential difficultiies with
> simple design and lack of documentation.
>
> Dynamism
> Simple design and continuous refactoring are excellent for highly
> dynamic environments, but a source of potentially expensive rework for
> highly stable environments.
>
> Personnel
> Requires continuous presence of a critical mass of scarce Cockburn
> Level 2 or 3 experts. Risky to use non-agile Level 1B people.
>
> Culture
> Thrives in a culture where people feel comfortable and empowered by
> having many degrees of freedom.
>
> ---------------------------------------
> Disciplined
>
> Size
> Methods evolved to handle large products and teams. Hard to tailor
> down to small projects.
>
> Criticality
> Methods evolved to handle highly critical products. Hard to tailor
> down to low-criticality products.
>
> Dynamism
> Detailed plans and Big Design Up Front excellent for highly stable
> environment, but a source of expensive rework for highly dynamic
> environments
>
> Personnel
> Needs a critical mass of scarce Cockburn Level 2 and 3 experts during
> project definition, but can work with fewer later in the project—
> unless the environment is highly dynamic. Can usually accommodate some
> Level * 1B people.
>
> Culture
> Thrives in a culture where people feel comfortable and empowered by
> having their roles defined by clear policies and procedures.
>
> -----------------------------------------------
> Personnel types
> 3
> Able to revise a method (break its rules) to fit an unprecedented new
> situation
>
> 2
> Able to tailor a method to fit a precedented new situation
>
> 1A
> With training, able to perform discretionary method steps (e.g.,
> sizing stories to fit increments, composing patterns, compound
> refactoring, complex COTS integration). With experience can become
> Level 2.
>
> 1B
> With training, able to perform procedural method steps (e.g. coding a
> simple method, simple refactoring, following coding standards and CM
> procedures, running tests). With experience can master some Level 1A
> skills.
>
> -1
> May have technical skills, but unable or unwilling to collaborate or
> follow shared methods.
>
> ------------------
>
> Looks to me that many of these definitions could be used for APL
> It might be a good idea to make a similar definition specific for
> where APL is suited or rather what is suited for APL

I recognised some of Cockburn's distinctions, but not the scheme
you've laid out. What's your source?

Stephen Taylor
editor@vector.org.uk

http://www.vector.org.uk
http://aplwiki.aplteam.com

On 13 Sep, 08:35, "Stephen Taylor <edi...@vector.org.uk>"
<StephenTaylorF...@googlemail.com> wrote:
> On Sep 12, 4:35*pm, Gosi <gos...@gmail.com> wrote:
>
>
>
> > It is interesting to note that Agile and Apl share a lot of common
> > ground.
> > The Agile people have defined some factors where Agile will be useful.
>
> > Agile
>
> > Size
> > Well-matched to small products and teams. Reliance on tacit knowledge
> > limits scalability.
>
> > Criticality
> > Untested on safety-critical products. Potential difficultiies with
> > simple design and lack of documentation.
>
> > Dynamism
> > Simple design and continuous refactoring are excellent for highly
> > dynamic environments, but a source of potentially expensive rework for
> > highly stable environments.
>
> > Personnel
> > Requires continuous presence of a critical mass of scarce Cockburn
> > Level 2 or 3 experts. Risky to use non-agile Level 1B people.
>
> > Culture
> > Thrives in a culture where people feel comfortable and empowered by
> > having many degrees of freedom.
>
> > ---------------------------------------
> > Disciplined
>
> > Size
> > Methods evolved to handle large products and teams. Hard to tailor
> > down to small projects.
>
> > Criticality
> > Methods evolved to handle highly critical products. Hard to tailor
> > down to low-criticality products.
>
> > Dynamism
> > Detailed plans and Big Design Up Front excellent for highly stable
> > environment, but a source of expensive rework for highly dynamic
> > environments
>
> > Personnel
> > Needs a critical mass of scarce Cockburn Level 2 and 3 experts during
> > project definition, but can work with fewer later in the project—
> > unless the environment is highly dynamic. Can usually accommodate some
> > Level * 1B people.
>
> > Culture
> > Thrives in a culture where people feel comfortable and empowered by
> > having their roles defined by clear policies and procedures.
>
> > -----------------------------------------------
> > Personnel types
> > 3
> > Able to revise a method (break its rules) to fit an unprecedented new
> > situation
>
> > 2
> > Able to tailor a method to fit a precedented new situation
>
> > 1A
> > With training, able to perform discretionary method steps (e.g.,
> > sizing stories to fit increments, composing patterns, compound
> > refactoring, complex COTS integration). With experience can become
> > Level 2.
>
> > 1B
> > With training, able to perform procedural method steps (e.g. coding a
> > simple method, simple refactoring, following coding standards and CM
> > procedures, running tests). With experience can master some Level 1A
> > skills.
>
> > -1
> > May have technical skills, but unable or unwilling to collaborate or
> > follow shared methods.
>
> > ------------------
>
> > Looks to me that many of these definitions could be used for APL
> > It might be a good idea to make a similar definition specific for
> > where APL is suited or rather what is suited for APL
>
> I recognised some of Cockburn's distinctions, but not the scheme
> you've laid out. What's your source?
>
> Stephen Taylor
> edi...@vector.org.uk
>
> http://www.vector.org.ukhttp://aplwiki.aplteam.com

http://www.extremeprogramming.org/xp...rs/paper20.doc

I was in a Agile meeting yesterday and there was a picture on the
slideshow showing the 5 scales like 5 dimensions
http://agile.is/wiki/pages/viewpagea...ion?pageId=265
Inherent risk reduction
The document is mixed Íslandish and english

I also downloaded ScrumWorks Basic down yesterday.
It is free.

It is interesting to note how the use client server to maintain
project information.
Simple web interface.

Something I would like to see in APL and J
All the ingredients are there but this GUI part is missing.
--------
Björn Helgason
http://groups.google.com/group/J-Programming

> It is interesting to note how the use client server to maintain
> project information.
> Simple web interface.
>

Most agile teams don't use software to maintain project status
information. Instead they usually maintain "Information Radiators" -
whiteboards with Index cards stuck on them, for instance. They do
often use wikis for longer-lasting documentation.

Of course, if the team is geographically dispersed, it becomes more
sensible to use simple software to maintain status information.

It would be interesting to see how a small APL team got on with
typical agile project management techniques. The focus in agile
project management is the same as in development: doing things simply
and doing only what gives value. This seems to fit well with the APL
mindset.

Romilly

On 14 Sep, 17:08, romilly <romilly.cock...@gmail.com> wrote:
> > It is interesting to note how the use client server to maintain
> > project information.
> > Simple web interface.
>
> Most agile teams don't use software to maintain project status
> information. Instead they usually maintain "Information Radiators" -
> whiteboards with Index cards stuck on them, for instance. They do
> often use wikis for longer-lasting documentation.
>
> Of course, if the team is geographically dispersed, it becomes more
> sensible to use simple software to maintain status information.
>
> It would be interesting to see how a small APL team got on with
> typical agile project management techniques. The focus in agile
> project management is the same as in development: doing things simply
> and doing only what gives value. This seems to fit well with the APL
> mindset.
>
> Romilly

I can see Agile and Apl work well together.
Both stimulate creative thought and want results.
A small Agile team does not need much documentation nor complicated
structure.
The best size of such a team is 3 to 8 people.
There is not much documentation involved and not much time for
meetings.
Short meetings every day and a lot of communications.

The people in the Agile team need to be of high quality and mostly
level 2 and 3.
If you get a small group working and the communication is working in
such a group it can make wonders.
If such a group could use APL too the productivity would go through
the roof.

You might think that you could use this technique for a group of one
but that could prove to be difficult.
Also the border between personnel type 3 and _1 could prove to be
paper thin.
While a singel person workng could be either 3 or _1 then the _1
person dould never operate for long with others.

I guess there are not that many percent of all people being of quality
2 and 3 so it is important to give them the best tools available.
I think Agile and APL could be a very good mix.

On Sep 15, 9:28*am, Gosi <gos...@gmail.com> wrote:
> On 14 Sep, 17:08, romilly <romilly.cock...@gmail.com> wrote:
>
>
>
> > > It is interesting to note how the use client server to maintain
> > > project information.
> > > Simple web interface.
>
> > Most agile teams don't use software to maintain project status
> > information. Instead they usually maintain "Information Radiators" -
> > whiteboards with Index cards stuck on them, for instance. They do
> > often use wikis for longer-lasting documentation.
>
> > Of course, if the team is geographically dispersed, it becomes more
> > sensible to use simple software to maintain status information.
>
> > It would be interesting to see how a small APL team got on with
> > typical agile project management techniques. The focus in agile
> > project management is the same as in development: doing things simply
> > and doing only what gives value. This seems to fit well with the APL
> > mindset.
>
> > Romilly
>
> I can see Agile and Apl work well together.
> Both stimulate creative thought and want results.
> A small Agile team does not need much documentation nor complicated
> structure.
> The best size of such a team is 3 to 8 people.
> There is not much documentation involved and not much time for
> meetings.
> Short meetings every day and a lot of communications.
>
> The people in the Agile team need to be of high quality and mostly
> level 2 and 3.
> If you get a small group working and the communication is working in
> such a group it can make wonders.
> If such a group could use APL too the productivity would go through
> the roof.
>
> You might think that you could use this technique for a group of one
> but that could prove to be difficult.
> Also the border between personnel type 3 and _1 could prove to be
> paper thin.
> While a singel person workng could be either 3 or _1 then the _1
> person dould never operate for long with others.
>
> I guess there are not that many percent of all people being of quality
> 2 and 3 so it is important to give them the best tools available.
> I think Agile and APL could be a very good mix.

The great virtue of the agile approaches I've seen lies in the way
they shorten communication and feedback paths in the development
process.

There is some contention about how scalable that is. I believe there
is a consensus that the benefits fade with teams much larger than 20,
though Jutta Eckstein makes a strong challenge to that in "Agile
Development in the Large".

I've asked at XP conference workshops about lower limits. How small
can a team get before the costs of XP practices become comparable to
their benefits? I've had several answers, all in the range 4-6.

4-6 is a largish APL project.

That fits my experience with colleagues on a project at a large
pension company. Our team size varied over time between 3 and 5. We
tried out XP practices such as developing in 2-3 week bounds with user
story cards. Some practices proved useful some of the time, but much
of it seemed to get in our way. We eventually fell back into what I've
heard an XP coach call "continuous flow". (He spoke of this as an
ideal state, rarely attainable.)

London boasts a weekly agile pub session, at the Extreme Tuesday Club.
It's a lively place and a great evening if you like meeting people
passionate about programming. Went down one evening with one of my
colleagues from the pensions project. Someone talked about having
worked on an agile project, hoping to be able to work on another one.
Someone else was working on an XP project then, making production
releases every 2-3 weeks, and excited about that. They asked us what
our "involvement with agile" was. We'd just had a big push on, the
team was up to six. We'd made 200 production releases in the previous
two months.

Of course, the comparison wasn't fair. Some of those changes had been
worked out by the users with us at the keyboard, coded, tested and put
into the system in under an hour. They hadn't been through rigorous
test phases; but then the business had found it preferred light
testing and quick fixes. No doubt some of those "production releases"
reflected second thoughts on earlier ones. It didn't matter. The point
is that our 'continuous flow' had shorter communication paths and
tighter feedback loops than a model agile project, and was delivering
user satisfaction like a train.

I once told Kent Beck my first reaction to reading "Extreme
Programming Explained: Embrace Change" was astonishment that Java
projects could be made so nimble. He grinned wolfishly and said he
would like one day to develop in Smalltalk again.

The Agile Alliance has won general respect for iterative development.
That respect is valuable to us; waterfall development drains away
APL's value. But the various agile practices themselves, as codified,
are of limited value to our tiny teams, and I would use Extreme
Caution about adopting any of them unmodified.

It seems to me our position is within the Agile Alliance, but distinct
from its famous members: XP, Scrum, &c. Gitte Christensen has coined
the phrase "Direct Development" to cover APL's development traditions.
I like the term, and think it would be worth taking some trouble to
elaborate what we mean by it. (Perhaps starting with a themed issue of
Vector?)

Stephen Taylor
editor@vector.org.uk

http://www.vector.org.uk

On 16 Sep, 09:44, "Stephen Taylor <edi...@vector.org.uk>"
<StephenTaylorF...@googlemail.com> wrote:
> On Sep 15, 9:28*am, Gosi <gos...@gmail.com> wrote:
>
>
>
> > On 14 Sep, 17:08, romilly <romilly.cock...@gmail.com> wrote:
>
> > > > It is interesting to note how the use client server to maintain
> > > > project information.
> > > > Simple web interface.
>
> > > Most agile teams don't use software to maintain project status
> > > information. Instead they usually maintain "Information Radiators" -
> > > whiteboards with Index cards stuck on them, for instance. They do
> > > often use wikis for longer-lasting documentation.
>
> > > Of course, if the team is geographically dispersed, it becomes more
> > > sensible to use simple software to maintain status information.
>
> > > It would be interesting to see how a small APL team got on with
> > > typical agile project management techniques. The focus in agile
> > > project management is the same as in development: doing things simply
> > > and doing only what gives value. This seems to fit well with the APL
> > > mindset.
>
> > > Romilly
>
> > I can see Agile and Apl work well together.
> > Both stimulate creative thought and want results.
> > A small Agile team does not need much documentation nor complicated
> > structure.
> > The best size of such a team is 3 to 8 people.
> > There is not much documentation involved and not much time for
> > meetings.
> > Short meetings every day and a lot of communications.
>
> > The people in the Agile team need to be of high quality and mostly
> > level 2 and 3.
> > If you get a small group working and the communication is working in
> > such a group it can make wonders.
> > If such a group could use APL too the productivity would go through
> > the roof.
>
> > You might think that you could use this technique for a group of one
> > but that could prove to be difficult.
> > Also the border between personnel type 3 and _1 could prove to be
> > paper thin.
> > While a singel person workng could be either 3 or _1 then the _1
> > person dould never operate for long with others.
>
> > I guess there are not that many percent of all people being of quality
> > 2 and 3 so it is important to give them the best tools available.
> > I think Agile and APL could be a very good mix.
>
> The great virtue of the agile approaches I've seen lies in the way
> they shorten communication and feedback paths in the development
> process.
>
> There is some contention about how scalable that is. I believe there
> is a consensus that the benefits fade with teams much larger than 20,
> though Jutta Eckstein makes a strong challenge to that in "Agile
> Development in the Large".
>
> I've asked at XP conference workshops about lower limits. How small
> can a team get before the costs of XP practices become comparable to
> their benefits? I've had several answers, all in the range 4-6.
>
> 4-6 is a largish APL project.
>
> That fits my experience with colleagues on a project at a large
> pension company. Our team size varied over time between 3 and 5. We
> tried out XP practices such as developing in 2-3 week bounds with user
> story cards. Some practices proved useful some of the time, but much
> of it seemed to get in our way. We eventually fell back into what I've
> heard an XP coach call "continuous flow". (He spoke of this as an
> ideal state, rarely attainable.)
>
> London boasts a weekly agile pub session, at the Extreme Tuesday Club.
> It's a lively place and a great evening if you like meeting people
> passionate about programming. Went down one evening with one of my
> colleagues from the pensions project. Someone talked about having
> worked on an agile project, hoping to be able to work on another one.
> Someone else was working on an XP project then, making production
> releases every 2-3 weeks, and excited about that. They asked us what
> our "involvement with agile" was. We'd just had a big push on, the
> team was up to six. We'd made 200 production releases in the previous
> two months.
>
> Of course, the comparison wasn't fair. Some of those changes had been
> worked out by the users with us at the keyboard, coded, tested and put
> into the system in under an hour. They hadn't been through rigorous
> test phases; but then the business had found it preferred light
> testing and quick fixes. No doubt some of those "production releases"
> reflected second thoughts on earlier ones. It didn't matter. The point
> is that our 'continuous flow' had shorter communication paths and
> tighter feedback loops than a model agile project, and was delivering
> user satisfaction like a train.
>
> I once told Kent Beck my first reaction to reading "Extreme
> Programming Explained: Embrace Change" was astonishment that Java
> projects could be made so nimble. He grinned wolfishly and said he
> would like one day to develop in Smalltalk again.
>
> The Agile Alliance has won general respect for iterative development.
> That respect is valuable to us; waterfall development drains away
> APL's value. But the various agile practices themselves, as codified,
> are of limited value to our tiny teams, and I would use Extreme
> Caution about adopting any of them unmodified.
>
> It seems to me our position is within the Agile Alliance, but distinct
> from its famous members: XP, Scrum, &c. Gitte Christensen has coined
> the phrase "Direct Development" to cover APL's development traditions.
> I like the term, and think it would be worth taking some trouble to
> elaborate what we mean by it. (Perhaps starting with a themed issue of
> Vector?)
>
> Stephen Taylor
> edi...@vector.org.uk
>
> http://www.vector.org.uk

The only real concern I have is that I have had different personnel
types working for me and _1 type can be very productive but are a pain
for the rest of the team if they are not contained.

So if you can have an agile team and making sure _1 personnel does not
ruin everything by making unpredictable code.
Soemtimes excellent but very often throwing in some untested stuff.

Unfortunately a _1 kind of person can do a lot of good stuff and be
quick in fixing things too and be considered some kind of hero because
of it.
In a bigger project they need to be controled.

That is why I would say that a lower limit of 3 should be the norm.
Even if you could leave personel type 3 alone to do things it is hard
to know the difference.

You may not need all the people in the group to do coding all the
time.
One or two may mostly just make sure things are tested and no
accidents get shipped.

_1 kind of people often start out and make great systems but the
systems most of the time outgrow their usefulness and they are the
kind of systems that become unmanageable when the _1 person leaves.