Lester Masher
2004-02-18 12:55:10 UTC
Hi Paul
My main concern with AM without PM comes with task commitment and the timing
thereof. When a developer is given free reign of his/her time they tend to
be overly agile with timely deliverables. So something that could have taken
a week could end up taking two weeks, because there is a sense of "what the
heck" its agile, we can change schedules without too much fuss. The
deliverable artifact is going to change anyway so why must it be delivered
this week. This attitude can then add "time wasted" creep into software
project schedules which are almost always already under estimated.
Lester.
-----Original Message-----
From: Paul Oldfield [mailto:***@compuserve.com]
Sent: Wednesday, February 18, 2004 2:35 PM
To: INTERNET:***@topica.com
Subject: [AM] AM and Project Mangement
(responding to Lester)
directly with Project Management aspects, it specialises
in Modelling. Similarly "Appropriate Process" specialises
in Process and practices, XP specialises in programming
with some strong overlap into analysis and design, weak
overlap into management (IMHO).
You might find Scrum interesting, it's an agile approach
centred around software development project management.
Consider investigating the online forums:
http://groups.yahoo.com/groups/scrumdevelopment
http://groups.yahoo.com/groups/agilemanagement
http://groups.yahoo.com/groups/agileprojectmanagement
However, all these groups seem to interpret their remit
rather broadly, and we do just occasionally touch on
management issues on this forum.
somebody may believe what it says. Beyond the
first few weeks, I wouldn't want to say very much about
what I expected to happen.
A common agile approach is to capture 'Implied
Requirements' - some sort of placeholder to say there
are more details to come on the topic. These are arranged
into a prioritised list (not too much detail on the priority of
low-priority requirements) and at least the higher priority
requirements have enough detail to allow estimates of effort
to be made. By ordering the requirements in order of
priority, and adding the effort estimates, you get a rough
idea of when each requirement will be worked on.
The advantage of this approach is that it's reasonably
flexible in case the customer adds new requirements or
changes priority on existing ones.
The XP practice "The Planning Game" goes into this in
detail, as does Scrum with its "Product Backlog".
For a starter on some of these topics, try following
links starting from
www.aptprocess.com/whitepapers/risk/RiskToPatternTable_files/FeatureCreep.h
tm
Paul Oldfield
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
www.aptprocess.com
any opinions expressed herein are not necessarily those of
Mentors of Cally or the Appropriate Process Movement
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com
For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org
EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com
TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------
My main concern with AM without PM comes with task commitment and the timing
thereof. When a developer is given free reign of his/her time they tend to
be overly agile with timely deliverables. So something that could have taken
a week could end up taking two weeks, because there is a sense of "what the
heck" its agile, we can change schedules without too much fuss. The
deliverable artifact is going to change anyway so why must it be delivered
this week. This attitude can then add "time wasted" creep into software
project schedules which are almost always already under estimated.
Lester.
-----Original Message-----
From: Paul Oldfield [mailto:***@compuserve.com]
Sent: Wednesday, February 18, 2004 2:35 PM
To: INTERNET:***@topica.com
Subject: [AM] AM and Project Mangement
(responding to Lester)
I have been through the entire AM web site and read every
single essay(twice). I am an ardent supporter and practioner
of AM methods. However no where is anytning mentioned
about Project Management principles an how its supported
by AM. e.g. what are the PM artifacts in AM and how are
tasks, resources, time schedules managed in an Agile
project.
Agile Modeling is not a full methodology, and does not dealsingle essay(twice). I am an ardent supporter and practioner
of AM methods. However no where is anytning mentioned
about Project Management principles an how its supported
by AM. e.g. what are the PM artifacts in AM and how are
tasks, resources, time schedules managed in an Agile
project.
directly with Project Management aspects, it specialises
in Modelling. Similarly "Appropriate Process" specialises
in Process and practices, XP specialises in programming
with some strong overlap into analysis and design, weak
overlap into management (IMHO).
You might find Scrum interesting, it's an agile approach
centred around software development project management.
Consider investigating the online forums:
http://groups.yahoo.com/groups/scrumdevelopment
http://groups.yahoo.com/groups/agilemanagement
http://groups.yahoo.com/groups/agileprojectmanagement
However, all these groups seem to interpret their remit
rather broadly, and we do just occasionally touch on
management issues on this forum.
I still find myself hauling out MS Project to get the project
scope documented and to report back to stakeholders on
project schedules. Do other Agile modelers find
themesleves in the same situation.
The trouble with using such a tool for planning is thatscope documented and to report back to stakeholders on
project schedules. Do other Agile modelers find
themesleves in the same situation.
somebody may believe what it says. Beyond the
first few weeks, I wouldn't want to say very much about
what I expected to happen.
A common agile approach is to capture 'Implied
Requirements' - some sort of placeholder to say there
are more details to come on the topic. These are arranged
into a prioritised list (not too much detail on the priority of
low-priority requirements) and at least the higher priority
requirements have enough detail to allow estimates of effort
to be made. By ordering the requirements in order of
priority, and adding the effort estimates, you get a rough
idea of when each requirement will be worked on.
The advantage of this approach is that it's reasonably
flexible in case the customer adds new requirements or
changes priority on existing ones.
The XP practice "The Planning Game" goes into this in
detail, as does Scrum with its "Product Backlog".
For a starter on some of these topics, try following
links starting from
www.aptprocess.com/whitepapers/risk/RiskToPatternTable_files/FeatureCreep.h
tm
Paul Oldfield
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
www.aptprocess.com
any opinions expressed herein are not necessarily those of
Mentors of Cally or the Appropriate Process Movement
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com
For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org
EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com
TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------