TURKU AGILE DAY WED-THU March 17th - 18th 2010 @ ICT-BUILDING, TURKU


Department of Information Technology, IT student clubs Digit and Asteriski, and
IT alumni organization 0-kerho from University of Turku proudly welcome You to
Turku Agile Day '010 Conference, the coolest software conference ever arranged
in Turku! The conference is held on March 17th - 18th 2010 at ICT-building,
Turku.

During the conference you will find out what is the hottest hot in the agile
software development world right now. The conference starts with hands-on
tutorials and workshops on Wednesday, while the pragmatic presentations on
Thursday reveal how the big players use agile methods and how You can adapt the
methods in Your own projects. There's something for both agile experts and agile
newcomers. The conference also provides an excellent networking opportunity by
means of a conference dinner.

Feedback from Turku Agile Day '09 (www.turkuagileday.fi/past/2009) suggested
that we should provide more hands-on sessions for the participants. Having this
valuable feedback, we decided to answer to the queries. On Wednesday we will
provide hands-on workshops 'for everyone' - from development practices
(continuous integration, test-driven development) to testing practices
(exploratory testing). If you wonder how to guide your development to get the
story done, Acceptance-Test-Driven Development workshop is meant for you. For
those interested in Lean SW development and prioritizing backlog items, the
'Gaming track' (Lean Manufacturing Game, Business Value Game) should provide the
most value.

Browse http://www.turkuagileday.fi and enroll now!


AGILE SW DEVELOPMENT IN A NUTSHELL

Agile SW development has been one of the top topics in SW industry lately. The
development methodology has raised from the realization that waterfall-like
project management methodologies do not reflect to the real world requirements
fast enough. Thus, one main concerns of agile sw development is to be adaptable
- any sw project should not fear change, since change is evitable in a SW
project. Agile aims to tackle the changing requirements by releasing early and
often and demonstrating the process to the customer. Getting feedback from the
customers is crucial for the project success.


PRELIMINARY PROGRAM

Wednesday, March 17th 2010, is a hands-on day with 8 workshop sessions. See
http://www.turkuagileday.fi/conference for the schedule

Thursday, March 18th 2010, is a full-day conference with 10 speakers from all
over the world.

See latest conference program from http://www.turkuagileday.fi/conference


KEYNOTE SPEAKERS

Elisabeth Hendrickson (http://www.qualitytree.com/company/elisabeth/,
http://testobsessed.com/)


PRICING AND ENROLLMENT

Go to register.turkuagileday.fi and enroll!

Pricing:
* Main event, Thu 18th: 100€
* Workshops, Wed 17th: 80€
* Early-bird discount, until January 8th 2010:
   * conference day: 10€
   * workshop day: 20€
* Member (member of Digit or Asteriski) discount for the main event: 20€
* Student fee for conference: 5€

All fee's are VAT exempt.
Enrollment closes 14 days before the event.


REFUND AND CANCELLATION POLICY

Full refund, no cancellation fee before December 31st, 2009
Full refund, 50€ cancellation fee after December 31st, 2009
No refund after March 1st, 2010

Br,
Tomi Juhola




[Non-text portions of this message have been removed]

You might want to take a look at https://www. ibm.com/develope rworks/mydevelop
erworks/blogs/ ambler/entry/ agile_scaling_ model for some ideas.  The detailed
whitepaper will be out in the next week or so, and in Q1 I'll have a detailed
paper on tailoring practices to address scaling situations.

- Scott Scott W. Ambler
Chief Methodologist/Agile, IBM Rational
Agile at Scale blog: http://www.ibm.com/developerworks/blogs/page/ambler
Follow me on Twitter: http://twitter.com/scottwambler



----- Original Message ----
From: Essam Badawi <Essam_Badawi@...>
To: agilemodeling@yahoogroups.com
Sent: Mon, November 30, 2009 12:58:13 AM
Subject: [AM] FW: Beyond Agile/Lean ..

I'm not sure if this does make sense or not, but I'm thinking of some
sort of a process with extreme flexibility.  It's not just about having
a minimum process. It's not just about having a light process. I'm not
sure if it goes under agile or lean. I'm not sure even if it can be
called a process at first place :-)  But it can be called a methodology,
after all!



It's about having:

*        good teams (virtual, pool, ..), 

*        constructed from good people,

*        who are trained on  agile/lean principles and  techniques,

*        guided to freely select from a verity of adapted practices,

*        applying incremental/iterative approaches,

*        working in a collaborative environment

*        based on the different situations (projects, contracts,
customers, ..) they deal with,

*        and supported by a value-driven  (kaizen!) management.



Maybe the closest concept to this is Alistair's concept behind crystal
methodology.



