[AM] A small success and a large irony

The success

Earlier in January I was working with a team of business analysts, managers, and technical people to develop a new requirements definition process for their business area, and solve some general communication problems between IS and the business community.  It’s a continuing contract with this Fortune-200 company in New York City.  

During the meetings, one of the women who works for the “VP of Brokers”, described a problem they were having with the brokers taking too much time to return opt-in responses for broker clientele for mass mailings the company was doing for new products.  To illustrate the point of Agile Modeling, I drew Use Cases on the white board to help me understand the problem and process she was describing.  Then we drew another set of Use Cases to describe a possible solution.  We sketched out a couple of screens on another white board. It was a group effort.  It was unplanned.  At the end of the 2-3 hour session, we had created a solution to the problem that would essentially solve the problem without introducing any new issues.  Since we had two programmers in the room, I asked if they had enough information from the discussion and the diagrams to write the code to implement the solution.  They said they did and began to throw out some code. They worked together, but not by direction, simply because it was convenient to do so.  IOW it wasn’t intentionally pair programming.  The rest of us went on to other things while they coded.  At the end of the day they had a prototype that the lady reviewed and approved at her level.  The entire team was impressed.  The lead guy started writing down the steps we took to document the process for implementation in other projects and assignments.  You can’t get more agile than that – an impromptu process created to solve a problem.  When the group suggested documenting what was on the board, I asked if the programmers needed it anymore.  They said they did not.  I pointed out that the code was working and had only to be implemented in production code to be real.  The models we created were of no further value and would simply be a waste of time to document them. Everyone agreed, and we did the Agile Modeling thing.

The Irony.

We didn’t immediately erase the board.  The lead guy needed to copy the model and the diagrams and other markings to provide supporting documentation for his process proposal that would suggest non-persistent modeling techniques, and to help him remember all the steps.  The lady, whose problem we solved, copied the model and diagrams and other markings so she could fully explain the solution to her managers and others.  One of the programmers copied down the model and the diagrams and other markings to have documentation for the programming manager and maintenance team while the other continued to test the code they had produced. And I copied down the model and diagrams and other markings partly to provide a physical record of my activities for the suits, but mostly because I anticipated, from the earlier project we discussed in this forum that there would be a number of down line users (150,00 brokers to start with) of this product who would need to be informed about the new changes that were about to be made to their system.  I figured the documents we put on the board would provide the basis for a notification to the users of the changes made.  An agile model that purportedly should be tossed out rather than documented, was actually documented four times for four different reasons including by the person advocating reduced documentation!  
I’m not sure how the Official Agile Modelers would have handled the situation, since it wasn’t really an Agile Modeling session; I simply took advantage of the opportunity to demonstrate in real-time what the process might be like.  I was, and still am, terribly amused at the scrambling to copy the white boards before the janitorial staff came in to clean them (public conference rooms – nothing allowed to stay on white boards or flip charts even when the same group is coming back the next say – it’s a security thing I believe).  I was more amused that I joined in on the documenting – for entirely valid and completely reasonable motives, of course.  
It is unlikely this process will ever be repeated, even with the Lead guy documenting it for posterity and reuse, so the entire thing, including the 4-way documentation, was done agilely – at least in the adaptive process approach – in that we only did what was necessary, or what we felt was necessary.  No one documented without a purpose.  

- steve

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: [email protected]

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: [email protected]

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------