Project 31-A

On the way home from ProductCamp Vancouver, we got discussing the increasing division of product development into smaller and smaller cubicles – each with a hyper specialized individual in it. Back in 1979, I had my first professional employee - then consulting gig. Technically I reported to the head of IT. My customer was a department head managing a 30+ employee group. I meet directly with the department head, his reports and the clerks that would use the application (an interactive system using CICS running on a big IBM 4331 –2 megabytes of memory!!). I did UX mockups and reviewed them. Shadowed the clerks. Refine the requirements. Then I proceed to write the specifications. After that I proceed to design the database and implement (create a relational database using ISAM – not a trivial feat). Then coded up the application in COBOL and tested it (did QA too!). Then it was passed over to user acceptance. Finally, writing up documentation for users as well as design documentation...

This weekend I attend Product Camp Vancouver . Some talks were interesting (review of information that I already know), some were so-so (or worst), and others were good “reference card” session such as the one on UX (User Experience). One of the impressions that I had was that product development is becoming a tower of Babel with everyone using in-vogue phrases scattered in each language (or pidgin language). A common frustration was poor communications with others in the team (UX Product Manager – Architecture – Development).   One of the most interesting talks (with a small attendance) was a pragmatic talk about how far does Agile Development scales. The concept of agile development is well known, but we are seeing terms like ‘agile architecture’ and ‘agile product management’ being tossed around. Often they seem to be used as excuse for not doing their homework.  An agile product management means that the architect must be agile – agile to the point of being continuousl...