I'm writing this because I have notice a degree of burden on many of the
applied processes  (even if it's  adopting from agile/lean) and that's
in different places where the appliers tend to freeze  their process,
you know (maybe there is a better word, but I think you are getting the
point of writing the process, giving all details, and asking people to
follow as it, ..),  the thing that leads to have some sort of "a
rigid(!) , or a fixed!,  of agile process" of this makes sense :-)



So, it's about having a static(!) process vs. dynamic(!) process. Maybe
I'm wrong in this as we might still need of a more of disciplined
process rather than  ad-hoc.



If we might have different opinions in this, I would go with the more
'living' process.

Maybe the title of this mail is incorrect, as this concept is not
'beyond' agile/lean principles, matte of fact, it is in the heart of it,
but just to not forget it when we build our processes.



What do you think?



Thank you,

Abd El'Latif



Disclaimer: NOTICE The information contained in this message is confidential and
is intended for the addressee(s) only. If you have received this message in
error or there are any problems please notify the originator immediately. The
unauthorized use, disclosure, copying or alteration of this message is strictly
forbidden. Raya will not be liable for direct, special, indirect or
consequential damages arising from alteration of the contents of this message by
a third party or as a result of any malicious code or virus being passed on.
Views expressed in this communication are not necessarily those of Raya.If you
have received this message in error, please notify the sender immediately by
email, facsimile or telephone and return and/or destroy the original message.


[Non-text portions of this message have been removed]



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




       __________________________________________________________________
Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your
favourite sites. Download it now
http://ca.toolbar.yahoo.com.

Agile was supposed to mean exactly what you espouse here.  I am not sure
when Agile started deviating from your vision, but it has in practice.

Any new public-domain name that might be use to label this vision would
inevitably follow one of two possible life cycles:
1. Become successful enough to be coopted to mean something much more
prescriptive and limiting.
2. Never attain enough success as a name for anybody to notice.

You could go to the trouble of creating a proprietary brand name to retain
control of what it means, but is expensive and time consuming to establish
and defend a brand name.  It only makes sense if you intend to make
sufficient money off of it.

My advice is to continue to follow and espouse your vision, but do not worry
about naming it or about contrasting it with Lean, Agile, Scrum, XP, etc.


On Sun, Nov 29, 2009 at 10:58 PM, Essam Badawi <Essam_Badawi@...>wrote:

>
>
> I'm not sure if this does make sense or not, but I'm thinking of some
> sort of a process with extreme flexibility. It's not just about having
> a minimum process. It's not just about having a light process. I'm not
> sure if it goes under agile or lean. I'm not sure even if it can be
> called a process at first place :-) But it can be called a methodology,
> after all!
>
> It's about having:
>
> * good teams (virtual, pool, ..),
>
> * constructed from good people,
>
> * who are trained on agile/lean principles and techniques,
>
> * guided to freely select from a verity of adapted practices,
>
> * applying incremental/iterative approaches,
>
> * working in a collaborative environment
>
> * based on the different situations (projects, contracts,
> customers, ..) they deal with,
>
> * and supported by a value-driven (kaizen!) management.
>
> Maybe the closest concept to this is Alistair's concept behind crystal
> methodology.
>
> I'm writing this because I have notice a degree of burden on many of the
> applied processes (even if it's adopting from agile/lean) and that's
> in different places where the appliers tend to freeze their process,
> you know (maybe there is a better word, but I think you are getting the
> point of writing the process, giving all details, and asking people to
> follow as it, ..), the thing that leads to have some sort of "a
> rigid(!) , or a fixed!, of agile process" of this makes sense :-)
>
> So, it's about having a static(!) process vs. dynamic(!) process. Maybe
> I'm wrong in this as we might still need of a more of disciplined
> process rather than ad-hoc.
>
> If we might have different opinions in this, I would go with the more
> 'living' process.
>
> Maybe the title of this mail is incorrect, as this concept is not
> 'beyond' agile/lean principles, matte of fact, it is in the heart of it,
> but just to not forget it when we build our processes.
>
> What do you think?
>
> Thank you,
>
> Abd El'Latif
>
> Disclaimer: NOTICE The information contained in this message is
> confidential and is intended for the addressee(s) only. If you have received
> this message in error or there are any problems please notify the originator
> immediately. The unauthorized use, disclosure, copying or alteration of this
> message is strictly forbidden. Raya will not be liable for direct, special,
> indirect or consequential damages arising from alteration of the contents of
> this message by a third party or as a result of any malicious code or virus
> being passed on. Views expressed in this communication are not necessarily
> those of Raya.If you have received this message in error, please notify the
> sender immediately by email, facsimile or telephone and return and/or
> destroy the original message.
>
> [Non-text portions of this message have been removed]
>
>
>


[Non-text portions of this message have been removed]

your bullets are all near and dear to my heart -- and reflect my
practices over the past 10-15 years

jon
blog: http://technicaldebt.wetpaint.com
twitter: http://twitter.com/JonKernPA



Essam Badawi said the following on 11/30/09 12:58 AM:
>
> I'm not sure if this does make sense or not, but I'm thinking of some
> sort of a process with extreme flexibility. It's not just about having
> a minimum process. It's not just about having a light process. I'm not
> sure if it goes under agile or lean. I'm not sure even if it can be
> called a process at first place :-) But it can be called a methodology,
> after all!
>
> It's about having:
>
> * good teams (virtual, pool, ..),
>
> * constructed from good people,
>
> * who are trained on agile/lean principles and techniques,
>
> * guided to freely select from a verity of adapted practices,
>
> * applying incremental/iterative approaches,
>
> * working in a collaborative environment
>
> * based on the different situations (projects, contracts,
> customers, ..) they deal with,
>
> * and supported by a value-driven (kaizen!) management.
>
> Maybe the closest concept to this is Alistair's concept behind crystal
> methodology.
>
> I'm writing this because I have notice a degree of burden on many of the
> applied processes (even if it's adopting from agile/lean) and that's
> in different places where the appliers tend to freeze their process,
> you know (maybe there is a better word, but I think you are getting the
> point of writing the process, giving all details, and asking people to
> follow as it, ..), the thing that leads to have some sort of "a
> rigid(!) , or a fixed!, of agile process" of this makes sense :-)
>
> So, it's about having a static(!) process vs. dynamic(!) process. Maybe
> I'm wrong in this as we might still need of a more of disciplined
> process rather than ad-hoc.
>
> If we might have different opinions in this, I would go with the more
> 'living' process.
>
> Maybe the title of this mail is incorrect, as this concept is not
> 'beyond' agile/lean principles, matte of fact, it is in the heart of it,
> but just to not forget it when we build our processes.
>
> What do you think?
>
> Thank you,
>
> Abd El'Latif
>
> Disclaimer: NOTICE The information contained in this message is
> confidential and is intended for the addressee(s) only. If you have
> received this message in error or there are any problems please notify
> the originator immediately. The unauthorized use, disclosure, copying
> or alteration of this message is strictly forbidden. Raya will not be
> liable for direct, special, indirect or consequential damages arising
> from alteration of the contents of this message by a third party or as
> a result of any malicious code or virus being passed on. Views
> expressed in this communication are not necessarily those of Raya.If
> you have received this message in error, please notify the sender
> immediately by email, facsimile or telephone and return and/or destroy
> the original message.
>
> [Non-text portions of this message have been removed]
>
>

> I'm writing this because I have notice a degree of burden on many
> of the
> applied processes (even if it's adopting from agile/lean) and that's
> in different places where the appliers tend to freeze their process,
> you know (maybe there is a better word, but I think you are getting
> the
> point of writing the process, giving all details, and asking people to
> follow as it, ..), the thing that leads to have some sort of "a
> rigid(!) , or a fixed!, of agile process" of this makes sense :-)


no, we do not know... so why not tell us...


On Nov 30, 2009, at 12:58 AM, Essam Badawi wrote:

I'm not sure if this does make sense or not, but I'm thinking of some
sort of a process with extreme flexibility. It's not just about having
a minimum process. It's not just about having a light process. I'm not
sure if it goes under agile or lean. I'm not sure even if it can be
called a process at first place :-) But it can be called a methodology,
after all!

It's about having:

* good teams (virtual, pool, ..),

* constructed from good people,

* who are trained on agile/lean principles and techniques,

* guided to freely select from a verity of adapted practices,

* applying incremental/iterative approaches,

* working in a collaborative environment

* based on the different situations (projects, contracts,
customers, ..) they deal with,

* and supported by a value-driven (kaizen!) management.

Maybe the closest concept to this is Alistair's concept behind crystal
methodology.

I'm writing this because I have notice a degree of burden on many of the
applied processes (even if it's adopting from agile/lean) and that's
in different places where the appliers tend to freeze their process,
you know (maybe there is a better word, but I think you are getting the
point of writing the process, giving all details, and asking people to
follow as it, ..), the thing that leads to have some sort of "a
rigid(!) , or a fixed!, of agile process" of this makes sense :-)

So, it's about having a static(!) process vs. dynamic(!) process. Maybe
I'm wrong in this as we might still need of a more of disciplined
process rather than ad-hoc.

If we might have different opinions in this, I would go with the more
'living' process.

Maybe the title of this mail is incorrect, as this concept is not
'beyond' agile/lean principles, matte of fact, it is in the heart of it,
but just to not forget it when we build our processes.

What do you think?

Thank you,

Abd El'Latif

Disclaimer: NOTICE The information contained in this message is
confidential and is intended for the addressee(s) only. If you have
received this message in error or there are any problems please
notify the originator immediately. The unauthorized use, disclosure,
copying or alteration of this message is strictly forbidden. Raya
will not be liable for direct, special, indirect or consequential
damages arising from alteration of the contents of this message by a
third party or as a result of any malicious code or virus being
passed on. Views expressed in this communication are not necessarily
those of Raya.If you have received this message in error, please
notify the sender immediately by email, facsimile or telephone and
return and/or destroy the original message.

[Non-text portions of this message have been removed]





[Non-text portions of this message have been removed]

I'm not sure if this does make sense or not, but I'm thinking of some
sort of a process with extreme flexibility.  It's not just about having
a minimum process. It's not just about having a light process. I'm not
sure if it goes under agile or lean. I'm not sure even if it can be
called a process at first place :-)  But it can be called a methodology,
after all!



It's about having:

*         good teams (virtual, pool, ..),

*         constructed from good people,

*         who are trained on  agile/lean principles and  techniques,

*         guided to freely select from a verity of adapted practices,

*         applying incremental/iterative approaches,

*         working in a collaborative environment

*         based on the different situations (projects, contracts,
customers, ..) they deal with,

*         and supported by a value-driven  (kaizen!) management.



Maybe the closest concept to this is Alistair's concept behind crystal
methodology.



I'm writing this because I have notice a degree of burden on many of the
applied processes  (even if it's  adopting from agile/lean) and that's
in different places where the appliers tend to freeze  their process,
you know (maybe there is a better word, but I think you are getting the
point of writing the process, giving all details, and asking people to
follow as it, ..),  the thing that leads to have some sort of "a
rigid(!) , or a fixed!,  of agile process" of this makes sense :-)



So, it's about having a static(!) process vs. dynamic(!) process. Maybe
I'm wrong in this as we might still need of a more of disciplined
process rather than  ad-hoc.



If we might have different opinions in this, I would go with the more
'living' process.

Maybe the title of this mail is incorrect, as this concept is not
'beyond' agile/lean principles, matte of fact, it is in the heart of it,
but just to not forget it when we build our processes.



What do you think?



Thank you,

Abd El'Latif



Disclaimer: NOTICE The information contained in this message is confidential and
is intended for the addressee(s) only. If you have received this message in
error or there are any problems please notify the originator immediately. The
unauthorized use, disclosure, copying or alteration of this message is strictly
forbidden. Raya will not be liable for direct, special, indirect or
consequential damages arising from alteration of the contents of this message by
a third party or as a result of any malicious code or virus being passed on.
Views expressed in this communication are not necessarily those of Raya.If you
have received this message in error, please notify the sender immediately by
email, facsimile or telephone and return and/or destroy the original message.


[Non-text portions of this message have been removed]

--- In agilemodeling@yahoogroups.com, Jon Kern <jonkern@...> wrote:
I had collected some of my recent UML toolage
> experiences here: http://technicaldebt.wetpaint.com/page/UML+Tools

   I would like a simple tool that is fairly quick to bring up and draw a diagram
like Visio but that can also export as XMI for other tools like Eclipsed based
tools if needed.

   [ of course most XMI implementations have serious issues ]

Thanks, Ol' Buddy ( Old = 10 years since we first met up on that network
switch software modeling gig).
I have put a bit more of a rant/dump on the topic at
http://step-10.blogspot.com/

Steve

--
Stephen R Palmer
www.step-10.com

Jon Kern wrote:
> Steve, Ol' Buddy, I had collected some of my recent UML toolage
> experiences here: http://technicaldebt.wetpaint.com/page/UML+Tools
>
> jon
> blog: http://technicaldebt.wetpaint.com
> twitter: http://twitter.com/JonKernPA
>
>
>
> Jaros³aw ¯eliñski [ Analityk kontraktowy | http://it-consulting.pl ]
> said the following on 11/10/09 9:27 AM:
>
>> Stephen R Palmer <stephen.palmer@...> napisa³(a):
>>
>>
>>> Yes, EA is definitely one of the better products out there and can't
>>> argue with the value for money of the low-end editions.
>>> Unless I am missing something, I do find manipulating attributes and
>>> operations on class diagrams clunky in EA compared with Together. When
>>> working initially with ideas in a class diagram together, I like being
>>> able to drag and drop attributes/operations from one class to another,
>>> and also select multiple attributes/operations and change the value of
>>> any property they have in common in one action.
>>>
>>>
>> It is good features, I have this in  my VP-UML
>>
>>
>>
>>
>>
>>
>>
>
>
> ------------------------------------
>
>
>
>
>

Steve, Ol' Buddy, I had collected some of my recent UML toolage
experiences here: http://technicaldebt.wetpaint.com/page/UML+Tools

jon
blog: http://technicaldebt.wetpaint.com
twitter: http://twitter.com/JonKernPA



Jaros³aw ¯eliñski [ Analityk kontraktowy | http://it-consulting.pl ]
said the following on 11/10/09 9:27 AM:
> Stephen R Palmer <stephen.palmer@...> napisa³(a):
>
>> Yes, EA is definitely one of the better products out there and can't
>> argue with the value for money of the low-end editions.
>> Unless I am missing something, I do find manipulating attributes and
>> operations on class diagrams clunky in EA compared with Together. When
>> working initially with ideas in a class diagram together, I like being
>> able to drag and drop attributes/operations from one class to another,
>> and also select multiple attributes/operations and change the value of
>> any property they have in common in one action.
>>
>
> It is good features, I have this in  my VP-UML
>
>
>
>
>
>

SETP-10 Call for papers
 
The 2010 International Conference on Software Engineering Theory and Practice
(SETP-10) (website: http://www.PromoteResearch.org) will be held during 12-14 of
July 2010 in Orlando, FL, USA.  SETP is an important event in the areas of
Software development, maintenance, and other areas of software engineering and
related topics.
 
The conference will be held at the same time and location where several other
major international conferences will be taking place. The conference will be
held as part of 2010 multi-conference (MULTICONF-10). MULTICONF-10 will be held
during July 12-14, 2010 in Orlando, Florida, USA. The primary goal of MULTICONF
is to promote research and developmental activities in computer science,
information technology, control engineering, and related fields. Another goal is
to promote the dissemination of research to a multidisciplinary audience and to
facilitate communication among researchers, developers, practitioners in
different fields. The following conferences are planned to be organized as part
of MULTICONF-10.
 

International Conference on Artificial Intelligence and Pattern Recognition
(AIPR-10)
 International Conference on Automation, Robotics and Control Systems (ARCS-10)
International Conference on Bioinformatics, Computational Biology, Genomics and
Chemoinformatics (BCBGC-10)
International Conference on Computer Networks (CN-10)
International Conference on Enterprise Information Systems and Web Technologies
(EISWT-10)
International Conference on High Performance Computing Systems (HPCS-10)
International Conference on Information Security and Privacy (ISP-10)
International Conference on Image and Video Processing and Computer Vision
(IVPCV-10)
International Conference on Software Engineering Theory and Practice (SETP-10)
International Conference on Theoretical and Mathematical Foundations of Computer
Science (TMFCS-10)
 
We invite draft paper submissions. Please see the website
http://www.PromoteResearch.org for more details.
 
Sincerely
John Edward
Publicity committee




[Non-text portions of this message have been removed]

Stephen R Palmer <stephen.palmer@...> napisa³(a):
> Yes, EA is definitely one of the better products out there and can't
> argue with the value for money of the low-end editions.
> Unless I am missing something, I do find manipulating attributes and
> operations on class diagrams clunky in EA compared with Together. When
> working initially with ideas in a class diagram together, I like being
> able to drag and drop attributes/operations from one class to another,
> and also select multiple attributes/operations and change the value of
> any property they have in common in one action.

It is good features, I have this in  my VP-UML





--
Jaros³aw ¯eliñski - kontraktowy analityk biznesowy i systemowy
http://wspolpraca.IT-Consulting.pl/ j.zelinski@it-consulting tel.: o-6o8 o5 9o
2o

Hi,

My experience is that tools work fine, when driven by someone who can use them
at a speed comparable to drawing on a whiteboard.

We have used a simple (and very fast) MSC tool, simple drawing tools, and wiki
pages to do modeling collaboration online. It's really important that the tools
be lithe and the tool operators be very comfortable with them. My recent
experience is all with cross-site teams, so we've been collaborating with
NetMeeting or Adobe Connect, which gives everyone equal access to the drawn
images. The bigger problem is audio, which usually doesn't work very well if
some participants are collocated (sharing a microphone) and others online.

I would rather be in a room with all the participants, but even if in the same
room I strongly prefer using a tool for creating an MSC of any significant size,
especially if you're at a stage where you're making changes to the diagram.
Hand-drawn MSCs are just painful to draw (all those long, straight lines and
little labels) and even more painful to change manually - the ability to easily
move sequences around is crucial.

scott



>
>From: Stephen R Palmer <stephen.palmer@...>
>To: agilemodeling@yahoogroups.com
>Sent: Tue, November 10, 2009 6:45:34 AM
>Subject: Re: [AM] UML Modeling tools
>
>  >
>>
>
>Yep - post-it notes and flipcharts/white- boards are my tool of choice
>>for collaborative session. Just like Scrum-style iteration planning
>>sessions, the minute you start using a computer directly in these
>>sessions, the energy and creativity takes a nose-dive.
>>For larger projects where I cannot carry the whole model in my head and
>>do not want to have to keep re-sketching it every time I need to talk
>>through some aspect of it with someone, I want it recorded somewhere -
>>possibly on a big wall if its a class model but I soon run out of wall
>>space if I'm sketching out an involved collaborations in sequence
>>diagrams. In the past, I have kept sketches of sequence diagrams made on
>>paper in card folders with other bits and pieces of info for the
>>features/user stories/use cases my team is implementing in the next
>>iteration.
>>... but  I have also been known to enter sequence diagrams into Together
>>by writing the skeleton code for the sequence and reverse engineering
>>the diagram ... and I always loved the way I could seamlessly switch
>>between entering code via a class diagram or via a programmers editor in
>>Together. I have just not had that level of immersion using tools like
>>RSA, Visio, or Enterprise Architect but maybe I've not worked long
>>enough with those tools within an IDE.
>
>>Steve
>
>>GW wrote:
>>> I too prefer fluid tools and mediums...
>>>
>>> I found that post-it notes, a moleskine notebook(engineerin g ruled),
>>> a zebra F-301, bar napkins w/ a scotch ring, a white board and a
>>> scanner really do work wonders to capture an idea instantly.
>>>
>>> I found that OmniGraffle is far more superior to Visio, and only use
>>> it when needed, however I have found that after capturing the idea by
>>> my preferred tools/mediums then coding straight away is always a
>>> better transition from concept/design into development.
>>>
>>> Which reminds me of my professors, who often squabbled about
>>> Development practices... Is it better to write it all out on paper
>>> then go to the computer? Or Is it better to just hop right on to the
>>> computer and just start coding away? - either is fine by itself, but
>>> an equilibrium between the 2 is always better. ;->
>>>
>>>
>>>
>>> On Nov 9, 2009, at 8:03 PM, John Hebley wrote:
>>>
>>> I prefer tools that do not enforce a process/methodology on me, or
>>> dictate a
>>> non-standard approach. Tools that obey UML are OK, but I'd prefer
>>> that they
>>> also let me do my own thing occasionally. A #2 pencil, preferably
>>> with an
>>> eraser on the other end, seems to be the only tool that totally meets my
>>> requirements. Visio is a high technology version at a much higher
>>> price tag.
>>>
>>> John
>>>
>>> _____
>>>
>>> From: agilemodeling@ yahoogroups. com
>>> [mailto:agilemodeling@ yahoogroups. com]
>>> On Behalf Of Stephen
>>> Sent: Monday, November 09, 2009 3:00 AM
>>> To: agilemodeling@ yahoogroups. com
>>> Subject: [AM] UML Modeling tools
>>>
>>> Having left Micro Focus last month, means I have left behind the
>>> Together
>>> modeling tool too. While I wait for whatever is next, I have started
>>> to look
>>> seriously at other modeling products for the first time in ages. As a
>>> result, I was wondering what folk expect from a software modeling
>>> tool these
>>> days. What do folk love and hate about the products out there, what
>>> do these
>>> tools do well, badly, what should they do, etc?
>>>
>>> _____
>>>
>>> avast! Antivirus <http://www.avast. com> : Outbound message clean.
>>>
>>> Virus Database (VPS): 091109-1, 11/09/2009
>>> Tested on: 11/9/2009 7:03:53 PM
>>> avast! - copyright (c) 1988-2009 ALWIL Software.
>>>
>>> [Non-text portions of this message have been removed]
>>>
>>>
>>>
>>>
>>>
>>> [Non-text portions of this message have been removed]
>>>
>>>
>>>
>>> ------------ --------- --------- ------
>>>
>>>
>>>
>>>
>>>
>
>
>

[Non-text portions of this message have been removed]

Yep - post-it notes and flipcharts/white-boards are my tool of choice
for collaborative session. Just like Scrum-style iteration planning
sessions, the minute you start using a computer directly in these
sessions, the energy and creativity takes a nose-dive.
For larger projects where I cannot carry the whole model in my head and
do not want to have to keep re-sketching it every time I need to talk
through some aspect of it with someone, I want it recorded somewhere -
possibly on a big wall if its a class model but I soon run out of wall
space if I'm sketching out an involved collaborations in sequence
diagrams. In the past, I have kept sketches of sequence diagrams made on
paper in card folders with other bits and pieces of info for the
features/user stories/use cases my team is implementing in the next
iteration.
... but  I have also been known to enter sequence diagrams into Together
by writing the skeleton code for the sequence and reverse engineering
the diagram ... and I always loved the way I could seamlessly switch
between entering code via a class diagram or via a programmers editor in
Together. I have just not had that level of immersion using tools like
RSA, Visio, or Enterprise Architect but maybe I've not worked long
enough with those tools within an IDE.

Steve


GW wrote:
> I too prefer fluid tools and mediums...
>
> I found that post-it notes, a moleskine notebook(engineering ruled),
> a zebra F-301, bar napkins w/ a scotch ring, a white board and a
> scanner really do work wonders to capture an idea instantly.
>
> I found that OmniGraffle is far more superior to Visio, and only use
> it when needed, however I have found that after capturing the idea by
> my preferred tools/mediums then coding straight away is always a
> better transition from concept/design into development.
>
> Which reminds me of my professors, who often squabbled about
> Development practices... Is it better to write it all out on paper
> then go to the computer? Or Is it better to just hop right on to the
> computer and just start coding away? - either is fine by itself, but
> an equilibrium between the 2 is always better. ;->
>
>
>
> On Nov 9, 2009, at 8:03 PM, John Hebley wrote:
>
> I prefer tools that do not enforce a process/methodology on me, or
> dictate a
> non-standard approach. Tools that obey UML are OK, but I'd prefer
> that they
> also let me do my own thing occasionally. A #2 pencil, preferably
> with an
> eraser on the other end, seems to be the only tool that totally meets my
> requirements. Visio is a high technology version at a much higher
> price tag.
>
> John
>
> _____
>
> From: agilemodeling@yahoogroups.com
> [mailto:agilemodeling@yahoogroups.com]
> On Behalf Of Stephen
> Sent: Monday, November 09, 2009 3:00 AM
> To: agilemodeling@yahoogroups.com
> Subject: [AM] UML Modeling tools
>
> Having left Micro Focus last month, means I have left behind the
> Together
> modeling tool too. While I wait for whatever is next, I have started
> to look
> seriously at other modeling products for the first time in ages. As a
> result, I was wondering what folk expect from a software modeling
> tool these
> days. What do folk love and hate about the products out there, what
> do these
> tools do well, badly, what should they do, etc?
>
> _____
>
> avast! Antivirus <http://www.avast.com> : Outbound message clean.
>
> Virus Database (VPS): 091109-1, 11/09/2009
> Tested on: 11/9/2009 7:03:53 PM
> avast! - copyright (c) 1988-2009 ALWIL Software.
>
> [Non-text portions of this message have been removed]
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
>
>
>
>

I too prefer fluid tools and mediums...

I found that post-it notes, a moleskine notebook(engineering ruled),
a zebra F-301, bar napkins w/ a scotch ring, a white board and a
scanner really do work wonders to capture an idea instantly.

I found that OmniGraffle is far more superior to Visio, and only use
it when needed, however I have found that after capturing the idea by
my preferred tools/mediums then coding straight away is always a
better transition from concept/design into development.

Which reminds me of my professors, who often squabbled about
Development practices... Is it better to write it all out on paper
then go to the computer? Or Is it better to just hop right on to the
computer and just start coding away? - either is fine by itself, but
an equilibrium between the 2 is always better. ;->



On Nov 9, 2009, at 8:03 PM, John Hebley wrote:

I prefer tools that do not enforce a process/methodology on me, or
dictate a
non-standard approach. Tools that obey UML are OK, but I'd prefer
that they
also let me do my own thing occasionally. A #2 pencil, preferably
with an
eraser on the other end, seems to be the only tool that totally meets my
requirements. Visio is a high technology version at a much higher
price tag.

John

_____

From: agilemodeling@yahoogroups.com
[mailto:agilemodeling@yahoogroups.com]
On Behalf Of Stephen
Sent: Monday, November 09, 2009 3:00 AM
To: agilemodeling@yahoogroups.com
Subject: [AM] UML Modeling tools

Having left Micro Focus last month, means I have left behind the
Together
modeling tool too. While I wait for whatever is next, I have started
to look
seriously at other modeling products for the first time in ages. As a
result, I was wondering what folk expect from a software modeling
tool these
days. What do folk love and hate about the products out there, what
do these
tools do well, badly, what should they do, etc?

_____

avast! Antivirus <http://www.avast.com> : Outbound message clean.

Virus Database (VPS): 091109-1, 11/09/2009
Tested on: 11/9/2009 7:03:53 PM
avast! - copyright (c) 1988-2009 ALWIL Software.

[Non-text portions of this message have been removed]





[Non-text portions of this message have been removed]

(responding to Mike)

> Such a heart rendering story as this has not passed my ears
> in many a year. Be brave and remember that others, like my
> great uncle, also lived in dire conditions where they drowned
> in a mixing tank at the distiller. To my great uncle's credit
> he put 6 men and 3 boys in hospital for repeatedly pulling
> him out. But alas before they could try for the 7th, his
> hand slipped below the surface, ordering 1 more round for all!
> 8-)

I don't wonder you describe your uncle as "great".
I'm sure it will be taken in the right spirit if I offer my
condolences that he went without you.   ;-)

Paul Oldfield

Yes, EA is definitely one of the better products out there and can't
argue with the value for money of the low-end editions.
Unless I am missing something, I do find manipulating attributes and
operations on class diagrams clunky in EA compared with Together. When
working initially with ideas in a class diagram together, I like being
able to drag and drop attributes/operations from one class to another,
and also select multiple attributes/operations and change the value of
any property they have in common in one action.

best

--
Stephen R Palmer
www.step-10.com

drc@... wrote:
>
>
> Check out Enterprise Architect from Sparx Systems. You can set various
> levels of UML "enforcement" including none.
>
> I've used EA for many years and think it's a great agile modeling tool and
> a fabulous value. YMMV.
>
> Cheers,
>
> -- David Chilcott
> Outformations, Inc.
>
> Keep Breathing. Tell the Truth. Be Fearless. Choose Love. Embrace the
> Mystery.
> ----------------------------------------------------------
> Email: drc@... <mailto:drc%40outformations.com>
> Voice: 510.655.7122
> Skype: DavidChilcott
> Twitter: DavidChilcott
> Facebook: www.facebook.com/DavidRChilcott
> LinkedIn: www.linkedin.com/in/DavidChilcott
> ----------------------------------------------------------
>
> Ask me about the Outformations Agile Enterprise JumpStart
> http://bit.ly/AgileJumpStart <http://bit.ly/AgileJumpStart>
> ----------------------------------------------------------
>
> "John Hebley"
> <jhebley@airmail.
> net> To
> Sent by: <agilemodeling@yahoogroups.com
> <mailto:agilemodeling%40yahoogroups.com>>
> agilemodeling@yah cc
> oogroups.com
> Subject
> RE: [AM] UML Modeling tools
> 11/09/2009 05:08
> PM
>
>
> Please respond to
> agilemodeling@yah
> oogroups.com
>
>
>
> I prefer tools that do not enforce a process/methodology on me, or dictate
> a
> non-standard approach. Tools that obey UML are OK, but I'd prefer that
> they
> also let me do my own thing occasionally. A #2 pencil, preferably with an
> eraser on the other end, seems to be the only tool that totally meets my
> requirements. Visio is a high technology version at a much higher price
> tag.
>
> John
>
> _____
>
> From: agilemodeling@yahoogroups.com
> <mailto:agilemodeling%40yahoogroups.com>
> [mailto:agilemodeling@yahoogroups.com
> <mailto:agilemodeling%40yahoogroups.com>]
> On Behalf Of Stephen
> Sent: Monday, November 09, 2009 3:00 AM
> To: agilemodeling@yahoogroups.com <mailto:agilemodeling%40yahoogroups.com>
> Subject: [AM] UML Modeling tools
>
> Having left Micro Focus last month, means I have left behind the Together
> modeling tool too. While I wait for whatever is next, I have started to
> look
> seriously at other modeling products for the first time in ages. As a
> result, I was wondering what folk expect from a software modeling tool
> these
> days. What do folk love and hate about the products out there, what do
> these
> tools do well, badly, what should they do, etc?
>
> _____
>
> avast! Antivirus <http://www.avast.com <http://www.avast.com>> :
> Outbound message clean.
>
> Virus Database (VPS): 091109-1, 11/09/2009
> Tested on: 11/9/2009 7:03:53 PM
> avast! - copyright (c) 1988-2009 ALWIL Software.
>
> [Non-text portions of this message have been removed]
>
> ------------------------------------
>
>



[Non-text portions of this message have been removed]

(responding to Joan on the path to Enlightenment)

>   In particular I want to know more about "user stories"
> – the name alone appeals to me – and see how it differs
> from what I'm familiar with.

The important points?

User Stories aren't requirements.  They start as a placeholder
for a requirement, with just enough information to:
- Know what you're going to talk about when it's time;
- Know who to talk to when it's time;
- Get a very rough idea of how big a job it will be;
- Prioritize so you get a rough idea of when its time will come.

That's what Ron (Jeffries) calls the "Card" - many more nuances
here but let's consider the clean concept.

Then there's the "Conversation"; during iteration planning we get
just enough information to get a better idea of size so we can
decide whether or not we can fit it with all the other work
in this iteration, then during the iteration, the actual
requirements are elicited in conversation with the developer.

Then there's the "Confirmation" - in effect Acceptance Tests,
often the only 'persistent' part of the requirement other
than the code itself.

So, there's a very short, simple, and just near enough correct
to be useful explanation of User Stories.  Mike Cohn has a
couple of great books if you want in-depth information; his
"Agile Estimating and Planning" seems to be the book I recommend
most often of ALL books.  His "User Stories Applied" is squarely
on topic.

Paul Oldfield
Capgemini

Check out Enterprise Architect from Sparx Systems.   You can set various
levels of UML "enforcement" including none.

I've used EA for many years and think it's a great agile modeling tool and
a fabulous value.  YMMV.

Cheers,

-- David Chilcott
Outformations, Inc.

Keep Breathing.  Tell the Truth.  Be Fearless.  Choose Love.   Embrace the
Mystery.
---------------------------------------------------------------------------
Email: drc@...
Voice: 510.655.7122
Skype: DavidChilcott
Twitter: DavidChilcott
Facebook: www.facebook.com/DavidRChilcott
LinkedIn: www.linkedin.com/in/DavidChilcott
----------------------------------------------------------------------------

Ask me about the Outformations Agile Enterprise JumpStart
http://bit.ly/AgileJumpStart
----------------------------------------------------------------------------









              "John Hebley"
              <jhebley@airmail.
              net>                                                       To
              Sent by:                  <agilemodeling@yahoogroups.com>
              agilemodeling@yah                                          cc
              oogroups.com
                                                                    Subject
                                        RE: [AM] UML Modeling tools
              11/09/2009 05:08
              PM


              Please respond to
              agilemodeling@yah
                oogroups.com






I prefer tools that do not enforce a process/methodology on me, or dictate
a
non-standard approach. Tools that obey UML are OK, but I'd prefer that they
also let me do my own thing occasionally. A #2 pencil, preferably with an
eraser on the other end, seems to be the only tool that totally meets my
requirements. Visio is a high technology version at a much higher price
tag.

John

   _____

From: agilemodeling@yahoogroups.com [mailto:agilemodeling@yahoogroups.com]
On Behalf Of Stephen
Sent: Monday, November 09, 2009 3:00 AM
To: agilemodeling@yahoogroups.com
Subject: [AM] UML Modeling tools




Having left Micro Focus last month, means I have left behind the Together
modeling tool too. While I wait for whatever is next, I have started to
look
seriously at other modeling products for the first time in ages. As a
result, I was wondering what folk expect from a software modeling tool
these
days. What do folk love and hate about the products out there, what do
these
tools do well, badly, what should they do, etc?






   _____


avast! Antivirus <http://www.avast.com> : Outbound message clean.


Virus Database (VPS): 091109-1, 11/09/2009
Tested on: 11/9/2009 7:03:53 PM
avast! - copyright (c) 1988-2009 ALWIL Software.




[Non-text portions of this message have been removed]



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

I prefer tools that do not enforce a process/methodology on me, or dictate a
non-standard approach. Tools that obey UML are OK, but I'd prefer that they
also let me do my own thing occasionally. A #2 pencil, preferably with an
eraser on the other end, seems to be the only tool that totally meets my
requirements. Visio is a high technology version at a much higher price tag.

John

   _____

From: agilemodeling@yahoogroups.com [mailto:agilemodeling@yahoogroups.com]
On Behalf Of Stephen
Sent: Monday, November 09, 2009 3:00 AM
To: agilemodeling@yahoogroups.com
Subject: [AM] UML Modeling tools




Having left Micro Focus last month, means I have left behind the Together
modeling tool too. While I wait for whatever is next, I have started to look
seriously at other modeling products for the first time in ages. As a
result, I was wondering what folk expect from a software modeling tool these
days. What do folk love and hate about the products out there, what do these
tools do well, badly, what should they do, etc?






   _____


avast! Antivirus <http://www.avast.com> : Outbound message clean.


Virus Database (VPS): 091109-1, 11/09/2009
Tested on: 11/9/2009 7:03:53 PM
avast! - copyright (c) 1988-2009 ALWIL Software.




[Non-text portions of this message have been removed]

JD:

The most interesting aspects of agile modeling, and probably the trickiest
to grasp, are the notions of self-organization and the concept of "just
enough".  The former refers to the practice of letting the team decide which of
the agile  practices to use in a particular project. The most common thread
is  probably includes the gathering and prioritizing of requirements,
establishing  an iteration schedule, deciding what requirements will be included
in  each iteration, and handling each iteration as a full  release.
Typically, those requirements having the greatest business value  are tackled as
early in the process as possible. (I usually include those  that pose the
greatest technical risk or degree of difficulty, as well, since  leaving these
for later iterations poses some risk of having to redo what has  already been
done). As far as documentation goes, it's a touchy subject,  since it is
reminiscent of "heavyweight command and control" practices of the  past; there
are those who suggest that a whiteboard and a camera is "just  enough" all
the documentation you'll need.

You'll find that there a quite a few approaches to software development
that are described as "agile", but the two most popular are probably XP
programming and Scrum (and apologies for adherents to the ones not mentioned).

One of the major criticisms of agile methods has been that it's all so much
  "touchy-feely" stuff that has no control, order or discipline. In
practice,  however, this is an illusion, based upon the assumption that the
formal
command  and control-related practices contributed value to the development
process.  Overwhelmingly, these heavyweight practices have been shown to
contribute  more to the "comfort level' of the participants and managers than to
the  successful delivery of software.

Regards,

Pete


In a message dated 11/9/2009 1:24:24 P.M. Pacific Standard Time,
jdavisconsulting@... writes:

New  topic: When you talk about informal whiteboarding sessions I wonder if
there's  an opportunity to formalize those requirement changes, enabling a
connection  for test scripts as well. I've had success using a proficient
scribe (me) on  the modeling tool (Provision Workbench) teamed with a
facilitator to guide the  discussion, capturing new models and changes live in a
workshop format. This  is nice as a webcast too, allowing for remote
participants and a broader  audience. Are people using technology to immortalize
the
decisions that are  being made along the way?




[Non-text portions of this message have been removed]

I recommend the agile books on this page:
http://www.mountaingoatsoftware.com/books as well as the presentation at the
same site.

These sessions are generally focussed on what will be implemented and
delivered in a short time box, typically 2 weeks, not things that won't be
delivered until some time later.

One particularly radical approach is that once the requirements for a user
story are understood via collaboration with the Product Owner, they are
formalized as automated tests that the software must pass in order for the
requirements to be met.  These executable requirements "documentation"
forces everybody to remove ambiguity and resolve differences in
interpretation.  They also serve as regression tests, so unlike other forms
of requirements documentation, it is easy to tell if they reflect reality -
just run them.  Of course, it is important to implement them collaboratively
and incrementally in a human readable way.

Here is a link to a book on how to do that:
http://www.acceptancetesting.info/the-book/

Steven Gordon



On Mon, Nov 9, 2009 at 2:21 PM, jd2home <jdavisconsulting@...>wrote:

>
>
> New topic: When you talk about informal whiteboarding sessions I wonder if
> there's an opportunity to formalize those requirement changes, enabling a
> connection for test scripts as well. I've had success using a proficient
> scribe (me) on the modeling tool (Provision Workbench) teamed with a
> facilitator to guide the discussion, capturing new models and changes live
> in a workshop format. This is nice as a webcast too, allowing for remote
> participants and a broader audience. Are people using technology to
> immortalize the decisions that are being made along the way?
> - JD
>
>
>


[Non-text portions of this message have been removed]

Ha - I remember walking on the Schuylkill Expressway one winter day it closed
for 3 ft of snow. Good times.
Pete, you highlight a core concept in collaboration - getting the right people
in the room is key.  How you determine the "right people" is a topic for another
day.  I do want to say that I can't see leaving any stakeholders in the dark, so
managing expectations deserves special attention in this fluid environment of
Agileness.   Through experience I'm sure I'll better understand the fine line of
"just enough" requirements vs. too much volatile detail.

New topic: When you talk about informal whiteboarding sessions I wonder if
there's an opportunity to formalize those requirement changes, enabling a
connection for test scripts as well. I've had success using a proficient scribe
(me) on the modeling tool (Provision Workbench) teamed with a facilitator to
guide the discussion, capturing new models and changes live in a workshop
format.  This is nice as a webcast too, allowing for remote participants and a
broader audience.  Are people using technology to immortalize the decisions that
are being made along the way?
- JD

--- In agilemodeling@yahoogroups.com, PeteCRuth@... wrote:
>
> Joan:
>
> Joan Davis? Philly Girl? Schuylkill Expressway in heavy snow during rush
> hour? Pat's Steaks? I miss all of it!
>
> I suspect that there's a far better chance of the mechanic having seen  a
> schematic of what's under the hood than has the salesman, for sure. My
> comment was intended to point out that it's a good idea to know which end  of
the
> horse to talk to get the details you need before you start  modeling. Time
> spent modeling high-end requirements that later have to  be reworked or
> discarded in light of discoveries at the lower end is  pretty much wasted.
Agile
> is about achieving the desired objectives with  minimal waste, which I
> think is the most significant aspect of agile methods  that is most frequently
> overlooked or misunderstood by its  detractors.
>
> There are quite a few excellent tomes on the subject of agile modeling, but
>  for starters, I usually recommend a visit to Scott Ambler's agile modeling
> site  at _www.agilemodeling.com_ (http://www.agilemodeling.com)  for a
> quick  and concise summary of what it's all about. Old Hands here can fill you
> in much  better than I can, but IMHO, that's a good place to start.
>
> Welcome aboard! Fasten your seat belt, and keep your hands and arms inside
> the cockpit!
>
> Regards,
>
> Pete
>
>
> In a message dated 11/9/2009 4:22:29 A.M. Pacific Standard Time,
> jdavisconsulting@... writes:
>
> Ouch!  This dialogue leads me to believe there's still a long way to go. I
> hope  Pete's mechanic has at least seen a schematic of what's under the
> hood.
>
>
>
> [Non-text portions of this message have been removed]
>

The transition suggestions have been great.  I'll study up and try to connect
locally for a volunteer or intern role to get some hands on experience.  In
particular I want to know more about "user stories" – the name alone appeals to
me – and see how it differs from what I'm familiar with.  Thank you all
contributing your "voices of experience".

Joan the Enlightened


--- In agilemodeling@yahoogroups.com, "jd2home" <jdavisconsulting@...> wrote:
>
> I'm a Business Systems Consultant specializing in the discovery of business
needs and translation into effective solutions.  A proficiency with workgroup
facilitation and the use of business information modeling techniques (including
UML) brings a consistent robustness to my analysis work. My dilemma is an
inability to find Agile/SCRUM work, without already having direct experience in
those methods.
>
> I'm a trained JAD facilitator, and as early as the mid-90's I was working on
Radical Application Development (RAD), a collaborative prototyping approach
similar to the later Agile and SCRUM methods.  I'm a seasoned resource with
excellent references and a quick study.  Can anyone advise me how I might get my
feet wet on an Agile/SCRUM project?
>

Paul
Such a heart rendering story as this has not passed my ears in many a year. Be
brave and remember that others, like my great uncle, also lived in dire
conditions where they drowned in a mixing tank at the distiller. To my great
uncle's credit he put 6 men and 3 boys in hospital for repeatedly pulling him
out. But alas before they could try for the 7th, his hand slipped below the
surface, ordering 1 more round for all!
8-)


Sent via BlackBerry by AT&T

-----Original Message-----
From: "pauloldfield1" <PaulOldfield1@...>
Date: Mon, 09 Nov 2009 08:42:34
To: <agilemodeling@yahoogroups.com>
Subject: Re: [AM] Need help in drawing use case, activity, and sequence
diagrams.

(responding to Mike)

>> My local has 20 scotch malts available to try, and for the
>> really keen there are a couple of distilleries within 20
>> miles... ("Blair Atholl" and "Edradour")
>
> So what did you do that is so worthy to be sent to heaven
> on earth!!!!

Sent??? It was personal choice.  It has its downsides -
did I mention the 300 mile commute?  But I get to work
from home on occasion, and every weekend is like a full
holiday.

I guess most of us could find a great home if we were prepared
to put up with 300 miles commuting to work.

Paul Oldfield
Capgemini




[Non-text portions of this message have been removed]

And to you, Sir, as well, although a few of your most recent, almost
poetic, comments put me in mind that  you have started without me and are
already a few flagons ahead! It must be those infernal time zones!

Regards,

Pete

In a message dated 11/9/2009 7:31:39 A.M. Pacific Standard Time,
g.wetter@... writes:

Single  Barrel Salute!!!




[Non-text portions of this message have been removed]

Joan:

Joan Davis? Philly Girl? Schuylkill Expressway in heavy snow during rush
hour? Pat's Steaks? I miss all of it!

I suspect that there's a far better chance of the mechanic having seen  a
schematic of what's under the hood than has the salesman, for sure. My
comment was intended to point out that it's a good idea to know which end  of
the
horse to talk to get the details you need before you start  modeling. Time
spent modeling high-end requirements that later have to  be reworked or
discarded in light of discoveries at the lower end is  pretty much wasted. Agile
is about achieving the desired objectives with  minimal waste, which I
think is the most significant aspect of agile methods  that is most frequently
overlooked or misunderstood by its  detractors.

There are quite a few excellent tomes on the subject of agile modeling, but
  for starters, I usually recommend a visit to Scott Ambler's agile modeling
site  at _www.agilemodeling.com_ (http://www.agilemodeling.com)  for a
quick  and concise summary of what it's all about. Old Hands here can fill you
in much  better than I can, but IMHO, that's a good place to start.

Welcome aboard! Fasten your seat belt, and keep your hands and arms inside
the cockpit!

Regards,

Pete


In a message dated 11/9/2009 4:22:29 A.M. Pacific Standard Time,
jdavisconsulting@... writes:

Ouch!  This dialogue leads me to believe there's still a long way to go. I
hope  Pete's mechanic has at least seen a schematic of what's under the
hood.



[Non-text portions of this message have been removed]

JD,

BTW, thanks for actively participating in the thread.

So many newcomers ask a question, and then never respond to clarifying
questions or responses.

Steve


[Non-text portions of this message have been removed]

Single Barrel Salute!!!

On Nov 9, 2009, at 10:30 AM, PeteCRuth@... wrote:

Paul:

What could be better than living where it suits you and working where
you
have the chance to make a real difference? I've always made that
choice and
the commutes that come with it, and adjusted my schedule to avoid the
sticky bits. I raise my glass to you, my friend!

Regards,

Pete


In a message dated 11/9/2009 12:42:56 A.M. Pacific Standard Time,
PaulOldfield1@... writes:

I guess most of us could find a great home if we were prepared
to put up with 300 miles commuting to work.

[Non-text portions of this message have been removed]





[Non-text portions of this message have been removed]

Paul:

What could be better than living where it suits you and working where you
have the chance to make a real difference? I've always made that choice and
the  commutes that come with it, and adjusted my schedule to avoid the
sticky bits. I  raise my glass to you, my friend!

Regards,

Pete


In a message dated 11/9/2009 12:42:56 A.M. Pacific Standard Time,
PaulOldfield1@... writes:

I  guess most of us could find a great home if we were prepared
to put up  with 300 miles commuting to  work.




[Non-text portions of this message have been removed]

Because, reality is that the original conception is never correct.  The only
times it appears so is when "control" does not allow the deltas discovered
between the original conception and what is really needed to be leveraged
during the project because it would be too expensive to redo so much design
and scheduling work.

Up front alignment on goals and vision is absolutely necessary, but delving
any deeper than that is very likely to either:
- be wasted when it has to be redone to deliver what will work better, or,
- be used as an excuse to just deliver the original conception instead of
what would have worked better.

This is knowledge work we are talking about, not manufacturing or
construction.  Thinking that we can get it right the first time without
building some working models and see how they work and what ideas they
inspire from the people who would use it is the kind of hubris that has lead
to the "software crisis".

If the top-down stops at a domain model, so that everybody is aligned on
vision, goals, context and terminology, then the agile way to continue would
be to iteratively define functional slices of the system (in priority order)
as "user stories" to be quickly delivered as working software.  This working
software would then quickly discover misconceptions, miscommunication, and
where seemingly good ideas just do not solve the problems on the ground.
Instead of investing months of detailed design work before discovering this,
we only need the amount of design work required to implement that slice.

There are other benefits, including progress being track more accurately by
delivery of working software instead of reams of paper, and cases where the
working implementation of a fraction of the system can actually be used to
recoup some ROI before the whole project is done.

Implementing each user story will often involve modelling, although because
the latency time between modeling, implementing, testing, delivery and
repair is so short, informal, collaborative whiteboard models are usually
more expedient than permanent models implemented by somebody sitting alone
in a cubicle.

This is the essence of agile modeling - doing just enough collaborative
modelling to get the real job done.  Never modelling for the sake of
modelling.

Steven Gordon, PhD

On Mon, Nov 9, 2009 at 5:19 AM, jd2home <jdavisconsulting@...>wrote:

>
>
> Ouch! This dialogue leads me to believe there's still a long way to go. I
> hope Pete's mechanic has at least seen a schematic of what's under the hood.
> Hey, isn't this the Agile MODELING group?
> My naive perception was that Agile is similar to RUP - iterations targeting
> an alignment of views - Business Owner, Process Owner, System User, System
> Builder, System Implementer - to create usable chunks of prioritized
> functionality.
> "Control" to me is a positive, not a negative, and implies an informed
> team. How can testing and training take place without some interpretation of
> what the system is supposed to do and not do? How do we meet expectations
> without first taking time to define them? How does a project not fail when
> the guy that's writing code without requirements finds a better job? What am
> I missing? - Joan the Naive
>
>
> --- In agilemodeling@yahoogroups.com <agilemodeling%40yahoogroups.com>,
> PeteCRuth@... wrote:
> >
> > Steven:
> >
> > My experience overwhelmingly reflects your view.
> >
> > When I hear a strange noise in my car's engine compartment while driving,
> I
> > take it to a mechanic, not a salesman. The top-level requirements provide
>
> > guidelines and boundaries, but the implementation is in the lower-level
> > details. Unless there is a compelling reason for building requirement
> models
> > up front (like a mandate from management), I don't spend any time on
> them.
> > On the other hand, it's not difficult to understand why some feel that
> > requirements models are an important part of the process. They serve as a
> window
> > on the process for those who need the feel of control; the subsequent
> > thrashing about reconciling the details with their overview gives them
> the
> > impression that "things are really happening now!"
> >
> > I have had some exceptions to this, and they were related to "blue sky"
> > projects, those for which no details were yet available. Even in these
> cases,
> > however, once I knew what ballpark we were in, the working code became
> the
> > model. This might sound like an oversimplification, or even blasphemy, to
>
> > some, but in my view, working code trumps everything else.
> >
> > Regards,
> >
> > Pete
> >
> >
> > In a message dated 11/7/2009 9:45:51 A.M. Pacific Standard Time,
> > sgordonphd@... writes:
> >
> > My experience leads me to believe that no matter how good a job we do of
> > eliciting requirements top-down, the rubber does not meet the road when
> it
> > comes time to implement.
> >
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
>  _
>


[Non-text portions of this message have been removed]