Posts Tagged ‘Agile’

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….

Can a SOA be created using Agile methods?

Tuesday, October 30th, 2007

A friend pointed out an interesting blog called RUP versus Agile for SOA Methodology by Eric Roch.  The initial premise seemed to be that Agile methodologies don’t provide enough structure to build a SOA.  My initial belief was that he misunderstood what was meant by agile methodologies.  He referenced extreme programming (XP) as his example of an agile methodology.  Granted, XP would not be my first choice for putting together a SOA either.  That really isn’t it’s purpose.  However, XP certainly can be used to create web services for the SOA.

He goes on to state that a lightweight version of RUP could be fabricated to provide design “deliverables”.  By deliverables, he means the structure and design used to enforce a set of standards across the SOA.  He does point out that, “RUP’s iterative nature and focus on architecture early in the process are well-suited for SOA.”  The key according to Mr. Roch is to keep the process lightweight and iterative.  What really struck me as fascinating is that is exactly the purpose behind OpenUP.  OpenUP is a lightweight version of RUP that is highly compatible with Agile development techniques.  Of course, OpenUP won’t really deal with the enterprise architecture requirements of the SOA either unless that is part of the architectural constraints of the various projects within the SOA.

Basically, Mr. Roch is treating a SOA as a single project rather then a series of projects build over a period of time by different groups who are experts only within the varying domains of the SOA.  An overarching architecture needs to be in place to define the domains and the governance processes and ensure that it meets its potential.  Otherwise, all the process in the world applied to individual projects will leave the business with nothing more then disjointed and conflicting web services.   The reality is, the problem he is trying to resolve has nothing to do with Agile vs non-Agile.  It is all about SOA architecture and governance.  Agile methodologies work well within that framework.  In fact, it is reasonable to assume that since one of the promises of SOA is the ability to respond quickly to changing business needs, that Agile methodologies are the perfect complement for a SOA.

Unfortunately, Mr. Roch is unfamiliar with the benefits of using a lightweight process framework like OpenUP to drive agile development.  I think if he was more aware of the benefits, he would see that using OpenUP and Agile development could be a win-win for the development teams creating the underlying services that make up the SOA and the architects trying to enforce the governance.