Discussion:
[AM] an anecdote about diagrams
Barr Bill P
2004-02-27 15:56:55 UTC
Permalink
Yesterday, I was in a meeting with some business sponsors who needed a
better way to reconcile receipts. The current process is largely manual due
to the paper-based nature of the incoming data. To their credit, they
provided a detailed workflow diagram of what they thought they wanted based
on how they currently perform the process. The goal was to eliminate some
redundant data entry currently performed for reporting.

After they explained the process, I asked a lot of questions like "Why?",
"What do you do with the results?", "What kind of data do you need to see?",
etc. I also started at the last step of the process and worked forward.

During the discussion, the flowchart quickly became a mess and people were
getting confused about the notation. I then asked for a description of one,
straight-line task with no variations, end-to-end in a perfect world. Using
only arrows and boxes, we came up with 5 parallel chains with a lot of
redundancy. We then identified all the common elements and I showed them how
to draw a simple UML activity diagram by starting with a few elements and
explaining the notation for synchronization, decision points and swim lanes.
With minimal guidance, they finished up their desired workflow in about 10
minutes PLUS they easily identified how they could eliminate a further 3
manual steps. They also noted how one iteration was self-correcting and we
were able to eliminate one step in the auditing process.

I did construct a use-case diagram, initially, for my own benefit. However,
during the session it became apparent that the activity diagram with swim
lanes was much more descriptive and functional. It's pretty clear to all
involved that the use-case diagram was a nice springboard, but the activity
diagram will persist as permanent documentation and is going to be included
in the training manual.

After the meeting, one of the program managers asked if I would be willing
to train some of her peers how to "draw that new flowchart you used."
--
Bill Barr

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
--^----------------------------------------------------------------
Paul Oldfield
2004-02-27 21:03:42 UTC
Permalink
(responding to Bill)
Post by Barr Bill P
After the meeting, one of the program managers asked if
I would be willing to train some of her peers how to "draw
that new flowchart you used."
Nice story, Bill.

I can't help feeling that the really valuable thing would be
having a set of tools (diagrams) to work with, and the ability
to choose the appropriate one, rather than just learning
the one that was useful *this time*.


Paul Oldfield.

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
--^----------------------------------------------------------------
Scott Ambler
2004-02-28 02:32:20 UTC
Permalink
Gotta start somewhere.

- Scott
Post by Paul Oldfield
(responding to Bill)
Post by Barr Bill P
After the meeting, one of the program managers asked if
I would be willing to train some of her peers how to "draw
that new flowchart you used."
Nice story, Bill.
I can't help feeling that the really valuable thing would be
having a set of tools (diagrams) to work with, and the ability
to choose the appropriate one, rather than just learning
the one that was useful *this time*.
Paul Oldfield.
For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
====================================================
Scott W. Ambler
Senior Consultant, Ronin International, Inc.
www.ronin-intl.com/company/scottAmbler.html

www.agiledata.org
www.agilemodeling.com
www.ambysoft.com
www.enterpriseunifiedprocess.info
www.modelingstyle.info
www.ronin-intl.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
--^----------------------------------------------------------------
Scott Ambler
2004-02-28 10:57:55 UTC
Permalink
<snip>
During the discussion, the flowchart quickly became a mess and people were
getting confused about the notation. I then asked for a description of
one, straight-line task with no variations, end-to-end in a perfect world.
Using only arrows and boxes, we came up with 5 parallel chains with a lot
of redundancy. We then identified all the common elements and I showed
them how to draw a simple UML activity diagram by starting with a few
elements and explaining the notation for synchronization, decision points
and swim lanes. With minimal guidance, they finished up their desired
workflow in about 10 minutes PLUS they easily identified how they could
eliminate a further 3 manual steps. They also noted how one iteration was
self-correcting and we were able to eliminate one step in the auditing process.
Seems to be a pretty clear case of knowing your models, applying the right
artifacts, modeling with others, and using the simplest tools (I'm assuming
you started the sketches on a whiteboard) in action. In this case the
primary skill was to know that some sort of process model (e.g. a data flow
diagram, a flow chart, or in this case a UML activity diagram) was needed
and then working together to do it.
I did construct a use-case diagram, initially, for my own benefit.
However, during the session it became apparent that the activity diagram
with swim lanes was much more descriptive and functional. It's pretty
clear to all involved that the use-case diagram was a nice springboard,
but the activity diagram will persist as permanent documentation and is
going to be included in the training manual.
Yes, some diagrams prove themselves to be valuable whereas other don't. In
other situations you could just as easily found that the activity diagram
wasn't sufficiently valuable and thus you would decide to discard it after use.
After the meeting, one of the program managers asked if I would be willing
to train some of her peers how to "draw that new flowchart you used."
My advice would be to keep it simple. They might find
http://www.agilemodeling.com/artifacts/activityDiagram.htm and perhaps
http://www.modelingstyle.info/activityDiagram.html to be of interest.

- Scott

====================================================
Scott W. Ambler
Senior Consultant, Ronin International, Inc.
www.ronin-intl.com/company/scottAmbler.html

www.agiledata.org
www.agilemodeling.com
www.ambysoft.com
www.enterpriseunifiedprocess.info
www.modelingstyle.info
www.ronin-intl.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
--^----------------------------------------------------------------
Loading...