Posts Tagged ‘process’

A Little Too Incremental – Part Duex

Friday, November 30th, 2007

I was having Thanksgiving dinner with my sister.   My sister comments that she read my A little too incremental blog and thought it was pretty funny.  (I guess that is why I was still invited to Thanksgiving dinner).  She didn’t think it was accurate, though.

So, the conversation went as follows:

Her:  I read your blog the other day.

Me: Was it okay?

Her:  Well, it didn’t put me in the best light, but it was pretty funny!

Me:  Well, if it makes you feel any better, more then 1 person asked me if you wanted a job.

Her: Really?  It’s a shame I don’t live closer.  I did have 1 problem with the blog?

Me:  Problem? oh.  What was that?

Her:  It wasn’t very accurate.

Me:  Well, you know, it may not have been word for word, but I tried to get the gist of the conversation right.

Her:  No, you don’t understand.  It’s far worse then you portrayed.

Me:  What?

Her:  Really. I’m on the data modeling team.  We used to be part of the various development teams, but they kicked us off.

Me:  Huh?

Her:  They kicked the data modelers off of the teams.  Apparently we ask too many questions to be agile.

Me:  Too many questions?  What kind of questions?

Her:  You know.  Things like, “What type of data are you capturing for that object?”,  “What is the max length of that string?”, “Aren’t an employee, customer, client, and user all variations of a ‘person’.  Shouldn’t we be capturing a subset of the same data for each so that we can have some code re-use and give the data warehouse folks common data to search on?”.

Me:  Troublemaker!

Her:  So, now we aren’t allowed on the development teams.  We have to wait until they make changes to their copies of the database, then bring them back and reverse engineer the changes to figure out what they did.  Once we figure that out, we can start working on the business intelligence tasks.

Me:  So, let me get this straight, you need to reverse engineer the database to figure what is being done.  Since each team is doing this on their own, you could get conflicting changes, and…

Her: Oh, we have conflicting changes all the time.  We give them to our boss and he calls the lead for the affected development teams to get resolution.

Me:  Well, at least that sounds like it functions well.

Her: Actually, that is why we are on iteration 4 while they are on iteration 34.

A Little Too Incremental

Monday, November 19th, 2007

I was talking with my sister last night.  The usual stuff, “How’s the family, how’s work…”

As it turns out she is looking for a job.  I asked why.  She stated that her company (which develops COTS and then offers services to customize) was up against a wall.  They had been promising a product (I think she said “for years”) and had a deliverable due in December.  She said that there was no chance of hitting that deadline.

We had a conversation similar to the following:

Me: (Knowing they adopted RUP about 1.5 years ago) That’s rough.  Where are you in the process?

Her: Oh, I’m following my process!

Me: (thinking “My process? hmmm…”) No, what phase are you in?

Her: Phase?  No, I use ClearCase when I need to and ClearQuest when I need to.  I’ve got that down.

Me: (Starting to understand why the project is having issues)  So, you’re not following an iterative process?

Her: Sure we are — we iterate all over the place.  My team is in iteration 4, while the development team is on iteration 32.  We tend to be behind ’cause they keep making changes and we need to catch up.

Me:  Ok, so you are following an iterative process, but not necessarily RUP?

Her:  No, its RUP, well lately everything has been agile?

Me: (wondering if my sister has suddenly developed blonde roots) Agile?  Well, that is good.  Then at least you’ll have something to deliver in December.  It may not be everything, but there will be something.

Her: No, it’s a mess.  All we do is go to meetings every morning.

Me: Oh, scrum meetings? good for you!  What do you think of Scrum?

Her: It stinks!

Me: Ummm, ok?  But you have a daily scrum in the morning for 15 minutes – what did you do, what are you going to do,etc…

Her:  Yep, that’s the one.

Me: Great! So the team got together and decided what parts of the project can be delivered for this sprint, you’ve got 2 sprints by the end of December, sounds promising!

Her: Sprint?  The whole team never gets together to decide anything. My team just meets in the morning.

Me: Oh, so this is a big project?  You meet with your team and your scrum master then meets to have a scrum of scrums with the other leads.

Her: Its about 80 people.  I don’t think my boss has ever met with the other team leads – well, since maybe July.  He’s got a list of stuff to do and he tells us when to do it.  When things don’t work with what the other teams develop we have to go back and fix it.

Me: Alrightly then, let me know if you need help with your resume….

DoDAF and RUP — The Department of Redundancy Department?

Monday, July 30th, 2007

I’m currently the architect on a project that is heavily RUP (Rational Unified Process) centric.  As we are pushing through the government’s C&A (Certification and Accreditation) process, the government project manager “found out” that the project must comply with the DoDAF (Department of Defense Architecture Framework).  This was a little bit of a surprise since you would normally expect this type of requirement to pop up somewhere closer to Inception.  But, here we are, so the goal is to meet the requirement without having to recreate the architecture and design that has been developed under the Rational Unified Process.

DoDAF is a framework that is designed to handle almost anything that the Department of Defense may need to acquire/build.  It provides no methodology – just “views” of the enterprise.  These views are broken into 3 categories (Operational, Systems, Technical Standards) as well as the ominous sounding “All View”.  These “views” are, in fact, a series of documentation and diagrams used to provide insight onto the project from a particular perspective.

RUP is a process for building applications.  It can be seen as a set of best practices to help ensure that the project will meet the customer’s needs.  It includes its own set of documentation (UML) for accomplishing the same goals as DoDAF.  So, my initial reaction was that this was going to be a major exercise in being redundant.

The good news is that it is not turning out to be the case at all.  RUP employs UML to model the application.  DoDAF does not specify UML, but considers UML to be an acceptable method for completing many of the views.  So, much of the work is done.  Obviously, it would have been better to have employed the DoDAF with RUP from the beginning and keep everything in sync.  Given that the both use UML, it would be fairly straightforward to follow the RUP process while complying with DoDAF without much additional work.

Some interesting links on the topic:

http://www.ibm.com/developerworks/rational/library/mar06/widney/index.html

ftp://ftp.software.ibm.com/software/rational/web/whitepapers/G507-1903-00_v5_LoRes.pdf.